Teleport Access Plane: Managed Service vs. Self‑Hosted Cluster – A Decision Guide

Decision: Managed Teleport vs. Self‑Hosted Access Plane

Teleport’s Access Plane provides a unified entry point for SSH, Kubernetes, and database access. Organizations must decide whether to rely on Teleport’s managed Omni service or to deploy a self‑hosted cluster. The choice hinges on control, compliance, cost, and operational complexity.

Constraints to Consider

• Compliance & Data Residency – Self‑hosting lets you keep all authentication data on premises; managed services may store data in cloud regions you cannot control.
• Operational Overhead – Managed services eliminate the need to run the Auth Service, Proxy, and backend storage; self‑hosting requires you to maintain etcd or DynamoDB, apply patches, and monitor health.
• Latency – The distance between the Proxy and target nodes can affect interactive sessions. A self‑hosted Proxy in each region can reduce round‑trip time.
• Cost – Managed services charge per node or per user per month; self‑hosting can be cheaper if you already have the underlying infrastructure.
• Feature Availability – Some advanced features (e.g., automatic node discovery, multi‑cloud federation) are only available in the Enterprise edition of the managed service.

Compact Comparison Table

Feature	Managed (Omni)	Self‑Hosted (Community)
Auth Service	Fully managed, backed by Teleport’s own infrastructure	Self‑hosted (etcd or DynamoDB)
Proxy Layer	Managed; auto‑scales with load	Self‑hosted; requires manual scaling
Identity Provider Integration	Native OIDC, SAML, LDAP support	Same – you manage the integration
Short‑Lived Certificates	Enabled by default	Enabled by default; must configure backend
Cost Model	Subscription per node/user	Infrastructure + operational cost
Compliance Controls	Limited to Teleport’s terms	Full control over data residency
Feature Set	Enterprise‑only features included	Community features only

Trade‑Offs Explained

• Control vs. Convenience – Managed services free you from day‑to‑day operations but lock you into Teleport’s infrastructure. Self‑hosting gives you full control over the Auth Service backend and network topology.
• Security vs. Complexity – Short‑lived X.509 certificates reduce the risk of key compromise. In a self‑hosted setup, you must secure the etcd or DynamoDB backend to prevent a single point of failure.
• Latency vs. Scale – Deploying a Proxy in each region reduces latency for local users but increases operational burden. Managed services automatically place Proxies closer to users via cloud load balancers.
• Cost vs. Feature Richness – Enterprise features like automatic node discovery or multi‑cloud federation come at a price. If you only need basic SSH and database access, the community edition may suffice.

Concrete Implementation: Self‑Hosted Teleport with OIDC

Below is a step‑by‑step example of deploying a self‑hosted Teleport cluster on a Linux host, integrating it with an OIDC IdP (e.g., Okta), and verifying short‑lived certificate issuance.

Prerequisites

• Ubuntu 22.04 LTS server with sudo access.
• Running OIDC IdP with client ID, secret, and discovery endpoint.
• Etcd cluster (single‑node for demo) or DynamoDB table for Auth Service backend.
• Public DNS name that points to the Teleport Proxy.
• Firewall rules: allow inbound TCP 3022 (Teleport Proxy) and outbound to OIDC IdP endpoints.

Step 1 – Install Teleport

# Download latest stable package
wget https://github.com/gravitational/teleport/releases/download/v13.0.4/teleport-v13.0.4-linux-amd64.tar.gz

# Extract and install
sudo tar -xzf teleport-v13.0.4-linux-amd64.tar.gz -C /opt
sudo ln -s /opt/teleport-v13.0.4-linux-amd64/teleport /usr/local/bin/teleport

Step 2 – Configure Auth Service

Create /etc/teleport.yaml with the following minimal configuration. Replace placeholders with your actual values.

teleport:
  nodename: "teleport-auth"
  data_dir: "/var/lib/teleport"
  auth_token: "<unique-token>"
  authentication:
    type: "oidc"
    oidc:
      client_id: "<oidc-client-id>"
      client_secret: "<oidc-client-secret>"
      discovery_url: "<oidc-discovery-url>"
      redirect_url: "https://<proxy-hostname>/v1/webapi/auth/oidc/callback"
      scopes: [ "openid", "profile", "email" ]
      identity_claims:
        username: "preferred_username"
        groups: "groups"
  auth_service:
    enabled: true
    cluster_name: "mycluster"
    storage:
      type: "etcd"
      etcd:
        endpoints: [ "http://localhost:2379" ]
  proxy_service:
    enabled: false
  ssh_service:
    enabled: false

Note: In a production cluster, keep the auth_token secret and use a multi‑node etcd cluster.

Step 3 – Configure Proxy Service

Create a second file /etc/teleport_proxy.yaml for the Proxy node.

teleport:
  nodename: "teleport-proxy"
  data_dir: "/var/lib/teleport"
  auth_token: "<unique-token>"
  auth_service:
    enabled: false
  proxy_service:
    enabled: true
    listen_addr: ":3022"
    web_listen_addr: ":3080"
    tunnel_listen_addr: ":3023"
  ssh_service:
    enabled: false

Both Auth and Proxy nodes share the same auth_token so they can join the same cluster.

Step 4 – Start Services

# Start Auth Service
sudo teleport start --config=/etc/teleport.yaml

# Start Proxy Service
sudo teleport start --config=/etc/teleport_proxy.yaml

Check that both services are running:

sudo systemctl status teleport
sudo systemctl status teleport-proxy

Step 5 – Register a Node

On a target machine (e.g., an application server), install Teleport and register it as an SSH node:

# Install Teleport (same as earlier)
sudo teleport start --config=/etc/teleport_node.yaml

Node configuration should point to the Proxy address:

teleport:
  nodename: "app-server-01"
  data_dir: "/var/lib/teleport"
  auth_token: "<unique-token>"
  auth_service:
    enabled: false
  proxy_service:
    enabled: false
  ssh_service:
    enabled: true
    listen_addr: ":3022"
    auth_token: "<unique-token>"
    auth_servers: [ "https://<proxy-hostname>:3022" ]

Step 6 – Verify Short‑Lived Certificate Issuance

From a client machine, use the Teleport CLI (tsh) to log in via OIDC:

# Install tsh
wget https://github.com/gravitational/teleport/releases/download/v13.0.4/tsh-v13.0.4-linux-amd64.tar.gz
sudo tar -xzf tsh-v13.0.4-linux-amd64.tar.gz -C /opt
sudo ln -s /opt/tsh-v13.0.4-linux-amd64/tsh /usr/local/bin/tsh

# Log in
export TELEPORT_HOST="https://<proxy-hostname>:3080"
# tsh login will open the browser for OIDC authentication
sudo tsh login --proxy=$TELEPORT_HOST

After successful login, tsh ls should list the registered node.

sudo tsh ls
# Output example
# 2026-10-14 15:07:32 UTC  ssh  app-server-01  2026-10-15 00:07:32 UTC  15m

The timestamp shows the short‑lived certificate’s expiration (15 minutes by default). You can adjust this via the auth_service: cert_expiry setting.

Step 7 – Test Connectivity

SSH into the node through the Proxy:

sudo tsh ssh app-server-01

You should be prompted for OIDC authentication if the session is new. The connection should be encrypted end‑to‑end with a TLS session established by the Proxy.

Limitations & Practical Checks

• Latency – Measure round‑trip time between the client and the Proxy. If you notice >200 ms latency, consider deploying a Proxy closer to the client.
• Firewall – Ensure ports 3022 (Proxy), 3023 (tunnel), and 3080 (Web UI) are open. Incorrect rules cause connection timeouts.
• Auth Service Backend – In a production cluster, use a multi‑node etcd or DynamoDB to avoid a single point of failure.
• Certificate Rotation – The Auth Service automatically rotates short‑lived certificates. Verify logs in /var/lib/teleport/auth_service.log for rotation events.

When to Pick Managed vs. Self‑Hosted

• Managed is ideal when you need rapid deployment, minimal operational overhead, and enterprise features. It’s also suitable for compliance regimes that accept Teleport’s data residency policies.
• Self‑Hosted is preferable when you require full control over authentication data, want to run Teleport in a highly regulated environment, or need to integrate tightly with existing infrastructure (e.g., custom etcd topology).

By evaluating the constraints and trade‑offs above, you can align Teleport’s Access Plane deployment with your organization’s security, compliance, and operational priorities.