Keycloak on Kubernetes vs virtual machines

Your team is responsible for the database, not the Operator. The Keycloak Operator does not manage the database, so you must provision it yourself, and the ephemeral PostgreSQL pod in the basic deployment guide is for development only. Backups, point-in-time recovery and restore drills belong to whoever runs your production database service, whether that is a managed PostgreSQL offering or a database team in your data center. On virtual machines the same duty exists, but it sits next to the Keycloak host instead of inside a cluster. Ask who owns the database backup schedule, the restore test cadence and the recovery time target before you pick a route. Those answers usually cost more to get right than the Keycloak install itself.

etcd quorum means the control plane keeps working only while a majority of its members agree. Kubernetes documentation says etcd should run with an odd number of members and recommends a five-member cluster in production, so a failed member can be lost without losing the majority. Keycloak does not run inside etcd, but every Keycloak pod depends on the API server, and the API server depends on etcd. An unhealthy control plane can stop scheduling, rolling upgrades and Operator reconciliation even when Keycloak pods are still serving logins. Your platform team must own etcd health checks, member replacement and the kubeadm topology you choose, either stacked control plane nodes or an external etcd cluster. kubeadm's high availability guide describes both topologies and asks for at least three control plane nodes behind a TCP load balancer on port 6443.

No. Kubernetes stores Secrets unencrypted in etcd by default, according to its Secrets good practices page. Keycloak admin passwords, database credentials and client secrets that you place in Kubernetes Secrets are therefore readable by anyone who can read the etcd data or the Secret objects. Your team should enable encryption at rest for etcd, restrict list and watch access with least-privilege RBAC, and consider an external store through the Secrets Store CSI Driver. Keycloak's own production guidance also expects a secure admin password and TLS certificates before go-live. Confirm with your cluster provider how encryption keys are stored and rotated, because a managed control plane may handle part of this for you while a self-managed cluster does not.

Start with the restricted level for the Keycloak namespace if your cluster enforces Pod Security Standards, then document any exception you need. Kubernetes defines three profiles, privileged, baseline and restricted, and the restricted profile is the strictest. A Keycloak pod normally runs as a non-root user, drops unneeded capabilities and avoids host networking, so it can usually meet the restricted profile after you test it in staging. Check the Keycloak image and any sidecars your team adds, such as metrics exporters or service mesh proxies, because each one can need an exception. Ask your security team which level applies to production and whether admission control is enforced or only audited.

On virtual machines, your team patches the operating system, the Java runtime and the Keycloak distribution itself. Running Keycloak from the server distribution requires OpenJDK 25, so someone must track JDK security updates and test them before rollout. Keycloak's distribution is a zip you unpack and manage, which means your configuration management or change process must replace the binaries, run the database migration and restart nodes in a controlled order. Patch windows also affect load balancer draining and cache state across nodes. Ask whether your standard VM patch cadence can include a Keycloak restart and a rollback plan, because Keycloak's Operator guidance warns against automatic upgrades and the same caution applies to scripted VM updates.

You manage the JDK lifecycle yourself on virtual machines. The zip distribution requires OpenJDK 25, so you must install that runtime, pin it, and plan its replacement when a newer release is needed. Keep the JVM version, Keycloak version and operating system patch level recorded together in your change records so a rollback can restore a known pair. Monitor JVM memory and garbage collection through the metrics Keycloak exposes, and size heap settings against the database and cache behavior you observe. Ask your team who owns JDK updates, whether a vendor or internal image supplies the runtime, and how long a runtime upgrade takes in your change window.

The load balancer must send users to healthy Keycloak nodes, handle TLS termination according to your design and keep sessions consistent with the cluster. On virtual machines, the front door is usually a load balancer you configure yourself, while on Kubernetes it is often an ingress or service that the platform manages. Keycloak's single-cluster high availability guide notes that it can run on virtual machines or bare metal, but its tested configuration uses OpenShift with the Operator, so you carry more of the design. Confirm health check paths, timeouts, sticky session behavior and the external hostname that Keycloak advertises. Use your own test plan to prove failover, because the vendor's blueprints describe a different platform.

Start with Keycloak's metrics documentation, which describes how to expose metrics for observability tools. Whichever route you choose, collect the Keycloak metrics, the database health and the Kubernetes or VM host signals in one dashboard, then set alerts on login failures, database connection errors and node restarts. On Kubernetes, add control plane and etcd signals as well, because a degraded cluster can hide Keycloak problems. On virtual machines, add disk, memory and JVM signals per host. Ask your monitoring team which tool will ingest the metrics and who receives the alerts at night.

On both routes, the upgrade path matters more than the platform. The Keycloak Operator documentation strongly recommends manual approval mode for operator updates, and its OLM notes warn there is no option to downgrade to the previous Keycloak version because of database migration changes. Keycloak migrates its schema automatically at startup by default, but it also supports manual migration, which the upgrading guide suggests for large deployments. On virtual machines you control the same decision directly. In both cases, take a database backup before each upgrade, rehearse in a non-production environment and confirm the Keycloak release notes for breaking changes before you approve the update.

Not safely without someone who can operate a cluster. The Keycloak Operator adds Keycloak, realm import and client custom resources on top of a cluster you already run, so the cluster itself, its upgrades, its ingress, its storage and its backup of etcd all remain your responsibility. The Kubernetes project maintains only the three most recent minor releases, so a cluster needs regular upgrades in its own right. If the team has no cluster staff, the more direct route is usually the server distribution on virtual machines, where the skills are general Linux administration, a JDK, a load balancer and a production database. Confirm which skills your platform team already has before choosing.

The Keycloak Operator documentation marks its Helm chart as experimental, so treat it as a non-production option unless you accept that status in writing and test it against your own change process. The documented installation paths are Operator Lifecycle Manager, which Keycloak recommends, and a kubectl kustomization install. Whichever path you choose, the Operator documentation strongly recommends manual approval mode for operator updates so that upgrades do not happen unintentionally. Ask any implementation partner to state which install method they will support and how that support is documented.

No. The Keycloak Operator does not manage the database, so you provision a supported production database yourself, such as PostgreSQL 14 to 18 or another database on the Keycloak list. The ephemeral PostgreSQL pod shown in the Keycloak Operator basic deployment guide is for development only. Your team owns backups, point-in-time recovery, patching, failover and sizing for that database. Keycloak's high availability designs also require a synchronously replicated database, so the database architecture shapes the whole deployment. Ask for the database design and recovery procedure as a separate deliverable in any scope.

The time depends on your realm size, your database, the number of nodes and how many versions you cross, and no fixed duration is supplied here. Keycloak migrates its database schema automatically at startup by default, and it also supports manual migration, which the upgrading guide suggests for large deployments. Keycloak plans four minor releases a year, so an upgrade calendar is a recurring cost. Ask for a timed rehearsal in a non-production copy of your database, a rollback plan that accounts for the no-downgrade limit, and the change window your business requires.

Plan on no. The Keycloak Operator's OLM upgrade notes warn that there is no option to downgrade to the previous Keycloak version because of database migration changes. The same logic applies to any deployment where the schema has been migrated, so your rollback plan should rely on restoring a database backup taken before the upgrade and redeploying the matching older image or package. Because automatic migration runs at startup by default, decide before the upgrade whether you will use manual migration so that the SQL can be reviewed and rehearsed first.

Both routes need identity administration, TLS, a production database and an upgrade process. The Kubernetes route adds cluster operations: installing and upgrading the cluster, the Operator and its custom resources, persistent storage, ingress, network policy, pod security settings and etcd backup, which Kubernetes documents as requiring a backup plan. The virtual machine route adds a supported Java runtime, which the zip distribution guide says is OpenJDK 25, service management, and a load balancer with node discovery through the database. Cluster discovery differs too: the default jdbc-ping stack needs only the --cache-stack option, while the DNS_PING based kubernetes stack is deprecated. Confirm each skill against your current staff.

DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms in your own infrastructure, and most engagements are fixed-scope with scope and deliverables agreed in writing before work starts. For this decision, ask the consultant to scope the route choice, the database design and recovery, cluster discovery and the upgrade and rollback procedure, plus hardening and documentation. Ask whether ongoing upgrades and testing are covered by a retainer. DeployOpen does not publish a price list, so ask for a quote that follows from the written scope.