Every login, logout, failed password attempt, and admin change in Keycloak produces an event. That's exactly what you want for security auditing and product analytics — until you realize where Keycloak puts them: in the same relational database that your authentication path depends on. At scale, event storage becomes a problem you can't ignore. Here's how we solved it, and how the key piece — an MDC-logging EventStoreProvider — is open source so you can solve it too.

Today we're launching a new way to run Phase Two: the Starter cluster tier, available at $149 per month. Starter bundles the same feature set as our existing dedicated clusters into a plan that's accessible for teams getting their use case off the ground or running development environments with lower SLA needs. It also includes a 30-day free trial, so you can validate your setup before committing.

Log into the dashboard and click Create Cluster to pick the new tier and provision yours.

Today we're launching Observability for dedicated Keycloak clusters — built directly into the Phase Two dashboard with zero setup. Requests, event data, and live logs are all there the moment your cluster is running. No agents to install, no log shippers to configure, no Prometheus, Grafana, or Loki stack to stand up and maintain.

A few quarters ago you got handed a single-line ask: "we need enterprise SSO and directory sync by the end of the quarter." Maybe the deal was a Fortune-500 logo. Maybe it was a Series B requirement. Either way you found WorkOS, wired in their SDK in a long weekend, shipped the deal, and got the high five.

Then the renewal came in. The seat-based pricing, that sounded harmless when you had two customers using SSO, looks different when you have forty. Suddenly there's a line item on a board slide that scales linearly with your enterprise revenue — a parasite that eats into the very margin that the enterprise tier was supposed to fund. The CFO walks over and asks you to "fix it."

Here is the awkward truth nobody tells the engineer-on-the-spot: the WorkOS feature set has had a fully open-source equivalent for years. Keycloak handles SSO. Phase Two's organizations extension handles multi-tenant orgs. The identity provider wizard handles the same admin-portal flow your customers see in WorkOS today. The catch is that nobody wanted to spend the runway to migrate.

We've now built the tool that turns that "we'll deal with it later" debt into an afternoon of work. Why? Because WorkOS customers are starting to wake up to Keycloak, and they're coming to us in droves.

We're shipping experimental SCIM 2.0 provisioning for the Phase Two Organizations extension. Each organization in a realm can now act as its own SCIM 2.0 service provider, so an upstream IdP like Okta or Entra ID can push users into a specific tenant rather than into the realm as a whole.

This is the piece of the multi-tenant story that Keycloak's stock SCIM support doesn't address today, and it's been a heavily requested item from customers running Organizations in production.

Keycloak has exactly four theme types you can set on a realm: login, account, admin, and email. Each one is its own directory of templates, message bundles and static assets, packaged into a JAR and dropped into the server's providers/ directory. That is the whole extension point. It is also why custom Keycloak themes tend to become a standing maintenance cost: your templates are copies of upstream files, and upstream moves every release.

We've completely rebuilt our bundled Keycloak themes. What used to live as a tangle of custom pages inside a forked Keycloak repository is now a first-class Keycloakify-based React application that ships all four: login, admin, account, and email. The result is faster to maintain, far more capable, and dramatically better out of the box for the organizations using Phase Two today.

Switching themes is four realm fields. Set them in Realm settings → Themes in the admin console, or from the CLI. Verified against Keycloak 26.7.3:

kcadm.sh update realms/<your-realm> \
  -s loginTheme=phasetwo-ui \
  -s accountTheme=phasetwo-ui \
  -s adminTheme=phasetwo-ui \
  -s emailTheme=phasetwo-ui

Starting now, all Phase Two containers ship with this theme bundled. Any realm you create through the Phase Two Dashboard automatically gets the new login, admin, account, and email themes active, with no configuration required. The first time a user hits your login page or receives an email from your realm, it already looks good.

If you are exposing tools over MCP, you usually do not want every client on the network calling them anonymously. Even for a local prototype, you typically want a real login flow, consent, scoped access tokens, and a clean way to validate who is allowed to run what.

Keycloak is the easiest way to do that without inventing your own authorization layer. It already handles browser login, consent, token issuance, JWKS discovery, and OAuth metadata. Your MCP server just needs to behave like a protected resource and validate bearer tokens correctly.

In this guide, we will build a tiny calculator MCP server in Python, protect it with Keycloak, and connect to it from VS Code using Dynamic Client Registration (DCR). By the end, VS Code will open a browser to Keycloak, you will sign in, approve access to the mcp:run scope, and then call your MCP tools directly from chat.

Phase Two is excited to announce that we are now ISO/IEC 27001 certified.

This milestone reflects how seriously we take security and compliance across our platform, operations, and internal processes. We completed this as a fast follow to our September 17, 2025 SOC 2 Type II compliance milestone, reaching full ISO/IEC 27001 certification just over six months later as part of our commitment to building a mature, enterprise-ready security program.

Learn more at our Trust Center: trust.phasetwo.io.

At Keycloak DevDay 2026, we shared our work on replacing Keycloak's distributed Infinispan caches with Redis/Valkey.

For the full technical deep dive, we will release slides when the talk is published on Youtube.

This post focuses on the core technical content from the presentation and summarizes what we built, what we learned, and what comes next.

We’re excited to announce built-in observability for dedicated clusters, starting with log downloads in the Phase Two dashboard.