Which Nextcloud deployment model fits your team
All-in-One suits teams that want a vendor-documented, managed set of containers, while the community Helm chart suits teams with Kubernetes operators who want Nextcloud to follow their own cluster standards. The choice is mainly about who owns the runtime: All-in-One's mastercontainer runs the AIO interface, manages and updates the other containers and handles BorgBackup-based backups and restores. With the Helm chart, your platform team owns the manifests, the database, the ingress, the backup tooling and the upgrade sequence.
Support is the first check. The nextcloud/helm chart is maintained by community volunteers for expert use and is not supported by Nextcloud GmbH. Its README points to All-in-One for quick deployment with the full set of Nextcloud Hub features, so a regulated team that needs vendor support or the complete feature set should confirm with Nextcloud GmbH which bundled services it expects to run. All-in-One also offers a Helm chart of its own, nextcloud-aio-helm-chart, which is worth comparing against the community chart before you commit to either path.
Ask your operators three questions before choosing. Do you already run Kubernetes with an approved etcd backup routine and secrets encryption at rest, since Kubernetes stores Secrets unencrypted in etcd by default? Will you own Nextcloud's upgrades one major version at a time, with a backup before each step? And does your change process accept a chart you maintain yourself? If the answers are yes, the Helm chart fits your cluster standards. If not, All-in-One reduces the moving parts, but confirm with your own security team that a container that manages other containers is acceptable under your access controls.
Who should pick All-in-One and who should pick the Helm chart
A small or mid-sized IT team that runs Docker on a few Linux hosts but does not operate Kubernetes is the natural fit for All-in-One. The mastercontainer manages and updates the other containers, runs the BorgBackup-based backup and restore workflow and bundles PostgreSQL, Redis and APCu caching, optional Nextcloud Office and Talk, ClamAV and full-text search. The team still owns the host, the public domain and TLS, disk capacity for data and backups, restore drills and the timing of each update. The Helm chart becomes the better choice only when a Kubernetes platform already exists and another group runs it.
- Fewest moving parts: One host and one management interface cover the stack, so generalist administrators have fewer components to diagnose.
- Bundled backups: Borg backups ship with the product, but the backup target, retention period and scheduled restore tests remain the team's job.
- Topology limits: All-in-One assumes a single domain and a single-server layout, so confirm that matches the planned footprint before committing.
- Container runtime access: The mastercontainer works through Docker, so confirm the host's security review accepts that access or evaluate the manual install route described in the project README.
- Upgrade ownership: Nextcloud publishes a new major version every four months and supports each for one year, so someone must schedule upgrades, back up first and disable third-party apps until they are confirmed compatible.
Before committing, confirm that one host and one domain match the planned footprint and name the person who will run restore tests.
A platform team that already operates Kubernetes can use the nextcloud/helm chart when it wants the cluster's own tooling for scheduling, storage classes, ingress and secrets. The chart is maintained by community volunteers for expert use, and Nextcloud GmbH does not support it. That makes the team responsible for the database, cache, persistent volumes, certificates, backups and every upgrade. The chart's README points to All-in-One for quick deployment with the full set of Nextcloud Hub features, so the chart fits best when the team is ready to own that full set of work.
- Chart version tracking: Follow chart releases such as nextcloud-9.4.1, published October 18, 2026, and test value changes in staging before each rollout.
- Cluster upgrade order: Kubernetes maintains only the three most recent minor releases, kube-apiserver must move one minor version at a time, and kubelets may trail by up to three minor versions.
- Secrets and etcd: Kubernetes stores Secrets unencrypted in etcd by default, so the team must enable encryption at rest, restrict access with least-privilege RBAC and take and test etcd snapshots.
- Identity wiring: The LDAP app, OpenID Connect and SAML backends must be configured and tested against the cluster's own authentication and policy controls.
- Staged major upgrades: Nextcloud does not allow skipping major releases, so each upgrade is a backed-up, one-step change rather than a single chart bump.
Confirm that the platform team has the staffing to meet the upgrade calendar before choosing the chart over All-in-One.
A regulated organization that needs a supplier to stand behind its platform should settle the support question first, then choose the deployment method. Nextcloud GmbH sells Enterprise support in Standard, Premium and Ultimate tiers with a 100-user minimum, and the community Helm chart sits outside that support. All-in-One is the official installation method, but the team should obtain written confirmation from Nextcloud GmbH that the subscription covers its exact deployment, including any Kubernetes setup, before relying on it. The condition that favors the chart is a regulated team that already runs a compliant Kubernetes platform, accepts self-support and wants full control over its manifests.
- Support tiers: According to Nextcloud's pricing page, Standard includes 1-year maintenance, Premium adds a maintenance lifecycle of 5 or more years plus clustered instance support, and Ultimate adds support up to 24/7 with response times down to 1 hour.
- List prices: Nextcloud lists starting prices of 71.29, 104.99 and 204.75 euros per user per year for Standard, Premium and Ultimate at 100 or more users, so request a written quote at the actual user count.
- Scope of support: Ask whether the subscription covers All-in-One, the Helm chart or a manual install, and whether it extends to the bundled Office, Talk and search components.
- Implementation and evidence: DeployOpen can plan, implement, harden, back up and document either path inside the organization's own infrastructure and prepare evidence for an assessment. It does not issue audit reports or certifications, and that work does not replace vendor support.
- Lifecycle alignment: Compare the subscription maintenance window with the organization's own risk acceptance and change schedule before selecting a tier.
Ask Nextcloud GmbH and the assessor which deployment method the support terms and compliance evidence actually cover.
Support, features, upgrades and skills side by side
This table compares Nextcloud All-in-One and the community nextcloud/helm chart factor by factor, from support and bundled features to upgrades and the skills each path asks of your team. Read each row as a question to answer for your own environment, since the Helm chart's bundled features depend on its values and should be confirmed in its configuration.
| Factor | Nextcloud All-in-One | nextcloud/helm chart |
|---|---|---|
| Publisher and support model | Nextcloud GmbH describes All-in-One as its official installation method, so it sits closest to the vendor's own path. | Maintained by community volunteers for expert use and not supported by Nextcloud GmbH. Plan for internal or third-party support. |
| Documented feature coverage | Bundles Redis and APCu caching, PostgreSQL, optional Nextcloud Office, Talk with recording, BorgBackup, ClamAV and full-text search. | Its README points to All-in-One for the full set of Nextcloud Hub features. Confirm each bundled service in the chart values before assuming it is included. |
| Kubernetes requirement | Runs on Docker through a mastercontainer. Kubernetes is available through its own nextcloud-aio-helm-chart, a separate chart. | Built for Kubernetes. Your team must already run and secure a cluster, including control plane, etcd and ingress. |
| Upgrade path | The mastercontainer manages and updates the other containers, so the update flow is handled inside the AIO interface. | Upgrades are driven by you through chart and image versions. Nextcloud requires one major version at a time, with a backup before each upgrade. |
| Backup ownership | BorgBackup-based backups and restores are handled by the mastercontainer, which the operator configures and runs. | No backup tooling is documented in the chart README. Your team designs and tests backups for Nextcloud data and the database. |
| Release cadence reference | Track the All-in-One releases on its GitHub repository and match them to the Nextcloud versions it installs. | Release nextcloud-9.4.1 was published on October 18, 2026, per its GitHub releases page. Check each release against Nextcloud 35 requirements. |
| Operating skills | Docker administration, reverse proxy and domain setup, and familiarity with the AIO interface and backup restore. | Kubernetes operations, Helm values management, persistent storage, etcd backup, RBAC and secrets handling, in addition to Nextcloud administration. |
What runs in each architecture
Nextcloud All-in-One and the community Helm chart both put Nextcloud on containers, but they hand you very different amounts of the stack. The cards below show which components the platform manages for you, which ones your team owns, and what the Kubernetes path inherits underneath.
AIO mastercontainer and managed containers
AIO runs a single mastercontainer that provides the setup interface and then manages, updates and restarts the other containers that make up Nextcloud, including the bundled database, caching and optional services. Your team does not assemble these pieces by hand, but it does give the mastercontainer a route to Docker. Check whether the Docker socket access the standard install relies on fits your container security policy, and note that the README also describes a manual install without that access.
Borg backup and restore flow
AIO's built-in backups use BorgBackup, and the mastercontainer drives both the backup and the restore. This is the main reason AIO suits small teams without a backup platform. Confirm where the Borg repository lives, how long backups are kept, and whether a restore has been rehearsed on a second host, because the Helm chart does not bring this flow with it.
Helm chart Kubernetes objects
The community nextcloud/helm chart renders standard Kubernetes resources such as deployments, services and storage claims from your values file, so Nextcloud is managed through the same GitOps and review tooling as your other workloads. Nothing in the chart runs a managed mastercontainer or an update engine. Upgrades, configuration and rollbacks become your pipeline's responsibility, so review the chart's values and release notes before each change.
External dependencies the operator supplies
The Helm path expects you to provide the database, cache, object or persistent storage, ingress and TLS certificates, and often the backup tooling. Each of these becomes a separate component with its own patching and recovery plan. Ask which database engine and version your Nextcloud release supports, and who owns the backup of persistent volumes if the cluster itself is lost.
Kubernetes control plane under the Helm path
Running the Helm chart means running a Kubernetes cluster, and the kubeadm high availability guide describes a stacked topology with etcd on the control plane nodes or an external etcd cluster, with at least three control plane nodes and a TCP load balancer on port 6443. Kubernetes documentation recommends an odd etcd member count, with five members in production. Confirm who operates the control plane before you choose this path.
etcd backup and Secrets exposure
Kubernetes stores Secrets unencrypted in etcd by default, and Nextcloud's database credentials and admin secrets usually end up there. Your team must plan etcd snapshots with etcdctl snapshot save, restore them with etcdutl, and enable encryption at rest or an external secrets store. Ask who runs these procedures, how often they are tested, and whether they cover the Nextcloud data volumes as well as the cluster state.
How upgrades differ when Nextcloud must move one major version at a time
Nextcloud does not allow skipping major releases, so every installation, whichever deployment method it uses, must step through one major version at a time. The current maintained lines are Nextcloud 35.0.2, 34.0.5 and 33.0.10, all published on October 15, 2026. Nextcloud 35 was released on September 16, 2026 and is supported until September 2027, Nextcloud 34 until June 2027 and Nextcloud 33 until February 2027. Before planning a move, check which line your instance sits on and confirm the next step in the Nextcloud upgrade manual, since a long gap between upgrades means several sequential jumps, each with its own backup and testing window.
The discipline the upgrade manual requires is the same on both paths: take a backup before every upgrade and disable third-party apps until each one is confirmed compatible with the target version. The backup and app review are the operator's work in every case. With All-in-One, the mastercontainer manages and updates the other containers and provides BorgBackup-based backups and restores, so the operator still decides when to take the backup, when to move to the next major version and which apps to re-enable. With the community nextcloud/helm chart, the chart and image versions, the database and the backup tooling are all the operator's to change and verify.
On Kubernetes, the upgrade surface is wider. The Kubernetes version skew policy requires kube-apiserver to be upgraded one minor version at a time, before kube-controller-manager, kube-scheduler and kubelets, and kubelets may run up to three minor versions behind. The project maintained 1.37, 1.36 and 1.35 as of September 2026, so cluster upgrades and Nextcloud upgrades must be sequenced together. Etcd also needs a tested backup plan using etcdctl snapshot save, with restores through etcdutl, because Secrets are stored unencrypted in etcd by default. Confirm who owns each of these steps in writing before the first upgrade.
Steps to choose and validate a deployment model
This sequence turns the choice between All-in-One and the community Helm chart into a documented decision, with each step producing evidence your team can review before any production rollout.
Confirm whether Kubernetes is already run and supported
Platform owners check whether your organization already operates a Kubernetes cluster with a supported minor version, a documented upgrade path and an owner for node, storage and network operations. If no cluster exists, the Helm chart adds a platform build on top of the Nextcloud work, so the choice is really about whether you want to own that platform. Done means a written statement naming the cluster owner, the version in use and the team that patches it. If the answer is no, All-in-One on Docker is the option to evaluate first, since its README describes it as the official installation method.
Decide the support level before comparing features
The CIO or head of IT decides whether your team will carry all support itself or buy a Nextcloud GmbH subscription. The nextcloud/helm chart is maintained by community volunteers and is not supported by Nextcloud GmbH, so a Helm deployment with no internal Kubernetes expertise has no vendor path for chart issues. Compare subscription tiers and what they cover in the Nextcloud Enterprise comparison, which is a sibling topic. Done means a signed-off record of who answers a production incident and under what contract.
List the features your users need in writing
Security, compliance and collaboration leads list the Nextcloud apps and integrations they require, such as Talk with recording, Nextcloud Office, full-text search, antivirus and single sign-on through LDAP, OpenID Connect or SAML. Check each item against what All-in-One bundles and against what the Helm chart's values expose, then record any gap as a custom build or add-on task. Done means a table with each required feature, the deployment method that covers it and a status of confirmed, partial or to be confirmed with the vendor.
Test backup and restore in a non-production environment
The platform team deploys the chosen method in a non-production namespace or host, loads representative data, runs a backup and restores it to a clean instance. All-in-One uses BorgBackup through its mastercontainer, while a Helm deployment depends on your own backup tooling for the database, data volume and configuration. Check that users, shares, encryption keys and the database all come back consistently. Done means a restore test record with the timestamp, the restored object counts and the list of anything that needed manual repair.
Rehearse a major version upgrade
The operations team plans an upgrade from one major Nextcloud version to the next, since the upgrade documentation does not allow skipping major releases. They take a fresh backup, disable third-party apps until each is confirmed compatible, and run the upgrade in staging. For the Helm chart, they also confirm the chart release that matches the target version. Done means an upgrade runbook with the exact steps, the rollback point and a list of apps checked for compatibility.
Confirm chart values and version pinning
For a Helm deployment, the platform engineer reviews the chart values file, pins the chart release and the Nextcloud image tag, and stores both in version control. They confirm which Kubernetes features the values rely on, including storage classes, ingress, secrets handling and encryption at rest for Secrets in etcd, as the Kubernetes Secrets guidance recommends. For All-in-One, they confirm the AIO release and its container set instead. Done means a reviewed values file and a version manifest that a second engineer has approved and that matches the staging environment.
Record the decision and the validation evidence
The project owner writes a short decision record that links the Kubernetes check, the support level, the feature table, the restore test and the upgrade runbook. It also names what must be confirmed with Nextcloud GmbH or the chart maintainers before go-live. Ask any implementation partner for a written scope that covers these artifacts, since the quote follows from that scope. Done means an approved record that a future auditor or new administrator can follow without asking the original team.
What drives the cost of running each option
The software is free on both paths: Nextcloud Server is AGPL-3.0-only, and the cost of running it comes from infrastructure, staff time and, for the Helm path, the Kubernetes platform underneath. The recurring cost of the Helm chart is the cluster itself: control plane nodes (the kubeadm guide calls for at least three in a highly available setup), etcd with its backup plan, a TCP load balancer in front of kube-apiserver, and storage classes for Nextcloud data and the database. Those components are paid for whether or not Nextcloud is running on them, and they need patching, certificate rotation and upgrades on the Kubernetes minor-version cadence. All-in-One carries a smaller platform bill: one host with Docker, plus the storage and bandwidth it needs for BorgBackup.
Backup storage recurs on both paths and is often underestimated. All-in-One's mastercontainer handles BorgBackup-based backups and restores, so the cost is the repository disk or remote target you provision and its retention. With the Helm chart, backups are your responsibility, and the cost includes etcd snapshots, database backups and volume snapshots, each with its own retention. Ask your team to estimate the size of user data, the retention period and the restore test frequency before comparing the two bills. Also confirm which backup tooling you will run and who maintains it.
Staff time is the largest variable. The Helm chart is maintained by community volunteers and is not supported by Nextcloud GmbH, so the cost of troubleshooting, chart upgrades and Kubernetes skills sits with your team or your implementation partner. If you add a Nextcloud Enterprise subscription, the pricing page lists Standard, Premium and Ultimate tiers with a 100-user minimum and per-user prices from 71.29, 104.99 and 204.75 euros per year for 100 or more users. Treat those figures as list-price reference only, since your quote depends on user count, the support hours you need and the written scope. Ask for one-time items (setup, migration, hardening, initial testing) separately from recurring items (subscription, platform hosting, backups, support retainers).
Questions teams ask before choosing a Nextcloud deployment
Is the nextcloud/helm chart supported by Nextcloud GmbH?
No. The nextcloud/helm chart is maintained by community volunteers for expert use and is not supported by Nextcloud GmbH. Its README points teams to All-in-One for quick deployment with the full set of Nextcloud Hub features. Support on the Helm path therefore comes from your own engineers, the community, or a partner you contract with directly. If your procurement or audit process requires a vendor support contract, confirm before choosing this route whether a Nextcloud Enterprise subscription, which is sold separately, fits your deployment model. Ask Nextcloud GmbH which of its paid tiers covers the infrastructure you run.
Can Nextcloud All-in-One run on Kubernetes?
Yes, with a caveat about which chart you use. Nextcloud All-in-One can be installed on Kubernetes with its own nextcloud-aio-helm-chart, which is distinct from the community nextcloud/helm chart. The AIO README also describes a manual install that avoids giving a container access to the Docker socket. Confirm with the AIO project which Kubernetes versions and storage classes its chart targets, and whether the chart manages the same backup and update workflow as the Docker-based mastercontainer. The two Kubernetes paths give you different amounts of control, so test the one you plan to run before committing.
How much Kubernetes skill does the Helm path need?
Expect to need working knowledge of several Kubernetes layers, not only Helm. The community chart runs on a cluster you operate, so your team handles ingress, persistent storage, database and cache services, secrets, and upgrades of the cluster itself. Kubernetes releases roughly three times a year, the project maintains only the three most recent minor versions, and the version skew policy requires kube-apiserver to be upgraded one minor version at a time before the other components. Production control planes also need a highly available topology with at least three control plane nodes and a backup plan for etcd. Ask whether your platform team already runs and patches clusters like this before choosing the Helm route.
How do backups differ between AIO and the Helm chart?
AIO includes its own backup path. The mastercontainer handles BorgBackup-based backups and restores for the containers it manages. The community Helm chart does not give you that built-in workflow, so you design backups around the cluster: database dumps, the Nextcloud data directory on persistent volumes, and configuration. Kubernetes stores Secrets unencrypted in etcd by default, so you must also decide how to encrypt them at rest and back up the etcd snapshots using etcdctl. Restores must be tested end to end, including the database and file data together. Ask any implementation partner to show the restore procedure, not just the backup job.
How are Nextcloud upgrades handled on each path?
Both paths must respect Nextcloud's own upgrade rules. Nextcloud does not allow skipping major releases, so you move one major version at a time, back up before every upgrade, and disable third-party apps until they are confirmed compatible. Nextcloud 35 was released on 16 September 2026 and is supported until September 2027, while 34 and 33 have earlier end-of-life dates, so plan for a major upgrade roughly every four months. AIO updates its managed containers for you, whereas the Helm path leaves chart version, image tag, Kubernetes version and database version to your change process. Test every step in a staging cluster first.
Can a small team run this without outside help?
It depends on the path and the team. A team that already operates Kubernetes, PostgreSQL and object or block storage can run the Helm chart with internal staff, but must own every upgrade, backup test and incident. A team without that background will find AIO easier to start with, because it manages its own container set through an interface. Count the roles you need: someone for the cluster, someone for Nextcloud administration, someone for backups and recovery, and someone for security hardening. If any of these roles is empty, the risk is in the gap, not the software.
When is an outside implementation partner worth scoping?
A partner is worth scoping when the work is bounded and the risk of getting it wrong is high. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. Typical triggers include a regulated environment that needs documented controls, a first Kubernetes deployment, or a migration from another platform. Ask for a written scope that names the chart or install method, the backup and restore tests, the upgrade runbook, and who supports the system after handover. DeployOpen does not publish a price list, so a quote follows from that scope.
Moving between the two paths later
Moving from AIO to a Kubernetes install, or back, is a migration project, not a configuration change. The two paths manage the data directory, the database and the backup format differently. AIO runs the mastercontainer, which creates and updates the other containers, and its BorgBackup-based backups and restores are tied to that managed layout. The Helm chart leaves the cluster operator in charge of persistent volumes, the database (which you supply or deploy separately) and any backup tooling. Before choosing a path, confirm with the vendor or in a test environment exactly which volumes, database dumps and Borg repositories you would need to carry across, who owns each one after the move, and whether a backup taken under one path can be restored under the other. Do not assume it can until a restore has been tested.
Database ownership is the decision that most often gets postponed. AIO bundles PostgreSQL, Redis and APCu caching inside its managed stack, so the database lifecycle follows the AIO updates. With the Helm chart, the database may sit in a separate managed service or a separate operator, which means its patching, backups and failover belong to a different team. Ask the vendor how a database managed by AIO is exported and imported into an external one, and which configuration values in config.php change when the host name or credentials move. Plan a rehearsal with a copy of production data, and record the Nextcloud version, the database version and the app list before and after the move.
The one-major-version rule applies on both paths and is the constraint that shapes any migration timeline. Nextcloud does not allow skipping major releases during upgrades, so a team moving from an older release must step through each major version in turn, with a backup before every step and third-party apps disabled until confirmed compatible. Choose the target version with the Nextcloud maintenance and release schedule in hand, since each major line has its own end-of-life date. Confirm with your support provider whether a path move counts as an upgrade, and build the rehearsal around the full sequence of steps, not only the final version.
How DeployOpen scopes and delivers Nextcloud deployments
DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For Nextcloud, that means choosing the deployment path that fits your Kubernetes or container standards, then delivering it with the identity, storage, backup and upgrade controls your team needs to run it.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope states which Nextcloud deployment path applies, and why it fits your cluster or container platform.
- Scope also records who owns Helm values, image updates, backups and upgrades after handover.
How we build
- We build inside your cloud accounts, data centers or air-gapped networks, not in a DeployOpen-hosted environment.
- Integration covers directory sign-in, object or local storage, database choice and office or talk components you select.
- Hardening and testing cover the platform, the Kubernetes layer and the backup and restore path before go-live.
How we hand over
- Deliverables include documentation of the configuration, the upgrade procedure and the restore steps your team will run.
- We walk your operators through the one-major-version-at-a-time upgrade rule and the pre-upgrade backup routine.
- Compliance evidence is prepared for your auditors, who issue any report or certification; DeployOpen does not issue them.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, agreed separately from the build scope.
- Retainers can cover monitoring of Nextcloud release lines and planning of each major upgrade in your change calendar.
- Ask for the support hours, response targets and escalation path in writing before you sign any retainer.
