What Is Standalone Mode in Keycloak?
The complete beginner-to-production guide to running Keycloak as a single, self-contained server — and how that idea carries into modern deployments.
Picture a single small bakery run entirely by one baker in one building — everything a customer needs is baked, priced, and sold right there, on-site, by that one shop, with no head office coordinating a chain of branches. Now picture a nationwide bakery chain instead, where a central office pushes the same recipes and pricing out to hundreds of branch locations simultaneously, keeping them all in sync. Both are legitimate ways to run a bakery business, but they solve very different problems at very different scales. Keycloak offers this same choice for how its own server is run, and the simplest of these choices — one self-contained server doing everything itself, with no central coordinator — is called Standalone Mode.
This guide explains what Standalone Mode means, how it fits alongside Keycloak’s other run modes, what its internal architecture looks like, and when it’s the right choice versus when an organization needs to grow beyond it. No prior identity or infrastructure background is assumed — every term is explained the moment it appears.
1Core Concepts
What Is Standalone Mode?
Standalone Mode is a way of running the Keycloak server as a single, independent instance that manages its own configuration entirely on its own — with no other Keycloak node coordinating alongside it, and no shared, centrally managed configuration being pushed out to it from elsewhere. Everything the server needs — its settings, its Realms, its database connection — lives with that one running instance.
Standalone Mode is about how a Keycloak server process is run and configured — it is a completely different concept from a “standalone Client” or any per-application setting discussed elsewhere in Keycloak’s terminology. Here, “standalone” describes the server itself, not an application registered inside it.
Where the Term Comes From
Keycloak’s underlying server technology historically offered three named run modes, inherited from the application server platform it was originally built on: Standalone (one independent server), Standalone Clustered (several independent servers that discover each other and share session state, but still each carry their own local configuration), and Domain Mode (many servers centrally managed from one domain controller that pushes out shared configuration to all of them). Modern Keycloak has since moved to a different underlying technology, but the same underlying idea — one self-contained node versus many centrally coordinated ones — still shapes how teams think about deployment today.
Standalone Mode is the single independent bakery from the opening example: one location, fully self-sufficient, making every decision on-site. Domain Mode is the bakery chain’s head office pushing the same recipe and pricing changes out to every branch at once. Standalone Clustered sits in between — several independent bakeries that happen to share a delivery network and coordinate on which one currently has a given customer’s order in progress, without a shared head office dictating each one’s local operations.
Why This Choice Matters
Because Keycloak is the identity server that every other application ultimately depends on for login, how it’s deployed has an outsized impact on the whole organization’s reliability and administrative overhead. Standalone Mode trades away centralized management and built-in redundancy in exchange for simplicity — an intentional trade-off, not a limitation to be worked around.
2Architecture & Components
graph TD
Admin["Administrator"] -->|"Configures directly"| Node["Single Keycloak Server
(Standalone Mode)"]
Node --> Config["Local Configuration
(Realms, Clients, Roles)"]
Node --> DB["Database
(Users, sessions, config storage)"]
App["Applications"] -->|"Send login requests"| Node
Node -->|"Issues tokens"| App
Single Server Process
Exactly one running Keycloak instance handles every login, token issuance, and admin console request.
Local/Direct Database Connection
The server connects to its own configured database for persisting Realms, users, and sessions — with no other node sharing that responsibility.
Self-Contained Settings
All server-level configuration lives with that one instance, edited directly rather than distributed from a central controller.
No Peer Discovery
Unlike clustered setups, a Standalone Mode server does not attempt to discover or coordinate with any other Keycloak node.
Contrast this with a clustered or centrally managed deployment, where multiple nodes sit behind a load balancer, discover each other, and share session information so a user’s login remains valid no matter which specific node happens to handle their next request. Standalone Mode deliberately has none of that — one process, one point of configuration, one point of failure.
3Internal Working
Request Arrives
An application redirects a user’s browser directly to the one running Keycloak instance’s login endpoint.
Configuration Read Locally
The server reads the relevant Realm and Client configuration from its own directly connected database — there’s no need to check with any other node, since none exists.
Authentication Performed
The server handles the entire login interaction itself — checking credentials, enforcing any Required Actions, and applying Realm settings — start to finish, with no coordination needed elsewhere.
Session Stored Locally
The user’s session is tracked entirely by this one server instance, held in its own memory and backing store.
Token Issued
The server issues the finished tokens directly back to the requesting application, completing the login without ever needing to consult a peer node or a central controller.
Because exactly one process handles every step above, if that process crashes, is restarted for maintenance, or the machine it runs on goes offline, every single login and every existing session tied to it is interrupted — there is no peer node standing by to pick up the work.
4Standalone vs. Clustered vs. Domain-Managed
| Mode | Number of Nodes | Configuration Managed | Failure Impact |
|---|---|---|---|
| Standalone | Exactly one | Locally, on that one instance | Full outage if that node fails |
| Standalone Clustered | Multiple, peer-to-peer | Locally per node, but sessions shared | Other nodes continue serving logins |
| Domain-Managed | Many, centrally coordinated | Pushed from one central controller | Individual nodes fail independently; central controller simplifies large-scale updates |
graph LR
subgraph Standalone
S1["Single Node"]
end
subgraph Clustered
C1["Node A"] |"shares sessions"| C2["Node B"]
C2 C3["Node C"]
end
subgraph Domain
D0["Central Controller"] -->|"pushes config"| D1["Node A"]
D0 --> D2["Node B"]
D0 --> D3["Node C"]
end
5Data Flow & Lifecycle
Initial Setup. A single server is provisioned, connected to a database, and configured with the organization’s first Realms and Clients — the fastest path to a working identity server.
Everyday Operation. The one instance handles every login, admin console change, and token issuance for as long as load and availability requirements remain modest.
Growth Pressure. As user volume grows, or as the organization can no longer tolerate downtime during restarts and maintenance, the single point of failure and single point of capacity becomes a real operational risk.
Migration to Clustering. At that point, teams typically move to a multi-node clustered deployment, placing several Keycloak instances behind a load balancer and configuring them to share session data — no longer “standalone” in the strict sense.
Production Example: Startup Growth Path
A small startup commonly begins with a single Standalone Keycloak instance to get identity management working quickly with minimal operational overhead. As the company scales and downtime becomes unacceptable, the same team typically migrates to a clustered deployment behind a load balancer — the identity equivalent of a growing bakery finally opening a second location.
6Advantages, Disadvantages & Trade-offs
Advantages
- Dramatically simpler to set up, configure, and reason about than any clustered arrangement
- Lower infrastructure cost — a single server instead of several plus a load balancer
- Fewer moving parts means fewer things that can go subtly wrong during day-to-day operation
- Well suited to development, testing, and small-scale internal deployments where downtime is tolerable
Disadvantages & Trade-offs
- A single point of failure — any crash, restart, or maintenance window interrupts every login and active session
- Capacity is capped by whatever one machine can handle, with no ability to spread load across peers
- No built-in redundancy during upgrades — applying an update typically means a brief, real outage
- Not appropriate for any organization with meaningful uptime requirements or unpredictable, growing login volume
7Security
Availability Is a Security Property Too
Security isn’t only about keeping attackers out — it also includes ensuring legitimate users can actually log in when they need to. A Standalone deployment’s single point of failure is itself a security-relevant weakness: an attacker doesn’t need to breach any data to cause real harm, only needs to knock the one server offline to disrupt every dependent application’s logins at once.
Problem
A team runs a business-critical identity server in Standalone Mode with no documented recovery plan, no automated backups of its configuration, and no tested procedure for standing up a replacement quickly.
Why It Fails
When that single server does fail — hardware issues, an accidental misconfiguration, or a botched update — the organization can face an extended outage across every dependent application while a replacement is manually rebuilt from scratch.
Correct Approach
If Standalone Mode is chosen deliberately for its simplicity, pair it with regular automated backups of the database, an infrastructure-as-code definition of the server’s configuration, and a tested, documented recovery procedure — or, for genuinely critical deployments, move to a clustered arrangement instead.
Direct Database Access
Since a Standalone instance connects directly to its own database with no other node sharing that connection, securing that single database connection — credentials, network access, encryption in transit — carries the full weight of protecting the organization’s entire identity store.
8Monitoring, Logging & Metrics
Uptime Monitoring
Since there’s no peer to absorb traffic if this one instance goes down, uptime monitoring with immediate alerting is essential, not optional.
Resource Utilization
CPU, memory, and database connection usage on the single machine directly determine how much login traffic the whole organization can handle.
Restart Frequency
Tracking how often the instance restarts (planned or unplanned) highlights how often users are experiencing brief login interruptions.
9Best Practices & Common Mistakes
Best Practices
- Use Standalone Mode intentionally for development, testing, and genuinely small-scale, downtime-tolerant deployments
- Automate configuration and backups even in a single-node setup, so recovery doesn’t depend on manual memory
- Plan the migration path to a clustered deployment before it becomes an emergency, not after an outage forces the issue
- Monitor uptime and resource usage closely, since there’s no peer node to quietly absorb a growing problem
Common Mistakes
- Running a genuinely business-critical identity server in Standalone Mode without any tested recovery plan
- Waiting until an actual outage to start planning a move to a clustered deployment
- Assuming Standalone Mode’s simplicity means it needs less monitoring, when in fact it needs more vigilance around its single point of failure
- Manually configuring the instance through the admin console with no version-controlled record of those settings
10Real-World & Industry Examples
Local Development Environments
Developers building and testing an application’s login integration almost universally run a single Standalone Keycloak instance on their own machine or a shared development server — full production-style clustering would be unnecessary overhead at this stage.
Small Internal Tools
A small internal company tool used by a handful of employees, where an occasional brief outage during a restart is a minor inconvenience rather than a serious business problem, is a reasonable candidate for a genuinely production Standalone deployment.
Proof-of-Concept Deployments
Organizations evaluating whether Keycloak fits their needs at all commonly start with a Standalone instance to prove out the identity model before committing the additional infrastructure investment a clustered rollout requires.
11Frequently Asked Questions
12Summary and Key Takeaways
Key Takeaways
- Standalone Mode runs Keycloak as a single, self-contained server instance with its own configuration and no peer nodes coordinating alongside it.
- It sits at one end of a spectrum alongside Standalone Clustered (multiple peer nodes sharing sessions) and Domain-Managed (many nodes centrally configured) deployments.
- Its biggest advantage is simplicity and low cost; its biggest risk is being a single point of failure for every application that depends on it for login.
- It’s well suited to development, testing, and small-scale, downtime-tolerant deployments — not to business-critical production systems with real uptime requirements.
- Even when chosen deliberately, pair it with automated backups, version-controlled configuration, and a tested recovery plan.
- Growing organizations typically migrate to a clustered deployment once login volume or uptime expectations outgrow what a single instance can safely provide.
- “Standalone” describes how the server process is run — a completely separate concept from Client types or other per-application Keycloak settings.