Releases

Citadel is under development and has not had a public release. Version numbers in the source identify builds; they do not establish a published release history. Use the matching current Core, Agent, and frontend build when testing Citadel.

Use the Citadel releases page to check for published versions and their notes when they become available. Leaving CITADEL_IMAGE blank in your installation's .env uses ghcr.io/citadel-p/citadel:latest. You can set a complete image address to choose a specific version instead.

The release workflow prepares notes for features, fixes, and breaking changes. It publishes Core and Agent container images with release-manifest.json (exact image digests, architectures, and signing identity) and SHA256SUMS (the manifest checksum). Check the published artifacts before choosing an image; a version in the source or an image tag alone does not mean a release is complete.

Choose an image versionCopy Anchor Link

The release workflow uses these tag conventions:

• Stable images use a full MAJOR.MINOR.PATCH version, with moving minor and major aliases. Core also uses latest for the newest stable image.
• Development images use a MAJOR.MINOR.PATCH-dev.N tag and the moving dev alias. They do not update stable aliases or latest.

These describe the publication scheme, not a list of available releases. Use an exact published version or digest when you need a repeatable installation. Pulling a newer image does not update a running container until you recreate it with docker compose up -d.

Documentation and APICopy Anchor Link

During development, documentation can change alongside the implementation. For build-specific instructions, read docs/content/docs at the source revision used to build your installation. Use your installation's /openapi/public/v1.json when building integrations; enable Swagger as described in the API reference.

See API Reference for reference options, including Swagger UI on your own installation.

For installation steps, see install Citadel. Before changing versions, follow upgrade and rollback.

Development database changesCopy Anchor Link

Development builds can change the database baseline. Check the target build's instructions before updating; do not assume an existing development database can always be upgraded in place. If startup reports a migration checksum mismatch, stop and investigate rather than rewriting the migration journal or applied checksums.

Back up the database, configuration, recovery keys, and workload data before changing builds. If a clean installation or data import is required, verify it separately and preserve the original database and volumes until recovery succeeds. Changing an image does not undo migrations; follow upgrade and rollback for the full procedure.