# Teleport: Certificate-Based Access to SSH, Kubernetes and Databases

> Gravitational Teleport replaces long-lived SSH keys and bastion hosts with short-lived certificates issued by its own CA. Here is how the binary is structured, how it installs, and where it stops being the right tool.

**gravitational/teleport** — The easiest, and most secure way to access and protect all of your infrastructure.

- Repository: https://github.com/gravitational/teleport
- Website: https://goteleport.com
- Stars: 20,957 · Forks: 2,166
- Language: Go
- License: AGPL-3.0
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/gravitational-teleport

## The problem Teleport addresses: shared secrets that never expire

Most infrastructure access starts with a key or a password that does not expire. An SSH key is copied to a new laptop, a kubeconfig is committed to a repository, a database password sits in a config file, and the only revocation mechanism is remembering to delete the file everywhere it was copied. Teleport's answer is to stop distributing secrets at all. The README describes a certificate authority that issues short-lived certificates, so the credential a user holds has a built-in expiry and does not need to be rotated by hand.

The project is aimed at teams that already feel this pain: several engineers, more than a handful of servers, at least one Kubernetes cluster, and an audit requirement that cannot be satisfied by grepping shell history. The README lists the access surface it covers, including SSH nodes, Kubernetes clusters, PostgreSQL, MongoDB, CockroachDB and MySQL databases, Windows hosts over RDP, internal web apps, cloud APIs and Model Context Protocol servers. It is not a single-purpose SSH wrapper. The scope is the reason the binary is large and the reason a small team may find it heavier than the problem it has.

## How the proxy, CA and tunnel actually fit together

Teleport ships as a single Go binary that plays several roles. The README names four components: an identity-aware access proxy, a CA that issues short-lived certificates, a unified access control system, and a tunneling system for reaching resources behind a firewall. In practice the proxy is the entry point users connect to, the CA is the authority that signs the certificates the proxy hands out, and the tunnel lets a node inside a private network register with the proxy without an inbound firewall rule.

Authentication is federated outward. The README lists GitHub Auth, OpenID Connect and SAML, with Okta and Microsoft Entra ID named as endpoints, so the identity provider remains the source of truth for who a person is. Authorization is expressed as roles, and the README describes both role-based and attribute-based access control applied across users, machines, workloads and resource types, plus just-in-time access requests for elevated roles. The audit side records activity across SSH, Kubernetes, database, RDP and web sessions, and the README also mentions session sharing for collaborative troubleshooting.

Two details in the repository layout are worth noting because they show where the complexity lives. The RDP client is not Go: Cargo.toml declares a Rust workspace whose members include lib/srv/desktop/rdp/rdpclient and lib/srv/desktop/rdp/decoder, built on the IronRDP crates. And the web UI is a separate TypeScript project, package.json names it teleport-ui and its scripts build both an open source and an enterprise bundle. A single binary does not mean a single toolchain.

## Where to get Teleport and what the repository tells you about running it

The README carries no install commands. It points readers to the download page at goteleport.com/download and to the getting started documentation, and it states that Teleport can be set up as a Linux daemon or as a Kubernetes deployment, with a link to Helm deployment documentation for the latter. That is the authoritative path for a first install; anything else would be guesswork about flags and package names.

What the repository does show is how the build is versioned. The Makefile opens with a version variable and a comment describing the naming convention for stable releases, pre-releases and the master branch, and the value currently set there is 19.0.0-prealpha.2. The most recent release listed is v18.10.0 from 2026-07-09, so the master branch is ahead of the latest stable artifact. The Makefile also defines targets for building all binaries in development mode, building for production, preparing a release tarball, cleaning artifacts and running tests, and it exposes WEBASSETS_SKIP_BUILD as a switch that skips building web assets.

The deployment shape is visible in the examples directory, which contains directories for systemd, upstart, launchd, chart and terraform. Those are the service-manager and orchestration entry points the project maintains, and they are a better starting point than writing a unit file from scratch. For a first cluster, the README's own ordering applies: read the getting started guide, then the architecture reference, then the reference guides for the specific resource type you are enrolling.

## Where Teleport is the wrong tool

The first limitation is licensing. The repository LICENSE is AGPL-3.0, and the README's own links separate the open source project from Teleport Enterprise, described as a cloud-hosted option for teams that need it. That split matters: a feature you saw in a blog post may not exist in the binary you compile. The README points to a feature matrix rather than enumerating the boundary, so the matrix is the document to read before you plan a deployment around a specific capability.

The second limitation is operational weight. Teleport is an identity provider integration, a certificate authority, a proxy and an audit store at once. A cluster needs a data directory, a token, a cluster name and a decision about where the auth service lives. For two servers and three engineers, that is more moving parts than an SSH key and a firewall rule, and the failure modes are worse: when the proxy or the CA is down, nobody reaches anything, whereas a broken jump host leaves direct SSH intact.

The third is that certificate-based access assumes the rest of your tooling can present a certificate. The README lists MCP servers, Git repositories and internal web apps among the supported targets, but anything that only accepts a static password and offers no proxy path stays outside the model. The README does not document a rollback procedure for a cluster that has already issued certificates, so an exit plan is something you design rather than something the project hands you.

## How it differs from plain OpenSSH with a certificate authority

The obvious comparison is OpenSSH's own certificate support. OpenSSH can sign user keys with a CA key, and that gets you short-lived credentials for SSH alone. The difference is scope and control plane. OpenSSH has no concept of a Kubernetes cluster, a PostgreSQL instance or an RDP desktop as a first-class resource, and it has no built-in notion of a role that grants access to a database but not a shell. Teleport's unified access control system is the part that does not have an OpenSSH equivalent, and the session recording across protocols is the other.

A second comparison is a traditional bastion host. A bastion centralizes the network path, which is what a proxy also does, but it does not remove the long-lived key: users still carry a private key, and the bastion typically logs the connection rather than the session content. Teleport's tunnel removes the need for an inbound firewall rule on the target, and its audit covers the session itself. The trade is that you now depend on the proxy being available, which a bastion shares, and on the CA being available, which a bastion does not.

## Maintenance, upgrades and what the licence implies

The repository is not archived and the last push was on 2026-09-17, so the project is receiving changes. The release cadence visible in the listing is regular: v18.10.0-rc.1 on 2026-07-01, v18.10.0-rc.2 on 2026-07-07, and v18.10.0 on 2026-07-09. That pattern means you should plan for release candidates appearing between stable versions rather than treating every tag as production-ready.

Upgrade cost is concentrated in the auth service, because it holds the certificate authority and the cluster state. The Makefile shows the version is a single variable, so building from source means tracking that value yourself; the README directs most users to prebuilt downloads instead. The repository also carries a CHANGELOG.md at the top level, which is the file to read before moving between major versions.

On licensing: the project is AGPL-3.0, and Cargo.toml declares AGPL-3.0-only for the Rust workspace members. The AGPL's network clause is the part that changes decisions for anyone offering a modified Teleport as a service, and the README's separation of an enterprise offering means some capabilities are not in this repository at all. Whether either point affects you is a question for your own legal review; the repository states the licence and does not interpret it for you.

## Conclusion

Adopt Teleport if you run SSH fleets, Kubernetes clusters or databases that several people reach through shared keys, static kubeconfigs or a jump host, and you want one certificate authority and one audit trail in front of all of them. Do not adopt it if a single SSH host with two administrators is your whole footprint, or if AGPL-3.0 is incompatible with how you ship software. Before committing, verify which protocols your version actually covers by checking the feature matrix linked from the README, confirm whether the capabilities you need sit in the open source binary or behind the Enterprise split the README points to, and read the architecture reference for how the proxy, auth service and nodes divide responsibilities. The version in the repository Makefile is 19.0.0-prealpha.2, so the master branch is ahead of the v18.10.0 release you would install.

## FAQ

### How do I install Teleport on Ubuntu 22.04?

The README does not give distribution-specific commands. It links to the download page at goteleport.com/download and to the getting started documentation, and it notes that Teleport can run as a Linux daemon. Follow those pages for the current package and version.

### How do I install Teleport on Windows?

The README does not describe a Windows installation. It lists Windows hosts as a resource type reachable over RDP, which is different from running the Teleport binary on Windows, and it points to the download page and documentation for install instructions.

### How do I install Teleport in general?

The README points to the download page at goteleport.com/download and to the getting started documentation at goteleport.com/docs/get-started. It also notes the option of a Kubernetes deployment via Helm.

### How do I install Teleport on a Mac?

The README does not give macOS instructions. It points to the download page at goteleport.com/download, and the repository contains an examples/launchd directory, which is the macOS service manager.

## Sources

- [gravitational/teleport on GitHub](https://github.com/gravitational/teleport)
- [License: AGPL-3.0](https://github.com/gravitational/teleport/blob/master/LICENSE)
- [Project website](https://goteleport.com)
- [README](https://github.com/gravitational/teleport/blob/master/README.md)
- [Releases](https://github.com/gravitational/teleport/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/gravitational-teleport