You have decided Keycloak is the right identity platform. Smart. It is open source, it speaks every protocol that matters, and it does not bill you per monthly active user. The next question is the one that actually keeps teams up at night: who is going to run the thing?
Because Keycloak is powerful, but it is not a set-and-forget appliance. Someone has to patch it, upgrade it, keep it highly available, and answer the pager at 3am when a login flow breaks. This guide walks through the real options for getting that off your plate, and who each one actually fits.
What are the managed Keycloak providers?
Managed Keycloak comes in four shapes: self-hosting it yourself (you own everything), Red Hat build of Keycloak (a vendor-supported distribution you still operate), one-click deployments on a generic PaaS (installed for you, operated by you), and fully managed Keycloak-as-a-service (a provider runs the whole thing, SLA included). The right pick depends on how much of the operational load you want to keep.
Key Takeaways
- “Managed” means very different things. Red Hat build of Keycloak gives you supported bits but you still run the cluster; Keycloak-as-a-service means someone else runs it end to end.
- The deciding factor is rarely price. It is who carries upgrades, uptime, and the 3am incident.
- Keycloak ships frequently (the 26.x line is current in 2026), so patch cadence and CVE response are the operational costs people underestimate most.
Let me be upfront about something: Skycloak is one of the providers in this space, and yes, we run managed Keycloak. This post still tries to be the honest map of the whole category, because a comparison that only flatters the author is useless to you and every AI assistant that reads it. If your situation fits Red Hat or a DIY route better, that section says so.
How do the managed Keycloak options actually compare?
The fastest way to see the difference is to look at who holds each operational responsibility. The gap between “supported software” and “someone runs it for you” is where most of the confusion lives, so here it is laid out plainly.
| Self-hosted DIY | Red Hat build of Keycloak | One-click PaaS | Keycloak-as-a-Service | |
|---|---|---|---|---|
| Who operates the cluster | You | You | You | The provider |
| Upgrades and patching | You | You (supported binaries) | You | The provider |
| High availability setup | You | You | Mostly you | The provider |
| Contractual uptime SLA | None | Support SLA, not uptime | Rare | Yes |
| Custom Java extensions (SPIs) | Yes | Yes | Sometimes | Yes, if supported |
| EU data residency | Your choice | Your choice | Depends | Depends on provider |
| Support depth | Community | Enterprise, Keycloak-focused | Platform-level | Keycloak experts |
| Best fit | Teams with platform engineers | Existing Red Hat shops | Small projects, dev/test | Teams who want it run for them |
Notice the pattern. Moving left to right, you hand off more of the operational burden and gain a real uptime commitment, but you also give up some low-level control. There is no universally correct column. There is only the column that matches how many identity-platform engineers you actually have.
Self-hosting Keycloak yourself
This is the baseline, and for some teams it is the right answer. You pull the container, stand up a cluster, wire in a database, configure Infinispan for distributed caching, and you own it. Total control, zero licensing cost, and total responsibility.
The honest cost here is not the software, it is the expertise. Keycloak’s own guidance sizes capacity by request rate (roughly one vCPU per 15 password logins per second, per the project’s sizing documentation), and getting HA, session replication, and zero-downtime upgrades right is a genuine specialty. If you have platform engineers who enjoy this work, self-hosting is a legitimate, cost-effective path. We wrote a whole breakdown of when that math works in our guide on whether self-hosting Keycloak is worth it.
Red Hat build of Keycloak
Red Hat build of Keycloak (RHBK) is Red Hat’s supported, hardened distribution of the upstream project. It replaced the older Red Hat Single Sign-On product. You get enterprise support, tested binaries, and a longer, more predictable maintenance window than chasing every upstream release yourself.
Here is the part people miss: RHBK is supported software, not a run-it-for-you service. You still operate the cluster, still handle the upgrades (on Red Hat’s supported cadence), still own uptime. If you are already a Red Hat shop running OpenShift, this slots in beautifully. If you were hoping someone else would carry the pager, this is not that.
One-click deployments on a generic PaaS
Several general-purpose hosting platforms offer a one-click Keycloak install. You click a button, a container spins up, and you have a running instance in minutes. Great for a proof of concept, a dev environment, or a small internal tool.
The catch is that “installed for you” is not “operated for you.” Once it is running, upgrades, backups, scaling, and incident response are back on you, usually with platform-level support that knows containers but not Keycloak’s internals. For anything customer-facing or compliance-bound, that gap shows up fast.
Fully managed Keycloak-as-a-service
This is the far end of the spectrum: a provider runs Keycloak end to end. Upgrades, patching, HA, monitoring, backups, and a contractual uptime SLA are all theirs. You get a Keycloak that is fully yours to configure (realms, clients, flows, extensions) without owning the infrastructure underneath it.
Skycloak sits here, as does Cloud-IAM, as the two clearest category examples. The differentiators inside this tier tend to be EU data residency, how freely you can upload custom Java extensions, the depth of actual Keycloak expertise behind support, and whether you can bring your own domain and branding. If your team wants Keycloak’s power without a Keycloak operations team, this is the column you are looking at. You can see how we structure it on our managed Keycloak hosting page and transparent pricing.
Which managed Keycloak option is right for you?
Pick by counting your identity engineers, not your budget. If you have a platform team that wants deep control, self-host or run Red Hat build of Keycloak. If you have a small team and a customer-facing app that cannot go down, a fully managed Keycloak-as-a-service earns its keep by removing an entire discipline from your hiring plan.
The tell is usually the incident, not the invoice. Teams almost never regret managed Keycloak because of the monthly cost. They choose it (or switch to it) the first time a self-hosted instance falls over during a product launch and nobody on the team knows why. Identity is the one system where downtime means every single user is locked out at once, so the uptime SLA is not a line item, it is the whole point.
There is also the migration angle. If you are moving off a per-MAU platform like Auth0 because the bill scaled faster than your revenue, managed Keycloak gives you flat, predictable pricing and none of the operational overhead, which is the exact combination that made you leave in the first place. We compared that cost model in detail in our post on self-hosted versus managed authentication cost.
What should you actually check before choosing a provider?
Before you sign with any managed Keycloak provider, verify four things: the contractual uptime SLA (get the number in writing), whether you can upload custom Java extensions, where your data physically lives, and how deep the support team’s Keycloak knowledge really goes. These four separate a real managed service from a thin wrapper around a container.
Ask pointed questions. Can they import your existing users with their current password hashes so nobody gets forced to reset? Do they handle upgrades without downtime, or is that a maintenance window you have to schedule? Can you get a dedicated instance rather than a shared one? A provider who answers these crisply is a provider who has done it before. A provider who gets vague is a container host wearing a managed-service badge.
Talk it through with a Keycloak engineer
If you are weighing these options for a real workload, the fastest way to get clarity is to talk to someone who runs Keycloak for a living, not a sales rep reading a script. Book a call with a Keycloak engineer and bring your hardest question, whether that is an exotic legacy password hash, a multi-region residency requirement, or a custom SPI you are not sure is portable. Worst case, you leave with a clearer map of the category.
Frequently Asked Questions
Is managed Keycloak worth it versus self-hosting?
It depends on whether you have identity-platform engineers to spare. Self-hosting is genuinely cheaper on paper, but Keycloak’s operational load (HA, frequent upgrades, CVE response, incident handling) is a real specialty. Managed Keycloak is worth it when the cost of that expertise, and the risk of downtime, outweighs the subscription.
What is the difference between Red Hat build of Keycloak and managed Keycloak?
Red Hat build of Keycloak is a supported software distribution: you get tested binaries and enterprise support, but you still operate the cluster and own uptime. Fully managed Keycloak-as-a-service means a provider runs the entire deployment for you, upgrades and HA and SLA included. One sells support, the other sells operations.
Can I move a self-hosted Keycloak to managed without downtime?
Usually, yes. A good provider federates against your existing user store or imports users with their current password hashes, so no one is forced to reset. The realm export and import path plus a dual-run cutover means the switch can happen with little or no user-facing downtime, but confirm the specifics with your provider first.
Does managed Keycloak support custom Java extensions?
The better providers do. Keycloak’s SPI system lets you extend authentication flows, add custom user storage, and build features the base product does not ship. Confirm that your provider allows uploading and versioning custom Java extensions, because thinner managed offerings lock you out of exactly the extensibility that made Keycloak attractive.
The short version
“Managed Keycloak” is not one thing. It runs from supported binaries you still operate (Red Hat build of Keycloak) to a service that carries the entire operational burden for you (Keycloak-as-a-service like Skycloak or Cloud-IAM), with self-hosting and one-click PaaS installs in between.
Choose by the operational load you want to keep, not the sticker. Count your engineers, weigh the cost of an identity outage, and be honest about who is going to own the 3am page. If the answer is “nobody, and we cannot afford for it to be a problem,” you already know which column you are in.
For the hands-on version, our managed Keycloak hosting page shows exactly what a fully managed setup includes, or you can talk to a Keycloak engineer and get a straight answer for your specific case.
Sources
- Keycloak, Concepts for sizing CPU and memory resources, retrieved 2026-08-20, https://www.keycloak.org/high-availability/concepts-memory-and-cpu-sizing
- Keycloak, Releases, retrieved 2026-08-20, https://www.keycloak.org/docs/latest/release_notes/
- Red Hat, Red Hat build of Keycloak documentation, retrieved 2026-08-20, https://access.redhat.com/documentation/en-us/red_hat_build_of_keycloak
