Free licence, expensive operations
Nobody bills you for Keycloak. You pay in the engineer who owns upgrades, the weekend spent on a realm migration, and the specialist knowledge that leaves when they do.
Identity & access · Straventa Accounts
A Keycloak alternative for teams who want the support contract
If you are running Keycloak you already agreed with the architecture — identity belongs in your own infrastructure. The problem is not the licence, which is free. It is that you are the vendor: you own the upgrades, the realm design, the tuning, and the incident at 03:00, and the escalation path is a forum thread. Straventa Accounts keeps the self-hosted posture and puts a named engineering team behind it.
Why teams move
What actually pushes organisations off Keycloak
The 03:00 escalation path is a forum
When sign-on is down for the whole organisation, community support is not a support tier. There is no one whose contract obliges them to pick up.
Realms are isolated, not hierarchical
A holding company modelled as separate realms gets isolation but no inherited scoping, so group-level administration and access review are rebuilt by hand in every realm.
Every integration is a project
Keycloak authenticates. Wiring it into your payments, operations, and back-office systems, and keeping permissions consistent across them, is work you scope and own.
What does not carry over
Keycloak ships SAML 2.0 alongside OIDC and has a large extension ecosystem. Straventa Accounts ships OpenID Connect and OAuth 2.0 only — no SAML, no SCIM, no live LDAP sync today. If your estate depends on Keycloak's SAML support or on custom provider extensions you have written, that is a real migration cost and we would rather size it with you honestly than discover it late. What you gain is a support contract, a native tenant hierarchy, and an identity layer the rest of the Straventa platform already authenticates against.
Straventa vs Keycloak
Straventa Accounts compared with Keycloak
Written for the person who has to defend the choice in a board pack. Competitor rows describe each vendor's publicly documented model at time of writing.
| Criterion | Straventa Accounts | Keycloak (self-run) |
|---|---|---|
| Deployment model | Self-hosted on your Kubernetes or Docker, or Straventa-managed at accounts.straventa.com. Your choice, same product. | Self-hosted only. |
| Where identity data lives | Your infrastructure, in Indonesia. Nothing leaves your environment on the self-hosted deployment. | Your infrastructure. |
| Pricing model | Per deployment, annual. Not per seat — headcount growth does not change the invoice. | Free licence; you pay in engineering time. |
| Who operates it | You, or Straventa under contract. Start managed and take it in-house later without re-platforming. | You. Entirely. |
| Who answers at 03:00 | A named Straventa engineering contact, on terms set in your contract, in your timezone. | A community forum. |
| Protocols | OpenID Connect / OAuth 2.0 — PKCE, discovery, JWKS. SAML and SCIM are not shipped today; see the FAQ. | OIDC and SAML. |
| Multi-tenant / group structure | Native tenant hierarchy with descendant-scoped permissions — built for holdings with subsidiaries. | Realms, isolated — no inherited scoping. |
| Ships integrated with your payments and ops stack | Yes — Payops and the Ops platform already authenticate against it and resolve permissions through it on day one. | An integration project. |
| Exit cost | Standard OIDC. Your apps point at an issuer URL — repoint them and leave. | Low. |
Competitor rows describe each vendor’s publicly documented model at time of writing; confirm current terms with the vendor before making a decision.
Migration
Moving off Keycloak, without a flag day
Both systems run in parallel until the last application is across. There is no single evening on which everything has to work.
Step 1 Audit your realms and any custom extensions
Map realms to the tenant hierarchy and list every custom provider or SPI extension you rely on. This is the step that determines whether the move is straightforward or interesting.
Step 2 Deploy Accounts alongside your Keycloak
Same infrastructure, same posture. Both run in parallel while you validate, so there is no window where sign-on depends on an untested system.
Step 3 Move clients over per realm
OIDC clients repoint at the Accounts issuer. Because both speak standard OpenID Connect, this is a configuration change on the application side.
Step 4 Hand operations over
Upgrades, tuning, and the on-call move onto the support contract. Your engineer stops being the identity vendor.
Straight answers
Questions we get from Keycloak teams
- Why pay for something we already run for free?
- Because the licence was never the cost. The cost is the engineer who owns upgrades and realm design, the incident with no escalation path, and the concentration of that knowledge in one person. If your team genuinely enjoys operating Keycloak and has depth behind that person, staying put is a perfectly rational decision and we will tell you so.
- Can we still self-host? We are not moving to SaaS.
- Yes — self-hosted inside your own Kubernetes or Docker is the primary deployment. Nothing about the support contract requires handing over the deployment. Straventa-managed exists for organisations that want it; it is an option, not the direction.
- What about our custom Keycloak extensions?
- They do not carry over — they are Keycloak SPIs. During the audit we list what each one does and decide whether it is a configuration in Accounts, a small piece of work, or a genuine blocker. If it is a blocker we will say so before you commit, not after.
Keep the architecture. Add the phone number.
Bring your realm layout and your extension list. We will tell you honestly whether the move is worth it for your team, including when the answer is no.