Teleport
Identity-aware access for infrastructure
Teleport is an open-source access platform that provides secure, identity-aware connectivity to SSH servers, Kubernetes clusters, databases, and web apps. It records sessions and enforces RBAC.
Key features
- SSH, Kubernetes, and DB access
- Session recording
- Identity-based RBAC
- Certificate-based auth
Pros & cons
Strengths
- Session recording and audit
- Covers SSH to databases
- Strong RBAC controls
Trade-offs
- Complex to operate
- Some features enterprise
Teleport replaces
Last reviewed Aug 26, 2026 · 824 words
Most homelabs do not need Teleport, and the honest guide says that first. With 5 machines and 1 user, SSH keys behind Tailscale give you 90% of the security for 5% of the operating burden. Teleport is for the moment you need to answer "who ran what, on which box, and show me the recording": several people, certificates that expire in hours instead of keys that live forever, and one login covering SSH, Kubernetes, databases and internal web apps. If that is your situation it is excellent, it is 1 Go binary, and it takes a weekend to set up properly rather than an hour.
Certificates, not keys, is the entire idea
You log in once with tsh login --proxy=teleport.example.com, prove who you are with a password plus WebAuthn or TOTP, and receive a short-lived SSH certificate. Every server trusts the Teleport certificate authority, so there is no authorized_keys file anywhere and nothing to revoke when someone leaves; their certificate simply expires. Nodes join the cluster with a token and dial out to the proxy over a reverse tunnel, which means a machine behind NAT with zero inbound ports is still reachable as tsh ssh alice@nas. That reverse tunnel is also why Teleport is good at reaching the odd box in a relative's house without punching holes anywhere.
One real domain, one public port, and DNS you control
The proxy multiplexes everything on a single TLS port, and it can fetch its own certificate:
teleport configure \
--cluster-name=teleport.example.com \
--public-addr=teleport.example.com:443 \
--acme [email protected] \
-o file:///etc/teleport.yaml
systemctl enable --now teleport
tctl users add alice --roles=access,editor --logins=alice,root
The last command prints a one-time signup link where Alice sets her password and enrols a second factor. Internally the auth service listens on 3025 and SSH nodes on 3022, but with the reverse-tunnel model only 443 needs to be reachable from outside. Two things must be true before any of this works: teleport.example.com resolves publicly (ACME will not issue otherwise), and if you plan to publish internal web apps through Teleport, a wildcard *.teleport.example.com record also exists, because each app gets its own subdomain. Fudging either with /etc/hosts is the classic wasted afternoon.
Adding a node is two commands: tctl tokens add --type=node --ttl=1h on the cluster, then teleport node configure --token=... --proxy=teleport.example.com:443 and a service start on the new machine.
Session recording is on by default, and it is the payoff
Every interactive SSH session is recorded to /var/lib/teleport/log and replayable from the web UI or with tsh play. Audit events (logins, commands, file transfers) land in a structured log you can ship to your monitoring stack. For a team, this is the feature: no agent to add, no shell hook to bypass, and the recording exists whether the user remembered to be careful or not. Recordings grow at a few MB per hour of active typing; put the data directory on a disk you back up.
What Community Edition does and does not include
Self-hosted Teleport, the AGPL-licensed community build, includes SSH, Kubernetes, database and application access, session recording, RBAC, and single sign-on through GitHub. It does not include OIDC or SAML login (so no Authentik or Okta in front of it), access requests with approvals, device trust, or hardware-key enforcement; those are enterprise. Teleport also tightened its community license terms in 2024 for larger companies, so check the current wording before running it at work rather than at home. For a household or a small team using GitHub identities, none of the gaps bite.
Operating it is the real cost
Teleport is Hard-rated for a reason. The auth service's data directory is the cluster's identity; lose it without a backup and every node must be re-joined. Upgrades must go one major version at a time, auth before proxies before nodes. The 1 GB minimum is for a quiet cluster; add Kubernetes and database access and plan for 2 GB. The three ways to do remote access post puts this in context: Tailscale for reach, a bastion for simplicity, Teleport for accountability.
What I'd do
If you are one person, stop reading and use Tailscale SSH. If you are 3 or more people sharing infrastructure, or you need recordings for compliance or your own peace of mind: one small VM as auth and proxy with ACME on 443, GitHub SSO, /var/lib/teleport backed up nightly, nodes joined over the reverse tunnel so nothing else is exposed, and a quarterly upgrade in the documented order. Give it the weekend it asks for and it removes a whole category of "who has a key to what" from your life.
Compare Teleport
5 head-to-head comparisons.
Similar remote access & vpn apps
RustDesk
Remote Access & VPNOpen-source remote desktop alternative to TeamViewer
Replaces TeamViewer, AnyDesk
frp
Remote Access & VPNFast reverse proxy to expose local servers behind NAT
Replaces ngrok
Headscale
Remote Access & VPNOpen-source self-hosted Tailscale control server
Replaces Tailscale
Sunshine
Remote Access & VPNSelf-hosted game-stream host for Moonlight clients
Replaces NVIDIA GameStream, Parsec
Tailscale
Remote Access & VPNZero-config mesh VPN built on WireGuard
Replaces ZeroTier
JumpServer
Remote Access & VPNOpen-source bastion host and PAM platform
Replaces CyberArk, Teleport