Nextcloud 32 to 33 upgrade: why now and what the supported path requires
An operator running Nextcloud 32 cannot jump straight to a later release. Nextcloud does not allow skipping major versions, so moving to Nextcloud 33 is the next required step on the path, and it should be planned as a dedicated change window. Nextcloud publishes a new major version every four months and supports each one for a year through monthly maintenance releases that address known critical bugs and security problems. Nextcloud 33 is supported until February 2027. Nextcloud 34 follows with support until June 2027, and Nextcloud 35, released on 16 September 2026, reaches end of life in September 2027. Each of these releases is a separate step, so the 33 move is one link in a chain.
Timing is the first decision. Support for Nextcloud 33 ends in February 2027, and the next major release, Nextcloud 36, is scheduled for 17 February 2027. An operator who waits until the 33 support window is nearly closed will be planning the 33 move and the following step at the same time, with less room to test. Before anything else, confirm the support status of the release you run today in Nextcloud's maintenance and release schedule. Confirm the exact version your instance runs, including any installed through a container or packaged method, because the starting point determines the steps. Record the end-of-life dates for your current release and for 33 in the change calendar so the people who approve maintenance windows can see the deadline.
The supported path is sequential. Back up data and the database before every upgrade, move one major version at a time, and disable third-party apps until each one is confirmed compatible with the target release. Apps are the usual source of delay, because an app that has not been updated can block the upgrade or fail after it completes. Assign a named owner to the app inventory, record which apps support business processes, and decide in advance whether each incompatible app will be removed, replaced or deferred. Those decisions usually take longer than the mechanical upgrade, so settle them before the first test run begins.
Plan the next step now. Once 33 is in place, 34 is the next move, followed by 35, and each has its own requirements and support window. A team that completes 33 and then stops has a supported instance only until February 2027. Write down the target release for the next two changes, the owner for each, and the date by which the next upgrade must start. If the organization needs maintenance longer than the standard one-year window, Nextcloud's pricing page describes Enterprise options: Standard includes one year of maintenance, and Premium adds a maintenance lifecycle of five or more years. Confirm with Nextcloud which option matches your requirement before you fix the schedule.
What changes in Nextcloud 33 and what each change asks of you
This table lists the Nextcloud 33 changes that most often block or delay an upgrade from Nextcloud 32, with the impact of each and the action your team should take before the upgrade window. Use it as a checklist: confirm exact minimum versions in the release notes and system requirements, then assign an owner to each row. The main takeaway is that the PHP and database changes need the most lead time, while the configuration, monitoring and network changes are quick to review but easy to miss.
| Change | Impact | Action needed |
|---|---|---|
| Dropped PHP 8.1 | Servers still running PHP 8.1 cannot run Nextcloud 33 | Confirm the PHP runtime against the system requirements and upgrade PHP before the Nextcloud upgrade |
| Dropped PostgreSQL 13 | Databases on PostgreSQL 13 fall outside the supported range | Plan a PostgreSQL upgrade, test it on a copy of the database, then upgrade |
| Dropped Oracle 11g | Oracle 11g installations are no longer supported for Nextcloud 33 | Plan a move to a supported Oracle release, confirming the minimum in the system requirements |
| Snowflake ID server configuration | Server ID settings in config.php may need review on each node | Review config.php on every node and confirm the setting against the release notes |
| New metrics endpoint | Existing monitoring scrapes may not match the endpoint | Update the monitoring scrape configuration and confirm the endpoint in the release notes |
| AI task worker change | Background AI task workers may run differently after the upgrade | Review worker setup, service units and queue access before enabling AI features |
| Connectivity check allowlist changes | Connectivity checks may reach hosts that current firewall or proxy rules block | Update firewall or proxy allowlists to match the hosts listed in the release notes |
How the PHP, database and Snowflake ID changes affect your stack
Settle the PHP, database and operating system targets before you change the Nextcloud package. Nextcloud 33 drops PHP 8.1, PostgreSQL 13 and Oracle 11g, so any server still running those versions must move first. The changes cascade. A new PHP version determines which PHP packages, extensions and php-fpm pool settings your operating system can supply, and each extension Nextcloud depends on (database drivers, intl, GD, Imagick, APCu, Redis) must support the target PHP release. The web server configuration follows PHP, and the database upgrade follows both. Put these in a written order: operating system, PHP and extensions, web server, database, then Nextcloud. Each step should be tested on a copy of production before the next one starts.
Confirm every minimum against the Nextcloud 33 system requirements documentation before you order packages, because the exact supported PHP, database and web server versions for 33 are the ones that govern this plan. Then check your operating system vendor's support matrix for the PHP and database packages you intend to use. Distribution repositories often ship older PHP or PostgreSQL builds than the Nextcloud minimum requires, so decide early whether you will use distribution packages, a vendor repository or containers. Each choice changes who patches the runtime, how long the stack stays supported and how much effort the upgrade takes. Ask your partner or internal team to record the chosen source for each component in the change plan.
Review the Snowflake ID server configuration on every node, including each member of a clustered deployment and every instance behind a load balancer. Treat this as a cluster-wide setting, not a one-server edit. Check the value in the configuration file on each node, and check any configuration management tool or container image that might override it. Confirm the exact configuration key, its default and its behavior in the Nextcloud 33 release notes and admin manual, and ask your team to write down the value each node should hold. Nodes that disagree during a rolling upgrade are the main risk here, so schedule the change so all nodes receive the same setting before traffic returns.
Plan the target version with the support calendar in mind. Nextcloud 33 is supported until February 2027, according to the maintenance schedule, so a team that is far behind may need several major steps, and each one needs its own backups and app checks. Nextcloud 35 recommends MariaDB 11.8 or PostgreSQL 18, PHP 8.5, and Apache 2.4 or nginx with php-fpm. If your path continues past 33, read the Nextcloud 34 to 35 upgrade page before you commit to a database or PHP target, because the requirements for 35 may change which versions you should install during this upgrade. Do not install the target database or PHP version solely because it is newest without checking each release's requirements first.
Preparing the Nextcloud 33 upgrade: backups, inventory and a test copy
Each card below is a task that must finish before the Nextcloud 33 upgrade starts, and each produces evidence the next step depends on. Nextcloud requires one major version at a time, a backup before every upgrade and third-party apps disabled until they are confirmed compatible, so these tasks set the conditions for a safe rollback and a clean test run.
Full backup before each step
Back up the data directory, the database and the configuration before the upgrade starts, and repeat the backup before each later major step. Nextcloud's upgrade documentation calls for a backup before every upgrade, so the backup is a precondition for the work that follows. The Nextcloud administrator owns the backup job, and the infrastructure team owns the storage it writes to. Evidence is a dated backup record plus a restore test on a separate host, which shows the copy can actually be used.
Third-party app inventory
List every installed app with its version, maintainer and source, then mark each one as confirmed compatible with Nextcloud 33 or disabled until it is. This list decides which apps run after the upgrade. Check the runtime versions against the Nextcloud 33 requirements too, since PHP 8.1, PostgreSQL 13 and Oracle 11g are dropped in this release. The Nextcloud administrator owns the list, and each app owner signs off on compatibility. Evidence is the signed inventory.
Custom configuration and proxy rules
Export config.php, any environment-specific overrides and the reverse proxy rules in front of the instance, then record why each custom setting exists. Nextcloud 33 changes several configuration areas, including the Snowflake ID server configuration and the connectivity check allowlists, so an undocumented override is a likely source of a surprise after the upgrade. The platform team owns this record, and the network team owns the proxy rules. Evidence is a versioned configuration export with a reviewed note for each setting that differs from defaults.
Test environment cloned from production
Build a non-production copy with the same Nextcloud version, PHP and database versions, apps and a recent copy of production data, then run the full upgrade there first. Isolate the copy from users, production storage and outbound email and notifications so test activity cannot reach live sharing. The platform team owns the clone, and the Nextcloud administrator owns a script of user journeys to check after the upgrade. Evidence is an upgrade log, a list of failed checks and the fixes applied before production.
Monitoring and metrics review
Capture a baseline of response times, error rates, cron health and storage use before the upgrade, so later changes can be traced to Nextcloud 33 and not to unrelated load. Nextcloud 33 introduces a new metrics endpoint, so confirm who can scrape it, how it authenticates and that your monitoring stack reads it before go-live. If you run AI features, review the AI task worker change as well. The SRE or monitoring team owns the baseline. Evidence is a dated baseline export and alerts tested in the test environment.
Upgrade sequence from Nextcloud 32 to 33 with rollback points
This sequence moves a Nextcloud 32 instance to Nextcloud 33 in controlled stages, with a named rollback point after each change so a failed step can be reversed without losing data. It keeps the one-major-at-a-time rule, because Nextcloud does not allow skipping major releases. The result is a production instance on 33 with a written record of checks and rollback references.
Freeze changes and confirm current version
Stop all non-essential changes to the instance for the upgrade window and record the exact Nextcloud 32 release, PHP version, database engine and version, web server, and installed app list with versions. Export the configuration directory as a baseline. The administrator confirms the instance is on 32 and that 33 is the next step, since Nextcloud does not allow skipping major releases. Done means the baseline record is signed off by the change owner and the output of the status command matches the recorded version. This baseline is the reference point for any later rollback decision.
Take and verify backups
Take a full backup of the data directory, the configuration directory, and the database, taken at the same point in time so files and database metadata agree. Store the set outside the application server. Restore the set into a separate test environment and confirm that login works, a sample of files opens, and file counts match the source. Rollback point 1 is this verified backup set. Nextcloud's upgrade guidance calls for a backup before every upgrade, and the team should not proceed until a restore has been tested, not only written.
Upgrade runtime and database prerequisites in a test copy
Build a copy of the production instance from the verified backup. Remove the prerequisites that Nextcloud 33 no longer supports, which the topic notes include PHP 8.1, PostgreSQL 13, and Oracle 11g, by moving the runtime and database to versions the 33 system requirements list. Confirm those minimums against the 33 requirements page before choosing targets, because they are not restated here. Run the upgrade of PHP and the database on the copy first, then confirm the 32 instance still starts and serves files. Rollback point 2 is the test copy itself, with production untouched.
Disable third-party apps and confirm compatibility
On the production instance, disable every third-party app before the core package is replaced. Review each app against its listed compatibility for Nextcloud 33 and record the result, including any app that has no 33 release. Keep the disabled list and the app versions in the change record. Verification is an app listing where only the shipped apps remain enabled, and the compatibility table has a decision for every removed app. Rollback point 3 is the recorded app inventory with versions, which allows each app to be restored to its prior release if needed.
Apply the 33 package and run the upgrade
Enable maintenance mode, replace the server code with the Nextcloud 33 package while keeping the configuration and data directories, and run the occ upgrade command from the command line. Watch the output and the server log for migration errors, then disable maintenance mode. The step is done when the status command reports 33, background jobs run, and a test login and file upload succeed. If migrations fail, rollback point 4 is restoring the verified backup set from step 2, with the code, data, and database restored together, because a partial restore can leave files and metadata out of step.
Update server configuration for 33
Apply the Nextcloud 33 configuration changes covered in this guide: the Snowflake ID server configuration, the new metrics endpoint, the AI task worker change, and the connectivity check allowlists. Test the metrics endpoint from the monitoring collector, confirm that an AI task completes on the worker, and confirm that the connectivity checks pass for each allowlisted host. The administration overview should show no new configuration warnings. Rollback point 5 is the configuration export from step 1, so each setting can be compared and reverted individually.
Re-enable apps one at a time with checks
Re-enable the third-party apps one at a time in the order set in the change record. After each app, test its core function with a named user, check the server log for new errors, and record the result before enabling the next app. An app that fails is left disabled and referred back to its vendor or to the compatibility decision from step 4. Done means every app has a recorded pass or a documented exclusion. Rollback point 6 is disabling the single app just enabled, which keeps the failure isolated from the rest of the instance.
How to test the 33 upgrade and roll back if it fails
The test copy is the only place where the 33 upgrade and a rollback can be proven before production users depend on the result. Clone the production database, the data directory, the configuration files and the installed app set onto infrastructure that matches production in PHP, database, web server and identity provider versions. Isolate the copy from live users, outbound email and push notifications so that test activity does not reach live accounts, and disable external storage credentials that could write to production systems. Run the upgrade on the clone first, one major version at a time, and record every warning the upgrade prints before you change anything else.
Run the checks your users depend on against the upgraded clone. Test login through the identity provider you chose, whether that is the LDAP backend, OpenID Connect or SAML, including group membership and one account that should be denied. Sync files from a desktop client and from at least one mobile client, creating, editing, renaming and deleting files in both directions. Exercise internal, external and link shares, confirm external storage mounts still resolve and read and write, and check that background jobs run and cron reports healthy. Then verify that your monitoring scrapes the metrics endpoint, that AI task processing completes a test task on the worker you run, and that outbound connectivity checks succeed against your allowlist.
Several 33 items need confirmation in your own environment instead of assumption. Confirm that your PHP runtime is not 8.1, that your PostgreSQL server is not version 13, and that no Oracle 11g database remains in the path, because those platforms are dropped in this release. Confirm that the Snowflake ID server configuration matches what your deployment expects, check that the metrics endpoint and its access control behave as your monitoring requires, and confirm the AI task worker still receives work after the change. Record the outbound hosts the connectivity checks contact and compare them with your firewall and proxy rules, because a blocked check often looks like a fault in another component.
Set the rollback decision point before the upgrade starts and write it down. The practical point is the last moment at which the clone and production can be compared without loss. Once users create or change data on the upgraded instance, restoring the pre-upgrade backup discards that work. Agree who has authority to call the rollback, which evidence triggers it (a failed login path, sync corruption, a broken background job or a failed restore check), and how long the team waits before deciding. Rehearse that decision on the clone by deliberately failing one check and carrying out the full rollback, timing each step so the production window is based on measured steps.
What drives the effort of a Nextcloud 32 to 33 upgrade
This table lists the factors that most change how much work a Nextcloud 33 upgrade involves, why each one adds effort and what to verify before scheduling. Read each row as a question to answer about your current installation. The main takeaway is that the largest drivers often sit outside the Nextcloud code itself, in apps, databases, proxy rules and monitoring.
| Driver | Why it lengthens the work | What to check |
|---|---|---|
| Third-party apps | Each enabled app must support Nextcloud 33, and unmaintained apps may block the upgrade or fail afterward. | Every enabled app, its version, its maintainer activity and whether a 33-compatible release exists. |
| Database engine and size | PostgreSQL 13 and Oracle 11g are dropped, so the database may need its own upgrade first. Larger databases lengthen migration steps and restores. | Current engine and version, database size, upgrade path to a supported version and a tested restore time. |
| Number of nodes and load balancer behavior | All nodes must move to the same code version, and sticky sessions or health checks can route users to nodes mid-upgrade. | Node count, shared maintenance mode, session affinity settings and load balancer health check rules. |
| Custom configuration | Overrides in config.php, trusted domains, trusted proxies and caching settings must be re-tested against the new release. | A diff of config.php against defaults, trusted proxy and trusted domain entries, and any custom scripts. |
| Reverse proxy rules | Rewrites for well-known paths, headers and body size limits can break login, sync or the admin interface after the upgrade. | Proxy rules for well-known URLs, forwarded headers, upload limits and WebDAV paths, tested against a staging copy. |
| Connectivity check allowlists | Nextcloud 33 changes the connectivity check allowlists, so outbound checks and integrations may need updated entries. | Outbound firewall and proxy rules, current allowlist entries and the connectivity check results after upgrade. |
| AI features and worker configuration | The AI task worker change means background processing and AI apps need configuration review, which adds testing time if AI features are used. | Whether AI apps are enabled, background job mode, worker processes, task queues and the Nextcloud 33 AI worker documentation. |
| Monitoring integrations | The new metrics endpoint may change paths or access, so existing scrapers, dashboards and alert rules can stop collecting data. | Scrape configurations, authentication for the metrics endpoint, dashboards and alert rules that depend on current metrics. |
| Test environment state | A staging system that differs from production in apps, data, versions or configuration gives results that do not predict production behavior. | Version parity, app list parity, a recent data copy, matching configuration and a completed test upgrade with a restore. |
| Change windows and approvals | Maintenance windows, change approvals and rollback sign-off set the schedule, and a failed upgrade may require a restore inside the window. | Agreed window length, verified backup, rollback procedure, named approvers and user communication timing. |
How much does a Nextcloud 32 to 33 upgrade cost and what does it need from our team?
What makes up the cost of a Nextcloud 32 to 33 upgrade?
The upgrade software itself carries no license fee for the community edition, so the cost is the labor and infrastructure around the change. Your team is paid in internal hours for planning, app review, backups, testing and sign-off. A partner's fee follows the written scope, which typically covers discovery of installed apps and current PHP and database versions, the staging rebuild, the production upgrade run and rollback testing. Test infrastructure is usually a second environment in your own cloud account or data center, and you pay for it directly. Recurring costs appear only if you buy post-upgrade support or a retainer, or if you choose an Enterprise subscription. Ask for each line item separately, mark which items are one-time and which recur, and check whether PHP or database changes for the 33 requirements are included, because platform rebuilds add effort.
Can our internal team run the Nextcloud 33 upgrade without a partner?
Yes, a team with Linux, PHP, database and web server experience can run the upgrade alone if it follows the documented steps. The upgrade manual requires one major version at a time, a backup before every upgrade, and third-party apps disabled until they are confirmed compatible. The hardest work is usually outside the core upgrade: confirming which apps still work, moving off dropped platform versions such as PHP 8.1, PostgreSQL 13 or Oracle 11g if you run them, reconfiguring the Snowflake ID server and the metrics endpoint, and testing desktop and mobile sync clients, Talk and external storage after the change. Teams without spare staff for a staging copy, regression testing or a change window often bring in a partner for scoping and the test run. Compare your capacity with the 33 release notes and your own app list before deciding.
How long does a Nextcloud 32 to 33 upgrade take, and what drives it?
Duration depends on how many things change at once, so the version step alone rarely sets the timeline. The main drivers are the number of installed apps that need compatibility checks, the size of the database and file store that backups and restores must handle, whether PHP or the database must also be upgraded, and how many integrations need reconfiguration, including identity, chat, monitoring, the AI task worker change and connectivity check allowlists. The number of test cycles your business requires before sign-off also matters. Scheduling is often the longest part, because change windows and approval cycles can take longer than the technical work. We do not give a duration here because it depends on your environment. Ask any provider for a timeline tied to a written scope, and ask your team to list each dependency so the estimate can be checked.
What do we need to provide before a Nextcloud 33 upgrade starts?
The upgrade needs named owners, access, a test environment and a change window before work begins. Assign one accountable owner for the decision, one administrator with server and database access, an owner for each business-critical app or integration, and a sign-off contact from the business. Provide shell or console access to the host or containers, database credentials with rights to run migrations, and admin access to the Nextcloud interface. A staging copy built from a recent backup, ideally in the same infrastructure as production, lets you test the 33 changes without touching users. Agree a change window that covers the upgrade, rollback and user testing, keep a backup taken before the first step as your rollback point, and tell users early that the service will be unavailable during the upgrade run.
Does Nextcloud Enterprise change the 33 upgrade or its cost?
Enterprise changes the support and maintenance terms around the upgrade more than the upgrade steps themselves, but confirm this with Nextcloud for your version. Nextcloud sells Enterprise in Standard, Premium and Ultimate tiers with a 100-user minimum. According to Nextcloud's pricing page, list prices start at 71.29, 104.99 and 204.75 euros per user per year respectively for 100 or more users, with lower rates from 200 users. Standard includes one year of maintenance. Premium adds a maintenance lifecycle of five or more years, extended support hours and clustered instance support. Ultimate adds support up to 24/7 with response times down to one hour. Enterprise is a recurring subscription, so it is a cost on top of the upgrade. Confirm which tier and lifecycle cover Nextcloud 33, and whether that support includes help with the upgrade itself.
Can we jump straight to Nextcloud 33 from an older release?
No. Nextcloud does not allow skipping major releases, so an older installation must move through each intermediate major version in order, with a backup and a check of third-party apps at every step. Nextcloud 33 is supported until February 2027 according to the maintenance schedule, so it is a current target, but plan your next upgrade early because Nextcloud publishes a new major version every four months. Each intermediate step can require PHP or database changes, so an older system may need several rounds of platform work before the Nextcloud steps begin. Ask for a step-by-step plan that lists each intermediate version, its platform requirements and its backup point. Confirm each step's requirements with Nextcloud before you begin, because platform minimums change between releases.
What should a written quote for a Nextcloud upgrade include?
A written quote should list each deliverable, the assumptions behind it, and who pays for each part. Ask for an inventory of installed apps with their compatibility status, a clear statement of whether PHP and database changes are included, the staging rebuild, the production upgrade run, rollback testing and handover documentation. Request a split between one-time work and any recurring retainer for post-upgrade support, and mark any Enterprise subscription separately. List what the client must provide, including access, owners and a test environment, because missing inputs change the cost. Confirm the change window, what happens if a compatibility problem appears mid-project, how scope changes are priced and what acceptance criteria close the work. DeployOpen works from a written scope agreed before work starts, so a quote should follow directly from that scope.
How DeployOpen scopes, delivers and supports the Nextcloud 33 upgrade
DeployOpen plans and runs Nextcloud 32 to 33 upgrades in infrastructure you control, one major version at a time. The written scope covers the dropped PHP 8.1, PostgreSQL 13 and Oracle 11g support, the configuration changes in 33, and a backup and rollback path before any change reaches production.
How we scope
- The written scope lists your current Nextcloud 32 version, PHP, database and operating system versions, and enabled apps.
- Scope covers Nextcloud 33 changes that apply to you: Snowflake ID configuration, metrics endpoint and AI task worker.
- Engagements are fixed-scope, agreed in writing before work starts, with ongoing support available as a retainer.
How we build
- Stage the path from Nextcloud 32 to 33 on a non-production copy, with each step of the upgrade documented.
- Review third-party apps against Nextcloud 33 and disable any that are not confirmed compatible before the upgrade.
- Upgrade PHP, PostgreSQL or Oracle components where your current versions are dropped, and update connectivity check allowlists.
How we hand over
- Handover includes a written runbook covering the upgrade steps, rollback procedure and backup restore checks.
- Post-upgrade checks cover the metrics endpoint, AI task worker behavior, and sync and login tests.
- Your team receives the configuration record, the change log and the list of apps confirmed or disabled.
How we support
- Retainers can cover applying Nextcloud 33 maintenance releases and troubleshooting after go-live.
- Nextcloud 33 support ends in February 2027 per Nextcloud's published schedule, so plan the next major upgrade early.
- Confirm support hours and response terms in the written quote, since they depend on the retainer chosen.
