On-Premises: You Own Everything

On-prem Keycloak means you own the entire stack. From the rack to the realm configuration, it’s all yours.

What you need to handle:

• Provision and maintain physical or virtual servers

• Set up and manage a production-grade database (PostgreSQL, MySQL...)

• Configure connection pooling, backups, failover

• Deploy and tune Infinispan / JGroups for clustering and cache

• Handle TLS certificates, load balancers, reverse proxies

• Plan and execute Keycloak version upgrades (and the database migrations that come with them)

• Manage custom themes, SPIs, and extensions

• Monitor everything: JVM metrics, database performance, cache hit rates, HTTP errors, logs

• Capacity planning and scaling

Who you need on the team:

Infrastructure engineers. A DBA. At least one person who understands Keycloak internals deeply enough to troubleshoot a failed rolling upgrade at 2 AM. And a DevOps/SRE to keep it all glued together. This isn’t a side project — it’s a dedicated team.

When it makes sense:

If you already have an infrastructure team, a DBA, and people who know Keycloak inside out — on-prem works. Full stop. These teams exist in large organizations, and if you’ve built one, there’s no reason to walk away from it. On-prem also makes sense when regulators require physical control of your infrastructure, or when you need a level of customization that only full stack ownership can give you.

 

IaaS (AWS, Exoscale, GCP...): The Hardware Is Gone, the Ops Aren’t

Moving to IaaS takes the hardware off your plate. You get VMs or managed Kubernetes, managed databases (RDS, Cloud SQL, etc.), and managed load balancers. The cloud handles the physical layer. But Keycloak? Still your problem.

What you need to handle:

• Choose and configure VMs or Kubernetes clusters

• Deploy Keycloak (Helm charts, Docker Compose, ECS tasks...)

• Configure the managed database (sizing, backups, connection limits, failover)

• Set up and tune Infinispan clustering across nodes

• Handle Keycloak upgrades and database migrations

• Build and maintain custom extensions and themes

• Set up monitoring and alerting for Keycloak-specific metrics

• Manage scaling policies and high availability

Who you need on the team:

Nobody’s racking servers anymore, but you still need people who understand Keycloak’s operational side at depth. What happens to Infinispan sessions during a rolling upgrade? How does the connection pool behave when your managed database hits its max connections? How do you migrate from Keycloak 24 to 26 without locking out half your users?

You need a Keycloak infrastructure specialist — someone who knows the product from the JVM flags and the Quarkus configuration, not just the admin console.

When it makes sense:

If your team already lives in AWS, GCP, or Exoscale and they know how to operate services there, this is a natural fit. You use the cloud’s building blocks — managed databases, load balancers, monitoring — and your team fills in the Keycloak-specific gaps. Many organizations run Keycloak this way and run it well. The question is straightforward: do you have (or want to build) a team that can own Keycloak operations for the long haul?

Cloud Marketplace (Exoscale, AWS Marketplace...): One-Click Deploy, Long-Term Maintain

Some cloud providers offer Keycloak as a marketplace image. Exoscale, for instance, lets you spin up a Keycloak instance in minutes. Day one feels effortless.

Day thirty is a different story.

The provider deploys it. You maintain it. That marketplace image won’t auto-update. The cloud provider isn’t going to upgrade Keycloak for you, run the database migrations, tune the cache, or figure out why your custom theme broke after a version bump.

What you need to handle:

• Keycloak upgrades and version migrations

• Database management, backups, and connection tuning

• Infinispan / cache configuration as you scale beyond a single node

• Extension and theme management across upgrades

• Monitoring, security patching, and incident response

• High availability setup if you need more than one instance

What the provider handles:

• The initial VM and deployment

• Basic infrastructure (networking, storage, compute)

• Sometimes a managed database option alongside it

Who you need on the team:

Here’s the trap: the one-click deployment creates an illusion of simplicity. It is simple — on day one. By day thirty, when a new Keycloak version drops and your staging environment won’t start after the migration, you realize you need the same Keycloak specialist you’d need with raw IaaS. You just saved time on the initial setup.

When it makes sense:

If you’re already on that cloud provider and you need Keycloak running fast for a proof of concept or a smaller workload, marketplace deployments are a solid starting point. They’re also fine if your team is ready to take over operations from day two. Just go in with eyes open: the one-click is for deployment, not for management. If you know that going in, it’s a perfectly valid path.

 

PaaS (Clever Cloud, Railway...): Less Infrastructure, Same Keycloak Complexity

A PaaS takes another layer off your plate. No VMs, no Kubernetes. You push your app, the platform handles deployment, scaling, and often the database.

The infrastructure gets simpler. Keycloak doesn’t.

What you need to handle:

• Configure Keycloak for the platform’s environment and constraints

• Manage database connection pooling and sizing (even with managed DBs, Keycloak has specific needs)

• Handle Keycloak upgrades — the PaaS won’t do this for you

• Manage Infinispan / cache configuration for multi-node setups

• Deploy and maintain extensions, custom SPIs, themes

• Understand Keycloak’s clustering behavior within the PaaS environment

• Monitor Keycloak-specific health and performance

Who you need on the team:

The infrastructure burden is lighter. The Keycloak expertise requirement is almost identical to IaaS. The platform runs your containers and your database. It doesn’t know that Keycloak 25 changed its Infinispan serialization format, or that your custom SPI will break after the upgrade. Someone on your team needs to know that. That person is still a Keycloak specialist.

The question they’ll need to answer, repeatedly: “Is this a Keycloak problem or a platform problem?”

When it makes sense:

If your team already uses Clever Cloud, Railway, or any PaaS — and they’re productive on it — deploying Keycloak there makes sense. Your developers already know the platform, the deployment pipeline exists, and the learning curve is only on the Keycloak side. The platform takes real infrastructure work off your plate, and your team can focus their energy on the Keycloak-specific parts. If you have (or are willing to build) that Keycloak expertise, this is a solid choice.

 

SaaS (Cloud-IAM): You Focus on IAM, We Handle the Rest

This is where the model changes fundamentally.

With Cloud-IAM, you don’t deploy Keycloak. You open a dashboard, create a realm, configure an OIDC client for your app, and set up the login flow. By the time you’re done with your coffee, your users can authenticate. You never touched a database. You never thought about Infinispan. You didn’t need to.

What we handle:

• Database provisioning, pooling, backups, failover

• Infinispan clustering and cache management

• Keycloak version upgrades and migrations (zero-downtime)

• Extension management and compatibility

• High availability and scaling

• Monitoring, alerting, and incident response

• Security patching

• TLS, DNS, load balancing

What you focus on:

• Configuring realms, clients, and authentication flows

• Setting up identity federation (SAML, OIDC, social logins)

• Defining authorization policies and roles

• Integrating your applications with Keycloak

• Managing users and access

Who you need on the team:

An IAM specialist. Someone who understands identity and access management — not someone who knows how to tune a JVM or migrate an Infinispan cache.

And honestly, we’ve built Cloud-IAM so that a developer or architect can configure their identity needs without becoming a Keycloak internals expert first. You don’t need a dedicated IAM team. You need someone who understands what authentication flows your app requires.

The Real Comparison: What Changes at Each Level

Look at that last row. It’s the only one that should require your attention. That’s the whole point.

 

It’s About the Team You Don’t Need to Build

Here’s what running Keycloak in production actually costs. It’s not the cloud bill. It’s the people.

Self-managed Keycloak means you need to hire and retain people who understand:

• How PostgreSQL connection pools interact with Keycloak’s internal pool (and what happens when both think they’re managing idle connections)

• What happens to distributed sessions when an Infinispan node drops out of the cluster

• How to perform a rolling upgrade from Keycloak 24 to 26 without locking out users mid-session

• How custom SPIs and providers behave after a major version bump (spoiler: not always well)

• Why your JVM is consuming 4GB of heap on a Sunday morning when nobody’s even logging in

These are real problems. Finding people who can solve them is expensive. Keeping them is harder.

With Cloud-IAM, you don’t need that team. Not because the problems go away — they don’t. We deal with them every day. That’s our job, and we’re good at it. Your job is building your product.

 

The Part Nobody Talks About: Guidance

There’s a subtler cost to self-managing Keycloak that doesn’t show up in team charts. It’s about direction.

On-prem teams are reactive. They’re not Keycloak teams — they’re infrastructure teams that also happen to run Keycloak. Nobody wakes up thinking about how your authentication flows could be better. They wake up because something broke. Keycloak is one of forty services they maintain, and it only gets attention when it demands it. There’s no one whose job is to ask: “Are we actually using Keycloak well, or just keeping it alive?”

Going solo on Keycloak without guidance is brutal. The documentation is thorough but enormous. The configuration surface is vast. Without someone who’s seen how hundreds of deployments handle the same problems you’re hitting, you’re figuring everything out from scratch. Every time.

IaaS and PaaS make this worse, not better. Responsibility is split between your team and the provider, and nobody owns the full picture. Is that session timeout issue a Keycloak config problem, a database pooling issue, or a platform networking quirk? When three parties share responsibility, the answer is always “not my layer.” Guidance gets fragmented because ownership is fragmented.

SaaS changes the dynamic entirely.

A SaaS provider doesn’t just host your software. They have a purpose — a point of view about what the product should do for you. At Cloud-IAM, ours is straightforward: make open-source IAM simple. That single goal shapes everything we build, every interaction we have with clients, every decision about what to automate next.

And that focus gives us something self-managed setups can’t replicate: pattern recognition across hundreds of deployments. We know which configurations cause problems at scale. We know which authentication flows work for which industries. We know when a client’s setup is heading toward a wall they haven’t seen yet — because we’ve seen it before, dozens of times.

That’s what “tailor-made” actually means. Not a custom build for every client. It means the provider’s entire focus is aligned with your outcome, and they’ve seen enough deployments to guide you before you hit the problem. The guidance is automatic because the ownership is clear.

When you self-manage, you’re the first person to encounter your specific combination of problems. When you use a focused SaaS, you benefit from every client who came before you.

 

“But I Lose Control”

Fair pushback. Let’s address it.

With Cloud-IAM, you keep full control over everything that matters for your application:

• Your realms, clients, and flows — fully configurable, same as self-hosted Keycloak

• Your data — it’s your instance, your data, your configuration

• Your integrations — standard OIDC/SAML protocols, no vendor lock-in

• Your extensions — custom themes and providers are supported

What you give up is the operational burden. The 2 AM pages. The upgrade weekends. The Infinispan debugging sessions. That’s not losing control — it’s choosing where your team spends its energy.

 

What Team Do You Have?

This is the question that should drive your decision. Not “what’s the best deployment model?” but “what’s the best model for the team I have today?”

You already have a Keycloak team? Then you have options. If your team can operate Keycloak in production — upgrades, migrations, cache tuning, the works — run it wherever makes sense. On-prem, IaaS, PaaS, marketplace. Your team can handle it. That expertise is a real asset.

You have a platform team on a specific cloud or PaaS? Deploy Keycloak there. Your engineers already know the platform, so the gap to fill is Keycloak-specific knowledge, not infrastructure.

You don’t have either — and you don’t want to build it? That’s where Cloud-IAM fits. And that’s most teams. Most companies don’t want to become Keycloak operations experts. They want authentication to work so they can ship their product.

Cloud-IAM makes the most sense when:

• You want Keycloak without building a Keycloak ops team

• Your team understands IAM but not Keycloak infrastructure

• You’re a startup that needs enterprise-grade IAM without enterprise headcount

• You’re a larger org looking to stop spending engineering cycles on identity infrastructure

• You’ve been through a Keycloak upgrade gone wrong and never want to do that again

• You’d rather put your engineering budget into your product, not into keeping Keycloak alive

 

The Bottom Line

The shift from on-prem to SaaS isn’t about where the servers live. It’s about who needs to know what.

• On-prem: You need infrastructure people, database people, AND Keycloak people.

• IaaS: You still need Keycloak infrastructure specialists.

• Marketplace: Day one is easy. Day thirty, you still need Keycloak infrastructure specialists.

• PaaS: The platform helps with ops. Keycloak expertise is still on you.

• SaaS (Cloud-IAM): You need someone who understands IAM. That might be a developer.

We built Cloud-IAM so your team can focus on building great authentication experiences instead of debugging Infinispan cluster splits at 3 AM.

Your users don’t care how Keycloak is hosted. They care that login works.