Boundary vs Teleport

Stop Sharing SSH Keys With Your Team

If your current access strategy is “drop the private key in a shared folder and hope for the best,” congrats — you’ve built a distributed time bomb. One offboarded contractor, one laptop stolen at a coffee shop, and suddenly you’re rotating credentials across thirty servers at 2 AM while questioning every career choice that led here.

That’s what identity-aware access proxies exist to solve. Instead of handing out long-lived keys, you broker connections through a central chokepoint that knows who is connecting, to what, when, and why — and can revoke that in one place.

Two tools dominate this space for self-hosters and small ops teams: HashiCorp Boundary and Teleport. Both are open source, both can run on your own hardware, and both will make you feel briefly guilty about the shared-key era. But they come at the problem from different angles.

Let’s get into it.

What Problem Are We Actually Solving

Before we compare, a quick gut-check on what “zero-trust access” means in practice for a homelab or small team:

• No more distributing SSH keys — keys are long-lived, hard to audit, and never actually get deleted when someone leaves
• No more “kubeconfig in the wiki” — a static kubeconfig is credentials left lying around
• Audit logs you can actually use — who ran what, against which server, and when
• Time-bound sessions — access that expires, not access that persists forever because nobody cleaned up
• SSO integration — your team logs in with the same identity provider they use for everything else

Both Boundary and Teleport hit all five. Where they differ is in how they get there.

Architecture: How Each One Is Built

HashiCorp Boundary

Boundary uses a controller/worker split. The controller handles identity, policy, and session brokering — it’s your control plane. Workers sit inside your networks (VPCs, home lab VLANs, whatever) and do the actual connection forwarding.

User → Boundary Controller (auth, policy) → Worker (in your network) → Target

Workers connect outbound to the controller, so you don’t need to punch inbound holes in firewalls to reach internal resources. That’s genuinely clever for hybrid environments.

The controller needs a database (PostgreSQL in production), and you’ll want KMS for key management. In practice, that means Boundary pairs naturally with Vault — Boundary can use Vault for credential brokering and dynamic secret injection.

Teleport

Teleport is a single-binary access proxy that runs as three logical services: Auth Server, Proxy, and Node (or Application, Kubernetes, Database, Desktop — depending on what you’re protecting).

User → Teleport Proxy → Auth Server (verify identity, issue cert) → Node/Target

The killer difference: Teleport mints short-lived X.509/SSH certificates at login. Your SSH clients never hold long-lived keys — they get a cert that’s valid for maybe 12 hours, cryptographically signed by Teleport’s CA. When it expires, gone. No revocation lists, no manual cleanup. The cert just stops working.

For a home lab running on a single host, Teleport can run as one process handling everything. For production, you’d split auth and proxy for HA.

Identity and SSO

Both tools support OIDC and SAML, so you can plug in GitHub, Google Workspace, Okta, Authentik, Keycloak — whatever your identity provider is.

Boundary leans heavily on Vault for its “managed credentials” story. You can configure Boundary to inject dynamic database passwords, SSH credentials, or API tokens from Vault directly into sessions. If Vault is already your secrets backbone, this is elegant — Boundary becomes the access layer on top of Vault’s credential engine.

Teleport handles identity more self-contained. It runs its own certificate authority and issues certs from that CA. You can still integrate with an external IdP for the login flow (OIDC/SAML), but Teleport is the one signing certs. Less dependency on external systems; slightly more trust placed in Teleport itself.

For a team already deep in HashiCorp tooling — Vault, Nomad, Consul — Boundary slots in naturally. For everyone else, Teleport’s self-contained approach means fewer moving parts.

SSH Access: The Daily Driver Test

This is where most people start, because SSH is still how you touch 90% of your infrastructure.

Teleport SSH

version: v3
teleport:
  nodename: homelab-node-01
  auth_token: /etc/teleport/token
  auth_servers:
    - teleport.yourdomain.com:3025

auth_service:
  enabled: false

proxy_service:
  enabled: false

ssh_service:
  enabled: true
  labels:
    env: homelab
    role: general

Install the teleport agent on each node, point it at your auth server, and that node shows up in tsh ls. Users connect with:

tsh ssh user@homelab-node-01

Teleport issues a short-lived SSH cert at login. Your ~/.ssh/ stays clean — no authorized_keys modifications, no permanent keys, nothing to leak.

Boundary SSH

controller {
  name        = "homelab-controller"
  description = "Home lab Boundary controller"

  database {
    url = "env://BOUNDARY_POSTGRES_URL"
  }
}

listener "tcp" {
  address     = "0.0.0.0:9200"
  purpose     = "api"
  tls_disable = true  # put TLS termination upstream
}

listener "tcp" {
  address = "0.0.0.0:9201"
  purpose = "cluster"
}

kms "aead" {
  purpose    = "root"
  aes_gcm_key = "sP1fnF5Xz85iqkMd..."
}

With Boundary, you define targets (SSH hosts) and host catalogs in its admin UI or Terraform. Users connect via boundary connect ssh:

boundary connect ssh -target-id tssh_abc123def456 -- -l ubuntu

Boundary proxies the TCP connection through a worker; your SSH keys or dynamic credentials from Vault handle authentication to the endpoint itself.

Boundary’s SSH story requires a bit more scaffolding — you need to define the host catalog, hosts, host sets, targets, and access policies before anyone connects. First-run friction is higher than Teleport’s.

Kubernetes Access

This is where the gap widens.

Teleport for Kubernetes

Teleport has first-class kubectl support. Enroll a cluster:

kubernetes_service:
  enabled: true
  kube_cluster_name: homelab-k3s
  kubeconfig_file: /etc/teleport/kubeconfig

Users request access with:

tsh kube login homelab-k3s
kubectl get pods -n default

Teleport injects identity into the kubeconfig — your actual cluster credentials never leave the auth server. RBAC on the Kubernetes side maps to Teleport roles. You can restrict dev users to specific namespaces right in the Teleport role definition. Session recording even captures kubectl exec sessions.

Boundary for Kubernetes

Boundary can broker a connection to the Kubernetes API server as a TCP target, but it doesn’t understand the Kubernetes protocol. You define a target pointing at kubernetes.default.svc:443, Boundary proxies the TCP tunnel, and your existing kubeconfig handles the actual authentication.

boundary connect -target-id ttcp_k8s123 -listen-port 6443
# Then in another terminal:
kubectl --server=https://127.0.0.1:6443 get pods

This works, but it’s not the same as Teleport’s native experience. Boundary doesn’t do cert minting for Kubernetes, doesn’t translate k8s RBAC to its own policy model, and won’t record kubectl exec sessions natively. You’re getting a zero-trust TCP tunnel, not zero-trust Kubernetes access.

If your use case is “I want audit logs and identity for kubectl,” Teleport wins this one decisively.

Database Access

Both tools broker database connections. Teleport has the flashier story.

Teleport supports PostgreSQL, MySQL, MariaDB, MongoDB, Redis, CockroachDB, and more. It acts as a database proxy — you connect to Teleport’s proxy port, it authenticates you via your Teleport identity, and forwards to the actual database. Short-lived certificates handle auth to the DB itself (for Postgres/MySQL, Teleport generates per-session X.509 certs).

The bonus: Teleport has an in-browser SQL client in its UI. You can run queries from a browser session, and every query is captured in the audit log.

tsh db login --db-user=readonly --db-name=myapp postgres-prod
psql "service=myapp"

Boundary can do the same TCP-proxy trick for databases, and with Vault integration it can inject dynamic database credentials from Vault’s database secrets engine. If you want truly ephemeral DB credentials that Vault creates and revokes automatically, the Boundary + Vault combination is hard to beat architecturally.

For homelab use: Teleport’s DB access is simpler to set up if you’re not already on Vault. Boundary + Vault is more powerful but requires two additional moving parts to be healthy.

Session Recording

Teleport records SSH sessions natively — keystrokes, output, timing. Recordings are searchable and replayable from the audit UI. This is table stakes for compliance, and Teleport ships it in the free OSS tier.

tsh recordings ls
tsh play <session-id>

Boundary’s session recording is an Enterprise feature in Boundary 0.13+. The OSS tier logs that a session happened — target, user, timestamps — but doesn’t capture what happened inside the session. For most homelab purposes that’s fine. For “I need to prove to an auditor what the contractor did,” that’s a gap.

Self-Hosting Reality Check

Teleport OSS runs as a single binary. SQLite backend works fine for small deployments (under ~100 nodes). Slap it on a VPS or a homelab VM, configure TLS, and you’re up in under an hour.

# Install on Ubuntu/Debian
curl https://goteleport.com/static/install.sh | bash -s 15.0.0
sudo teleport configure --output=/etc/teleport.yaml \
  --cluster-name=homelab.yourdomain.com \
  --public-addr=teleport.yourdomain.com:443 \
  --acme [email protected]
sudo systemctl enable --now teleport

Boundary OSS needs PostgreSQL. That’s a real dependency — you’re either running a dedicated Postgres instance or adding it to an existing one. Add in KMS configuration (dev mode uses a local in-memory key; production wants real KMS) and the initial setup is heavier.

For a single-operator home lab: Teleport’s lower setup friction matters. For a team that already runs Postgres and Vault: Boundary’s dependencies aren’t new infrastructure, they’re just configuration.

Workload Identity (Machine-to-Machine)

Humans aren’t the only ones that need access. Your CI/CD pipeline needs to deploy to Kubernetes. Your backup script needs to write to the database.

Teleport Machine ID issues short-lived certificates for bots (CI runners, automation scripts). A GitHub Actions job can get a Teleport cert scoped to exactly the permissions it needs, valid for the duration of the job, then gone.

Boundary + Vault handles this through Vault’s app role or JWT auth — Boundary brokers the connection, Vault injects the credential. More composable, more complex.

Both approaches are production-grade. Teleport Machine ID is newer and simpler for common CI/CD patterns. The Boundary/Vault combo gives you more knobs.

Verdict

Here’s the honest take:

Choose Teleport if:

• You want SSH, k8s, DB, and web app access in one tool with minimal setup
• SSH certificate hygiene matters to you (it should)
• You want session recording without paying for Enterprise
• You don’t already run Vault
• You’re a solo operator or small team who wants to be up in an afternoon

Choose Boundary if:

• You’re already invested in the HashiCorp stack (Vault, Terraform, Nomad)
• You want Vault-powered dynamic credentials injected at session time
• Your security team has standardized on Vault as the identity backbone
• You need granular TCP-level brokering more than you need protocol-aware access

For the homelab? Teleport. It’s more opinionated, more batteries-included, and the free OSS tier covers everything a home lab needs — including the session recording that would cost you Enterprise on Boundary. The SSH certificate model alone is worth the setup time.

The shared-key era had a good run. It’s over.

Full example: Working Teleport and Boundary configs at github.com/KingPin/sumguy-examples/security/boundary-vs-teleport

Related Reading

• 3-2-1-1-0: The Backup Strategy That Survives Ransomware
• Authentik vs Authelia: SSO for Your Self-Hosted Stack
• Private Docker Registry with Harbor
• SOPS + age: Secrets in Git
• Using AI to Find Security Bugs in Your Code