--- description: >- Set up approved automatic updates for a self-hosted Watcher deployment using a host scheduler, deployment pipeline, or internal mirror. --- > Part of the Watcher docs. Index of all pages, with summaries: https://watcher-docs.apolloresearch.ai/llms.txt > Before upgrading Watcher, read the release pages and full changelogs for every version crossed: https://watcher-docs.apolloresearch.ai/releases/index.md > Found an issue with this page? Report it: https://github.com/ApolloResearch/watcher-bin/issues/new?title=Docs%20feedback%3A%20Automate%20Analyzer%20updates&body=Page%3A%20Automate%20Analyzer%20updates%0AURL%3A%20https%3A%2F%2Fwatcher-docs.apolloresearch.ai%2Fself-hosting%2Fautomatic-updates%2F%0A%0A # Automate Analyzer updates Desktop [Watcher clients](../client/index.md) installed with the public installer automatically update. They must be running through their [login agents](../concepts/index.md). They update to match the version of the Watcher server they connect to. If that server stays on an old release, the desktop clients stay on that release too. You still need to keep your self-hosted [Analyzer](../concepts/analyzer.md) deployment up to date. Update the Analyzer, API, and background workloads together. Use the target release's deployment definitions. We recommend checking for releases daily. Review the required upgrade actions. Automatically deploy an approved release during a maintenance window. These are operating recommendations. Watcher does not have a built-in scheduler. Your deployment tooling owns the server update. ## 1. Establish the update policy Before enabling a job, record: - Who approves releases and who responds when an update fails. - Where the job gets release files, server images, and credentials. - The check frequency, maintenance window, and timezone. - The backup location, restore procedure, and failure-notification destination. Use the [published releases](https://github.com/ApolloResearch/watcher-bin/releases) or your approved internal release catalog to discover candidates. Exclude prereleases. Check the release notes and [required upgrade actions](updates.md) for every version crossed before approving an exact target version. A discovery job can open a change request. It must not turn a newly discovered release into a deployment approval. Use short-lived credentials. The scheduled job must be able to renew them without an interactive login. Test registry access as the same operating-system user or runner that will deploy. The bundled AWS registry-login timer refreshes Docker credentials. It does not update Watcher. ## 2. Choose where the job runs | Your setup | Recommended mechanism | What approval changes | | --- | --- | --- | | Compose on a Linux host | A systemd timer or existing host scheduler invokes your deployment job | The exact release the job may install | | Existing CI/CD or Kubernetes/GitOps | A scheduled release check proposes a change to version-controlled deployment inputs | A reviewed commit or pipeline approval promotes the target release | | Internal registry or restricted network | An import pipeline prepares an approved release for the deployment job above | Matching release files and images become available in your internal catalog | ### Compose on a Linux host Have your coding agent adapt the deployment sequence in the next section. Put it into your host's deployment job. Put the job and its scheduler configuration under your normal configuration management. If you already deploy from CI, keep using that pipeline. Do not introduce a second deployment owner. Keep a fixed Compose project name when unpacking each release into a new directory. Run `docker compose ls` to identify the existing project. Pass that name with `docker compose --project-name ...` on every deployment command. Preserve the database and audit-log volumes, external database address, and paths to operator-owned configuration. A different project name can create a second stack with empty volumes. Give a timer an explicit working directory and executable path. Schedule it inside the agreed maintenance window. Prevent concurrent deployments, including manual ones. Recheck the window when the job starts. This prevents a missed timer run from deploying after the window has closed. ### CI/CD and Kubernetes/GitOps Use one reviewed change to select the target deployment definitions and matching image tag. Keep secrets in your existing secret store. Serialize deployments to the same environment. Make backup and bootstrap failures stop the pipeline before it updates the long-running workloads. If your deployment uses the separately distributed [Watcher Helm chart](kubernetes-infrastructure.md), use the target chart with its matching `image.tag`. Its pre-upgrade bootstrap Job must finish before rollout. Confirm your GitOps controller honors that ordering. Rendering a chart into manifests alone does not establish it. Disable automatic application rollback after a database migration. Recovery needs the matching database backup as well as the previous application. ### Internal registries and restricted networks Run release discovery, verification, and scanning in the environment that can reach the release sources. Import the release files and all three server image repositories together. Follow [Use internal mirrors](supply-chain.md#use-internal-mirrors). Let the deployment job select only completed, approved imports. Keep the previous release available for recovery. Server image mirroring and client mirroring are separate choices. Clients installed from an internal mirror need an approved client release. Distribute it through your fleet tooling. This applies even after the server has updated. ## 3. Configure the deployment job Implement [Update the server](updates.md#update-the-server) in your existing deployment tooling. Use this sequence as the job's acceptance criteria: 1. Read the installed version and approved target. Exit without changing the deployment if they match or no target is approved. Treat an unreadable version or approval record as a failure. Handle downgrades as recovery. 2. Confirm all required upgrade actions are complete. Confirm the maintenance window is open. Confirm no other deployment is running. 3. Verify and stage the target release files and images. Take and verify the pre-update database and configuration backups before running bootstrap. 4. Apply operator-owned configuration to the target deployment definitions. Preserve storage, secrets, proxy settings, and the choice of whether to run async grading. Refresh release-owned utilities with the release. 5. Run the target bootstrap workload and require success. Deploy the matching API, Analyzer, retention cleanup, and enabled grading-scheduler workloads. 6. Require the public health response's `status` to be `healthy`. Require the version response to report the target release. Complete [Verify an update](update-verification.md), including a test client, before reporting success. A timer that only pulls images does not perform this sequence. Restarting only the Analyzer leaves the server components on different releases. Keep the approved version pinned throughout the job. Record the previous and target versions, backup reference, start time, and verification result. Do not include secret values. On failure, notify the owner. Pause further deployments until the failed run is investigated. Application rollback alone cannot undo a database migration. Use the [documented recovery procedure](updates.md#update-the-server). ## 4. Verify the automation before enabling its schedule Run the job manually as its scheduled identity. In a test environment, check these cases: - An approved upgrade - A repeated run at the installed version - A run without approval - A failed backup or bootstrap The last case must prevent rollout and deliver a notification. Confirm credentials renew without your interactive session. Confirm the job targets the existing storage. Record the job location, owner, schedule, last result, and next run. Enable the schedule only after these checks pass. Monitor missed checks and releases waiting for approval. Also monitor failed deployments. This prevents an idle pipeline from leaving Watcher indefinitely out of date. Public-installer clients running through their [login agents](../concepts/index.md) check the server every two to two-and-a-half hours. They can update during your server verification. A strict client canary gate requires mirror-backed distribution. Foreground-only public-installer clients require `watcher update`. Mirror-backed clients require fleet rollout. See [client updates](updates.md#update-watcher-clients). During [guided setup](setup.md), either verify the configured automation or explicitly defer it. Include an owner, reason, and follow-up date. Until it is enabled, that owner must keep the deployment current manually.