Skip to content
Allay

WikiAllay Server

Releasing

Nothing deploys by itself. Every push to master that touches the server runs the tests and builds ghcr.io/allay-ai/server:sha-<commit>. Servers pin a released version.

#Make a release

  1. Add a ## X.Y.Z section to CHANGELOG.md: patch for fixes, minor for features, major for breaking changes. Push it.

  2. Run the “Release” workflow:

    gh workflow run release.yml -R allay-ai/server -f version=X.Y.Z

    Its changelog field overrides the section; one of the two must be there.

  3. Watch it with gh run watch.

The workflow tests the code, pushes ghcr.io/allay-ai/server:X.Y.Z, tags vX.Y.Z, and creates the GitHub release with a docker pull line.

#The version

Nothing in the repository holds the version. The image gets it as the APP_VERSION build argument, and /api/health reports it.

#After the release

With its moonlands switch on (the default), the workflow's deploy job starts Moonlands' ship-plugin.yml, which puts the new backend on that server. It needs the FAMILY_ACTIONS_TOKEN secret.

Never delete or re-tag a published release; finish a half-failed one by hand.

#The weekly autopilot

.github/workflows/autopilot.yml runs Claude every Monday at 03:00 UTC. It updates dependencies, fixes what they break, pushes to master, and runs the “Release” workflow when what the project ships changed. It needs the CLAUDE_CODE_OAUTH_TOKEN secret.

Next: Development