A service on your Ubuntu servers was installed as a snap, and its version changed overnight with no deploy from your team. Why did that happen, and what control do you actually have over when snaps update?

## Why the version changed Snapd's design assumption is that keeping software current is more valuable than keeping it frozen — a defensible position for a desktop browser, and a jarring one for a server. `snapd` polls the Snap Store on a timer, by default several times a day, and when the channel you track has a newer revision it downloads and switches to it. No operator action is involved; nothing you did triggered it. This is the single most important operational fact about the format: **a snap's lifecycle is not your deploy pipeline's lifecycle** unless you deliberately make it so. You can see the schedule directly: ``` $ snap refresh --time timer: 00:00~24:00/4 last: today at 04:22 UTC next: today at 11:07 UTC ``` That `00:00~24:00/4` is the default: four refresh attempts spread through the day, randomised so the store is not hit by every machine at once. ## Lever 1: pick the right channel and track A snap's channel is `track/risk` — `latest/stable`, `latest/candidate`, `latest/beta`, `latest/edge`. The single most common self-inflicted wound is running something other than a stable risk level in production because it was installed that way once. Beyond risk, some publishers define extra **tracks** that correspond to major versions, so you can follow a major line and receive only its updates instead of jumping major versions automatically. `snap info <name>` lists the channels a snap publishes, and `snap refresh --channel=<track>/stable <name>` moves to one. Choosing the right track is not a workaround — it is the intended mechanism for controlling how much change you accept. ## Lever 2: hold refreshes `snap refresh --hold` suspends refreshes. The important nuance is scope: holding a **named** snap can be indefinite (`--hold=forever`), whereas a **blanket** hold covering all snaps is capped — the documented limit is 90 days — because snapd deliberately refuses to let a machine drift unpatched forever. `snap refresh --unhold` releases it, and `snap refresh --list` shows what is waiting. The older equivalent, still present, is the system configuration option `snap set system refresh.hold=<time>`, which defers until a given moment. ## Lever 3: control when, not whether Often the real complaint is not that the snap updated but that it updated at 14:00 on a weekday. `snap set system refresh.timer=` accepts a schedule string, so you can confine refreshes to a maintenance window — a Sunday-night slot, for example. Related knobs exist for constrained environments, such as holding refreshes while the connection is metered. This is usually the healthiest compromise for a fleet: the machine stays patched, but the change lands when someone is watching. ## Lever 4: revert quickly when a revision is bad Because snapd retains previous revisions (`refresh.retain` governs how many), rollback is a genuine primitive rather than a reinstall: ``` sudo snap revert nextcloud # back to the previous revision sudo snap revert nextcloud --revision=1234 # or a specific one ``` That retention is one of the format's real strengths, and it changes the incident calculus: an unexpected refresh that breaks a service is a one-command recovery, provided you notice. ## Lever 5: put a proxy between the fleet and the store For an organisation, the supported answer is Canonical's **Snap Store Proxy**: the machines are pointed at your proxy instead of the public store, and the proxy controls which revisions are offered, so you can test a revision and then release it to the fleet. That converts snap refresh from an upstream event into an internal one, which is what change control actually requires. It is infrastructure to run, so it is worth it when snaps are load-bearing for you and not otherwise. ## The judgment answer The strong senior answer does not stop at flags. It says: alerts and change records should include snap revisions, so a version change is visible rather than discovered during an incident; a service whose availability you own should be delivered in a format whose update timing you own, which for many teams means an archive package or a container image rather than a snap; and if snaps are the delivery format — as they are for some Canonical-adjacent tooling — then the right posture is a stable track, a maintenance-window timer, a proxy for anything critical, and a rehearsed `snap revert`. Simply trying to disable snapd's updating outright fights the design and eventually fails.