On this page

Self-hosted & enterprise

Your infra, your data, your control. Anyport is available as a self-hosted solution for enterprises that want the platform running on-prem or in their own cloud. You get the same development and deployment experience (projects, apps, secure access, cost control) while keeping the Anyport platform itself inside your boundary. No data leaves your perimeter unless you choose.

What you get#

Platform on your side — Run the Anyport platform (dashboard, API, and supporting services) in your own infrastructure. On-prem data centers, private cloud, or your VPC—you decide where it lives.
Enterprise-grade — Same capabilities as the managed offering: bring your own clusters, spin up projects, deploy apps, pause to save cost, RBAC, and publishing apps over HTTPS from servers with no public IP. With the added guarantee that the control plane is under your control. The one exception is Anyport Cloud, which runs on Anyport's hardware and is part of the hosted service only.
Compliance and data residency — Keep metadata, tokens, and audit data within your boundary. Useful for regulated industries or policies that require the platform to be hosted on-prem.
Your clusters + your platform — You already bring your own clusters; with self-hosted, you also host the platform. End-to-end on the infra you own or lease.

So: enterprise-grade deployment and security, with the platform running where you need it.

How it works#

You deploy the Anyport platform (e.g. via our Helm chart or install guide) into your project. Once it's running, your team uses the same Anyport app—pointed at your instance—to connect clusters, create projects, and deploy apps. The agent still runs on your clusters; the only difference is that the dashboard and API run in your infra instead of ours. You get updates and support; we don't see your data unless you opt in.

Signing in with your identity provider#

A self-hosted console does not come with accounts of its own. It trusts one OpenID Connect issuer, which is where your team signs in: your Keycloak, Microsoft Entra ID, Okta, Zitadel, Authentik, or any other compliant provider. Point the console at it and single sign-on is the only way in. There is nothing to buy and no enterprise tier; it is how the product authenticates.

The console reads two things from the issuer, both found through OpenID discovery: the signing keys, to validate the access token the browser brings back, and the userinfo endpoint, to fill in a name or an address the token left out. It holds no client secret of its own, so the browser-side client is public and uses PKCE.

Six values in the Helm chart configure it. Three the browser sees, three the API checks:

Value	What it is
`NEXT_PUBLIC_OIDC_ISSUER` and `OIDC_ISSUER`	The issuer URL, exactly as the provider writes it in the token's `iss` claim. The API compares the two strings and never normalises, so a trailing slash the provider does not emit fails every sign-in with an issuer error. Keycloak and Entra emit none; Auth0 emits one.
`NEXT_PUBLIC_OIDC_CLIENT_ID`	The public client registered for the console, with `https://<your console>/auth/callback` as its redirect URI.
`OIDC_AUDIENCE`	What the provider puts in the access token's `aud` claim. This is where most setups go wrong, because providers do not put the client id there by default; see each provider below.
`NEXT_PUBLIC_OIDC_AUDIENCE`	Only for providers that mint an opaque access token unless an API is named on the authorize request (Auth0, Zitadel). Leave it empty for Keycloak and Authentik, which reject the unknown parameter.
`NEXT_PUBLIC_OIDC_SCOPE`	Defaults to `openid profile email`. Add a scope here when the provider needs one to mint a token for the API.
`NEXT_PUBLIC_OIDC_PROVIDER_NAME`	Names the button: "Continue with Keycloak". Leave it empty for a provider your people don't know by name, and the button reads "Sign in or create an account".

The access token must be an RS256 JWT. A provider that signs with another algorithm, or that mints opaque tokens for a client with no API scope, produces a token the console cannot verify.

Keycloak#

Verified against Keycloak 26.3 with the console's own validator.

In your realm, create a client anyport-console: OpenID Connect, client authentication off, standard flow on, PKCE S256, valid redirect URI https://<your console>/auth/callback, web origin https://<your console>.
Add an Audience mapper to the client (Client scopes → anyport-console-dedicated → Add mapper → Audience) with Included Client Audience anyport-console and Add to access token on. Without it Keycloak's access tokens carry only aud: account, and a console configured with the client id as its audience refuses every one of them. Setting OIDC_AUDIENCE to account also works, and is the wrong way round: it accepts a token minted for any client in the realm.
Make sure users have a verified email in Keycloak, or the console will ask each person to confirm their address by mail before they can do anything.

envVars:
  OIDC_ISSUER: "https://id.example.com/realms/anyport"   # no trailing slash
  OIDC_AUDIENCE: "anyport-console"
ui:
  env:
    NEXT_PUBLIC_OIDC_ISSUER: "https://id.example.com/realms/anyport"
    NEXT_PUBLIC_OIDC_CLIENT_ID: "anyport-console"
    NEXT_PUBLIC_OIDC_PROVIDER_NAME: "Keycloak"

Keycloak brokers SAML on the console's behalf: an identity provider added to the realm (an enterprise SAML IdP, Google, GitHub) shows up as a button on Keycloak's login page, and the console never sees SAML at all.

Microsoft Entra ID#

Written from Microsoft's documentation; not run against a tenant.

Register an application (single tenant), add a Single-page application platform with redirect URI https://<your console>/auth/callback.
Under Expose an API, set the Application ID URI (api://<application id>) and add a scope, for example console. In the app manifest set requestedAccessTokenVersion to 2, so the access token is a v2 token whose issuer is the /v2.0 URL below rather than https://sts.windows.net/….
Under Token configuration, add the optional claim email to the access token. Entra does not assert that an address is verified, and its userinfo endpoint answers only to a Microsoft Graph token, so each person confirms their address once with the mail the console sends. The chart's mail settings therefore have to be filled in.

envVars:
  OIDC_ISSUER: "https://login.microsoftonline.com/<tenant id>/v2.0"
  OIDC_AUDIENCE: "api://<application id>"
ui:
  env:
    NEXT_PUBLIC_OIDC_ISSUER: "https://login.microsoftonline.com/<tenant id>/v2.0"
    NEXT_PUBLIC_OIDC_CLIENT_ID: "<application id>"
    NEXT_PUBLIC_OIDC_SCOPE: "openid profile email api://<application id>/console"
    NEXT_PUBLIC_OIDC_PROVIDER_NAME: "Microsoft"

Without the API scope in NEXT_PUBLIC_OIDC_SCOPE, Entra mints an access token for Microsoft Graph, which is signed for Graph and fails validation.

Okta#

Written from Okta's documentation; not run against an org.

Use a custom authorization server (the default one is fine): the org authorization server mints opaque access tokens that only Okta itself can check. Create a native or single-page OIDC application with PKCE and the console's redirect URI, and assign the people who should sign in.

envVars:
  OIDC_ISSUER: "https://<org>.okta.com/oauth2/default"
  OIDC_AUDIENCE: "api://default"       # the authorization server's audience setting
ui:
  env:
    NEXT_PUBLIC_OIDC_ISSUER: "https://<org>.okta.com/oauth2/default"
    NEXT_PUBLIC_OIDC_CLIENT_ID: "<client id>"
    NEXT_PUBLIC_OIDC_PROVIDER_NAME: "Okta"

Okta's userinfo endpoint accepts the access token, so the name, address and email_verified arrive from there even though the access token itself carries only the subject.

Auth0#

The hosted console runs on Auth0, so this is the most exercised path. Create a Single Page Application and an API; the API's identifier is the audience.

envVars:
  OIDC_ISSUER: "https://<tenant>.<region>.auth0.com/"   # Auth0 emits the trailing slash
  OIDC_AUDIENCE: "https://api.example.com"               # the API identifier
ui:
  env:
    NEXT_PUBLIC_OIDC_ISSUER: "https://<tenant>.<region>.auth0.com/"
    NEXT_PUBLIC_OIDC_CLIENT_ID: "<client id>"
    NEXT_PUBLIC_OIDC_AUDIENCE: "https://api.example.com"

Checking a setup#

The console logs JWT validator initialized with the issuer at start, and a refused token as Failed to validate JWT token with the claim that failed: invalid issuer claim (iss) is the trailing-slash mismatch, invalid audience claim (aud) is the audience configured on one side and not the other. Both are visible in kubectl logs of the console deployment before anyone opens a ticket.

Who it's for#

Enterprises — Need the platform on-prem or in a dedicated tenant for policy or compliance.
Regulated industries — Data residency or audit requirements that mean the control plane must sit inside your boundary.
Teams that want full control — You bring your own infra for both workloads and the platform; we simplify how you develop and deploy on it.

Summary#

What	What you get
Self-hosted platform	Run the Anyport dashboard and API in your own infrastructure (on-prem or your cloud).
Enterprise-grade	Same features, RBAC, and security; platform under your control.
Your data, your boundary	Metadata and control plane stay where you host them; no data leaves unless you choose.

Bring your own infra—including the platform. Contact us or check the docs for the self-hosted install path.

Next steps#

Architecture — How Anyport fits together and the value of bringing your own infra.
Connecting clusters — Connect your clusters to your Anyport instance (managed or self-hosted).
Quick start — Get going with a connected cluster and your first project.