teleport
The easiest, and most secure way to access and protect all of your infrastructure.
Top Related Projects
Boundary enables identity-based access management for dynamic infrastructure.
Enterprise VPN server
Mirror of Apache Guacamole Server
Cloudflare Tunnel client (formerly Argo Tunnel)
Quick Overview
Teleport is an open-source, identity-aware access proxy for SSH, Kubernetes, web applications, and databases. It provides secure access to infrastructure across multi-cloud environments, replacing traditional VPNs and SSH key management. Teleport enables teams to implement security best practices like Zero Trust and BeyondCorp models.
Pros
- Unified access for multiple protocols (SSH, Kubernetes, databases, web apps)
- Strong security features including certificate-based authentication and audit logging
- Seamless integration with existing infrastructure and identity providers
- Easy to scale and manage across multi-cloud environments
Cons
- Steeper learning curve compared to traditional SSH/VPN solutions
- Requires changes to existing workflows and infrastructure setup
- May be overkill for small teams or simple environments
- Some advanced features are only available in the enterprise edition
Getting Started
To get started with Teleport, follow these steps:
- Install Teleport:
curl -O https://get.gravitational.com/teleport-v9.0.0-linux-amd64-bin.tar.gz
tar -xzf teleport-v9.0.0-linux-amd64-bin.tar.gz
cd teleport
sudo ./install
- Generate a minimal configuration file:
sudo teleport configure --acme --acme-email=your-email@example.com > teleport.yaml
- Start the Teleport service:
sudo teleport start --config teleport.yaml
- Create a user and generate credentials:
sudo tctl users add myuser --roles=editor,access
- Connect to Teleport using tsh:
tsh login --proxy=teleport.example.com --user=myuser
For more detailed instructions and advanced configurations, refer to the official Teleport documentation.
Competitor Comparisons
Boundary enables identity-based access management for dynamic infrastructure.
Pros of Boundary
- More flexible identity-based access control with fine-grained permissions
- Better integration with HashiCorp ecosystem (Vault, Terraform, etc.)
- Simpler setup and configuration for small to medium-sized deployments
Cons of Boundary
- Less mature and feature-rich compared to Teleport
- Limited support for advanced authentication methods (e.g., hardware tokens)
- Smaller community and ecosystem of third-party integrations
Code Comparison
Teleport configuration example:
teleport:
nodename: example-node
data_dir: /var/lib/teleport
auth_token: secret-token
auth_servers:
- 10.1.0.5:3025
Boundary configuration example:
controller {
name = "example-controller"
database {
url = "postgresql://boundary:boundary@localhost/boundary"
}
public_cluster_addr = "boundary.example.com"
}
Both projects aim to provide secure access to infrastructure, but they differ in their approach and feature sets. Teleport offers a more comprehensive solution with advanced features and broader protocol support, while Boundary focuses on simplicity and tight integration with the HashiCorp ecosystem. The choice between them depends on specific use cases and existing infrastructure.
Enterprise VPN server
Pros of Pritunl
- Simpler setup and configuration process
- More lightweight and resource-efficient
- Better suited for small to medium-sized organizations
Cons of Pritunl
- Limited advanced features compared to Teleport
- Less comprehensive audit logging and compliance capabilities
- Fewer integrations with third-party tools and services
Code Comparison
Pritunl (Python):
def start_server(server, delay=0):
from pritunl import utils
from pritunl import logger
if delay:
logger.info('Delaying server start', 'server',
server_id=server.id,
delay=delay,
)
time.sleep(delay)
Teleport (Go):
func (s *Server) Start() error {
s.Lock()
defer s.Unlock()
if s.started {
return trace.AlreadyExists("server is already started")
}
s.started = true
return nil
}
Both projects use different programming languages, with Pritunl primarily using Python and Teleport using Go. Pritunl's code snippet shows a server start function with a delay option, while Teleport's code demonstrates a more straightforward server start method with error handling. Teleport's implementation appears more robust and thread-safe due to its use of locks and error checking.
Mirror of Apache Guacamole Server
Pros of Guacamole Server
- Provides a clientless remote desktop gateway, accessible through a web browser
- Supports multiple protocols (RDP, VNC, SSH) in a single solution
- Highly extensible with a plugin architecture for adding new protocols
Cons of Guacamole Server
- Requires more setup and configuration compared to Teleport
- Less focus on security auditing and compliance features
- Limited built-in support for modern authentication methods (e.g., SSO, MFA)
Code Comparison
Teleport (Go):
func (s *Server) Start() error {
s.Lock()
defer s.Unlock()
if s.started {
return trace.AlreadyExists("server is already started")
}
s.started = true
return nil
}
Guacamole Server (C):
int guac_client_start(guac_client* client) {
if (client->state != GUAC_CLIENT_WAITING)
return 1;
client->state = GUAC_CLIENT_RUNNING;
return 0;
}
Both examples show server/client start functions, but Teleport uses Go with more robust error handling and locking, while Guacamole Server uses C with simpler state management.
Cloudflare Tunnel client (formerly Argo Tunnel)
Pros of cloudflared
- Simpler setup and configuration for basic use cases
- Tighter integration with Cloudflare's ecosystem and services
- Lightweight and focused on tunneling functionality
Cons of cloudflared
- Limited access control and authentication features compared to Teleport
- Less comprehensive auditing and logging capabilities
- Narrower scope of supported protocols and services
Code Comparison
Teleport configuration example:
teleport:
nodename: example-node
data_dir: /var/lib/teleport
auth_token: secret-token
auth_servers:
- auth.example.com:3025
cloudflared configuration example:
tunnel: example-tunnel
credentials-file: /path/to/credentials.json
ingress:
- hostname: example.com
service: http://localhost:8000
- service: http_status:404
Both projects aim to provide secure access to resources, but Teleport offers a more comprehensive suite of features for access management, auditing, and multi-protocol support. cloudflared, on the other hand, focuses on providing simple and efficient tunneling capabilities, particularly within the Cloudflare ecosystem.
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual CopilotREADME
Teleport provides connectivity, authentication, access controls and audit for infrastructure.
Here is why you might use Teleport:
- Set up SSO for all of your cloud infrastructure [1].
- Protect access to cloud and on-prem services using mTLS endpoints and short-lived certificates.
- Establish tunnels to access services behind NATs and firewalls.
- Provide an audit log with session recording and replay for various protocols.
- Unify Role-Based Access Control (RBAC) and enforce the principle of least privilege with access requests.
[1] The open source version supports only GitHub SSO.
Teleport works with SSH, Kubernetes, databases, RDP, and web services.
- Architecture: https://goteleport.com/docs/architecture/introduction
- Getting Started: https://goteleport.com/docs/getting-started/
Table of Contents
- Introduction
- Installing and Running
- Docker
- Building Teleport
- Why Did We Build Teleport?
- More Information
- Support and Contributing
- Is Teleport Secure and Production Ready?
- Who Built Teleport?
- License
Introduction
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.
We have implemented Teleport as a single Go binary that integrates with multiple protocols and cloud services:
- SSH nodes.
- Kubernetes clusters
- PostgreSQL, MongoDB, CockroachDB and MySQL databases.
- 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:
- No need to manage shared secrets such as SSH keys or Kubernetes tokens: it uses certificate-based auth with certificate expiration for all protocols.
- Two-factor authentication (2FA) for everything.
- Collaboratively troubleshoot issues through session sharing.
- Single sign-on (SSO) for everything via GitHub Auth, OpenID Connect, or SAML with endpoints like Okta or Active Directory.
- Infrastructure introspection: Use Teleport via the CLI or Web UI to view the status of every SSH node, database instance, Kubernetes cluster, or internal web app.
Teleport uses Go crypto. It is fully compatible with OpenSSH, sshd
servers, and ssh
clients, Kubernetes clusters and more.
Project Links | Description |
---|---|
Teleport Website | The official website of the project. |
Documentation | Admin guide, user manual and more. |
Blog | Our blog where we publish Teleport news. |
Forum | Ask us a setup question, post your tutorial, feedback, or idea on our forum. |
Slack | Need help with your setup? Ping us in our Slack channel. |
Cloud-hosted | We offer Enterprise with a Cloud-hosted option. For teams that require easy and secure access to their computing environments. |
Installing and Running
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.
Follow our guide to registering your first server with Teleport Enterprise Cloud.
Docker
Deploy Teleport
If you wish to deploy Teleport inside a Docker container see the installation guide.
For Local Testing and Development
To run a full test suite locally, see the test dependencies list
Building Teleport
The teleport
repository contains the Teleport daemon binary (written in Go)
and a web UI written in Javascript (a git submodule located in the webassets/
directory).
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 v16.0.0
gets release v16.0.0.
Dockerized Build
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
Local Build
Dependencies
Ensure you have installed correct versions of necessary dependencies:
Go
version from go.mod- If you wish to build the Rust-powered features like Desktop Access, see the
Rust
andCargo
versions in build.assets/Makefile (search forRUST_VERSION
) - For
tsh
version >10.x
with FIDO2 support, you will needlibfido2
andpkg-config
installed locally - To build the web UI:
pnpm
. If you have Node.js installed, runcorepack enable pnpm
to makepnpm
available.- If you prefer not to install/use pnpm, but have docker available, you can run
make docker-ui
instead. - The
Rust
andCargo
version in build.assets/Makefile (search forRUST_VERSION
) are required. - The
wasm-pack
version in build.assets/Makefile (search forWASM_PACK_VERSION
) is required. binaryen
(which containswasm-opt
) is required to be installed manually on linux aarch64 (64-bit ARM). You can check if it's already installed on your system by runningwhich wasm-opt
. If not you can install it likeapt-get install binaryen
(for Debian-based Linux).wasm-pack
will install this automatically on other platforms.
For an example of Dev Environment setup on a Mac, 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, regardless of whether it is stable. If you want to build the latest stable release, run
git checkout
andgit submodule update --recursive
to the corresponding tag (for example,- run
git checkout v8.0.0
) before performing a build.
Get the source
git clone https://github.com/gravitational/teleport.git
cd teleport
To perform a build
make full
To build tsh
with Apple TouchID support enabled:
Important
tsh
binaries with Touch ID support are only functional using binaries signed with Teleport's Apple Developer ID and notarized by Apple. If you are a Teleport maintainer, ask the team for access.
make build/tsh TOUCHID=yes
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
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.
-
Install CompileDaemon:
go install github.com/githubnemo/CompileDaemon@latest
Note that we use
go install
instead of the suggestedgo get
, because we don't want CompileDaemon to become a dependency of the project. -
Build and run the Teleport binary:
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 theTELEPORT_ARGS
parameter: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
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
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
Devbox Build (experimental)
Note: Devbox support is still experimental. It's very possible things may not work as intended.
Teleport can be built using devbox. To use devbox, follow the instructions to install devbox here and then run:
devbox shell
This will install Teleport's various build dependencies and drop you into a shell with these dependencies. From here, you can build Teleport normally.
flake.nix
A nix flake is located in build.assets/flake
that allows for installation of Teleport's less
common build tooling. If this flake is updated, run:
devbox install
in order to make sure the changes in the flake are reflected in the local devbox shell.
Why did We Build Teleport?
The Teleport creators used to work together at Rackspace. We noticed that most cloud computing users struggle with setting up and configuring infrastructure security because popular tools, while flexible, are complex to understand and expensive to maintain. Additionally, most organizations use multiple infrastructure form factors such as several cloud providers, multiple cloud accounts, servers in colocation, and even smart devices. Some of those devices run on untrusted networks, behind third-party firewalls. This only magnifies complexity and increases operational overhead.
We had a choice, either start a security consulting business or build a solution that's dead-easy to use and understand. A real-time representation of all of your servers in the same room as you, as if they were magically teleported. Thus, Teleport was born!
More Information
Support and Contributing
We offer a few different options for support. First of all, we try to provide clear and comprehensive documentation. The docs are also in GitHub, so feel free to create a PR or file an issue if you have ideas for improvements. If you still have questions after reviewing our docs, you can also:
- Join Teleport Discussions to ask questions. Our engineers are available there to help you.
- If you want to contribute to Teleport or file a bug report/issue, you can create an issue here in GitHub.
- If you are interested in Teleport Enterprise or more responsive support during a POC, we can also create a dedicated Slack channel for you during your POC. You can reach out to us through our website to arrange for a POC.
Is Teleport Secure and Production-Ready?
Yes -- Teleport is production-ready and designed to protect and facilitate access to the most precious and mission-critical applications.
Teleport has completed several security audits from nationally and internationally recognized technology security companies.
We publicize some of our audit results, security philosophy and related information on our trust page.
You can see the list of companies that use Teleport in production on the Teleport product page.
Who Built Teleport?
Teleport was created by Gravitational, Inc.. We have built Teleport by borrowing from our previous experiences at Rackspace. Learn more about Teleport and our history.
License
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.
Top Related Projects
Boundary enables identity-based access management for dynamic infrastructure.
Enterprise VPN server
Mirror of Apache Guacamole Server
Cloudflare Tunnel client (formerly Argo Tunnel)
Convert designs to code with AI
Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.
Try Visual Copilot