Managed Keycloak hosting

Collaboration and identityOn-prem or your region

Single sign-on for everything else you run, with your own directory as the source of truth and no per-seat bill between you and it. Pilae runs it on your own servers, or in Zurich, Switzerland, and eleven other Pilae Cloud regions.

Talk to us about Keycloak

Licence: Apache-2.0
Runs on: Your own hardware, or any of 10+ Pilae regions — six of them in Switzerland and the EU
Upgrades: Pinned, tested against your configuration, applied in your window
Upstream: www.keycloak.org

Running Keycloak in production: what it takes

Pin and deploy
A version we have run, on your machine or in a region you pick, behind TLS, with the database separated from the application from the first day.
Import the realm
Your realm is a file we hold in your repository. Rebuilding this deployment somewhere else is an import, not an afternoon of clicking through an admin console.
Federate and test
The directory is bound read-only and we test the paths that actually break — a leaver losing access, a group change reaching an application, a token expiring mid-session.
Back up and prove it
The database and the realm export go offsite nightly. Once a month we restore them into a scratch environment and sign in against the restored copy.
Patch in your window
Keycloak ships often and its upgrades touch token handling. We test each one against your realm in staging, then apply it in the window you agreed, with the previous version ready to come back.

What Keycloak is, and who runs it

Keycloak is an identity server. Applications hand it the job of asking who someone is: it runs the login page, checks the password or the second factor, and returns a signed token the application can trust. It speaks OIDC and SAML, so the new internal tool and the fifteen-year-old system that only does SAML can sit in the same realm.

It is the piece that makes the rest of a self-hosted stack coherent. Without it, every application you run keeps its own user list, and removing someone who leaves means remembering all of them. With it, there is one directory, one place to revoke an account, and one audit trail of who signed in to what.

Red Hat builds it and ships it as the upstream of their commercial product, which is why it has the enterprise features — directory federation, fine-grained authorisation, token exchange — that smaller identity servers leave out. It is Apache-2.0, with no seat count and no edition that unlocks single sign-on as a paid tier.

The cost is operational. Keycloak is a Java application with a database behind it, it releases often, and its upgrades have historically changed how tokens and clients behave. A realm that nobody can rebuild from a file is a single point of failure, and a signing key nobody has a backup of takes every application down with it. That is the part we take: a pinned version, a realm you can export, a database that gets restored on a schedule, and upgrades tested against your own configuration before they reach it.

Keycloak system requirements

Before anything is deployed, this is what has to exist. We size it with you in the first session, and we say so when your own hardware is already enough.

CPU and memory: 2 vCPU · 4 GBTwo is enough for a single node; the memory is what a federated directory of any size wants.
Database: PostgreSQLEvery realm, session and token signing key lives here, so this is the thing that gets backed up.
Directory: LDAP or Active DirectoryRead-only, and optional. Without it you are managing users in two places.
Mail: SMTP relayFor password resets and address verification.
DNS and TLS: 1 hostnameCertificate issuance and renewal are automated end to end. The token issuer URL derives from this name and is painful to change later, so it is chosen once.

Migrating from Okta to Keycloak

Moving off Okta is mostly a mapping exercise, not a data migration: users come from your directory in both cases, so what actually moves is the application wiring. We inventory every client, rebuild them as a Keycloak realm you can export as one JSON file, and run both identity providers side by side until the last application has been repointed. Passwords do not come across: no hosted identity provider will export them. So either your people keep signing in with the password that already lives in your directory, or everyone resets once. We tell you which applies before you commit.

Inventory the clients
Every application currently trusting Okta, with its redirect URIs, scopes and claim mappings. This is the list that decides how long the rest takes.
Build the realm
Clients, roles, groups and claim mappers rebuilt in a realm you can export as one file. It lives in your repository from the first day, not ours.
Federate the directory
LDAP or Active Directory bound read-only, so accounts keep coming from where they already come from and leavers still leave.
Run both, then cut over
Applications repoint one at a time with Okta still live behind them. When the list is empty, the old tenant is switched off — not before.

Keycloak realm export: the whole configuration in one file

{
  "realm": "acme",
  "enabled": true,
  "sslRequired": "all",
  "accessTokenLifespan": 300,
  "ssoSessionIdleTimeout": 1800,
  "clients": [
    { "clientId": "nextcloud",  "protocol": "openid-connect" },
    { "clientId": "outline",    "protocol": "openid-connect" },
    { "clientId": "legacy-erp", "protocol": "saml" }
  ],
  "userFederation": [
    { "providerId": "ldap", "editMode": "READ_ONLY", "vendor": "ad" }
  ]
}

The shape of a realm export — clients, token lifetimes and the directory binding, in one file kept in your repository. Rebuilding the deployment elsewhere is an import, not an afternoon in an admin console.

What Pilae is responsible for

A pinned version

A version we have run, not whatever latest resolves to that day.

A runbook

What it depends on, how it fails, what to do about it. In your repository.

A restore drill

Backups restored on a schedule. A backup nobody has restored is a file.

A patch window

Security updates in a window you agreed, with a rollback ready.

Someone watching

Every endpoint probed on the minute. An alert reaches a person, not a dashboard nobody opens.

Where it runs: zur1, fra1, fal1, gra1, ams1, hel1, lon1, ash1, hil1, sin1, tok1, syd1, on-premZurich, Frankfurt, Falkenstein, Gravelines, Amsterdam, Helsinki, London, Ashburn, Hillsboro, Singapore, Tokyo, Sydney, Your own hardware
Who holds the credentials: You do. Ours are separate, named, logged and revocable with one command. We ask before anything changes outside an agreed window.
If you leave: The machine, the data, the compose files and the runbook are already yours. Nothing stops when our access does.

What running Keycloak costs

On Starter, Keycloak runs in Pilae Cloud for CHF 449EUR 479USD 559 a month, hosting and onboarding included. On Business, it is one of up to three apps for CHF 1,590EUR 1,690USD 1,990 a month, on your own servers or in Pilae Cloud. Enterprise is quoted. The plans set what each includes; these are the inputs that move the price around them.

Instance size: The CPU, memory and, where a model runs, the GPUs the app needs for your users and your data.
High availability: One machine with tested restores, or a replicated setup that keeps serving when a node fails.
Storage and backups: How much data it holds, how long backups are kept, and point-in-time recovery for its database.
Plan and support: Starter, Business or Enterprise: support hours, response times in the contract and how often we review the service with you.
Region: Your own hardware, where the infrastructure is already yours, or a Pilae Cloud region, where machines are priced per month. On Starter, Pilae chooses the site.
Sign-on and integrations: Single sign-on, directory sync, mail relays and the other systems the app has to reach.

Keycloak: common questions

Can Keycloak use our existing Active Directory?

Yes, and it usually should. Keycloak federates LDAP and Active Directory read-only, so accounts stay governed where they already are and Keycloak becomes the thing applications talk to rather than a second place to create users.

What happens to our Okta passwords?

They do not come across. No hosted identity provider exports password hashes. So either the cutover uses your directory, where the password already lives, or everyone resets once. If you federate a directory, most people never notice a change.

Keycloak upgrades are known to break things. How do you handle them?

That is fair: releases have changed token handling and deprecated client settings between major versions. We pin a version, run each upgrade against a copy of your realm in staging first, apply it in your window, and keep the previous version one command away.

Who can see our realm and our signing keys?

You hold them. Our access is separate, named and logged, and revoking it is one command on your side. The realm export and the database are in your repository and your backup target, not ours.

Does this work if our applications only speak SAML?

Yes. Keycloak does OIDC and SAML in the same realm, which is usually why it wins over rebuilding everything around one protocol. Older SAML clients need their assertion signing checked after a major upgrade, and that is part of the staging test.

Back to apps

Bring us your Keycloak. We will tell you what it takes.

Thirty minutes on the deployment you already have, or the one you are about to start.

Start with one workload Book a 30-minute briefing