Teleport Self Hosted
You set up a teleport self hosted deployment by running an auth server and node agents. These core parts issue short-lived certificates so engineers can log in to servers and databases. Most platform teams host these services on Linux virtual machines or inside Kubernetes clusters. They link the auth service to an identity provider for single sign-on. Still, teams often grant broad cluster roles just to get engineers working fast. When roles are too wide, any logged-in user can run risky command
Teleport + Self-Service Access Portals: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a teleport self hosted deployment by running an auth server and node agents. These core parts issue short-lived certificates so engineers can log in to servers and databases. Most platform teams host these services on Linux virtual machines or inside Kubernetes clusters. They link the auth service to an identity provider for single sign-on. Still, teams often grant broad cluster roles just to get engineers working fast. When roles are too wide, any logged-in user can run risky commands on production systems.
How a teleport self hosted architecture works
A self-managed deployment relies on three main roles that run from one binary. The auth service acts as the central certificate authority for your whole fleet. It holds the cluster state, checks user identities, and signs short-lived credentials. The routing service sits at the network edge and accepts incoming user traffic. It sends users to the auth service to log in and then routes traffic inward.
Resource agents run alongside your Linux servers, Kubernetes clusters, and databases. Each agent joins the cluster by presenting a join token to the auth service. Once trusted, the agent opens an outbound tunnel back to the routing layer. This setup lets teams reach internal nodes without opening inbound firewall ports. Admins define roles that map identity provider groups to specific target labels. When an engineer logs in, they receive a certificate that expires after a few hours.
What self-hosting solves and what gaps remain
Running your own cluster removes the need for static SSH keys and shared passwords. Teams gain a single place to manage who can log in to each host. When someone leaves the company, disabling their single sign-on account blocks future logins right away. The central auth server also records when sessions start and which user opened them.
Still, managing this stack yourself takes ongoing operational work. Your team must back up cluster state, rotate TLS certificates, and patch servers on schedule. High availability requires shared storage back ends and load balancers across multiple zones.
Teleport + Self-Service Access Portals: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
More importantly, node and role rules mostly control who can open a session. Once a database or shell session starts, the user holds full permissions for that role. A developer with database read rights can still pull whole tables full of sensitive data. A shell user with sudo rights can run destructive commands without a second check. Standard role checks do not inspect individual queries or mask fields in flight. If a query returns emails, phone numbers, or card numbers, the raw values appear on screen. To reduce risk, teams need controls that check each command and mask data in results.
Planning day-two operations for your cluster
Before going live, teams must plan how to keep the control plane running. If the auth service goes down, no one can get new certificates to fix broken systems. You need automated backups for the backend state database and clear recovery steps. Teams also need a staging cluster to test version upgrades before updating production agents. Agents and auth servers must stay within supported version bounds or tunnels may drop. Setting up alerts on certificate expiry and disk space prevents sudden login outages across your fleet.
Add runtime guardrails and masking beside your databases and APIs
Login rules, role grants, and CI checks govern who connects to your stack. Yet any allowed script, engineer, or AI agent still runs commands with the full scope of its role. For workloads on Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes, SSH, or internal HTTP services, hoop.dev sits beside the service as an open-source proxy, a sidecar for your database or API.
Before a query runs, hoop.dev guardrails check the statement against your rules. An AI Analyzer you configure can score intent or hold risky calls for human review. Next, hoop.dev data masking rewrites sensitive fields in responses, and each verdict is logged per listener. Explore the MIT-licensed project on GitHub.
Frequently asked questions
What components do I need to run a teleport self hosted cluster?
You need an auth service, a routing service, and agents on your target resources. For production, you also need a state database, object storage, and a load balancer.
How do agents talk to the control plane across private networks?
Agents use reverse tunnels that dial out from the private network to the routing service. This approach works across NAT boundaries without opening inbound ports on your internal firewalls.
Does a role-based login setup stop users from reading sensitive database rows?
No, role checks only decide which database account the user assumes at login time. Unless you add query inspection or data masking, the user sees all rows that account can read.