Nextcloud Upgrades Without Losing a Weekend: Clone, Rehearse, Redeploy on PaaS

Nextcloud releases a major version roughly every four months, each one raising the minimum PHP version sooner or later, and each one with a changelog that includes at least one app that stopped working for someone. For the IT administrator at a secondary school we will call Fenwick Academy, upgrades meant a Friday evening, a full backup, and a phone that had to be answered on Saturday. This post is how she does it now on MassiveGRID PaaS, built on Virtuozzo Application Platform (formerly Jelastic): rehearse on a clone, apply with a redeploy that has a rollback point, and keep the backup one click away.

Why Nextcloud upgrades feel risky

A Nextcloud upgrade touches three things at once. The application code changes, and the updater runs database migrations that cannot be reversed by copying files back. Third-party apps may need updates of their own, and some will simply be disabled. And every major version or two, the PHP version underneath has to move, which on a traditional server means changing the operating system's packages while the site is down.

The administrator's old process handled all three with time: a long maintenance window, a full backup, and a willingness to spend Saturday fixing whatever broke. The platform lets her replace time with a rehearsal.

Step one: clone production and upgrade the clone

From the dashboard, Clone Environment makes a complete copy of the Nextcloud environment, application server, database and the data directory, in a few minutes. The clone gets its own URL on the platform domain with the built-in SSL certificate, and it has no access to the production database because it is a copy, not a link. The administrator uses the platform's network isolation on the school's environment group as a belt-and-braces measure: even a configuration file that still named the production database host could not reach it from the clone.

On the clone she runs the upgrade exactly as she will on production: put Nextcloud in maintenance mode, run occ upgrade from the built-in web SSH, review the list of disabled apps, test the SAML login, the calendar app the staff room depends on, and the desktop client sync. If something fails, the clone is deleted and the upgrade is postponed, at the cost of the hour it ran. At MassiveGRID's published rate of $0.003372 per cloudlet-hour, a clone of a 12-cloudlet environment costs about four cents an hour.

Step two: the PHP version, handled by redeploy

When a Nextcloud release requires a newer PHP, the platform's container redeploy replaces the application server's image with a newer tag while preserving the data the stack marks as user data, the web root and configuration among it. The administrator tests this on the clone first. The mechanism is what makes it safe: the platform applies the redeploy to a snapshot of the container and merges it only if every step succeeds, so a failed redeploy returns the container to exactly where it was.

The order matters and the rehearsal settles it. Nextcloud versions support a range of PHP versions, so the sequence is usually upgrade Nextcloud to the version that supports both the old and new PHP, redeploy the container to the new PHP tag, then upgrade Nextcloud again. Doing it on the clone tells her which order works for this particular pair of versions before production is touched.

Step three: production, at lunchtime

With the rehearsal passed, production follows the same steps in the same order, at a time when the school is quiet but staff are still around to notice problems. Before starting, two safety nets are set.

• A fresh database backup. The Database Backup/Restore add-on already runs nightly to a separate Backup Storage node; a manual Backup Now gives a restore point from the minute before the upgrade. Restoring it is one click from the dashboard.
• The clone kept running. Rather than delete the upgraded clone, she keeps it until production is confirmed healthy. If production fails in a way the rehearsal did not predict, the upgraded clone with yesterday's data is a fallback she can swap domains to while she investigates.

The upgrade itself takes twenty minutes. The redeploy causes a restart of the application server, which is the only downtime, and for a single-node school deployment a short maintenance page at lunchtime is acceptable. A larger deployment with several application servers would redeploy them sequentially, one at a time with a delay, so the service never stops.

Step four: watch, then delete the clone

For the rest of the day the administrator watches two things the platform already collects: the application server's statistics, because a new PHP version occasionally changes memory behaviour and the node's cloudlet usage will show it, and the load alerts, which email her if the node approaches its cloudlet ceiling. If the new version needs more memory, raising the dynamic ceiling is a slider, not a server migration.

The next morning, with no complaints, she deletes the rehearsal clone. Total additional cost of the upgrade: one clone running for about a day, a few dollars. Total weekend hours: none.

The checklist she keeps

1. Read the Nextcloud release notes for the target version and the PHP versions it supports.
2. Clone production. Confirm the clone is in the isolated group.
3. On the clone: maintenance mode, occ upgrade, review disabled apps, redeploy PHP if required, test login, sync, calendar and the two apps staff complain about most.
4. Schedule production for a quiet hour. Take a manual database backup with the add-on.
5. Repeat the rehearsed steps on production. Keep the clone running.
6. Watch statistics and load alerts for a day. Delete the clone.

For a school with one administrator, the difference between this list and the old one is not the number of steps, it is that step three happens on something that can be thrown away.

Frequently Asked Questions

Does the clone include the user files?

Yes. Cloning copies the containers' file systems, including Nextcloud's data directory, so the rehearsal runs against real files. For very large data directories the clone takes longer and costs more disk while it exists; you can also clone, then trim the data directory on the clone to a sample if only the upgrade path needs testing.

What if the new Nextcloud version needs a newer database version too?

The database container is redeployed to a newer tag in the same way as the PHP node, with data preserved. Note that the platform does not support redeploying MySQL-family databases to a lower version, so take the database backup first and rehearse the database step on the clone as well.

Can this be automated?

Yes. Clone, start, redeploy, and delete are all available through the platform API and CLI, and Nextcloud's occ commands run over SSH. A script can create the clone, run the upgrade and a smoke test, and report the result, leaving the administrator to approve production.