Keycloak's repository hands you start-dev and sends the rest to the docs site

Two commands, and the only mode they name is start-dev

The fastest documented path to a running process is a single command on an unpacked distribution:

bin/kc.[sh|bat] start-dev

Or, from a container:

docker run quay.io/keycloak/keycloak start-dev

The bracketed sh|bat is a platform switch, so one distribution carries a shell script and a Windows batch file, which means the Windows path is the same command with a different suffix and nothing else changes. What neither line does is name a production counterpart. There is no start goal, no production profile, and no environment variable list anywhere in the repository. The consequence for a reader is concrete: run either command and put the result behind a public hostname, and you are running a mode whose own name marks it as development, with no in-repo checklist telling you which settings must change before traffic arrives.

The nightly tag is four years older than the numbered release

Three releases are visible from the repository: a build named nightly dated 2022-09-27, version 26.7.3 dated 2026-08-31, and version 26.7.4 dated 2026-09-16. The number in a version string is a calendar-style release identifier rather than a semantic version, so the tag itself does not tell you which build is newer. That makes the 2022 nightly the trap for automation: any script, registry mirror, or dashboard that sorts releases by timestamp can select a build predating the numbered ones by years. The practical rule for a repeatable deployment is to pin the numbered version and treat the nightly tag as something whose date you read every time rather than something you consume, because a stale artifact selected by a naive sort looks exactly like a fresh one.

Cloning gives you forty modules, not a server

The repository root is a Maven multi-module tree: quarkus/, rest/, authz/, authzen/, scim/, saml-core/, saml-core-api/, federation/, crypto/, themes/, js/, operator/, test-framework/, testsuite/, boms/, and misc/ sit beside pom.xml, maven-settings.xml, the mvnw and mvnw.cmd wrappers, and the get-version.sh and set-version.sh scripts. Source of that shape is not a runnable product. The build path is delegated to docs/building.md, and the README names no Maven goal, no profile, and no flag, so there is no build command in the repository to copy into a pipeline. What the layout does show is the product's shape: SAML code lives here, an authzen module lives here, a container operator lives here, and a Node.js adapter does not.

No Java floor, no memory figure, no database name

The project is Java and Apache-2.0 licensed, and the repository root carries no toolchain marker at all: no .sdkmanrc, no .tool-versions, no .java-version, and no root Dockerfile. Nothing in the README states a minimum or maximum JDK, a heap size, a database it expects to persist into, or a supported platform beyond the sh and bat script pair. A reader arrives with no way to know whether the installed Java is compatible until the process starts and something breaks, and the failure will not name a version requirement. If your decision depends on running this on a chosen base image or an existing Java version, the only pointers the repository offers are the downloads page and the documentation site, so check those before you commit to a runtime.

RELEASES.md sits at the root and the README never points at it

RELEASES.md, GOVERNANCE.md, MAINTAINERS.md, PR-CHECKLIST.md, and SECURITY.md all sit in the repository root, and the README links only to CONTRIBUTING.md. The release history is therefore in the repository and unreferenced from the entry point. Nothing here documents rollback, realm export or import, theme compatibility between versions, or a supported upgrade path from any earlier number to 26.7. Plan an upgrade expecting to derive the procedure yourself from the documentation site, and expecting no statement in this repository about whether an upgrade can be undone or what a realm survives. For a reader who needs the rollback story in writing before deploying to real users, that gap is the reason to verify elsewhere first.

Disclosure is a policy file, defects are tracker issues with repro steps

Vulnerabilities are routed to the repository security policy page, and defects go to the issue tracker with what the project asks for: a good summary, a description, and steps to reproduce. The tree also carries scanning configuration that acts before merge rather than after release: .gitleaks.toml for secret detection, a .trivy/ directory for vulnerability scanning, SECURITY-INSIGHTS.yml, and a crypto/ module. None of that describes a running deployment. A flaw in a realm you configured, or in a theme you wrote, is not a repository defect, so neither the policy file nor the issue tracker covers it, and the README gives no response time and no disclosure window for either path. Report engine bugs here; take configuration problems to the community channels.

Adapters and client libraries ship from sibling repositories

This repository covers the Keycloak server and the Java adapters, with ADOPTERS.md at the root. Everything else a consuming application needs sits next door: keycloak-client holds the client libraries, keycloak-nodejs-connect is the Node.js adapter, and keycloak-quickstarts holds the QuickStarts. A Node.js or single page application reaches for the client library or the Connect adapter, and both track their own release cadence rather than the server's. The consequence is version skew: nothing in this repository states which client library or adapter release matches a given server build, so a mismatched pairing surfaces as a runtime failure inside your own application rather than as a failed installation of Keycloak, which leaves you bisecting across two repositories.

Help arrives through Slack channels and a mailing list under CNCF governance

Questions go to a user mailing list on Google Groups, to the #keycloak Slack channel for general questions, to #keycloak-dev for design and development, and to community meetings, with Slack accounts created at slack.cncf.io. Participation is governed by the CNCF Code of Conduct, enforced by the project, with incident reports and appeals emailed to [email protected], and GOVERNANCE.md at the root indicates who decides what. What you do not get from any of these channels is a stated response time, a support contract, or a compatibility answer, so a production decision about an upgrade path or an adapter pairing has to come from the documentation site or from testing in your own environment.

Editorial conclusion

Choose Keycloak when you want identity in Java and accept reading the documentation site rather than the repository for every operational decision, because the repository hands you a development start command and nothing about production mode, Java versions, or upgrades. Teams that need their upgrade path and rollback story written down before they commit should confirm both on keycloak.org first, and anyone expecting adapters, client libraries, or quickstarts inside this repository will be tracking a second release stream.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes