teleport Documentation

1. Project Overview & Quickstart (gravitational/teleport) Copy Chapter

File: README.md Copy Chapter

Teleport provides connectivity, authentication, access controls and audit for
infrastructure.

You might use Teleport to:

• Set up single sign-on (SSO) for all of your cloud and on-prem
  infrastructure.
• Protect access to servers, Kubernetes clusters, databases, Windows
  desktops, web applications, and cloud APIs without long-lived keys or
  passwords.
• Establish secure tunnels to reach resources behind NATs and firewalls
  without VPNs or bastion hosts.
• Record and audit activity across SSH, Kubernetes, database, RDP, and web
  sessions.
• Apply consistent Role-Based and Attribute-Based Access Control (RBAC/ABAC)
  across users, machines, workloads, and resource types.
• Enforce least privilege and Just-in-Time (JIT) access requests for
  elevated roles or sensitive systems.
• Maintain a single identity and access layer for both human users and
  workloads.

Teleport works with SSH, Kubernetes, databases, RDP, cloud consoles,
internal web services, Git repositories, and Model Context Protocol (MCP)
servers.

More Information Copy Chapter

Teleport Getting Started
Teleport Architecture
Reference Guides
FAQ

Table of Contents Copy Chapter

1. Introduction
2. Why We Built Teleport
3. Supporting and Contributing
4. Installing and Running
5. Docker
6. Building Teleport
7. License
8. FAQ

Introduction Copy Chapter

Teleport includes an identity-aware access proxy, a CA that issues short-lived
certificates, a unified access control system, and a tunneling system to access
resources behind the firewall.

Teleport is a single Go binary that integrates with multiple protocols and
cloud services, including

• SSH nodes
• Kubernetes clusters
• PostgreSQL, MongoDB, CockroachDB and MySQL
  databases
• Model Context Protocol
• Internal Web apps
• Windows Hosts
• Networked servers

You can set up Teleport as a Linux
daemon
or a Kubernetes
deployment.

Teleport focuses on best practices for infrastructure security, including:

• No shared secrets such as SSH keys or Kubernetes tokens; Teleport uses
  certificate-based auth with automatic expiration for all protocols.
• Multi-factor authentication (MFA) for everything.
• Single sign-on (SSO) for everything via GitHub Auth, OpenID Connect, or
  SAML with endpoints like Okta or Microsoft Entra ID.
• Session sharing for collaborative troubleshooting for issues.
• Infrastructure introspection to view the status of every SSH node, database
  instance, Kubernetes cluster, or internal web app through the Teleport CLI
  or Web UI.

Teleport uses Go crypto. It is
fully compatible with OpenSSH, sshd servers, and ssh clients,
Kubernetes clusters and more.

Why We Built Teleport Copy Chapter

While working together at Rackspace, the creators of Teleport noticed that
most cloud users struggle with setting up and configuring infrastructure
security. Many popular tools designed for this are complex to understand and
expensive to maintain across modern, distributed computing infrastructure.

We decided to build a solution that's easy to use, understand, and scale. A
real-time representation of all your servers in the same room as you, as if
they were magically teleported. And thus, Teleport was born!

Today, Teleport is trusted by everyone from hobbyists to hyperscalers to
simplify security across cloud CLIs and consoles, Kubernetes clusters, SSH
servers, databases, internal web apps, and Model Context Protocol (MCP) used
by AI agents.

Learn more about Teleport and our history

Supporting and Contributing Copy Chapter

We aim to make Teleport easy to adopt and contribute to, starting with clear and comprehensive documentation.

If you have questions, are exploring ideas, or want to sanity-check something, please start with a GitHub Discussion. Discussions help us answer questions, explore use cases, and decide together whether something should become a bug report or feature request.

• Start a conversation in Teleport Discussions
  This is the best place to ask questions, share ideas, and get help. Our engineers actively participate there, and discussions can be promoted to issues when there is a clear, actionable next step.

• Issues are for confirmed bugs and well-defined feature requests
  If something has already been validated as a bug or an enhancement, feel free to open an issue. When in doubt, start a discussion and we will help guide it.

• Enterprise and POC support
  If you are evaluating Teleport Enterprise or need more responsive support during a POC, we can set up a dedicated Slack channel. You can reach out to us through our website to get started.

Installing and Running Copy Chapter

To set up a single-instance Teleport cluster, follow our getting started
guide.
You can then register your servers, Kubernetes clusters, and other
infrastructure with your Teleport cluster.

You can also get started with Teleport Enterprise Cloud, a managed Teleport
deployment that makes it easier to enable secure access to your
infrastructure.

Sign up for a free trial of Teleport
Enterprise Cloud, and follow this guide to register your first
server.

Docker Copy Chapter

Deploy Teleport Copy Section

If you wish to deploy Teleport inside a Docker container see the
installation guide.

For Local Testing and Development Copy Section

To run a full test suite locally, see the test dependencies
list

Building Teleport Copy Chapter

The teleport repository contains the Teleport daemon binary (written in Go)
and a web UI written in TypeScript.

If your intention is to build and deploy for use in a production infrastructure
a released tag should be used. The default branch, master, is the current
development branch for an upcoming major version. Get the latest release tags
listed at https://goteleport.com/download/ and then use that tag in the git clone. For example git clone https://github.com/gravitational/teleport.git -b v18.5.0 gets release
v18.5.0.

Dockerized Build Copy Section

It is often easiest to build with Docker, which ensures that all required
tooling is available for the build. To execute a dockerized build, ensure
that docker is installed and running, and execute:

make -C build.assets build-binaries

This command will build Linux binaries matching the host architecture.
It is not possible to cross-compile to a different target architecture.

Local Build Copy Section

Dependencies

The following dependencies are required to build Teleport from source. For
maximum compatibility, install the versions of these dependencies using the
versions listed in build.assets/versions.mk:

1. Go
2. Rust
3. Node.js
4. libfido2
5. pkg-config

For an example of dev environment setup on macOS, see these
instructions.

Perform a build

Important

• The Go compiler is somewhat sensitive to the amount of memory: you will
  need at least 1GB of virtual memory to compile Teleport. A 512MB
  instance without swap will not work.

• This will build the latest version of Teleport.

Get the source

git clone https://github.com/gravitational/teleport.git
cd teleport

To perform a build

make full

tsh dynamically links against libfido2 by default, to support development
environments, as long as the library itself can be found:

$ brew install libfido2 pkg-config  # Replace with your package manager of choice

$ make build/tsh
> libfido2 found, setting FIDO2=dynamic
> (...)

Release binaries are linked statically against libfido2. You may switch the
linking mode using the FIDO2 variable:

make build/tsh FIDO2=dynamic # dynamic linking
make build/tsh FIDO2=static  # static linking, for an easy setup use `make enter`
                             # or `build.assets/macos/build-fido2-macos.sh`.
make build/tsh FIDO2=off     # doesn't link libfido2 in any way

tsh builds with Touch ID support require access to an Apple Developer
account. If you are a Teleport maintainer, ask the team for access.

Build output and run locally

If the build succeeds, the installer will place the binaries in the build
directory.

Before starting, create default data directories:

sudo mkdir -p -m0700 /var/lib/teleport
sudo chown $USER /var/lib/teleport

Running Teleport in a hot reload mode

To speed up your development process, you can run Teleport using
CompileDaemon. This will
build and run the Teleport binary, and then rebuild and restart it whenever
any Go source files change.

1. Install CompileDaemon:

   shell Copy

   go install github.com/githubnemo/CompileDaemon@latest

   Note that we use go install instead of the suggested go get, because
   we don't want CompileDaemon to become a dependency of the project.

2. Build and run the Teleport binary:

   shell Copy

   make teleport-hot-reload

   By default, this runs a teleport start command. If you want to
   customize the command, for example by providing a custom config file
   location, you can use the TELEPORT_ARGS parameter:

   shell Copy

   make teleport-hot-reload TELEPORT_ARGS='start --config=/path/to/config.yaml'

Note that you still need to run make grpc if you
modify any Protocol Buffers files to regenerate the generated Go sources;
regenerating these sources should in turn cause the CompileDaemon to rebuild
and restart Teleport.

Web UI Copy Section

The Teleport Web UI resides in the web directory.

Rebuilding Web UI for development

To rebuild the Teleport UI package, run the following command:

make docker-ui

Then you can replace Teleport Web UI files with the files from the
newly-generated /dist folder.

To enable speedy iterations on the Web UI, you can run a local web-dev
server.

You can also tell Teleport to load the Web UI assets from the source
directory. To enable this behavior, set the environment variable DEBUG=1
and rebuild with the default target:

# Run Teleport as a single-node cluster in development mode:
DEBUG=1 ./build/teleport start -d

Keep the server running in this mode, and make your UI changes in /dist
directory. For instructions about how to update the Web UI, read the web
README.

Managing dependencies Copy Section

All dependencies are managed using Go
modules. Here are the
instructions for some common tasks:

Add a new dependency

Latest version:

go get github.com/new/dependency

and update the source to use this dependency.

To get a specific version, use go get github.com/new/dependency@version instead.

Set dependency to a specific version

go get github.com/new/dependency@version

Update dependency to the latest version

go get -u github.com/new/dependency

Update all dependencies

go get -u all

Debugging dependencies

Why is a specific package imported?

go mod why $pkgname

Why is a specific module imported?

go mod why -m $modname

Why is a specific version of a module imported?

go mod graph | grep $modname

License Copy Chapter

Teleport is distributed in multiple forms with different licensing
implications.

The Teleport API module (all code in this repository under /api) is
available under the Apache 2.0 license.

The remainder of the source code in this repository is available under the
GNU Affero General Public License. Users compiling Teleport
from source must comply with the terms of this license.

Teleport Community Edition builds distributed on
http://goteleport.com/download are available under a modified Apache 2.0
license.

FAQ Copy Chapter

Is Teleport production-ready? Copy Section

Yes, Teleport is production-ready and used to protect and facilitate
access to the most precious and mission-critical applications at many of
today's leading companies. You can learn more about the companies using
Teleport in production on our website.

Is Teleport secure? Copy Section

Yes, Teleport has completed several security audits from nationally and
internationally recognized technology security companies. We publicize
audit results, our security philosophy, and related information on our
trust page.

What resources does Teleport support? Copy Section

Teleport secures access to a broad set of infrastructure
resources, including Linux
servers, Windows desktops, Kubernetes clusters, databases, internal web
applications, cloud provider APIs and consoles (such as AWS, Azure, and
GCP), and Model Context Protocol (MCP) servers used by AI agents.

How is Teleport deployed? Copy Section

Teleport can be deployed to fit most
environments,
either as a self-hosted cluster on Linux or Kubernetes or using Teleport
Enterprise Cloud. In all cases, Teleport agents run close to your
resources and connect through an Auth Service and Proxy Service that
enforces identity, access control, and audit.

Is Teleport an identity provider (IdP)? Copy Section

Teleport uses existing IdPs (Okta, Google Workspace, Microsoft Entra ID,
or GitHub) to issue short-lived certificates and apply access policies.
Teleport can also be configured to act as a SAML
IdP to authenticate
users into applications when needed.

Does Teleport require credential handling or secrets management? Copy Section

Teleport eliminates long-lived passwords, SSH keys, database credentials,
credential rotations, and vault processes by issuing short-lived,
auto-expiring mTLS and SSH
certificates
bound to human or non-human identity.

Is Teleport a Privileged Access Management (PAM) solution? Copy Section

Teleport provides modern PAM software capabilities like strong
authentication, session recording, policy-based access, and JIT elevation
without secrets, credential rotation, or vault dependencies. This enables
controlled, audited access to servers, Kubernetes, databases, cloud
consoles, and other privileged environments using short-lived certificates
and role-based policies.

Is Teleport a Just-in-Time (JIT) access solution? Copy Section

Teleport enables JIT access through time-bound Access
Requests.
Users request the roles or resources they temporarily need, policies decide
whether approval is required, and privileges automatically expire. This
approach maintains least privilege while keeping access workflows
efficient and predictable.

Does Teleport secure access to Kubernetes? Copy Section

Teleport can proxy and secure Kubernetes
access
with identity-based authentication, role-based access controls, and
detailed auditing of kubectl activity.

Does Teleport support SPIFFE? Copy Section

Teleport supports SPIFFE-compatible identities for
workloads,
allowing it to participate in SPIFFE ecosystems and federation.
Teleport issues short-lived SVIDs and can integrate with external PKI
hierarchies.

Is Teleport an alternative for VPNs or bastion hosts? Copy Section

Yes. Teleport is frequently used as an alternative to traditional VPNs
and bastion hosts, enabling direct, identity-based access to
resources
instead of broad network access.

Does Teleport secure the Model Context Protocol (MCP) and AI agents? Copy Section

Teleport secures MCP
connections
by placing identity-aware policy enforcement between MCP clients and
servers. This ensures all tool invocations are authenticated, authorized,
and audited without custom authorization code and that sensitive systems
are protected from overly broad access.

File: docs/README.md Copy Chapter

Teleport Docs

Teleport docs are built using Docusaurus. Please see
the README in the docs-website repo
for details on how to make and test changes to Teleport docs.

2. Official Technical Reference & Guides (gravitational/docs-website) Copy Chapter

Website

This a port of the Teleport docs from the original custom engine to Docusaurus.

Installation Copy Chapter

$ yarn

Initialize content modules Copy Chapter

This loads the Teleport content branches that are used in the versions.

$ cp .gitmodules.example .gitmodules
$ yarn git-update

Local Development Copy Chapter

$ yarn dev

This command starts a local development server and opens up a browser window. Most changes are reflected live without having to restart the server.

Running in Docker Copy Chapter

The run-docker.sh script requires a semver as an argument. For example, to develop locally and have your changes appear in the 19.x branch, run:

$ ./run-docker.sh 19.x

For the example above, you can view your changes at http://127.0.0.1:3000/ver/19.x/

If you already have a service using local port 3000, modify the LOCAL_PORT value in the run-docker.sh script to an unused port.

Most changes should also display live; sometimes the filesystem watcher is a little slow, sometimes it is not.

Build Copy Chapter

$ yarn build

This command generates static content into the build directory and can be served using any static contents hosting service.

Deployment Copy Chapter

Deployment happens automatically to commits to the main branch. Deploy is woriking thought AWS Amplify.

Settings for AWS Amplify are following:

1. nodejs 20 and yarn v1.22.22.
2. Build command yarn build
3. Build results folder build
4. Following env variables should be set: INKEEP_API_KEY, YOUTUBE_API_KEY
5. This variable should be set increase nodejs memory NODE_OPTIONS=--max-old-space-size=8192
6. Add the following redirect to make 404 work:
   • Source address: /<*>
   • Target address: /404.html
   • Type 404 (Rewrite)

Architecture overview Copy Chapter

Current setup is made with the goal to make this project backward compatible with the original docs engine so they can run in parallel until transition period is not over.

To make it possible, we convert content from the orginal format to the Docusaurus format at the build time and also use some of the orignal plugins.

How it works under the hood:

1. We store docs in the git submodules of the main teleport repo as in the original setup. Submodules are fetched inside content folder to the subfolders named after the teleport versions 15.x, 16.x, etc. Then we build the docs we update submodules to the latest version.
2. Info about versions, their status and original branches are manually added to the config.json file. See version config description below.
3. To make old docs work with Ducsaurus we need to move files to correct location and also generate a bunch of config files. To do it we use scripts/prepare-files.mts file. It does the following based on config.json content:
   1. Move mdx files, except includes to the versioned_docs/version-{name} folder for the non-current versions.
   2. Move mdx files, except includes to the docs folder for the current version.
   3. Create versioned_sidebars/version-{name}-sidebars.json configs for sidebars of the non-current versions.
   4. Create sidebars.json config for sidebar of the current version.
   5. Create versions.json file with the list of non-current versions.
4. To make old docs work with Docusaurus we also need to run them through a bunch of custom plugins:
   1. remark-includes - plugin from the old docs to work with the (!filepath!) syntax.
   2. remark-variables - plugin from the old docs to work with the (=variable=) syntax.
   3. remark-update-asset-paths - this plugn updates paths to the assets from new folders to the content/{version} folders.
   4. remark-update-tags - this plugin replaces custom components used in the old docs to their Docuaaurus alternatives or removes them completely.

Everything else is more or less straightforward Docusaurus code.

Folder structure Copy Section

• content – pre-migration docs content.
• scripts – helper CLI scripts.
• server – code for plugins and config parsing.
• src - frontend-related files.
• src/component – components ported from the old site, mostly header-related.
• src/styles – CSS used in the site header.
• src/theme – overrides for the default theme files of Docusaurus.
• src/utils – client-side utils.
• static - static files for the site: manifests, favicons, etc.
• docs, versioned_docs and versioned_sidebars – folders for Docusaurus site content that will be automatically populated by a script (yarn prepare-files).
• data is a folder for navigation element data.

`config.json` format Copy Section

type Version = {
    name: string; // should be the same as the folder in `content`
    branch: string; // name of the original git branch
    deprecated: boolean; // Unsupported versions
    latest: boolean; // Last officially released version
    current: boolean; // Next version currently in development
}

type Config = {
    versions: Version[]
}

Only non-deprecated versions are built in the docs.

If no versions are marked as current/latest, last version in alphabetical order is marked as it.

CLI commands Copy Section

• yarn git-update – update git submodules.
• yarn prepare-files – copy files from content to folders used by Docusaurus.
• yarn start – start server in dev mode.
• yarn build - buld static site.
• yarn swizzle - used to eject files from the default Docusaurus theme to the src/theme folder. See swizzling.
• yarn serve – server static files.
• yarn typecheck - check types.

For other commands see Docusaurus docs.