# Upgrades

> How releases reach your deployment, and how to upgrade the stack.

LightHouse is upgraded by Atlantic. Your deployment is upgraded by you, as a reviewed change, when you choose.

## Release cadence

Atlantic releases LightHouse, the engine and the infrastructure modules as tagged versions, each with its changes in the [changelog](/changelog/). There is no fixed cadence. How Atlantic tells you before something changes: [Change notices](/trust/change-notices/).

## Upgrading the stack

Your stack pins Atlantic’s module at a tag, `?ref=vX.Y.Z`, and every image by digest. To upgrade:

1. Open a merge request that moves the tag (and any image digests) to the new version. A dependency bot such as Renovate can propose it.
2. Read the release’s changelog and the plan your pipeline shows.
3. Merge. Your pipeline applies it from `main`, with the same deployment identity as the first time.

Never point the stack at a branch: a tag is what makes a deployment reproducible.

## Engine versions and the telemetry contract

A newer engine can speak a newer revision of the [telemetry contract](/concepts/telemetry-contract/) than LightHouse accepts. It sends only what the revision it is told LightHouse accepts allows, and holds back anything newer, so upgrading the engine first is safe.

## Rolling back

Move the tag back in a merge request and apply. Data stores (the key, the database, the file system, the secrets) are kept across versions and across a change of [deployment profile](/concepts/deployment-profiles/). An agent’s own version is rolled back separately, through the release ledger: see [Versioning and rollback](/build/versioning/).

Source: https://docs.atlanticagenticlabs.com/operations/upgrades/