Keycloak Support and Managed Keycloak
Last reviewed by Tyler Eastridge
AceMQ gives enterprises that run Keycloak in production 24/7 support, a high-availability design for Kubernetes with PostgreSQL, upgrade planning with a tested rollback, and managed Keycloak on your infrastructure or ours. It is run by the team that supports the message brokers your tokens protect, including RabbitMQ OAuth 2.0 and Kafka bearer-token authentication. AceMQ is an independent provider: it is not a Red Hat reseller and sells no Red Hat build of Keycloak.
A senior engineer, not an SDR. No sales sequence attached.
Without changing your identity providerFor production incident cover, see AceMQ Keycloak 24/7 support.
Customers
Partners
The Problem
Eight Keycloak problems that teams bring to AceMQ, from an identity provider nobody owns to an Operator that upgraded itself overnight. If one describes your quarter, that is where the work starts.
Keycloak went into production as a side project, and now every application and broker log-in depends on it with no named owner
Nobody can say what Keycloak support means, because the project's downloads page publishes no support or end-of-life policy
Production is several minors behind Keycloak 26.8.1 and nobody has read the breaking-changes list for each step
The upgrade cannot be rolled back at the database, per Keycloak's own upgrade guide, and the backup was never test-restored
In a high-availability setup sessions and tokens live in the database, so a slow PostgreSQL slows every log-in
Broker clients are disconnected or refused further operations when a token expires, and token lifetime was never tied to client behavior
The Operator's automatic update can upgrade Keycloak itself overnight, and the Operator guide recommends manual approval
Managed Keycloak, Red Hat's build or another identity provider: the choice is argued without a table of what each one gives up
A good fit if you run Keycloak in production for applications and message brokers and need senior engineers on call, a high-availability design, or an upgrade you can roll back.
Not a fit for small teams with non-critical workloads. AceMQ is not a budget consultancy: we work with enterprises running business-critical and compliance-heavy Keycloak.
How it breaks, and the fix
Keycloak issues tokens for people and for services. When log-in and admin traffic saturates it, token requests from broker clients queue behind them, and a client that cannot renew its token loses its connection at expiry.
Token issuance for brokers under load
Clients, one Keycloak, two brokers and the log-in pages
Applications and broker clients get tokens quickly. The brokers validate them, and log-in traffic is light.
A surge on the log-in and admin pages saturates Keycloak and its database. Token requests for the brokers queue behind it, clients cannot renew, and at expiry an AMQP 1.0 client is disconnected.
The database is tuned, token lifetimes are set to give renewal headroom, and log-in traffic is kept from starving service tokens. Token issuance for the brokers recovers.
A broker that authenticates with OAuth 2.0 depends on Keycloak twice: when a client connects, and every time a token must be renewed. RabbitMQ's documentation says that when the latest token on an existing AMQP 1.0 connection expires, the client is disconnected, and on AMQP 0.9.1 the broker refuses further operations after a limited time without disconnecting. In Keycloak's high-availability setups, user sessions and, in multi-cluster version 2, authentication sessions and tokens are stored in the database, so a slow PostgreSQL slows issuance for everyone. The review reads token lifetimes against client behavior, sizes the database for session load and tests the failure with a broker connected.
Our Services
AceMQ runs five Keycloak service lines: 24/7 production support, high-availability design, upgrade planning and rehearsal, broker and platform authentication, and a fixed-scope health check. Managed Keycloak runs at Tier 3 on your infrastructure or Tier 4 on AceMQ's.
24/7 engineers for Keycloak in production: log-in failures, token issuance problems, slow admin and login pages, and upgrades that go wrong.
A written design, or a review of what runs today, for Keycloak on Kubernetes or virtual machines with a replicated PostgreSQL.
A written upgrade path from your version to the target, rehearsed on a restored copy before production.
Keycloak as the OpenID Connect provider for RabbitMQ and Kafka, and for platform consoles, set up and tested from the broker side.
The fixed-scope entry engagement: a written report on how your Keycloak is configured and where it is exposed, which your team can act on with or without AceMQ.
Senior engineers on your account, a 15-minute emergency response, no ticket routing and no junior triage.
24/7 Support
AceMQ gives you an engineer and a 15-minute first response when Keycloak fails in production, 24/7. Lower severities get 1-hour, 4-hour and next-day responses. Fixes in Keycloak's own code come from the project, or from Red Hat for its own build: AceMQ produces neither.
P1 escalation path
A replay of one P1, from the first page to the written root-cause analysis
15-minute P1 response, 24/7.
A response time, not a resolution time.
P1 opened, on-call engineer paged
Phone, email or Slack reaches the on-call senior engineer directly, whether the incident is in RabbitMQ, Kafka, Redis, PostgreSQL or Kubernetes. No web form, no tier-1 queue.
Senior engineer on your bridge
A senior engineer who already knows your environment joins a live bridge, so nobody has to re-explain your topology.
Specialists across the stack join
When an incident crosses components, the engineers who know each one join. For RabbitMQ, the path runs to the core team.
Written root-cause analysis
Root cause, the fix applied and the prevention steps, delivered after every P1.
Beyond SLAs — the model behind senior-only, zero-cold-start expert access.
Tickets go to senior engineers briefed on your environment, not an anonymous queue. The proposal states who does the work.
Any ticket can be escalated to a live session with an engineer through calendar booking. No gatekeeping and no approval step.
Scheduled health checks on your deployment and alerts on risks in the versions you run, so problems surface before they reach production.
Proactive alerts on critical bugs and CVEs affecting your exact version, with version compliance monitoring so you're never caught off guard.
How It Works
An AceMQ Keycloak engagement runs in four stages: a scoping call with a quote within 1 hour, an environment review, a written plan with a tested rollback, then the work or a handover. Each stage ends in writing.
Quote within 1 hour
A senior AceMQ engineer asks what you run: Keycloak version and distribution, how it is deployed (Operator, containers or virtual machines), the database, the realms and clients that matter most, and what has prompted the question. A quote request is answered within 1 hour.
Scoped per estate
The deployment read end to end: cluster topology, database and its backup, load balancer, caches, the client and broker integrations that depend on token issuance. Findings are written down and your team keeps them.
Scoped per estate
A recommendation in writing: the high-availability design, the upgrade path with its breaking changes, and who runs what afterwards. The plan includes a rehearsal on a copy and a rollback that has been tested, not assumed.
Ongoing or fixed scope
Changes staged one environment at a time with a rollback for each. The work ends with a runbook for the next upgrade. You can stop there, add 24/7 cover, or have AceMQ run Keycloak for you as a managed service.
A senior engineer, not an SDR. No sales sequence attached.
Upgrading Keycloak
Keycloak's upgrade guide is blunt: the database schema stops being compatible with the old server after the upgrade, and Keycloak does not support rolling back database changes. So the rollback is a restored backup, and the plan is built around proving that restore works before anything is upgraded.
Before
The guide asks for a backup of the old installation and of the database, and for a shutdown first when the upgrade does not support a rolling update. Rolling back means restoring both. AceMQ restores the backup on a copy first, so the rollback is known to work.
Read
The guide lists breaking changes per version. In the 26.8 notes they include SMTP StartTLS being required when enabled, stricter X.509 authenticator validation, mandatory signature validation for OIDC identity provider backchannel logout tokens, and brute-force failure data stored in the database by default. Each one is checked against your realms.
Rehearse
The new version runs against the restored database copy, with your real clients and brokers pointed at it. Token issuance, log-in flows, the management consoles and broker connections are tested before the production window.
Cut over
Patch releases can use rolling updates from Keycloak 26.6.0. Minor and major upgrades follow the shutdown path, with a window, the tested rollback and the Operator's update approval set to manual.
Typical engagements
Typical Keycloak engagements from AceMQ: what the environment looks like, what AceMQ assesses or changes, and what the engagement delivers. Each card links to the full write-up.
Platform Engineering Team
Reviewing how Keycloak runs on Kubernetes with PostgreSQL, testing the failure and the restore, and writing the upgrade path from the current version.
PostgreSQL
Kubernetes
RabbitMQ
Government Systems Integrator
A Boomi integration estate depended on RabbitMQ with no automated failover and no way to replay messages after an outage. AceMQ designed the DR model and the replay path, both under audit constraints.
BoomiRabbitMQKubernetesIndustrial Equipment Manufacturer
Stopping month-end Atom restarts caused by maps that loaded entire order files into heap while several scheduled processes ran at once.
BoomiPostgreSQLSolutions
AceMQ covers Keycloak end to end. Projects: consulting and implementation, health checks and migrations. Ongoing cover in four tiers, from 24/7 support and incident management to proactive monitoring, managed Keycloak on your infrastructure and fully managed Keycloak on AceMQ infrastructure, plus end-of-life versions.
Projects
Fixed-scope work led by a senior engineer: architecture and new builds, a health check of what you run today, or a migration with a reversible cutover.
Support and managed services
Four tiers of ongoing cover once you are live. Each tier hands more of the day-to-day work to AceMQ, from a 15-minute emergency SLA to AceMQ hosting and running Keycloak for you.
Compare the four Keycloak support tiersSide by side
All four can issue the tokens your applications and brokers need. They differ in who runs the service, who answers a failure and what you give up. Each row below answers one question.
| Question | Self-hosted Keycloak with AceMQ | Red Hat build of Keycloak | Managed Keycloak host | Another identity provider |
|---|---|---|---|---|
| Who supports the software? | The community project for code defects. Keycloak's downloads page publishes no support policy. AceMQ supplies engineers for the running service. | Red Hat, under a subscription and its published policy: each minor is supported for about 12 months, and at least two minors are supported at any time. | The host, on its own terms. Ask what it commits to for version currency and incident response. | The vendor, as a cloud service on its own terms. |
| Who runs it at 3am? | An AceMQ engineer within 15 minutes, 24/7, on your infrastructure (Tier 3) or ours (Tier 4). | You, or AceMQ beside your subscription. Red Hat Support handles defects in its build. | The host's operators. They do not run your brokers, so token failures at the broker side still need your own engineers. | The vendor. Broker-side token failures remain yours. |
| Where does it run? | Your Kubernetes or OpenShift cluster with the Keycloak Operator, containers or virtual machines, on a supported database such as PostgreSQL 14 to 18. | The same shapes, on the versions and configurations Red Hat supports. | The host's cloud. | The vendor's cloud. |
| What do you give up? | Nothing in capability. You take on upgrades, high availability and backups, which is the work AceMQ does. | Freedom to run any upstream release the day it ships, because the build follows Red Hat's even-numbered minors. | Control of the database, topology and upgrade timing. | Keycloak realms, clients and protocol mappers have to be rebuilt in another model, and the migration needs its own plan. |
| Who should stay put? | A team that wants control of the topology and has engineers to call on, or already runs Keycloak and needs it to be dependable. | A team that wants a vendor accountable for the build and already buys Red Hat subscriptions. | A team with no appetite for operating an identity provider and no broker-side token dependence. | A team whose applications already trust that provider. AceMQ is not the right partner if the goal is only to replace Keycloak. |
For the wider choice of identity providers, read Keycloak alternatives: self-host, managed or move. AceMQ is an independent provider: it sells no Red Hat subscription and gives no Red Hat licensing advice.
Red Hat publishes dated support phases for its own build, and community Keycloak publishes none. These are the Red Hat dates on 4 November 2026, from Red Hat's Product Life Cycles data. They apply to the Red Hat build only.
| Red Hat build of Keycloak | Generally available | Maintenance Support ends |
|---|---|---|
| 26.6 | 3 June 2026 | 15 May 2027 |
| 26.4 | 30 October 2025 | 3 December 2026 |
| 26.2 | 13 May 2025 | Ended 3 June 2026 |
| 26.0 | 13 November 2024 | Ended 13 November 2025 |
| 24.0 | 25 April 2024 | Ended 13 May 2025 |
| 22.0 | 15 November 2023 | Ended 31 January 2025 |
Red Hat's policy describes minor versions about every six months, based on the even-numbered community minors, each supported with patches for about 12 months.
One partner, not five
Keycloak rarely fails in isolation. AceMQ covers the full surrounding infrastructure — so one team owns the whole path instead of pointing at each other.
Guides, articles and comparisons
Guides from AceMQ engineers on identity provider options, plus the AceMQ services around Keycloak: RabbitMQ, Kafka, PostgreSQL and Kubernetes.
FAQs
Five answers on Keycloak from AceMQ: support without a Red Hat subscription, high availability, broker authentication and what AceMQ does not sell.
Still have questions about Keycloak? Email an Expert
Keycloak is a CNCF Incubating project, and its downloads page publishes no support or end-of-life policy, so community Keycloak is supported by the community. Red Hat sells a commercial build, the Red Hat build of Keycloak. AceMQ supplies the engineers who run Keycloak in production: diagnosis, high availability, upgrades and 24/7 on-call. A defect in Keycloak's own code goes to the project, because AceMQ produces no Keycloak builds.
Keycloak's high-availability guide describes single-cluster and multi-cluster (version 2) topologies and, for both, a synchronously replicated database. In a single cluster, user session state is held in the database, and version 2 also moves authentication sessions and tokens there, which the guide says raises database load. The Keycloak Operator installs on Kubernetes and OpenShift, and PostgreSQL 14 to 18 is supported. AceMQ designs the topology, sizes the database and tests the failure.
Yes. RabbitMQ's OAuth 2.0 authentication backend lists Keycloak among the identity providers that are compliant with OpenID Connect; the audience claim must match RabbitMQ's resource server identifier, and at token expiry an AMQP 1.0 client is disconnected while an AMQP 0.9.1 client is refused further operations. Kafka brokers can validate bearer tokens through SASL/OAUTHBEARER with a JWKS endpoint, and Kafka's default implementation is for non-production use only. AceMQ configures and tests the broker side.
Yes. AceMQ works on Keycloak in two ways: ad hoc engagements for a defined piece of work, such as a health check, an upgrade or an incident, or an annual contract that covers 24/7 support and proactive reviews. Many teams start ad hoc and move to an annual contract once the first engagement is done.
Every AceMQ proposal is tailored to your requirements: your Keycloak environment, the SLA you need, the hours of cover and the scope of work. Most contracts run $24,000–72,000 a year, depending on the SLA, the scope and how Keycloak is deployed, with aggressive discounts when several technologies share one contract. Request a quote and AceMQ replies within 1 hour.
Let's talk
A senior AceMQ engineer reviews your Keycloak deployment, tells you what to check first, and quotes the work. Quote requests are answered within 1 hour.
Production incident right now?Email a Keycloak Architect
Send us a message and we'll follow up within 1 hour — or book a free 30-min consultation directly.
305-204-2607info@acemq.comPrefer to talk now? Call us directly or use the consultation tab to find a time that works.
