Nextcloud All-in-One deployment guide

When does a Nextcloud All-in-One deployment fit an organization?

A Nextcloud All-in-One deployment suits a single-host, self-managed setup with a small set of bundled services. It becomes harder to fit once customization, reverse proxy design, storage placement or upgrade control matter to the organization. All-in-One is the official Nextcloud installation method, and it packages the pieces most small installations need: Redis and APCu caching, PostgreSQL, optional Nextcloud Office, Talk with recording, BorgBackup-based backups, ClamAV antivirus and full-text search. The convenience is real, but the difficulty lies in what the bundle decides for you. Database choice, cache layout, backup tooling and container structure are fixed by the project, so your team inherits those decisions along with the benefits.

Before committing, a team should map the work the bundle does not remove. DNS records and TLS certificates must point at the host correctly, and the setup depends on how inbound traffic reaches it. If you already run a reverse proxy, a load balancer or a web application firewall, confirm how All-in-One will coexist with it, because proxy headers, timeouts and upload limits affect sync and large file transfers. Ask who owns certificate renewal and how a failed renewal would be noticed. Treat these as design questions with named owners, not as installation details that will sort themselves out.

Backups are the next place where assumptions break. All-in-One drives BorgBackup, but the backup destination, retention window, encryption key custody and restore procedure are still your responsibility. Confirm where backup repositories will live, whether they are separate from the production host, and who can restore them. An unrestored backup is not a recovery plan, so schedule a restore test before go-live and record how long it took. The same test shows whether the chosen destination has enough capacity for the data growth your organization expects.

Upgrades carry the heaviest hidden work. Nextcloud does not allow skipping major releases, so administrators must move one major version at a time, back up before every upgrade and disable third-party apps until each is confirmed compatible. A single-host bundle makes this simpler to start but leaves the schedule, the test environment and the app review with your team. Decide who will track the four-month release cadence, who approves an upgrade window and whether a staging copy exists. If any of those answers is unclear, the deployment is probably larger than a single-host bundle can carry without a plan.

Use these questions to test fit. Does one host meet the capacity and availability your users expect? Can you accept the bundled database, cache and backup choices? Will your reverse proxy, DNS and certificate process fit around the containers? Who owns each upgrade and each restore test? If the answers point to strict identity integration, custom storage, clustering or a fixed upgrade policy, compare All-in-One with a manual or Kubernetes build before the first installation. Confirm the current supported major versions and their dates against the Nextcloud release schedule at the time of your decision.

What the All-in-One master container bundles and how it runs

Nextcloud All-in-One packages Nextcloud with the supporting services it needs in one managed set of containers. The cards below describe each bundled component, what it does for you, and the decisions that stay with your team after installation.

Master container and web interface

The AIO master container is the single container you install directly. It pulls, creates, starts and updates the other containers and exposes a setup web interface where you choose which optional components to enable. Check who can reach that interface, because it controls the whole stack. Confirm how your team will restrict access to it during setup and after go-live.

Nextcloud application container

This container runs the Nextcloud server code that serves file sync, sharing and the web client. AIO manages its image and upgrades, so your team does not assemble the PHP runtime or web server by hand. Your decisions include the public domain name, the trusted domains list and any custom apps you plan to add, since third-party apps must be checked before each major upgrade.

Redis and APCu caching

AIO bundles Redis for file locking and transactional caching and APCu for local in-memory caching. Operators get these without separate configuration, which removes a common cause of slow or locked files. Confirm that Redis is only reachable inside the container network and that your memory allocation suits your user count, since caching data lives in RAM.

PostgreSQL database

AIO runs PostgreSQL as the Nextcloud metadata database, so the database version and its upgrades follow the AIO release process rather than your database team's schedule. This matters if your standards require a centrally managed database service. Decide whether the bundled database meets your backup, monitoring and access policies, or whether an external database is needed.

Optional Office, Talk and search containers

Nextcloud Office, Talk with recording and full-text search are optional containers you enable in the master interface. Each adds CPU, memory and storage demand and its own network exposure, such as Talk media ports. Decide which features your users need at launch, size the host for them, and confirm the Talk recording storage location and retention before you enable recording.

BorgBackup backups and antivirus

AIO includes BorgBackup-based backups of the Nextcloud data and database, and a ClamAV container for antivirus scanning of uploaded files. The backup target, retention period, encryption passphrase handling and restore procedure are your decisions, and an untested backup is not a recovery plan. Confirm where backup repositories live, who holds the passphrase, and how often a restore is rehearsed.

Which deployment method fits: AIO, manual install or Kubernetes

This table compares four ways to deploy Nextcloud: AIO on a single host, AIO behind a proxy you run, a manual install on Apache or nginx with php-fpm, and the Helm chart for Kubernetes. Read each row for the fit, the operations your team takes on, and what the choice limits later. The main takeaway is that more control over PHP, the database and backups means more work for your team, and no option removes the rule to upgrade one major version at a time.

Option	Fits when	Operational cost	Constraints later
AIO on a single host	Teams that want the official bundle of Redis, PostgreSQL, Talk, ClamAV and BorgBackup managed together on one host.	Your team applies AIO updates, watches its containers and must test BorgBackup restores itself.	The bundled components set the stack. Confirm in the AIO documentation which PHP, database and web server settings you can change.
AIO with a reverse proxy you control	Organizations that must keep an existing TLS proxy and certificate process, and still want AIO's bundled services.	Your team owns proxy configuration, certificates, headers and proxy upgrades. Confirm the proxy setup the AIO documentation describes.	Proxy changes can affect uploads, timeouts and headers. Any proxy standard you adopt must be carried through later AIO changes.
Manual install on Apache or nginx with php-fpm	Teams that need their own PHP, database, web server or OS choices, or that already run this stack for other platforms.	Highest effort: your team installs and patches PHP, the web server, the database and Nextcloud, and writes its own backup and cron jobs.	Nextcloud 35 recommends PHP 8.5 (8.3 and 8.4 supported) and Apache 2.4 or nginx with php-fpm. Database support: MariaDB 10.11 to 12.3, PostgreSQL 14 to 18.
Helm chart on Kubernetes	Platform teams already running Kubernetes, with an external database, Redis and object or shared storage they manage.	Your team owns the cluster, storage, database, Redis, ingress, backups and background job design, and needs Kubernetes operations skills.	Major upgrades still go one at a time with a backup first. The chart does not remove database or storage design work. Confirm the chart version you target.

Where Nextcloud All-in-One stops fitting an organization

All-in-One is a good fit when the organization accepts its bundled stack as the stack. The constraints that push teams away from it are mostly decided at install time, so they are worth checking before anyone copies the Docker command. The bundled components include Redis and APCu for caching, PostgreSQL as the database, BorgBackup for backups, ClamAV for antivirus and full-text search. Swapping the database or the caching layer later is not a configuration toggle. It is a migration project, and the longer the instance runs on the bundled choice, the more expensive that move becomes. If your standard is MariaDB, MySQL or a managed database service, decide that first.

Reverse proxy and TLS placement also shape the install. All-in-One expects to own the public ingress on your host and terminate TLS in its own containers, which conflicts with corporate load balancers, web application firewalls or ingress controllers that already terminate certificates for other services. Confirm who owns certificate issuance, where TLS ends, and whether your security team requires inspection points in front of the application. Changing this after go-live means reworking trusted domains, forwarded headers and certificate renewal. Note that the platform's own requirements list Apache 2.4 or nginx with php-fpm for standard installs, so an existing proxy layout should be mapped against those expectations early.

Customization has limits. You can add apps and adjust configuration, but the container layout, the update mechanism and the bundled services are managed as a unit. Teams that need custom PHP extensions, a different web server, additional sidecar services, or strict control over image builds will find the model constraining. The same applies to Oracle Database. Oracle is only available with an enterprise subscription, so organizations standardized on Oracle must budget for that license separately and confirm it is supported for their chosen Nextcloud version. Enterprise support tiers are a separate purchase from Nextcloud Enterprise, and they are not a feature of All-in-One. Ask which support level your organization needs, and treat it as its own line in the quote.

Upgrades are the constraint that surprises most operators. Nextcloud does not allow skipping major releases, so an instance must move one major version at a time. Before every upgrade, take a backup, and disable third-party apps until each one is confirmed compatible with the target version. Major versions arrive every four months, and each receives one year of support, so an instance that falls behind will need several sequential upgrades. Plan a recurring upgrade window, assign an owner for app compatibility checks, and test the restore path before relying on it. A quick update that skips these steps is the most common route to a broken production instance.

How to install Nextcloud All-in-One step by step

This sequence takes a prepared host from a checked resource baseline to a running Nextcloud instance with a trusted domain, chosen optional components, a verified BorgBackup destination and a tested admin login. Each step ends with a check so the team can fix a gap before moving on. The exact setup prompts may change between releases, so confirm them against the official repository at the time you install.

Confirm the host against system requirements
Compare the planned host's CPU, memory, disk and operating system with the requirements published for the Nextcloud release you are installing. The platform engineer or sysadmin records each value next to its documented minimum, and sizes the data directory and backup repository separately because both grow over time. Any gap is raised before the host is used for production data. Ask your partner or vendor to confirm the exact figures for the current release. The check is a signed-off requirements record with no open gaps.
Prepare DNS and certificate names
Choose the domain name users will open and decide how its TLS certificate will be issued, either through your internal certificate authority or a public one your reverse proxy supports. Network staff create the DNS record and confirm it resolves from every network where users will connect. Check that the name points to the host and that a client device trusts the certificate chain before you continue. The step is complete when the name resolves correctly and a browser shows a trusted certificate for it.
Install a supported container runtime
Install a container runtime that the All-in-One documentation lists as supported for your operating system, and confirm it starts automatically at boot. The platform engineer does this on the host with the required administrative rights. Record the runtime version in the build record, because image pulls and setup instructions depend on it. Check the supported list in the current repository before installing, since it may change. The check is a test container that starts, runs and exits cleanly.
Start the AIO master container
Run the official master container using the command given in the current All-in-One repository, without altering flags or volume paths unless the documentation tells you to. The platform engineer runs this once, and the master container then creates and manages the other Nextcloud containers. Confirm the command matches your chosen release before running it. The step is complete when the master container is running and its setup interface answers on the expected local address. Review the container logs for errors before moving on.
Choose domain and reverse proxy mode
Open the setup interface in a browser, enter the one-time passphrase it displays, and enter the domain name prepared earlier. Choose the reverse proxy mode that matches your environment, either the built-in web server option or an external proxy you already operate, and follow the proxy-specific settings in the repository. The platform lead makes this decision with the network team, because it determines how TLS and headers are handled. The check is a domain that validates and a setup that continues without certificate or proxy errors.
Select optional components
Choose which optional components to enable: Nextcloud Office, Talk with recording, ClamAV antivirus and full-text search. Each one adds services to the stack, so agree with the business owner which features users need at launch and which can wait. Compare each component's resource needs with the host sizing from the first step before enabling it. Save the final component list in your build record. The check is a host with enough headroom for the selected components, and any component without a confirmed need stays off until that need is confirmed.
Configure BorgBackup destination and schedule
Set the backup location and schedule in the All-in-One interface, which uses BorgBackup for its backups. Choose a destination separate from the Nextcloud host, such as a storage target you control, and agree the schedule with the operations team so backups run outside peak use. Store the backup passphrase and encryption material in your secrets management system, because encrypted backups cannot be recovered without them. The check is a destination the host can reach and a schedule that is saved in the interface.
Run first backup and complete admin setup
Start a manual backup from the interface and wait for it to finish without errors. Log in as the initial admin account, upload a test file, and restore that file from the backup to a scratch location using the documented restore procedure. Then finish admin setup by changing the initial password and enabling two-factor authentication. The step is complete when the backup succeeds, the restored file matches the original and the admin login works. Confirm current setup and backup prompts in the official All-in-One repository, since the interface may change.

How AIO behaves on a single host, behind your proxy, on Kubernetes and offline

On a single host, AIO is closest to the official installation path. AIO runs its own set of containers, and the stack includes the bundled components the AIO project describes, such as Redis, APCu, PostgreSQL, BorgBackup-based backups, ClamAV and full-text search. The team accepts AIO's layout and update cycle and plans operations around it.

TLS termination: Confirm which certificate options and HTTP ports the current AIO release uses before you expose the host to users.
Backup placement: BorgBackup writes to a destination you configure on the host. Confirm that the destination sits on storage separate from the data volumes and that a copy leaves the host.
Updates: AIO and its bundled containers update through the AIO release process. Read the release notes before each update and take a backup first.
Monitoring: Confirm what health information the containers expose, then add host-level metrics, disk alerts for data and backup volumes, and certificate expiry checks.

Verify that a restore from the BorgBackup repository succeeds on a separate host before go-live.

What drives the effort and cost of an AIO deployment

This table lists the main drivers of effort and cost in a Nextcloud All-in-One deployment, how each one changes the work, and how to keep it contained. Read each row before the design is fixed, because most drivers are set during planning and are expensive to change after install. The main takeaway is that the one-time build and the recurring operations each need their own line in any plan or quote.

Driver	Effect on effort and cost	How to keep it down
User count and concurrency	Raises sizing for the app server, database and PHP workers, and increases login, sync and support load at peak times.	Confirm named users, peak concurrent sessions and sync patterns before choosing hardware.
Data volume and growth	Drives storage capacity, preview generation, backup duration and restore time. Growth adds cost every year.	Define storage sizing and a growth assumption in writing before the install.
Optional components enabled	Nextcloud Office, Talk with recording, ClamAV and full-text search each add containers, resources and tuning work.	Enable only what is needed at go-live, and add components later through a tested change.
Backup volume and retention	Longer retention and larger data sets raise storage cost and backup run time. Restores need periodic testing.	Set retention periods and backup windows in writing, then schedule and record a restore test.
Reverse proxy and certificate work	An existing proxy, load balancer, domain and TLS certificate process add configuration, header rules and renewal duties.	Decide the public hostname, certificate source and proxy ownership before the install starts.
Identity integration (LDAP, AD, OIDC, SAML)	Each directory or identity provider adds attribute mapping, group rules, login testing and deprovisioning design.	Choose one identity source and group model first, and confirm the method against current Nextcloud documentation.
Custom branding or apps	Theming and third-party apps need compatibility checks before every major upgrade and may need rework after updates.	Limit apps to a short vetted list and keep branding within supported theming options.
Compliance evidence needs	Access logs, access reviews, backup records and change records need collection, retention and an owner. Auditors decide sufficiency.	Agree the evidence list, owners and retention period with the assessor before go-live.
One-time and recurring work	One-time: design, install, first backup restore test and initial hardening. Recurring: maintenance releases, backup monitoring, major upgrades and staff time.	Ask for one-time and recurring work as separate lines in any fixed-scope quote.

Securing the AIO master container, admin access and backup keys

An All-in-One install concentrates control in one master container, one Docker host and one backup passphrase. The cards below cover the AIO-specific controls that protect those points, so that the setup interface, admin account, backup keys and network exposure are governed deliberately. Application-level hardening such as TLS headers, brute-force protection and sharing policies is covered on the security hardening topic page.

Restrict access to the master container

The AIO master container runs the setup interface that creates and reconfigures the other containers, so anyone who can reach it can change the stack. Confirm that the interface is reachable only from administrator networks or over a private path, and that the initial setup password is recorded in your secrets store and not left in a shared chat or ticket. Check who holds Docker socket access on the host, because that access is equivalent to control of every container.

Protect the initial admin account

The Nextcloud admin account created during setup has full control over users, apps and server configuration. Replace any shared or default credentials with a named administrator password held in a password manager, and avoid using the admin account for daily work. Confirm with your identity team whether administrators should instead sign in through a directory or SSO integration, since that changes how the local account is kept as a break-glass login.

Enable two-factor authentication for administrators

Two-factor authentication should be enforced for all administrator accounts before users are onboarded, and the recovery codes for each admin should be stored under the same controls as other privileged credentials. Confirm which second factor methods your policy allows and whether an enforcement group is needed for users outside the admin role. Test a recovery path with a second administrator so that a lost authenticator does not lock the only admin out.

Handle the BorgBackup repository passphrase

AIO's BorgBackup repository is encrypted with a passphrase, and without it the backups cannot be restored, even if the backup disk is intact. Record the passphrase in at least one offline, access-controlled location separate from the Docker host, and document who may retrieve it under which approval. Run a restore test on a separate host that uses only the stored passphrase, so that you know the recovery path works before an incident requires it.

Limit exposed ports to the reverse proxy

AIO expects a reverse proxy in front of the Nextcloud containers and the setup interface should not be published directly to the internet. Review the published ports on the Docker host and close everything except what your reverse proxy needs to reach, typically the HTTPS entry point used by users. Verify the result from outside your network with a port scan that you have authorized, and repeat the check after every AIO update that changes container configuration.

Control image pulls and update rights

AIO updates pull new container images from public registries, so an update changes the code running in your environment. Decide who may trigger updates, who reviews release notes before an update, and whether the host can pull only from registries your change process approves. Keep a record of the image versions running after each update so that a rollback target is known, and confirm the current upgrade and release guidance from the AIO project before scheduling a change.

Keep the Docker host patched

The host operating system and the Docker engine sit beneath every container, so unpatched host components expose the whole stack regardless of how well AIO is configured. Assign ownership for operating system and Docker engine patching, define a maintenance window that includes a reboot test, and confirm that the host is on a vendor-supported release. Include the host in vulnerability scanning, and treat kernel and container runtime advisories as changes that need a tested rollback plan.

How to test that an AIO install works and fails safely

Before handover, the install needs a written set of acceptance tests that a second person can repeat, and a short set of failure tests that prove the operator will notice when something breaks. A deployment that starts and shows a login page has not yet been shown to work. Start with the login paths. Log in as the administrator and as an ordinary user, both locally and through any directory or single sign-on method the design uses. Confirm that the administrator account is not the only way in and that a failed password attempt is refused without exposing detail.

Next, test the edge. Check that the certificate served for the public hostname is valid, that its chain is complete, and that its expiry date is recorded somewhere the operator will see it. Confirm the response from the reverse proxy in front of the All-in-One containers, including that plain HTTP redirects to HTTPS and that the expected security headers are present. Then exercise the file path end to end: upload a file through the web interface, sync that same file from a desktop client and a mobile client, and confirm the change appears on the other device. Record the client versions you tested, because sync behavior differs across releases.

Sharing needs two recipients. Share a file and a folder with an internal user, then with an external recipient through a public link with a password, and confirm both can open the item and that the permission you set is the permission they get. If Talk is enabled, place a call between two accounts and test a screen share. If Nextcloud Office is enabled, open and save a document in the browser. If ClamAV is enabled, upload the standard EICAR test string, which is a harmless file that antivirus engines are designed to flag, and confirm it is detected and blocked or quarantined as your policy states. Use only that test string, never real malware. Each optional component you leave out of scope should be written down as excluded, not silently skipped.

Restore testing is the most important test in the set. Run a full backup with the All-in-One backup function, then restore it into a separate host that has no access to production. On the restored system, compare files, database content and configuration against the source. A file count and a checksum sample for the data directory, row counts for key tables, and a diff of the configuration are a reasonable starting point, and your team should agree the exact comparison before the test. A restore that only brings up a login page does not prove the data is intact.

Failure tests show whether the install fails safely. Stop the database container on a non-production copy and confirm that the failure is visible: the web interface should show an error, the administration overview should report a problem, and the monitoring you chose should raise a signal. Then force a failed backup run, for example by making the backup target unavailable in a test environment, and confirm that the failure produces an alert that reaches a named operator through a channel they actually watch. Record every result, including the screenshots, timestamps, client versions, backup identifiers and the names of the people who witnessed each test. This record is the evidence the handover needs, and it should be kept with the runbook.

Running AIO after go-live: updates, backups, monitoring and documentation

This table lists the recurring tasks that keep a Nextcloud All-in-One installation running and supported after go-live, with the owner, the frequency to set and the signal that means action is needed. Treat each row as an operating commitment with a named person behind it. Nextcloud publishes a new major version every four months and supports each one for one year, so confirm the current support window on the official maintenance and release schedule before setting upgrade dates.

Ongoing task	Owner	Frequency to set	Action signal
Container health and disk space	Platform administrator	Automated checks continuously, with a human review at least weekly	A container restarting repeatedly, an unhealthy status, or the data volume approaching its capacity limit
Backup runs and restore tests	Backup owner, with the service owner approving the test scope	Review each AIO backup run; restore test on a fixed schedule agreed with the risk owner	A missed or failed BorgBackup run, or a test restore that does not complete or does not match expected data
AIO and Nextcloud updates	Platform administrator, after change approval	Apply AIO and Nextcloud maintenance releases promptly, with a fresh backup taken first	An update notice in the AIO interface, or a security advisory that affects the installed version
Release schedule and supported major version	Service owner	Review the official Nextcloud schedule each quarter and before planning any upgrade	The installed major version nearing end of support, or no upgrade scheduled for the next major release
Third-party app compatibility	Application owner, with the platform administrator	Before every major upgrade and whenever an installed app receives an update	An app marked incompatible with the target version, or an app with no release for that version
Reverse proxy and certificate renewal	Network or web team	Monitor certificate expiry continuously, and test the proxy configuration after every change	A certificate expiry warning, a failed renewal, or client addresses and HTTPS headers no longer passing through correctly
Runbook: components, domains, backups and recovery	Platform owner, reviewed by security	Update on every change and review after each upgrade or restore test	A domain, volume, backup location or recovery step missing from the runbook, or a step that has never been tested

What do buyers ask about Nextcloud All-in-One deployment cost, time and effort?

Is Nextcloud All-in-One free to use, and what does Enterprise add?

Yes, the Community edition of Nextcloud Server is open source under AGPL-3.0, and Nextcloud All-in-One is the official installation method for it, so the software carries no license fee. Your costs are the infrastructure, storage, backup space and the staff time to run it. Enterprise is a paid subscription from Nextcloud GmbH aimed at enterprise, public sector and education users. Nextcloud's pricing page lists Standard, Premium and the highest tier per user per year, with list prices starting at 71.29, 104.99 and 204.75 euros for 100 or more users. The minimum is 100 users, and rates are lower 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. The highest tier adds support up to 24/7 with response times down to one hour. Confirm current prices and terms with Nextcloud, because list prices can change.

How long does a Nextcloud All-in-One installation take?

The duration depends on the drivers below, not on a fixed number of hours. The main ones are the host and network you provide, whether DNS records and a valid TLS certificate path are ready, how much existing data must be moved in, whether a reverse proxy already exists or must be built, and how many decisions remain open on identity, storage location, backup target and apps such as Office and Talk. A single-host AIO install with those answers agreed can be a short exercise. LDAP or SSO integration, a migration from another platform, backup restore testing and a client rollout each extend it. Ask any partner to list each task with its dependencies and the decisions it waits on, and to state which steps you must complete. Most delays come from waiting on DNS, certificates, directory access and sign-off, so start those first.

Can our own team deploy Nextcloud All-in-One without outside help?

Yes, a small team with Docker experience can deploy AIO on one host if the design is simple and the runbook is clear. That covers one server, one public domain, the bundled components and a tested backup and restore procedure. The team should be able to read container logs, manage DNS and certificates, open the required ports and use the Nextcloud occ command line tool. Bring in outside help when the work includes LDAP or SSO integration, a migration from SharePoint, Google Drive, Dropbox or ownCloud, a multi-server or high availability design, or evidence for a compliance assessment. Also decide who owns upgrades after go-live, because the one-major-at-a-time rule makes upgrades a recurring task. DeployOpen agrees scope, deliverables and timelines in writing before work starts, so a partner quote should show which parts you keep and which you hand over.

What does an organization need to provide before a Nextcloud install?

The organization provides the infrastructure, the people and the decisions. Infrastructure includes a host or virtual machine sized for the expected users, a domain with DNS records pointing to it, a certificate path, and outbound network access for software updates. Storage needs capacity for user data plus a separate backup target, because BorgBackup writes to storage you choose. People include a named owner who approves changes, answers for data handling and receives upgrade notices. Decisions include how users sign in (local accounts, LDAP or Active Directory, OpenID Connect or SAML), which groups map to shares and quotas, how departing users are deprovisioned, whether Office and Talk are in scope, and how long data is retained. Ask a partner to list each item as an input with an owner and a due date before the quote is final.

Can Nextcloud All-in-One be customized, and where are the limits?

Yes, within limits. AIO is delivered as a bundle, so supported options such as optional Nextcloud Office, Talk with recording, backup settings and the domain can be configured through the setup. You can also add Nextcloud apps through the standard app system, and theming is usually a low-risk change. Limits appear when you replace bundled components such as PostgreSQL, Redis or APCu with other products, edit the generated container setup by hand, add custom containers, or write reverse proxy rules the project does not document. These changes can complicate updates, because the project maintains the bundle as a whole. Confirm the supported changes in the official AIO documentation for the version you deploy, keep a written list of every deviation, and test each change in staging before it reaches production.

Can Nextcloud All-in-One be upgraded without downtime?

Do not promise zero downtime until you have tested it on your own data. Nextcloud does not allow skipping major releases, so an installation must move one major version at a time, with checks at each step. Before every upgrade, take a backup of the database, data and configuration, and disable third-party apps until each is confirmed compatible with the target version. Downtime depends on the size of the data and database, the number of steps needed to reach a supported major, and the apps in use. Nextcloud publishes a new major version every four months and supports each for one year, so a team that falls behind may need several steps. Ask the vendor or partner for a documented downtime estimate based on your data size, a rollback plan, and a rehearsal of the upgrade on a copy of production.

Which database and PHP versions does Nextcloud 35 require?

Nextcloud 35 recommends MariaDB 11.8 or PostgreSQL 18. It supports MariaDB 10.11 to 12.3, PostgreSQL 14 to 18 and MySQL 8.4 or 9.7. It recommends PHP 8.5 and supports PHP 8.3 and 8.4. The supported web servers are Apache 2.4 or nginx with php-fpm. Oracle Database is available only with an enterprise subscription. AIO bundles PostgreSQL along with Redis and APCu, so most of these choices are made for you, but confirm that the bundled versions match the Nextcloud release you intend to run. If you plan to use an external database, a different web server or an existing PHP stack, these requirements decide what you must build and test. Check the matrix for your target version during procurement, because support windows move with each release.

How DeployOpen scopes, builds and hands over an AIO deployment

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For Nextcloud All-in-One, we start by confirming whether the bundled components fit your requirements, then build and verify the deployment in your environment and hand over the documentation your team needs to run it.

How we scope

Engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts.
The written scope states which bundled components are in use, such as the database, caching, Office, Talk and ClamAV, and which are excluded.
We confirm the target hosting environment, reverse proxy design, domain names and backup destination before any build begins.

How we build

We install the All-in-One containers in your own cloud account, data center or air-gapped network, following the official installation method.
We configure BorgBackup-based backups and test a restore before the system is considered ready for users.
We document the reverse proxy, TLS and maintenance mode settings, and record every customization that falls outside the supported configuration.

How we hand over

You receive runbooks covering daily checks, the update procedure, backup and restore steps, and the points where AIO limits customization.
Administrators are walked through the admin interface, the mastercontainer, and how to apply major and minor updates safely.
Handover includes a record of the deployed versions, configuration decisions and the evidence collected during verification.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing like the initial build.
Upgrades follow one major version at a time with a backup before each step and a check of third-party app compatibility.
We recommend confirming update and support terms with Nextcloud directly, since community and Enterprise support differ.

Nextcloud All-in-One deployment