When Nextcloud All-in-One fits and when a manual install fits better
Choose Nextcloud All-in-One (AIO) when one domain serves the whole instance, your team is comfortable operating containers, and you want the official method to bundle the database, caching and optional services for you. Choose a manual install on a LAMP or LEMP stack when you need several domains, must reuse existing database or web server standards, or need direct control over PHP and web server settings. Neither path is wrong on its own; the deciding question is which set of constraints your platform team already lives with.
AIO runs PostgreSQL, Redis and APCu caching as part of its managed container set, and lets you enable optional containers for Talk with its high performance backend and TURN server, Nextcloud Office, ClamAV, full-text search and Imaginary. Its interface also creates, restores and integrity-checks BorgBackup backups and can update containers, Nextcloud and its apps. That bundle suits a small or mid-sized team with one domain that wants fewer moving parts. Confirm before committing that your hosting platform supports the container runtime and the ports AIO needs, and that a single domain covers every user you plan to onboard, since the project's README states that multiple domains are not supported and will not be added.
A manual install suits teams whose standards already define the stack. If your database platform is an existing PostgreSQL, MariaDB or MySQL service with its own backup, monitoring and patching, or your web server is standardized on Apache 2.4 or nginx with php-fpm, a manual install lets Nextcloud join that estate rather than run beside it. It also gives you direct control over php.ini, PHP-FPM pools and web server rules, which matters when security baselines or performance tuning must be documented. The cost is ownership: you select PHP and database versions against the system requirements, schedule upgrades one major version at a time, and build your own backup and monitoring. Ask whether your team can staff that work before choosing the manual route.
How the two install paths compare on each factor
This table sets Nextcloud All-in-One against a manual LAMP or LEMP install on the factors that decide day-to-day ownership. Read each row as a question to ask your team: who builds the stack, who patches it, and what you can change later. Items the supplied documentation does not settle are marked for you to confirm before you commit.
| Factor | Nextcloud All-in-One | Manual installation |
|---|---|---|
| Supported stack | Containers managed by AIO, with PostgreSQL as the database and Redis and APCu for caching | Classic LAMP or LEMP stack you configure; Nextcloud 35 supports Apache 2.4 or nginx with php-fpm and several databases |
| Bundled components | Optional Talk with TURN, Imaginary, ClamAV, full-text search and Nextcloud Office are offered as containers | None bundled; you install and integrate each optional service yourself |
| Domain support | Multiple domains are not supported and will not be added; multiple AIO instances on one server need a separate guide | Confirm your own virtual host and domain layout with your web server configuration |
| Backup tooling | Built-in BorgBackup backups that can be created, restored and integrity-checked from the AIO interface | Backups are your responsibility; Nextcloud requires a backup before every upgrade, so plan your own tooling |
| Update mechanism | AIO interface can update containers, Nextcloud and its apps automatically | Manual upgrades one major version at a time, with third-party apps disabled until confirmed compatible |
| Kubernetes option | AIO has its own Helm chart for Kubernetes deployments | Not a packaged option; confirm with your platform team how a bare-metal or VM stack would run on your cluster |
| Configuration control | Less control over the web server and runtime layout because AIO manages the containers | Full control over web server, PHP settings, database tuning and file layout |
| Patching ownership of web server, PHP and database | AIO updates the containers it runs; confirm with your own security team how host OS patching and any custom changes are handled | Your team patches the web server, PHP runtime, database and operating system directly |
What AIO runs as containers and what a manual install runs as services
Nextcloud All-in-One packages the application and its supporting services into containers that one mastercontainer starts and updates. A manual install on a LAMP or LEMP stack asks you to choose, configure and patch each of those layers yourself, which keeps control in your hands and puts maintenance on your team.
The AIO mastercontainer
AIO starts from a mastercontainer that deploys, configures and updates the other containers from its own interface. It is the single point that decides which optional containers run and when Nextcloud and its apps are updated. Check who can reach that interface, because it controls the whole stack. Confirm in the AIO README how the mastercontainer is started and which ports it needs on your host before you plan the network rules.
Bundled PostgreSQL, Redis and APCu
AIO runs Nextcloud with PostgreSQL as the database and uses Redis and APCu for caching, all as managed containers. You do not pick the database engine or cache layout at install time. In a manual install, you select MySQL, MariaDB or PostgreSQL, size it, back it up and tune the cache yourself. Confirm which database version AIO ships and whether your standards accept it before you commit.
Optional Talk, TURN and Office containers
Talk with its high performance backend and TURN server, Nextcloud Office, Imaginary and full-text search are optional containers that AIO can add. Each one adds memory, CPU and open ports that you must plan for. Talk also depends on TURN reachability from outside your network, which is often where calls fail. Decide which optional containers you need before enabling them, and confirm the resource profile in the AIO documentation.
ClamAV and search containers
AIO can run ClamAV for antivirus scanning and a full-text search container as part of the same managed stack. A manual install has the same features available, but you install the scanner, the search backend and their integrations separately. Check how each scanner's signature updates reach your environment, especially in air-gapped networks, and confirm that scanning fits your file sizes and upload volume.
Apache or nginx with php-fpm
A manual install on a LAMP or LEMP stack has you configure the web server yourself. Nextcloud 35 documents Apache 2.4 or nginx with php-fpm as supported choices, and you own the virtual host, TLS, headers and upgrades of that layer. This is the control a manual install keeps: you decide the web server build, hardening and reverse proxy design. Ask your team who owns those files after go-live.
PHP and database versions
Nextcloud 35 runs on PHP 8.3, 8.4 or 8.5, and the documented recommendation is PHP 8.5. Supported databases are MySQL 8.4 or 9.7, MariaDB 10.11 to 12.3 and PostgreSQL 14 to 18, with MariaDB 11.8 or PostgreSQL 18 recommended. Oracle is available only with an enterprise subscription. A manual install lets you pick any supported combination, while AIO fixes these choices for you. Confirm the matrix against the version you plan to deploy.
Why the one domain limit in AIO changes the decision
The AIO README states that multiple domains are not supported and will not be added, so a single AIO instance serves one domain name. If your organization uses one primary domain for staff and customers, this limit costs nothing. If you host several brands, a customer-facing and an internal name, or separate tenants that each expect their own hostname, a single AIO instance will not cover that layout. Decide this before installation, because changing the domain of an existing instance later is a migration task, not a setting you flip.
The README does describe a path for more than one tenant on the same hardware: running multiple AIO instances on one server, documented in a separate guide. Each instance then carries its own containers, data directory, database and backup set, so the server's CPU, memory and disk must be sized for every instance at once. Ask whether your plan requires separate data isolation per tenant, and whether your backup and restore process can handle one Borg repository per instance. The Helm chart route is another option for Kubernetes, but it is a different installation method with its own upgrade process, so it is not a simple substitute.
Before choosing, write down every hostname the platform must answer on, which teams own each name, and whether any tenant needs separate administrators, audit trails or retention rules. Confirm with Nextcloud GmbH, in the AIO documentation, or in a pilot on your own infrastructure how the multi-instance guide handles DNS, TLS certificates and reverse proxies for each name. If your plan needs several domains within one trust boundary and one administration model, a manual install on a LAMP or LEMP stack gives you the web server configuration to serve those names yourself.
How upgrades, backups and monitoring differ day to day
This table sets out the routine work each path puts on your team after go-live: upgrades, backups, monitoring and skills. Read each row as the question you will face every month, not as a one-time setup step. The main takeaway is that AIO moves most routine tasks into one managed interface, while a manual install keeps every task in your hands.
| Area | Nextcloud All-in-One | Manual installation on LAMP or LEMP |
|---|---|---|
| Container and app updates | The AIO interface can update the containers, Nextcloud and its apps automatically, so routine patching follows the tool's schedule. | You update the web server, PHP, database and Nextcloud packages yourself, and you test third-party apps before each change. |
| Major-version upgrades | AIO still follows Nextcloud's rule of one major version at a time, so you confirm the path before you start. | You step through each major version in order, back up before every upgrade and disable third-party apps until they are confirmed compatible. |
| Backups | BorgBackup backups can be created, restored and integrity-checked from the AIO interface. | You choose and run the backup tooling, and you must test restores of files, database and data directory yourself. |
| Version support windows | Nextcloud 35 was released on 16 September 2026 and is supported until September 2027, and Nextcloud 34 until June 2027. Plan your upgrade window against these dates whichever path you choose. | The same support windows apply, and you must schedule each move to a supported line before end of life, including monthly maintenance releases. |
| Monitoring and health checks | Check the AIO interface and container status, then add your own uptime and log monitoring for the public domain. | You monitor the web server, PHP-FPM, database, cron jobs and disk space with your existing tools, and you own alert thresholds. |
| Skills the team needs | Container basics, Docker host administration, DNS and certificate handling, and enough Nextcloud knowledge to read admin settings. | Linux administration, web server and PHP tuning, database administration, and Nextcloud occ command-line work. |
| Who runs the work | Your operations staff can run most routine tasks from one interface, with DeployOpen available for scoped support if agreed in writing. | Your team or a partner handles every layer, so the work scales with the number of components you run. |
| Recurring effort drivers | Container image changes, backup storage growth and checks on the AIO interface after each release. | Package updates for every layer, backup design changes, tuning changes and cron or database maintenance. |
What a major Nextcloud upgrade looks like on each path
The sequence below is the one that applies to both paths, so the reader can see which steps AIO automates and which remain the administrator's responsibility. It ends with a verified, working instance on the target major line, with no third-party apps re-enabled until they are confirmed compatible.
Confirm the current major line
Identify which Nextcloud major version is running now and which version is the next one, since Nextcloud does not allow skipping major releases. On AIO, the administrator checks the version shown in the AIO interface and the update status it reports. On a manual install, the administrator checks the version in the admin overview and the installed server files. The step is done when the current version and the single next major target are written down and agreed by the people who own the service.
Check the target's system requirements
Compare the PHP version, database version and web server against the requirements for the target major line on the official system requirements page. On AIO, the containers ship with their own runtime and database, so the administrator confirms the AIO release supports the target. On a manual install, the administrator is responsible for upgrading PHP, the database or the web server first if they fall outside the supported range. The step is done when every component is on a supported version and any gaps are closed or scheduled.
Take and test a full backup
Back up both the data directory and the database before any change, because Nextcloud requires a backup before every upgrade. On AIO, the built-in BorgBackup solution creates the backup from the AIO interface, and the administrator confirms the backup can be integrity-checked. On a manual install, the administrator runs the backup with their own tooling and tests a restore on a separate system. The step is done when a restore has been tested and the backup is recorded as usable.
Disable third-party apps before upgrading
Turn off all third-party apps until each one is confirmed compatible with the target major version, following the upgrade guidance. On AIO, the administrator reviews which apps are enabled in the instance before starting the update. On a manual install, the administrator disables apps with the occ command line tool or the admin interface and keeps a list of what was turned off. The step is done when the list of disabled apps is saved and no unverified app remains active.
Upgrade one major version at a time
Run the upgrade to the next major version only, not the latest, and repeat the cycle for each intermediate version if the instance is behind. On AIO, the interface performs the container and Nextcloud update, and the administrator selects the next major version and monitors progress. On a manual install, the administrator updates the source or package and runs the upgrade command, watching the log for errors. The step is done when the instance reports the new major version and the upgrade log shows no unresolved errors.
Re-enable and verify each app
Re-enable third-party apps one at a time, and only those confirmed compatible with the new version, then check the web interface, sync clients and integrations after each change. On AIO, the administrator still owns app compatibility decisions even though the interface handles the core update. On a manual install, the administrator performs the checks and the reenabling by hand. The step is done when each app is either active and tested or left disabled with a recorded reason.
Verify the instance and record the result
Run a final check of logins, file upload and download, sharing, email notifications and the admin overview, and confirm the server reports no outstanding warnings. On AIO, the administrator also confirms the containers are healthy and the scheduled backup still runs. On a manual install, the administrator reviews web server and PHP logs and confirms the cron jobs still execute. The step is done when the upgrade is recorded with the versions involved, the backup used and the list of apps that remain disabled.
Which team should pick which path
A team with one domain, a small group of administrators and no dedicated Linux operations usually fits Nextcloud All-in-One. The README describes AIO as the official installation method, and it runs Nextcloud with PostgreSQL, Redis and APCu caching, with optional containers for Talk, Nextcloud Office, ClamAV and full-text search. The interface also creates, restores and integrity-checks BorgBackup backups and can update containers, Nextcloud and its apps.
- Domain limit: AIO does not support multiple domains, and the project states it will not add that support.
- Bundled services: Office, Talk, antivirus and search are switched on from the interface rather than assembled by hand.
- Routine work: Backups and updates are handled by the stack, so the team still owns restore tests and upgrade checks.
- Major upgrades: Nextcloud requires one major version at a time, so someone must still plan each jump.
Confirm that a single domain covers the next several years, that the host can run Docker with the ports AIO needs, and that someone will test a restore from Borg before you need one.
A team that already runs Apache or nginx, PHP-FPM and a relational database under configuration management, with monitoring and patch routines, may prefer the manual route. The Nextcloud manual installation page describes it as a classic LAMP stack configured by the administrator, and the system requirements list Apache 2.4 or nginx with php-fpm alongside PHP 8.3, 8.4 or 8.5 and supported database versions for Nextcloud 35.
- Stack reuse: The web server, PHP pools, database and backup tooling can match standards the team already audits.
- Database choice: MariaDB, PostgreSQL or MySQL can be selected to match existing operations, within the listed versions.
- Caching and cron: Redis, APCu and background jobs are configured explicitly, so their state is visible to your monitoring.
- Upgrade ownership: Every step, including the backup before each major upgrade, sits with your team.
Confirm which PHP and database versions your existing platform supports, which backup tool your standards require, and whether you can run the monthly maintenance releases on the schedule Nextcloud publishes.
Requirements for several domains or a Kubernetes cluster change the answer. AIO is limited to one domain on a single server, though the project documents running multiple AIO instances on one host through a separate guide. It can also be installed on Kubernetes with its own Helm chart, which suits teams that want that model. A manual install gives full control over virtual hosts and ingress, which can matter when each domain needs its own configuration.
- Multiple domains: Plan one AIO instance per domain if you choose AIO, and review the separate guide before committing.
- Kubernetes fit: Compare the AIO Helm chart with the community chart on support, features and upgrades before choosing.
- Shared services: Decide whether databases, caches and object storage are shared across domains, since AIO bundles them per instance.
- Hosting model: Manual installs on a shared web tier suit operators who already manage virtual hosts.
Confirm the number of domains and tenants in scope, whether the cluster is already standardized, and how each option will be backed up and restored across instances.
Teams that must connect Nextcloud to a directory or identity provider should check identity requirements before choosing a path. Nextcloud documents an LDAP app that lets Active Directory and LDAP users sign in with directory credentials, and it also documents OpenID Connect and SAML authentication backends. Those settings are applied in the Nextcloud configuration in either route, so the install method matters less than the team's ability to test them after each upgrade.
- Configuration access: Both routes allow identity settings to be applied, but a manual install gives direct access to the configuration files and server environment.
- Testing burden: Identity changes should be tested in staging before each major upgrade, because apps can change between releases.
- Certificates and trust: Directory and identity connections depend on certificate chains and network paths that your team must manage.
- Support boundary: Confirm whether your identity provider is covered by Nextcloud documentation or by a vendor contract.
Confirm the protocol, the directory product and version, the attributes needed for group mapping, and who will own the identity configuration after handover.
What drives the cost of running each path
The main cost of either path is staff time, not licenses, because Nextcloud Server is AGPL-3.0 and the community edition carries no per-user fee. With Nextcloud All-in-One, the platform team pays for the initial build of the mastercontainer, the choice of domain and reverse proxy, and the sizing of the host, then pays a smaller recurring share for reviewing container updates and checking the BorgBackup jobs. With a manual install, the team pays for building and hardening the LAMP or LEMP stack, configuring PHP, the database and the web server, and then for patching each of those layers separately on its own schedule. Server resources are paid for in both cases, but a manual install often needs more careful sizing of PHP-FPM, database memory and cache settings, which adds hours to the initial build. External help is usually bought for the one-time build, for a migration, or for a retainer covering upgrades, and that quote should be written against a fixed scope.
Some costs are one-time and others recur. The one-time items are the initial build, the first backup design and restore test, and any migration of existing files or accounts. The recurring items are major upgrades, which Nextcloud does not allow you to skip, so each step must be planned, backed up and tested with third-party apps disabled until they are confirmed compatible, plus monthly maintenance releases, plus monitoring and security patching of the operating system, PHP and database. Nextcloud publishes a new major version every four months and supports each for one year, per the Nextcloud maintenance and release schedule, so the upgrade load is steady rather than occasional. Confirm the current support windows on the Nextcloud maintenance and release schedule before you size the budget for upgrades.
The drivers that raise or lower effort are concrete. Count the number of domains, since AIO does not support multiple domains and a second domain pushes you toward a separate AIO instance or a manual install. Decide whether you need Talk with its TURN server, Nextcloud Office, ClamAV or full-text search, because each optional container adds resource use and something to monitor. Check whether your identity source is LDAP or Active Directory, OpenID Connect or SAML, because each integration adds configuration to test on every upgrade. Ask whether the team will test restores, not just backups. In a quote, request a line item for each of these: build, migration, upgrade cadence, backup restore test, monitoring, and who handles security patching when a critical fix ships outside the regular cycle.
Questions buyers ask before choosing an install path
Can Nextcloud All-in-One be customized?
Yes, but only within the options AIO exposes. AIO runs a managed set of containers and its interface lets you choose optional components such as the Talk high performance backend with TURN server, Imaginary, ClamAV, full-text search and Nextcloud Office. Settings outside those choices, such as a custom web server layout or a different database engine, are not what AIO is built for. Confirm the exact options in the AIO repository against the release you plan to run, and list every customization your users need before choosing AIO. If a required change falls outside those options, a manual install gives you that control.
Can a manual Nextcloud install run Talk or Office?
Yes, but you install and connect each component yourself. The manual route is a classic LAMP or LEMP stack that you configure, so Talk, its TURN server and an office integration are separate services you deploy, secure and keep current. The Nextcloud administration manual describes the manual route as a classic LAMP stack configured by the administrator, so the work sits with your team. Ask your engineers to map each component, its version, its network path and its update owner before committing.
How long does setup take and what drives it?
No supplied figure gives a setup duration for either path, so measure it in your own environment. The main drivers are the number of optional components, whether you need TLS certificates and DNS in place, how many domains you run, and whether your team already operates PHP, a database and a web server. AIO removes most of the component wiring, while a manual install adds work for each service you configure. Ask any implementation partner for a fixed-scope plan listing these steps before agreeing a timeline.
Can our own team run Nextcloud upgrades?
Yes, if you can follow a strict upgrade process. Nextcloud does not allow skipping major releases, so you must move one major version at a time, back up before every upgrade and disable third-party apps until they are confirmed compatible, according to the Nextcloud upgrade manual. AIO can update the containers, Nextcloud and its apps automatically, which reduces manual steps but does not remove the need to check app compatibility. Nextcloud 35 is supported until September 2027, so plan a recurring upgrade window for your team regardless of install path.
What does external help cover for each install path?
External help can cover planning, implementation, customization, integration, hardening, backup, upgrades, documentation and support, under a written scope. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. Most engagements are fixed-scope, and ongoing support and upgrades are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. Ask for the scope to name which install path it covers and which components sit in it.
Can an AIO install move to a manual install later?
Confirm this with Nextcloud before you rely on it. The supplied facts describe AIO's bundled PostgreSQL, Redis, backup and update features, and the AIO backup is based on BorgBackup, but they do not document a supported path from an AIO instance to a manual LAMP or LEMP install. Before you choose AIO, ask the vendor or your partner for the documented migration procedure, the database export and file steps it requires, and whether the Borg archives can be restored outside AIO. Test that procedure on a copy of your data before you need it.
Does AIO limit how many domains or instances a team can run?
Yes, AIO supports one domain per instance. The AIO README states that multiple domains are not supported and will not be added. Multiple AIO instances on one server are possible through a separate guide, and AIO can also run on Kubernetes through its own Helm chart. If you need several domains under one platform, a manual install or a different deployment model may fit better, so confirm the domain count before choosing the path.
How DeployOpen scopes and runs a Nextcloud deployment
DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For Nextcloud, that means choosing between All-in-One and a manual LAMP or LEMP build based on your domain plan, database needs, backup design and upgrade ownership, then delivering the result in writing.
How we scope
- Engagements are fixed-scope, with the deployment method, domains, users and integrations agreed in writing before work starts.
- We confirm whether one domain is enough, since All-in-One does not support multiple domains on one instance.
- The written scope names who owns Nextcloud, PHP, database and web server upgrades after handover.
How we build
- We deploy either All-in-One inside your chosen infrastructure or a manual stack with the web server, PHP and database configured by hand.
- Optional components such as Talk, Nextcloud Office, ClamAV and full-text search are included only where the scope requires them.
- Identity integration, such as LDAP or Active Directory, is configured and tested against the directory accounts you specify.
How we hand over
- Deliverables include configuration documentation, backup and restore runbooks, and a record of the upgrade path chosen.
- We test restores from backup before handover, so recovery steps are proven rather than assumed.
- Your team receives the evidence and controls needed for internal reviews or external compliance assessments, which auditors then evaluate.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after the initial deployment.
- Upgrades follow the one-major-version-at-a-time rule, with a backup taken before each change and third-party apps checked first.
- Confirm response expectations and maintenance windows in the written retainer before work begins, since these vary by agreement.
