The snap's promise is install and forget - and updates are where that promise is kept. Here is what actually happens on update day, and the controls you still hold.
On a manual install, updating Nextcloud is a project you schedule. On the snap, snapd checks the store several times a day and refreshes the package by itself - that is the design, and Nextcloud's own manual describes the snap as a Nextcloud that updates itself. Self-updating software deserves two questions: what exactly will it do to my server, and what levers do I still have? Both have good answers.
When snapd refreshes Nextcloud, it downloads the new package, swaps the running services over to it - expect the web interface to blink for a short moment - and Nextcloud runs its own internal upgrade steps for the database and apps. Your data directory and database are not replaced; they are upgraded in place, which is why an export backup before big version jumps is still the wise habit from the backup guide.
One calming detail: the snap team traditionally holds a brand-new major Nextcloud release back briefly while it is tested in the snap's channels, so snap users usually receive majors slightly after the manual crowd - wearing that as a feature, not a delay.
Automatic does not remove your timing choices for the updates that matter:
snap info nextcloud shows the channel you track and the version waiting or installedsudo snap refresh nextcloud pulls the pending refresh immediately - the move to make on a quiet Sunday instead of a busy Mondaysnap refresh --time shows when snapd plans its automatic checks, and the refresh schedule itself can be shaped in snapd's settings for those who want a set windowSometimes a hold is right: the office cannot risk any change this week, or you want to read about a release first. sudo snap refresh --hold nextcloud pauses automatic refreshes for the package, and --unhold resumes them. Use it like a snooze button, not an off switch. Every week an internet-facing file server runs an old release, it runs with publicly documented flaws unfixed - the hold should be measured in days, with a date in your diary to release it.
Snap keeps the previous revision of the package on the machine, which gives you the escape hatch manual installs envy: sudo snap revert nextcloud returns the application to the revision before the refresh while you investigate. Revert is a bridge, not a home - find the cause (the snap's logs and the Nextcloud log are the first reads), fix it, and refresh again. And the honest footnote: revert rolls back the program, which is one more reason the data-level backup from the export command stays part of the routine.
The one-step install in the video - updates like these are why the easy route keeps being easy.
Watch Full VideoRefreshes are the snap's normal, tested path and major releases are held briefly for testing before they reach the stable channel. Breakage is rare - and if it happens, the previous revision is one revert command away while you diagnose.
You can hold refreshes indefinitely, but it is a bad bargain: you would own an internet-facing server with known, published vulnerabilities and no fixes arriving. Hold for days when you need stability - then let it update.
The refresh replaces the application code and upgrades the database structure; your data directory stays yours. That is by design - and keeping an export backup before major jumps remains the belt-and-braces habit.