Updates
Releases come in two shapes; your deployment tells them apart by itself.
| Shape | What it is | How it applies |
|---|---|---|
| Soft | Image-only: a pull and a container restart, confirmed locally against the release manifest | Automatically where an applier exists (something that can pull images and restart services), typically within ~15 minutes of a release |
| Hard | A new required env var, or a release the vendor flagged breaking | Never automatic: the console shows Update needs an operator naming exactly what to set (names only; values never leave the deployment) |
| Platform | Soft updates |
|---|---|
| Docker / Compose | Applied automatically, through the bundled updater. |
| AWS (CloudFormation quicklaunch) | Applied automatically via the stack's updater Lambda. EnableAutoUpdate=false removes the applier. |
| Kubernetes (Helm) | Off by default (images stay pinned). One value, image.tag: policy-stable, turns on a moving channel plus the chart's nightly roll. That roll is unconditional, so it applies hard releases too (they stall rather than start). Automatic image updates. |
| Railway | Never auto-applied; redeploy the service, or bump its pinned image tag. |
Auto-apply is on by default wherever an applier exists. Toggle it in the console's sidebar
Updates panel, or via the API (capability update:run):
PUT /admin/update/settings
{ "autoSoftUpdates": false }
Schema and data migrations
No manual migration step: the gateway self-migrates its schema on boot, and migrations are
expand/contract-safe, so rolling updates and rollbacks keep working. Durable state (spend
history, client keys, provider keys, caps, aliases, routing config) lives in Postgres, not the
containers; nobody re-runs anyray-connect after an upgrade. To roll back, pin the previous
ANYRAY_IMAGE_TAG and re-pull (note your version before updating; latest records no prior
one).