Teleport vs Pomerium: which to choose

Teleport vs Pomerium: when each one is the right choice

Choose Teleport when the thing you need to protect is infrastructure: SSH nodes, Kubernetes clusters, PostgreSQL, MongoDB, CockroachDB or MySQL databases, or Windows hosts. Teleport issues its own short-lived certificates through its built-in certificate authority, so engineers authenticate once and reach those resources without shared SSH keys or static Kubernetes tokens. It also runs as a single Go binary that can reach resources behind the firewall through its tunneling system. Pick it when your main question is who may open a shell, a database session or a cluster context, and when you want that answer recorded and time-limited.

Choose Pomerium when the thing you need to protect is internal web applications, and you want users to reach them without a corporate VPN. Pomerium is a clientless, identity and context-aware reverse proxy governed by policies, and it publishes a Kubernetes Ingress Controller for running it as the entry point for cluster services. Its Core edition is Apache-2.0 and self-run. Pick it when the decision is which users and device contexts may reach which route, and when your estate is mostly HTTP services. Pomerium Zero adds a managed control plane, and the plan limits for clusters, routes and policies in the pricing page should be checked against your route count before you commit.

The decision turns on four questions. First, protocols: Teleport covers shells, databases and Windows hosts, while Pomerium covers web traffic plus native SSH, TCP and UDP through its CLI or desktop app. Second, edition limits: check which SSO providers, directory sync, session recording and Rego policies sit in the paid tier you need, since Teleport Community Edition has its own licensing conditions. Third, licensing: confirm that your organization fits the Teleport Community Edition terms before relying on it. Fourth, who operates it: a self-run Pomerium Core cluster and a self-hosted Teleport cluster both need a team that owns certificates, upgrades and identity provider configuration. Ask each vendor to confirm these points in writing for your environment.

Which platform fits which scenario

This table maps common team scenarios to the platform that usually fits better and the condition that decides it. Read each row against your estate, your edition needs and your approval requirements, because the better fit flips when those conditions change.

Scenario	Better fit	Condition that makes it so
SSH and Kubernetes operations team	Teleport	Engineers need short-lived certificates for SSH, Kubernetes, and databases, with a single access control system, and OpenSSH compatibility matters for existing tooling.
Web-app estate behind a reverse proxy	Pomerium	Most access is clientless HTTPS to internal web apps, and policies need to sit in front of each route without installing agents on user machines.
Mixed estate needing both infrastructure and web access	Both, often together	Teams can run Teleport for servers and clusters and Pomerium for web routes, but the two products have separate policy models and you should confirm how identity and audit records will be joined.
Small organization on Community or Core terms	Depends on eligibility	Teleport Community Edition distribution terms apply only under the employee and revenue limits in its license, so confirm eligibility first. Pomerium Core is Apache-2.0 and self-run, but its feature set is narrower than Zero or Enterprise.
Regulated enterprise needing SSO, approvals and audit	Teleport Enterprise, after confirming fit	Enterprise lists Okta, Microsoft Entra ID and SAML SSO, just-in-time access requests and session moderation, and FIPS builds for self-hosting. Confirm the specific control evidence your assessor expects with the vendor.
Session recording for SSH sessions	Teleport	Teleport includes session recording with playback in both editions, while Pomerium reserves SSH session recording and playback for its Enterprise edition.
Need to run the control plane entirely in your environment	Teleport or Pomerium Enterprise, with confirmation	Teleport can be deployed on premises, in the cloud or hybrid. Pomerium Zero keeps application traffic in your environment but hosts the control plane with Pomerium, so confirm whether that model meets your data residency rules.

How Teleport and Pomerium are built and what that means for operations

Teleport and Pomerium both sit in front of internal resources and enforce identity-based access, but they put different parts of that job in different places. The cards below cover the core components, where each platform's control plane lives, how each one deploys on Kubernetes, and what upgrades and on-call look like once the proxy is in production.

Teleport as one binary

Teleport ships an identity-aware access proxy, its own certificate authority, a unified access control system and a tunneling system as a single Go binary. That means one artifact to pin, patch and roll back, and the CA that signs user and host certificates lives inside the same deployment as the proxy. Check how your team will back up and protect that CA, because losing or compromising it affects every session the cluster issues.

Short-lived certificates from Teleport's CA

Teleport replaces long-lived SSH keys and shared Kubernetes tokens with certificates that expire automatically, and it states full compatibility with OpenSSH servers and clients. Operations shift from rotating keys on each host to managing role definitions and certificate lifetimes. Confirm with your security team how certificate revocation and lock behavior fit your incident response playbook before you rely on expiry alone.

Pomerium Core as a policy proxy

Pomerium Core is an Apache-2.0 reverse proxy that enforces identity and context-aware policy in front of internal web applications, and it does not issue user certificates for infrastructure access. Your team manages routes, policies and an identity provider connection, while the applications themselves remain unchanged. Check which traffic types your applications need, since clientless web access is the primary use case and native SSH or database protocols require a different setup.

Pomerium Zero's split control plane

With Pomerium Zero, you run the Pomerium Core cluster in your own environment while Pomerium hosts the control plane and management console, so application traffic stays where you put it. This splits operations: you own data plane uptime and upgrades, and you depend on a vendor-hosted control plane for policy management. Ask what happens to enforcement during a control plane outage, and whether your data handling rules accept a hosted management layer.

Helm for Teleport on Kubernetes

Teleport can run as a Kubernetes Helm deployment, which lets platform teams manage the proxy, auth and node components with the same release tooling as their other workloads. Operations work includes chart version pinning, storage and certificate planning for the cluster, and coordinated upgrades across the components Teleport runs. Confirm with the vendor how the chart handles high availability and backend storage in your environment before you standardize on it.

Ingress controller for Pomerium

Pomerium publishes an Apache-2.0 Kubernetes Ingress Controller for running Pomerium as the ingress for cluster services. Teams that already operate ingress for their applications can place Pomerium in that path, which keeps access policy close to the routes it protects. The trade-off is that ingress upgrades now affect application access, so plan change windows and test policy changes in a non-production cluster before promoting them.

Protocols, SSO, recording and licensing side by side

This table sets Teleport's protocol coverage, single sign-on by edition, session recording and core licensing against Pomerium's equivalents, using only the supplied feature facts. Read each row as a question to answer for your environment: where a cell says to confirm, check the vendor's current matrix before you decide. The main takeaway is that Teleport covers server, database and Kubernetes access natively, while Pomerium focuses on proxying web and network access.

Capability	Teleport	Pomerium
Protocols protected	SSH nodes, Kubernetes, PostgreSQL, MongoDB, CockroachDB, MySQL, MCP servers, internal web apps and Windows hosts	Clientless web apps, native SSH, TCP and UDP (Zero), and Kubernetes access (Zero)
Core access model	Identity-aware proxy with its own certificate authority issuing short-lived certificates	Identity and context-aware reverse proxy with attribute-based policies
SSO in Community or Core	GitHub only	OAuth 2.0 and OIDC identity providers, including Keycloak, Okta, Microsoft Entra ID and Google
SSO in Enterprise or Zero	Google Workspace, Microsoft Entra ID, Okta, SailPoint, OIDC and SAML	Zero includes SSO and mTLS; confirm which identity providers Enterprise adds with Pomerium
Session recording	Available in both editions with playback; moderated sessions and dual authorization are Enterprise only	SSH session recording and playback are reserved for Enterprise; confirm what Zero records for web sessions
Core build license	API module Apache 2.0; rest of the source AGPL-3.0; Community builds under a modified Apache 2.0 license	Pomerium Core under Apache-2.0
Community or free use limits	Community builds limited to organizations under 100 employees and under $10,000,000 annual revenue, with a critical security patch exception	Core is open source and self-run; Zero Personal is free for personal use with limits on clusters, routes and policies
Hosting of control plane	Self-hosted deployment on premises, in the cloud or hybrid, per Teleport's pricing page	With Zero, Pomerium hosts the control plane while the Core cluster and application traffic stay in your environment
Confirm before deciding	Which SSO providers your edition includes and whether your license terms fit your organization size	Whether Core alone meets your SSO and recording needs, or whether Zero or Enterprise is required

What the license and each edition allow

Teleport licenses its code in layers, so the legal answer depends on which component you deploy. The API module is Apache 2.0, the rest of the source code is AGPL-3.0, and the Community Edition builds that Teleport distributes use a modified Apache 2.0 license. Those builds are limited to organizations with fewer than 100 employees and less than $10,000,000 in annual revenue, with an exception for designated critical security patch versions.

Layered licensing: the API module, the remaining source and the distributed Community builds each carry different terms, so confirm which artifact your team actually runs.
Community size limit: Community builds are for organizations under 100 employees and under $10,000,000 in annual revenue. A company that grows past either figure needs to move to a different license arrangement.
Critical patch exception: designated critical security patch versions fall outside the size limit, so ask Teleport which versions qualify before relying on that exception.
Enterprise-only features: access requests and reviews within Identity Governance, access lists, locks, SCIM provisioning, moderated sessions, dual authorization, Device Trust and HSM support. FedRAMP controls and FIPS binaries apply only to self-hosted Enterprise.
Pricing model: Teleport's pricing page says customers pay for active users and protected resources and does not publish prices, so a quote depends on those counts and the deployment type.

Check the current Community Edition license text and the Teleport feature matrix before deciding, since both can change between releases.

What drives the running cost of each platform

Running Teleport or Pomerium costs more than the software line on a quote. The components below separate what you pay once from what recurs, and show which ones change with your user count, resource count and operating model.

Hosting the cluster or proxy

Teleport runs as a single Go binary on a Linux daemon or a Kubernetes Helm deployment, and its certificate authority and tunneling system sit in the path of every session. Pomerium Core runs as a proxy in front of your web apps, and the Kubernetes Ingress Controller adds another deployment if you use it. Both need highly available compute, storage for logs and recordings, and load balancing that you pay for every month. Ask the vendor or your implementation partner to size the footprint for your expected peak concurrent sessions, and confirm which components must run in each region.

Skills to operate the trust layer

Teleport's own certificate authority issues short-lived certificates, so your team must understand certificate rotation, role mapping and revocation. Pomerium's cost sits in writing and reviewing attribute-based policies, which become a maintenance task as routes multiply. The cost is mostly recurring salary or contractor time, not a license line. Ask who will own certificate lifecycle or policy review after go-live, and whether that person is already on your staff.

Subscriptions tied to users and resources

Teleport's pricing page says customers pay for active users and protected resources, and it does not publish prices, so the recurring fee moves with headcount and the number of servers, clusters, databases and desktops you onboard. Pomerium Zero Business is listed at $9 per user per month billed monthly or $7 billed annually, per Pomerium's pricing page, and Enterprise is custom priced. Model both at your expected growth and ask each vendor what counts as an active user and a protected resource.

Edition features that carry a fee

Some controls you may need sit only in paid tiers. For Teleport, SSO beyond GitHub, just-in-time access requests, moderated sessions and Device Trust are Enterprise features. For Pomerium, directory sync, Rego policies, administrator RBAC and SSH session recording are reserved for Enterprise. Map each control your audit requires against the edition matrix before you size the budget, because a missing feature can force an upgrade within the first year.

Upgrades and patch cadence

Both products ship frequently: Teleport 18.11.4 followed 18.11.3 on October 2, 2026, and Pomerium v0.33.4 was published on October 2, 2026. Each upgrade needs staging tests on the access paths that users depend on, plus a rollback plan for the certificate authority or proxy configuration. This work recurs for the life of the platform. Ask how long each vendor supports older lines and how the upgrade path affects your edition and your plugins.

Support, implementation and quotes

Initial deployment, identity provider integration and policy migration are one-time costs, usually fixed-scope. Support, upgrades and continuous testing recur, often as a retainer. When requesting quotes, ask for the vendor's license price and its per-user or per-resource basis, the implementation scope in writing, the support response terms, the renewal uplift and the exit terms for moving to another platform. Pomerium Zero's managed control plane means the vendor, not you, runs that layer, which changes what your team must patch. Confirm that boundary in writing.

Moving from one platform to the other without losing audit history

This sequence moves protected resources from Teleport to Pomerium or the reverse while keeping a dated record of who had access, to what, and when. Each step ends with a check you can verify before the next one starts.

Inventory resources, policies and audit sinks
Build a list of every protected resource in the current platform: SSH nodes, Kubernetes clusters, databases, Windows hosts and internal web apps for Teleport, or routes and policies for Pomerium. For each entry, record the owner, the access rule, the session recording setting and where audit logs are sent. Keep the list under change control so the audit trail can be traced back to a known starting state. The step is done when the security team and the resource owners have signed off on the list and nothing is unassigned.
Export and retain the existing audit history
Before any cutover, export the audit and session logs the current platform produces and store them in your own retained location with integrity controls that match your compliance obligations. Do not assume the new platform will import the old records. Confirm with each vendor which log formats, session recordings and retention settings their current release exposes, because this varies by edition. The step is done when a test restore or sample read of the archived records succeeds and the retention owner has accepted the archive.
Map identity sources and roles
Translate the access model from one side to the other. Teleport uses roles and short-lived certificates tied to identity provider groups, while Pomerium uses route policies evaluated per request with identity claims and context. Document which groups or claims grant which access, and note where a Teleport role has no direct Pomerium equivalent so it can be redesigned rather than copied. Confirm which single sign-on options your edition supports, since Teleport limits Community Edition SSO to GitHub, and Pomerium reserves directory sync for its Enterprise edition. The step is done when every group has a mapped policy or a documented gap with an owner.
Run both platforms in parallel for a pilot group
Stand up the target platform alongside the current one and move a small, named group of users and a limited set of low-risk resources. Keep the original path available for rollback. Compare access decisions for the same user and resource on both sides, and check that session recording and audit events appear in the destination you intend to keep. The step is done when the pilot group has completed normal work on the new path, and every access decision in the test matches the mapped policy.
Move resources and policies in waves
Migrate the remaining resources in groups, starting with those whose owners have confirmed their access rules. For each wave, rebuild the policy on the target platform, switch users to the new path, and verify that audit records for the wave are written to the destination you recorded in step one. Some items will be rebuilt rather than transferred, including certificate-based SSH and Kubernetes access and session recording configuration. The step is done when each wave passes its access and audit check and the owner accepts it in writing.
Confirm the audit trail spans the cutover
After the final wave, reconcile the archived records from the old platform with the first records from the new one. Check that the timestamps, user identifiers and resource names line up across the boundary, and that no access period is left without a record. Ask each vendor to confirm how their platform identifies sessions and events so the two sources can be joined. The step is done when the reconciliation report is reviewed and any gaps are documented with a reason.
Retire the old access path
Disable the old platform's access rules and listeners, revoke any long-lived credentials it issued, and remove its endpoints from DNS and firewall rules. Keep the archived audit history and the exported configuration under the retention rules you set in step two, even though the service is no longer running. The step is done when a test attempt through the old path fails, the credential inventory shows nothing left active, and the archive is confirmed as readable.

Where implementation projects usually run long

Implementation time on Teleport goes mostly into access design before any agent is installed. The team has to map identity groups from the SSO provider to Teleport roles, decide which SSH nodes, Kubernetes clusters and databases each role may reach, and confirm which login traits and principals each role grants. Certificate and agent rollout to SSH and Kubernetes follows, and it is usually slower where OpenSSH hosts were managed by shared keys or where kubeconfig files were copied between engineers. Database protocol configuration is the next common source of delay, because each engine (PostgreSQL, MongoDB, CockroachDB, MySQL) needs its own listener and authentication settings. Before rollout, confirm in the feature matrix which SSO connector your edition supports, since Community Edition single sign-on is limited to GitHub and the Enterprise connectors change the identity work.

Pomerium implementation time goes mostly into route and policy design. Each internal web app needs a route, a public or internal hostname, and a policy that says who may reach it, and these are often written without an owner. The identity provider setup (for example Keycloak, Microsoft Entra ID or Okta, all listed in Pomerium's identity provider documentation) must match the claims the policies depend on. Where services need mTLS between hops or Kubernetes ingress through the Pomerium Ingress Controller, the certificate and ingress configuration adds a separate workstream. With Pomerium Zero, the team also sets up the hosted control plane and connects the self-run Core cluster to it, while application traffic stays in its own environment. Confirm early which features your plan includes, because directory sync, Rego policies and SSH session recording are reserved for Enterprise.

Three delays appear in both projects and are worth planning for. The first is unmapped identity groups: directory groups that do not match a Teleport role or a Pomerium policy block access on the first day, and fixing them usually means revisiting the access model. The second is legacy protocols, such as older SSH clients, shared service accounts or non-HTTP applications that do not fit a web proxy, and each one needs a decision to keep, replace or exempt it. The third is unclear ownership of policies. When no one is named to approve route and role changes, exceptions accumulate and the access model drifts. Ask any implementation partner for a written scope that lists these items, the owner of each policy set, and the acceptance tests for SSO and access logs.

Questions buyers ask before choosing a platform or hiring help

Can Pomerium replace Teleport for SSH access?

Only for some SSH use cases. Pomerium Zero plans include native SSH, TCP and UDP access through the Pomerium CLI or desktop app, and SSH session recording and playback is reserved for Pomerium's Enterprise edition. Teleport is built around SSH, Kubernetes, databases and Windows hosts, with its own certificate authority issuing short-lived certificates and full compatibility with OpenSSH servers and clients. If your core need is shell access to a fleet of servers with recorded sessions, test both against your own hosts, confirm which recording features your edition includes, and check how each handles certificate lifetimes and host key trust before deciding.

Which edition do we need for corporate single sign-on?

It depends on which identity provider you use and which product you choose. Teleport's feature matrix limits Community Edition single sign-on to GitHub, while Enterprise supports Google Workspace, Microsoft Entra ID, Okta, SailPoint, OIDC and SAML. Pomerium uses OAuth 2.0 and OIDC for user identity and documents providers including Microsoft Entra ID, Okta, Google and Keycloak, and Pomerium's Enterprise edition reserves directory sync and RBAC for administrators. Confirm the exact provider and protocol your organization requires against the current feature matrix or pricing page, and ask the vendor to show the edition in writing before you rely on it.

What drives implementation effort, and what should we ask for in a fixed-scope quote?

Effort is driven by the number and type of resources to protect (SSH nodes, Kubernetes clusters, databases, Windows hosts or internal web apps), the identity provider integration, the policy model, the number of clusters or routes, and the recording and audit requirements. DeployOpen plans, implements and documents self-hosted platforms in your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. Ask for the resource inventory the quote assumes, the identity provider and edition it covers, who handles certificate or key rotation, what testing and handover are included, and which items are one-time versus ongoing retainer work.

Can our own team run this without outside help?

A capable platform team can run either product, but the answer depends on skills and capacity. Teleport runs as a single Go binary or a Kubernetes Helm deployment and relies on certificate-based access, so your team needs to manage the certificate authority, roles and access requests. Pomerium Core is Apache-2.0 and self-run, while Pomerium Zero moves the control plane to Pomerium's hosted environment with the cluster still in your environment. Assess your staff's experience with SSH certificates, reverse proxies, identity protocols and on-call coverage, then decide whether you want DeployOpen for implementation, hardening or ongoing support retainers.

How do we confirm license eligibility for Teleport Community Edition?

Start with the Teleport Community Edition license text, which limits distributed builds to organizations with fewer than 100 employees and less than $10,000,000 in annual revenue, with an exception for designated critical security patch versions. Compare your headcount and revenue against those thresholds using the terms in force on the date you deploy, and ask your legal or procurement team to review how affiliates and contractors are counted. If you exceed either threshold, you need to discuss Enterprise licensing with Teleport directly before going into production.

Does Pomerium Core or Teleport fit a compliance audit better?

Neither product certifies compliance, and DeployOpen does not issue audit reports or certifications. Both can produce logs and access records that auditors may review, but the evidence you need depends on the controls in scope. Teleport offers session recording with playback in both editions, while moderated sessions, dual authorization and FIPS binaries are Enterprise features, and Pomerium reserves SSH session recording for its Enterprise edition. Ask the independent auditor which evidence they expect, then confirm which edition delivers it and document the configuration as part of readiness work.

What happens if we switch from one product to the other later?

Switching cost comes from policies, roles, identity mappings, routes and the audit history you need to keep. Teleport's access model is built on its own certificate authority and roles, while Pomerium expresses access as routes and policies, so the rules do not translate one to one. Plan the migration by inventorying every protected resource, mapping roles to policies, running both systems in parallel for a test group, and confirming that session records or access logs are retained in the format your auditors require. Ask for a migration plan in the written scope before committing.

How DeployOpen helps choose, implement or migrate

DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens and documents self-hosted open-source platforms inside your own infrastructure. For a Teleport vs Pomerium decision, we start by confirming which access patterns your team needs, then build and hand over only what the written scope covers.

How we scope

Inventory which SSH, Kubernetes, database, desktop and internal web app targets need access, and which users reach them
Confirm the identity provider, the edition you need for SSO and whether session recording must be moderated
Agree the scope, deliverables and timeline in writing before any work starts, since most engagements are fixed-scope

How we build

Deploy the chosen platform in your cloud account, data center or air-gapped network, with your own identity provider connected
Write access policies and roles for each resource type, then test them against the users and groups you defined
Run security testing against the deployment and record the configuration needed for your own compliance evidence

How we hand over

Document the architecture, configuration, certificate or route setup, and the licensing and edition limits that apply to your organization
Walk your administrators through daily operations, including user onboarding, policy changes and session log review
Deliver backup, upgrade and runbook documentation so your own team can operate the platform after handover

How we support

Provide upgrades and patching for the platform version you run, scheduled with your change process
Offer ongoing support and continuous testing as a retainer, separate from the initial fixed-scope work
Reassess the setup when your edition, identity provider or resource footprint changes, and confirm the new scope in writing

Teleport vs Pomerium