Keycloak works. Until running it stops being fun.
Keycloak is the right answer for a lot of teams — it is battle-tested, Red Hat-backed, and genuinely free. WeldForge is for the teams whose answer to "who's upgrading Keycloak this quarter?" is a long pause. Same OIDC + SAML wire protocols, a smaller footprint, SCIM and PKI and audit webhooks in the box, and a hosted option so nobody has to be the Keycloak person.
If Keycloak is working for you, don't switch
Seriously. Keycloak is a mature platform with over a decade of production deployments, a massive community, good docs and a commercial support path via Red Hat. If your platform team knows it, if upgrades are smooth for you, and if realms map cleanly to your tenancy model — keep it. You're not leaving money on the table.
But most teams we talk to didn't choose Keycloak for its features — they chose it because it was free and open-source. And they didn't know the real cost was somewhere else: the engineering time it takes to operate it safely. That's what this page is about.
The three reasons teams actually migrate
Upgrade pain
Keycloak major-version upgrades have broken custom themes, SPIs, realm schemas and storage backends at least three times in the last five years (the Quarkus migration being the sharpest). If your only identity engineer is the one who remembers how to survive the next one, you are one resignation away from a crisis.
Missing features you had to build
Keycloak ships OIDC, SAML and user federation. It does not ship SCIM (community extension), PKI, HMAC-signed audit webhooks, or a multi-tenant control-plane above realms. If you've written SPIs for any of those — and bear the maintenance cost — WeldForge ships them in the base tier.
"Nobody wants to run it any more"
The single most common reason we hear. Keycloak wants JVM + database + Infinispan cache + reverse proxy + theme-compile pipeline + upgrade testing lane + on-call. If your team would rather ship product than babysit an IdP, the managed option is the decision.
Feature-for-feature
What's in the box on each side. ✓ = included, + = available via community extension or SPI you maintain, — = not offered.
| Capability | Keycloak (community) | WeldForge |
|---|---|---|
| OAuth 2.0 / OpenID Connect issuer | ✓ | ✓ |
| SAML 2.0 Service Provider | ✓ | ✓ |
| SAML 2.0 Identity Provider | ✓ | ✓ |
| LDAP / Active Directory upstream | ✓ | ✓ |
| Kerberos / GSSAPI | ✓ | — not planned |
| MFA — TOTP / WebAuthn / FIDO2 | ✓ | ✓ |
| SMS OTP | + via SPI or theme extension | ✓ (Twilio pass-through) |
| Social login (Google, Microsoft, GitHub, Apple, …) | ✓ | ✓ |
| User federation (custom storage) | ✓ | + via webhooks |
| SCIM 2.0 (inbound + outbound) | + community extension | ✓ built in |
| Internal PKI — per-tenant CA, CRL, OCSP | — | ✓ built in |
| HMAC-signed outbound audit webhooks | + custom SPI | ✓ built in |
| Group-to-role binding with priority | + scripted (deprecated) or custom SPI | ✓ built in, admin-portal UI |
| Scoped API keys (path + method) | — | ✓ built in |
| Service-account tokens with admin role | Client credentials only | ✓ with admin role + expiry |
| Password policies (length, complexity, history) | ✓ | ✓ |
| Customisable login themes | ✓ (FreeMarker + CSS) | ✓ (CSS + logo; no template engine) |
| Multi-tenancy | ✓ via realms (heavier per-tenant) | ✓ application-layer (one schema, tenant-scoped queries) |
| Admin portal UI | ✓ (jQuery-era, recently replaced) | ✓ (Angular 21, per-tenant) |
| First-party managed cloud | — Red Hat SSO is on-prem subscription | ✓ from $29/mo |
| POPIA-native data residency | Bring your own hosting | ✓ Cape Town region |
| Licence | Apache 2.0 | Source-available (commercial) |
| Commercial support path | Red Hat SSO (per-socket, opaque pricing) | Transparent tiers |
The short version: Keycloak has a larger feature surface for edge cases (Kerberos, custom storage SPIs, deep theme customisation). WeldForge has more things built-in for the 90% case (SCIM, PKI, audit webhooks, scoped API keys) plus a managed-cloud option Keycloak doesn't offer directly.
Total cost of ownership
Both Keycloak and WeldForge are free to self-host. The honest comparison isn't licence fees — it's what running the thing costs you.
| Cost driver | Keycloak self-host | WeldForge self-host | WeldForge Cloud Business |
|---|---|---|---|
| Infrastructure (2-node HA + Postgres) | ~$180 / mo JVM nodes need 2–4 GB each | ~$120 / mo smaller footprint | included |
| Engineering time — ops (cluster, cache, upgrades) | ~20% of 1 FTE ~$40 000+ / yr | ~10% of 1 FTE ~$20 000 / yr | 0 |
| Engineering time — extensions (SCIM / webhook / audit SPIs) | 6–12 weeks one-off maintenance thereafter | 0 built in | 0 |
| Commercial support | Red Hat SSO: contact for quote typical $5–15k / socket / yr | Self-Host Supported: $249 / mo | included |
| Upgrade risk absorbed by vendor | No major versions occasionally break things | Partial we publish migration notes | Yes we roll forward |
| Effective yearly cost at 10 000 MAU | ~$42 000+ | ~$23 000+ | $8 388 |
Migrating from Keycloak
The good news: Keycloak and WeldForge speak the same standard protocols on the wire (OIDC, SAML 2.0). Applications that talked to Keycloak keep working by changing an issuer URL. The actual data migration is 3 steps.
Step 1 — Export the Keycloak realm
Keycloak ships a CLI export. Run against a stopped server for a consistent snapshot:
./kc.sh export --dir /tmp/keycloak-export \
--realm acme \
--users realm_file
You get acme-realm.json and
acme-users-0.json. Keycloak's user export includes
password hashes (PBKDF2-SHA256 by default) which WeldForge
accepts natively — no password resets required.
Step 2 — Create the WeldForge tenant
curl -X POST $HOST/api/admin/tenants \
-H "x-app-authorization: $TOKEN" \
-H "Content-Type: application/json" \
-d '{"slug":"acme","name":"Acme Corporation"}'Step 3 — Run the Keycloak import converter
The converter maps Keycloak's realm JSON to WeldForge's admin-API shape: users → users, clients → oidc-clients, client scopes → custom claims, identity providers → SAML SPs / social providers, roles → admin roles or group-role mappings. Bulk-imports run in a single transaction so the cut-over is atomic.
curl -X POST $HOST/api/admin/migrate/keycloak \
-H "x-app-authorization: $TOKEN" \
-H "Content-Type: application/json" \
--data-binary @keycloak-export-acme-realm.jsonStep 4 — Update issuer URLs in every client
Change the OIDC issuer from
https://keycloak.example.com/realms/acme to
https://sso.weldforge.org/t/acme. The
/.well-known/openid-configuration document has the
same shape in both platforms — your OIDC libraries don't
need to change.
Step 5 — Decommission Keycloak
Keep Keycloak running read-only for a 30-day grace period so you can fall back if something goes sideways. No traffic should reach it after the DNS cut-over. Then tear down the cluster, retire the oncall rotation, and go ship product.
When you should NOT switch
Being honest about where Keycloak remains the better answer.
You rely on Kerberos / GSSAPI
Keycloak has first-class Kerberos ticket-forwarding. WeldForge doesn't, and it's not on the roadmap. If your workforce auth flows through a Windows AD forest with Kerberos SSO, Keycloak stays.
You have heavy User Storage SPIs
Keycloak's User Storage SPI lets you back a realm with arbitrary custom storage (mainframes, bespoke HR systems). If you've built one, WeldForge's equivalent is outbound webhooks + SCIM — a different pattern. Migrating the SPI to webhooks is real work.
You are a Red Hat customer
If your org has a Red Hat enterprise agreement, Red Hat SSO may be bundled or deeply discounted. We can't beat bundled zero.
You want deep theme customisation
Keycloak's FreeMarker themes let you ship a fully bespoke login flow with server-side rendering. WeldForge's customisation is CSS + logo + custom claims. If your brand needs pixel-perfect per-tenant login pages with server-side logic, Keycloak is deeper.
FAQ
Will my users need to reset their passwords?
No. Keycloak's default PBKDF2-SHA256 hashes import into WeldForge natively. Legacy Keycloak deployments using bcrypt or scrypt also carry over cleanly. Users sign in with their existing password the moment after DNS cut-over.
Do my existing OIDC-integrated apps keep working?
Yes. WeldForge's OIDC discovery document is standard — change the issuer URL in each app's config and you're done. The token format, userinfo payload and logout flow are all spec-compliant.
What happens to my realm-level admins?
Realm admins map to WeldForge's TENANT_ADMIN role. Master-realm admins map to SUPER_ADMIN. The migration tool preserves the role assignment per user.
How does WeldForge compare to Red Hat SSO specifically?
Red Hat SSO is Keycloak with Red Hat's support contract plus curated release cadence. The feature set is effectively Keycloak + Red Hat's backport list. If you're paying per-socket for RHSSO and don't use the Red Hat ecosystem, WeldForge Cloud typically comes in 60–80% cheaper with more features bundled.
Can I self-host WeldForge the way I self-host Keycloak?
Yes — the Developer tier is free and runs as a Spring Boot jar or container. Docker Compose for dev, Kubernetes manifests for production. Smaller footprint than Keycloak (~512 MB per pod vs 2-4 GB for Keycloak).
Will you support Kerberos eventually?
Not planned. The overlap between "needs Kerberos" and "wants a managed IdP in Cape Town" is small enough that the engineering cost isn't justified. If Kerberos is non-negotiable, Keycloak is the better answer — we'll tell you that up front.