Why a Nextcloud Kubernetes deployment needs more design than a single server
Running Nextcloud in an existing Kubernetes cluster is sound, provided the application pods stay stateless and everything that holds state sits outside them: an external database, Redis for caching and locking, shared or object storage for user files, and a scheduled cron runner for background jobs. Major version upgrades then become a controlled, one-at-a-time procedure rather than a rolling restart. The platform team should treat the Helm chart as the starting point for that design, not as the design itself. A Deployment manifest makes the application look like any other web service, and that is where the trouble starts. User file data is the first difference. Nextcloud writes uploads, previews and versions to a data directory, and if two replicas or a rescheduled pod cannot see the same storage, users see missing files or conflicting copies. Sessions and file locking are the second. Without Redis or another shared locking backend, concurrent edits and sessions can behave differently depending on which pod answers a request. Confirm with your storage vendor how the chosen volume access mode behaves under concurrent writers before you commit to a layout. Background jobs are the third difference. Nextcloud expects a regular cron job to run tasks such as file scans, trash cleanup and notifications. Running that work inside each web pod, or leaving it on the default AJAX mode, duplicates or delays jobs as replicas multiply. Plan a dedicated cron workload with a single responsibility and check the configured background job mode in the admin settings after every change. Upgrade ordering is the fourth. Nextcloud does not allow skipping major releases, so the platform must hold a path from the current version to each intermediate major, back up before every step, and disable third-party apps until each one is confirmed compatible. Pipelines that roll new images automatically through a cluster will break this unless the upgrade is gated by hand. App compatibility is the fifth risk: apps installed through the app store can block an upgrade or change behavior, so keep an inventory of every app in use and its vendor or maintainer. Three sibling topics go deeper on these concerns: storage design, high availability and upgrade handling. Read them alongside this page before fixing a storage class, replica count or upgrade runbook.
Which Nextcloud components become pods, services and external dependencies
A Helm-based Nextcloud deployment splits one server into several workloads, each with its own scaling, storage and failure behavior. The cards below cover the application pods, the background job runner, the database, Redis and storage, and the chart choice that sets the defaults for all of them.
Application pods running PHP and a web server
The Nextcloud application runs PHP with either Apache 2.4 or nginx with php-fpm, following the stack in the Nextcloud 35 system requirements. In Kubernetes this becomes one or more stateless pods behind a service, so the pod image, PHP version and web server must match the supported combination. Confirm which PHP and web server the chosen image tag ships before you set resource requests.
Separate cron runner for background jobs
Nextcloud background jobs such as file scanning, notifications and maintenance tasks should run from a system cron rather than from web requests. In a Kubernetes deployment this is usually a separate workload that runs the same image on a schedule or as a sidecar pattern. Check how the chart implements it, because a missing or duplicated cron runner causes stalled jobs or unexpected load.
External database as a managed dependency
Nextcloud 35 recommends MariaDB 11.8 or PostgreSQL 18, and supports MariaDB 10.11 to 12.3, PostgreSQL 14 to 18, and MySQL 8.4 or 9.7. Most Helm setups either deploy a database subchart or point to an existing external service, and that choice decides who owns backups, upgrades and failover. Confirm the exact database version and whether it lives inside or outside the cluster.
Redis for file locking and caching
Redis handles transactional file locking and memory caching, and it becomes a separate service that every application pod must reach. Without it, concurrent edits and sync clients can conflict, so treating Redis as optional in a multi-pod deployment is a common mistake. Confirm whether the chart deploys Redis, how authentication is configured, and whether a failed Redis pod leaves sessions or locks in a bad state.
Data directory on persistent or object storage
The Nextcloud data directory holds user files and must be shared by every application pod that serves requests. Options include a ReadWriteMany volume, a storage class that supports shared access, or S3-compatible primary object storage, and each option changes performance, backup and later migration. Confirm the access mode your storage class provides and where config.php and the data directory are mounted.
Chart choice sets the defaults
The Nextcloud Helm chart and the All-in-One chart from the All-in-One project are different choices with different bundled components and defaults. All-in-One bundles Redis, PostgreSQL, backups, antivirus and full-text search, while the standard chart expects you to supply more of these yourself. Before installation, pin the chart name, chart version and image tag, then review every default that creates a pod, service or volume.
Which Kubernetes choices change day-two operations for Nextcloud
This table compares the Kubernetes and component choices a team must settle before deploying Nextcloud, with the day-two effects of each option on backups, upgrades, ownership and performance. Read each row as a decision: the first column names it, the middle columns show when an option fits and what it costs to run, and the last column shows what to confirm with the vendor or your own environment.
| Decision | Option and when it fits | Day-two operational cost |
|---|---|---|
| Deployment chart | Official Nextcloud Helm chart fits teams that already run their own database, cache and storage and want each component managed as a separate Kubernetes resource | You own every component's versioning and backup scope, and upgrades follow your release process rather than a bundled one |
| Deployment chart | All-in-One chart fits teams that want a bundled stack with Redis, PostgreSQL and backup tooling included and accept its packaging choices | Upgrade timing and component versions are tied to the bundle, and customization outside the bundle is limited, so confirm which options your team needs |
| Database placement | In-cluster database fits small pilots or teams with strong database operations skills inside Kubernetes | You own backups, replication, minor version patches and storage performance, and must restore the database consistently with file data |
| Database placement | Managed or external database fits teams that want the provider to handle patching, backups and failover under a contract | Backup scope splits between the provider and your Nextcloud runbook, and you must confirm the provider supports the database versions Nextcloud 35 requires |
| Redis placement | In-cluster Redis fits a single cluster with low latency needs and simple operations | Redis holds locking and cache data, so a failure or restart affects performance and file locking, and you must monitor it as a critical component |
| Redis placement | External Redis fits teams that share a cache service or need it isolated from application pods | Network policy, authentication and TLS for the connection become your responsibility, and capacity is planned separately from the cluster |
| File data storage | Shared volume fits clusters with a supported ReadWriteMany storage class and workloads that need local file paths | Backups must capture the volume and database together, and storage class performance and snapshot behavior drive restore time |
| File data storage | S3-compatible object storage fits teams that want storage decoupled from pods and a storage platform they already operate | Object store versioning, lifecycle and encryption settings affect backup scope, and migration away later requires planning for object metadata |
| Background jobs | Sidecar cron fits small installations that want the scheduler tied to each app pod's lifecycle | Multiple replicas can run jobs concurrently, so you must confirm the job lock behavior and watch for duplicated work |
| Background jobs | Separate CronJob or external scheduler fits clusters that want one scheduled job per instance and clear job history | You must confirm the schedule, concurrency policy and failure alerts, and keep the job's container image in step with app upgrades |
| Ingress and TLS | Ingress controller with TLS termination at the edge fits clusters with an existing certificate process and standard headers | Certificate renewal, client body size limits and forwarded headers must be configured and tested after every upgrade |
| Ingress and TLS | TLS passthrough or end-to-end encryption fits environments with strict internal encryption rules | Inspection, header handling and brute-force protection move to the application or a separate layer, which adds configuration to verify |
Building the Nextcloud Helm deployment in the right order
This sequence brings up the database, cache, storage, chart, ingress and background jobs in dependency order, so each layer is proven before the next one depends on it. The result is a stable baseline that can be upgraded and reproduced from code.
Provision and verify the database engine
Create the external database before anything in the cluster points at it. Nextcloud 35 recommends MariaDB 11.8 or PostgreSQL 18, and supports MariaDB 10.11 to 12.3, PostgreSQL 14 to 18, and MySQL 8.4 or 9.7. Confirm the chosen engine and version against the Nextcloud 35 system requirements, then create a dedicated database and user with only the privileges the installer needs. Check it by connecting from a temporary pod in the target namespace and running a simple query. The step is done when that test succeeds from inside the cluster network, not only from your workstation.
Deploy Redis and confirm reachability
Deploy Redis as a separate workload in the same namespace and set authentication before the application is configured. Nextcloud uses Redis for file locking and memory caching, so a missing or unauthenticated cache causes errors later that look like application faults. From a pod running the Nextcloud image, open a connection to the Redis service name and send a ping. The step closes when the application pod can reach Redis with the credentials it will use in production, and the connection fails when the password is wrong.
Create and test persistent or object storage
Create the data volume or the object storage bucket that will hold user files. Shared file systems need ReadWriteMany access, and a single-writer volume will limit you to one app pod. Object storage needs a bucket, a scoped access key and a region or endpoint that matches your provider. Mount the volume into a test pod, or use the storage client with the bucket credentials, and write a file, read it back and delete it. The step is complete when a write from one pod is readable from another pod, confirming the storage path works before Nextcloud depends on it.
Install the chart with pinned versions and external secrets
Install the Nextcloud Helm chart with an exact chart version and image tag, so a later redeploy cannot change the application underneath you. Point the values at the external database, Redis and storage created earlier. Pull credentials from your secrets manager or an external secrets operator rather than placing them in values files. Keep the admin password and database password out of the rendered manifests. The check is a successful rollout with the pod running, and a rendered manifest review confirming no plaintext credentials appear in the release.
Run the installation and occupancy checks
Once the pod is ready, run the server status command inside the application container and confirm the installation reports as installed, the database connection is active and the data directory is writable. Review the admin overview page for warnings about missing indexes, cache configuration or memory limits. Check that the pods are scheduled on nodes with enough capacity for the PHP workers you configured. The step closes when the status command reports a healthy installation and the admin warnings are either resolved or recorded as known items with an owner.
Configure trusted domains, proxy headers and ingress TLS
Set the trusted domains to the exact host names users will type, and add the trusted proxy addresses of your ingress controller so client IP addresses and HTTPS detection work correctly. Configure the forwarded headers the ingress passes through, and terminate TLS at the ingress with a certificate issued for the Nextcloud host. Confirm that the protocol and host seen by Nextcloud match the public URL. The check is a login through the public address with the browser showing a valid certificate, and the admin overview reporting no trusted domain or HTTPS warnings.
Switch background jobs to cron and confirm execution
Change the background job mode from AJAX to cron, because AJAX jobs depend on user traffic and can fall behind. Create a CronJob that runs the Nextcloud cron script in the application container on a fixed schedule, using the same configuration and user as the web pods. Set the concurrency policy so overlapping runs do not start. Confirm execution by reading the job history and the last cron timestamp shown in the admin overview. The step is complete when the timestamp updates on schedule and no background job errors appear in the log.
Enable required apps and record configuration as code
Enable only the apps the business requires, and only after the baseline above has stayed stable through a few days of normal use and a restart test. Enable one group at a time, rechecking the admin overview after each. Then record the final state in version control: the chart values, the pinned versions, the Nextcloud configuration changes made through occ, the app list and the cron definition. Store the secrets references, not the secret values. The check is a clean redeploy from the repository into an empty test namespace that reaches the same healthy status as the production baseline.
How to upgrade Nextcloud major versions on a running cluster
The upgrade rules set the order of work before any Kubernetes change is made. Nextcloud does not allow skipping major releases, so an installation on an older major must move to the next major, then the next, until it reaches the target. Each step needs its own backup taken before the upgrade starts, and third-party apps stay disabled until their owners confirm they work with the target version. For a Helm-based deployment, this means the plan is a list of major versions with a compatibility check attached to each step. Write that list from your current major to your target, and confirm the step sequence against the upgrade manual on the day you schedule the work.
The release cadence explains why the path matters. Nextcloud publishes a new major version every four months and supports each one for a year through monthly maintenance releases. The published schedule lists Nextcloud 33 as supported until February 2027, Nextcloud 34 until June 2027, and Nextcloud 35, released on 16 September 2026, with end of life in September 2027. Nextcloud 36 is scheduled for 17 February 2027. A cluster that stays on Nextcloud 33 into 2027 will have to step through later majors within a short window, so map the path while the dates are still ahead. Confirm the current dates on the maintenance and release schedule, because a published schedule can change.
Kubernetes adds the sequencing controls. Pin the Nextcloud image to the exact target tag in the Helm values so no pod can start on a different major during a rolling update. Scale the cron runner down or suspend its CronJob so background jobs do not touch a half-upgraded codebase, and confirm that no jobs are still running before you continue. Run the upgrade step once as a separate Job that performs the migration, and keep application pods from running it at startup, since several pods racing through the same migration is a failure worth designing out. Roll the application pods only after that Job completes successfully, then restore the cron runner.
Set the go or no-go checks before the maintenance window opens. Confirm that the database, Redis and PHP versions meet the requirements for the target release, that a consistent backup of the database, the data directory or object storage, and the config exists, and that maintenance mode is enabled for the window. Name who can call a stop and how long the cluster can stay in maintenance mode. Plan recovery as a restore from the pre-upgrade backup, and check the upgrade documentation for any supported downgrade route before you assume one exists. If you hold an Enterprise subscription, confirm in writing how the vendor will be engaged during the window.
Rehearse the full path in a staging cluster with a copy of production data before touching production. Build staging from the same chart version, image family, database engine and Redis version as production, then run each major step in order, including the app disable and re-enable steps. Record how long each step took, which apps failed compatibility, and what the upgrade Job logs show at each stage. The rehearsal output becomes the production runbook. When you request a quote, check whether staging rehearsals, the data copy and runbook writing are inside the fixed scope, and who provides the staging environment.
How the Kubernetes model changes across cloud, on-premises and air-gapped environments
In a managed Kubernetes service inside the client's own cloud account, the provider runs the control plane and the team owns the Nextcloud workloads, data, edge and access rules. Storage classes usually come from the provider's CSI drivers, while object storage is typically a separate cloud service reached over the network. Ingress depends on the load balancer and ingress controller the team installs, and DNS and certificates usually sit with the provider's DNS service and a certificate manager. Background jobs run as Kubernetes CronJobs or a dedicated worker deployment.
What to check:
- Storage classes: Confirm which CSI drivers the provider supports, whether volumes can be expanded, and whether shared access modes are available if more than one pod mounts the data directory.
- Ingress: Confirm the load balancer type, TLS termination options and request body size limits, since large file uploads depend on them.
- Image supply: Confirm whether images are pulled from public registries or the provider's registry, and which egress rules and pull secrets apply.
- DNS and certificates: Confirm how records are managed in the provider's DNS zone and how certificates are issued and renewed.
- Cron scheduling: Confirm that the CronJob runs on schedule and that Nextcloud's background job mode is set to match.
Confirm with the provider which managed features your design depends on and how those features are covered in your agreement.
On self-managed clusters in the client's own data center, the team owns the control plane, the nodes and usually the storage platform. No cloud load balancer or dynamic provisioning is present by default, so the team must supply those pieces. DNS typically runs on internal resolvers, and certificates usually come from an internal certificate authority. Image pulls can go to an internal registry or proxy cache, and cron work still runs as a Kubernetes CronJob.
What to check:
- Storage classes: Confirm that the storage backend offers the access modes and latency the database and data directory need, and that the storage team supports snapshots for backups.
- Ingress: Choose a load balancer implementation and ingress controller, then confirm how failover behaves when a node or controller fails.
- Image supply: Confirm which internal registry or proxy cache serves images, and whether nodes can reach public registries at all.
- DNS and certificates: Confirm the internal DNS zone, the certificate authority chain, and how clients and servers receive the trust chain.
- Cron scheduling: Confirm that node time synchronization is reliable and that background jobs survive node drains and restarts.
Confirm these pieces with the platform, network and security teams before the cluster design is fixed, since each one can change the Nextcloud configuration.
In an air-gapped cluster, nodes have no route to the internet, so every container image, Helm chart and dependency must be transferred into the network and stored in internal registries and chart repositories before installation. Updates follow the same path, which makes the transfer process part of the operating model. Storage and ingress resemble the on-premises case, but certificates must come from an internal authority because public automated issuance is unavailable. Background jobs still run in the cluster, and the team must confirm how app and maintenance updates reach the server.
What to check:
- Image supply: Mirror every image the chart references, including the database and Redis images, and record the exact versions and digests that were transferred.
- Chart packages: Store the chart archive in an internal repository with pinned versions, so upgrades can be reviewed before they are transferred.
- DNS and certificates: Plan renewal monitoring for internal certificates, since no public process will warn the team before expiry.
- Storage and backups: Confirm that backup copies can cross the boundary under the organization's transfer rules and that restores have been tested from transferred media.
- Apps and updates: Confirm how Nextcloud apps and maintenance releases are delivered offline, because the app store is not reachable from inside the network by default.
Confirm the transfer approval process, media handling rules and the offline update path with the security team before the first install.
On a single node or a small cluster, the team may choose the Nextcloud All-in-One Helm chart. That chart bundles Redis, APCu caching, PostgreSQL, backup tooling, antivirus and full-text search into one deployment, so the team manages fewer separate services. The trade-off is that the database, cache and object storage are not separated into independent services as they are in the multi-service model, which limits how each one can be scaled or replaced. Storage, ingress, DNS and certificates each reduce to one configuration path.
What to check:
- Storage classes: Confirm one storage class for both database and data volumes, and confirm the volume size and growth expectations with the storage owner.
- Ingress and certificates: Confirm the reverse proxy and certificate arrangement that the chart expects, along with the issuer used for renewals.
- Image supply: Confirm which images the chart pulls. In an air-gapped setting, mirror all of them before installation.
- DNS: Confirm the single public record and how internal clients resolve it.
- Cron and updates: Confirm that the bundled background job handling runs correctly and that component versions move forward only through chart upgrades.
Confirm whether your organization needs an external database, external cache or object storage, because the bundled design may not allow those attachments.
What drives the effort and cost of a Nextcloud Kubernetes deployment
This table lists the factors that change the build and run effort of a Nextcloud Kubernetes deployment, how each one changes the work, and what keeps it contained. Read it before requesting a quote, because the one-time build and the recurring upgrade work respond to different drivers. Use the controls in the last column to ask a partner or your own team what the quote assumes.
| Driver | How it changes the work | What keeps it down |
|---|---|---|
| User count and concurrent sessions | Higher concurrency raises PHP-FPM worker sizing, database connections, Redis load and the number of app pod replicas needed, and it shapes load testing before go-live. | Confirm peak concurrent sessions, not total accounts. Size from a load test in staging, and set autoscaling limits in writing. |
| Data volume and file count | Large file counts slow preview generation, file scans, backups and restore tests. Volume also sets the size of the persistent or object storage claim. | Agree a data inventory during discovery. Set preview limits and file-count expectations, and test restore time against the real dataset. |
| Number of integrations | Each identity provider, Office server, Talk component, or external storage mount adds configuration, network paths, secrets and test cases that must pass after every upgrade. | Limit the first release to named integrations. Document each one as a tested scenario so later additions are scoped separately. |
| Number of clusters and environments | Production, staging and disaster recovery clusters multiply Helm values, secrets, certificates, monitoring and backup jobs. Drift between them is a common source of upgrade failures. | Keep one chart version and one values structure across environments, with environment differences limited to a documented overlay file. |
| Storage type chosen | Shared file storage, S3-compatible object storage or external mounts change the persistence design, backup method, performance profile and cost of later migration. | Decide storage before build starts. Confirm the storage vendor's compatibility with the chosen Nextcloud release and record the decision in the design. |
| Database and cache design | An external database and Redis are required for a multi-pod setup, and the chosen engine must match the supported versions for the Nextcloud release in use. | Pick a supported database engine version from the Nextcloud 35 system requirements or the release you deploy, and confirm it with the upgrade plan. |
| Compliance evidence required | Evidence for access reviews, change records, backup restore tests, logging and encryption adds documentation and sampling work. DeployOpen prepares evidence; auditors and certification bodies issue any assurance. | Define the control list and evidence owners at scope stage. Ask which evidence is generated automatically by logs and pipelines. |
| Customization of apps and theming | Custom themes, non-store apps or patched code must be rebuilt and retested for every major upgrade, which adds recurring work beyond the initial build. | Standardize on a minimal app set, use supported theming settings, and require an app compatibility check before each upgrade. |
| Upgrade cadence and staging | Nextcloud releases a new major version roughly every four months and requires one major version at a time, so each upgrade is a repeated cost over the life of the system. | Use a staging cluster to rehearse each upgrade with a restored production backup, and agree a support or retainer scope for upgrades in the quote. |
Testing scale-out, background jobs and failure behavior before go-live
Before go-live, the team should prove that the Nextcloud Kubernetes deployment installs cleanly, serves users consistently across pods, and fails in ways that lose no data and expose no sessions. Start with the basics: the instance should complete installation, the admin overview should show no outstanding setup warnings, and the health endpoint behind the readiness probe should return success from every app pod. A failed result here usually points to a missing database or Redis connection, a wrong trusted domain, or a data directory that the pods do not share. Fix those before running any scale-out test, because every later result depends on them. Next, test scale-out with real state. Create a file and a public share from a client session, then delete one app pod while the session is active and confirm that the same user keeps working, the file is still visible, and the share link resolves. Repeat the check with a second pod deleted and a new pod scheduled. Sessions should live in Redis, not in pod memory, and every pod should mount the same primary storage. If a session drops or a file appears on only one pod, check whether the session store and the shared storage are configured as the design requires, and whether the ingress is pinning clients to a single pod through affinity settings you did not intend. Concurrency and background work come next. Open the same document or file from two clients, edit both, and confirm that the second save is refused or conflicts are reported rather than silently overwritten. Nextcloud uses transactional file locking backed by Redis in a clustered setup, so verify the locking backend is reachable from every pod and that a lock is released when a client disconnects. For cron, confirm the background job mode is set to the cron method, that the CronJob or sidecar runs on the schedule you chose, and that the Nextcloud background jobs page shows recent successful runs. A duplicate run is a failure. Check that only one scheduler exists and that job runs do not overlap. Then test failure behavior deliberately. Restart or fail over the database while a client uploads a large file, and confirm the upload either completes or fails with a clear error that the client can retry, with no corrupted file left in the file cache. Evict an app pod during an upload in the same way. Restore a recent backup into a separate namespace with its own database and storage, log in as a test user, and compare file counts and a sample of checksums with the source. Finally, check the reverse proxy: the trusted proxies list must include the ingress address range, the access log should record real client addresses rather than the ingress IP, and generated share and login links must use HTTPS. Wrong client IPs or HTTP links mean the forwarded headers or overwrite settings need correction before users arrive. Write down the expected result and the observed result for each test, and tie each failure to a named owner and a retest. Ask the implementation partner, or your own team, to hand over the test scripts and evidence so the checks can be repeated after every Helm upgrade and every major version change.
Securing secrets, pod permissions and admin paths in the cluster
A Nextcloud pod is only as secure as the cluster it runs in. These controls cover how credentials reach the pods, what each container is allowed to do, which network paths exist, who can reach administration, and which image versions run. Application-level hardening is covered on the security hardening page, and encryption choices depend on the storage design.
Keep credentials out of Git
Database credentials, the Nextcloud admin password, Redis passwords and object storage keys should reach pods through Kubernetes secrets or an external secret manager synchronized into the cluster. Chart values committed to Git should reference secret names only. Confirm with your team how secrets are rotated, who can read them in each namespace, and whether the Helm release history stores any values in plain text.
Restrict pod security context
Set a non-root user, drop unneeded Linux capabilities, block privilege escalation and enable a read-only root filesystem where the image allows it. Nextcloud writes to its data and configuration paths, so writable volumes must be mounted explicitly for those locations. Test the chart with the exact image you plan to run, because required writable paths differ between image builds and versions.
Limit network policies to required endpoints
Define network policies so that only the ingress controller reaches the Nextcloud pods, and those pods reach only the database, Redis and storage endpoints they need. Deny other egress by default, then add explicit rules for DNS and any identity provider or mail server. Verify the policies with connection tests from a debug pod, since a missing rule often fails silently as a timeout.
Restrict occ and admin UI access
The occ command interface and the administration UI give full control over users, apps and configuration. Limit exec access to the Nextcloud pods through Kubernetes role-based access control to named platform administrators, and map application admin rights to a defined group rather than individual accounts. Record who runs occ commands and review kubectl exec audit logs as part of change management.
Pin image digests and mirror images
Reference the Nextcloud image, and any sidecar images, by immutable digest rather than a floating tag, and mirror approved images into a registry your organization controls. Mirroring lets you scan, sign or verify images before deployment and keeps rollouts working if a public registry is unavailable. Agree in advance who approves a new digest and how it is tied to the supported Nextcloud major version in your upgrade plan.
What to monitor, back up, upgrade and document after go-live
The operating model for a Nextcloud Kubernetes deployment starts with a short list of signals that tell you the platform is healthy before users notice a problem. Pod restarts on the app deployment are the first one to watch, because repeated restarts usually point to a failing liveness check, memory pressure or a bad configuration change. Alongside them, track whether the background cron job runs on schedule, since file scans, notifications, trash cleanup and share expiry all depend on it. Watch database connection counts against the limit your database allows, Redis memory usage and eviction behavior, and free capacity on the data volume or object storage bucket. Certificate expiry belongs on the same dashboard, because an expired certificate at the ingress stops desktop and mobile clients from syncing without any change in Nextcloud itself.
Backups need one rule above all others: the database, the data directory or object storage bucket, and the configuration and secrets must be captured as a set from the same point in time. Copying files while users are writing produces a restore that looks complete but contains database rows pointing at missing files or the reverse. Put the instance into maintenance mode for the copy window, or use a method your team has tested that quiesces writes, then take the database dump, the data copy or bucket snapshot, and the config.php contents together with the Kubernetes secrets and sealed values they depend on. Confirm with your business owners how long backups must be kept, how many restore points they need, and the maximum time the service may be unavailable during recovery. Those targets drive the backup frequency and the storage design, and they should be written down before go-live rather than discovered during an incident.
Upgrades are where many Kubernetes deployments drift away from support. Nextcloud publishes a new major version every four months and supports each one for a year through monthly maintenance releases, so a platform that is not reviewed regularly will fall off the supported list. Assign one owner to track the Nextcloud maintenance and release schedule, and plan each move one major version at a time. Nextcloud does not allow skipping major releases, so a platform several versions behind needs intermediate upgrades. Before every upgrade, take a verified backup, disable third-party apps, and re-enable each one only after its maintainer confirms compatibility with the target release. Test the same chart version and image in a non-production namespace first, using a copy of production data where your data rules allow it.
Keep an app inventory as a controlled list, not a memory. For each enabled app, record the version, the source, the maintainer, the Nextcloud major versions it declares compatibility with, whether it changes the database schema, and who approved it. Apps that are not in the inventory should not be enabled in production. This list is the first input to every upgrade plan and the main reason an upgrade stalls, so keep it current after each change.
Documentation is what allows a different engineer to restore the service at 2 a.m. Record the Helm chart version and the exact container image digests in use, not only tags, because tags can move. Store the values files in version control with secrets referenced rather than embedded, and keep runbooks for scaling, rotating credentials, handling cron failures, recovering from a failed upgrade and performing a restore. Each restore step should be tested on a schedule, with the date, the restore point used and the time taken recorded. Ask your implementation partner to deliver these artifacts as part of the handover, and confirm who in your organization is responsible for keeping them accurate after the project closes.
Questions teams ask before running Nextcloud on Kubernetes
Can our in-house team build a Nextcloud deployment on Kubernetes without outside help?
Yes, many platform teams can, provided they already run Kubernetes in production and have people who know PHP applications, relational databases and identity systems. The harder part is rarely the Helm install. It is the surrounding design: an external database, Redis for locking and caching, shared or object storage that every app pod can reach, background jobs that run outside the web pods, and a tested backup and restore path. Ask whether your team has done this work before and whether it has an owner for the first year. Outside help usually makes sense when the timeline is short, the team is stretched, or the environment has unusual constraints such as air-gapped networks or strict data residency.
What does our side need to provide for a Nextcloud Kubernetes project?
Plan to provide five things before work starts:
- Cluster access: a namespace or cluster with rights to create workloads, secrets, ingress and persistent volume claims, plus the network paths to the database, identity provider and storage.
- Storage: a decision on primary file storage, such as a shared filesystem or S3-compatible object storage, and capacity for backups.
- Database: a supported MariaDB or PostgreSQL service with credentials and a backup policy.
- Identity: access to LDAP, Active Directory, OpenID Connect or SAML settings, if users will sign in with them.
- A named owner: one person who approves design choices, accepts test results and owns the environment after handover.
Missing any of these usually moves time into discovery and rework, so confirm each item in the scoping conversation.
What drives the duration of a Nextcloud Kubernetes deployment?
Duration depends on scope and on how quickly decisions are made. The main drivers are the number of environments (for example, a test cluster plus production), whether the database and storage are new or existing, how many identity sources must integrate, whether Nextcloud Office or Talk are included, the scope of migration or data import, and how much backup and restore testing is required. Client rollout and user training add time when they are in scope. A fixed-scope agreement sets out these items in writing so that the timeline reflects agreed work rather than assumptions. Ask for the timeline to be tied to named milestones and to the decisions your side must make.
How is a fixed-scope quote for Nextcloud on Kubernetes built?
A fixed-scope quote follows from a written scope, not from a price list. DeployOpen does not publish prices. The scope usually lists the deployment method, the Kubernetes objects and cluster assumptions, the database and storage design, identity integration, backup and restore testing, documentation, handover sessions and any apps or integrations. Each item should state what is delivered and what the client must provide. Ask the vendor to separate one-time work (design, build, testing, handover) from recurring costs (support, upgrades, infrastructure, licenses). Compare quotes on the same scope, since a lower figure often means fewer deliverables or more assumptions on your side.
Does buying a Nextcloud Enterprise subscription change the Kubernetes design?
The subscription changes support and lifecycle terms more than the basic architecture. Nextcloud's pricing page lists Standard, Premium and Ultimate tiers. According to that page, Premium adds clustered instance support and a maintenance lifecycle of 5 or more years, and Ultimate adds support up to 24/7 with response times down to 1 hour. Clustering support matters for how you lay out multiple app pods, but the design principles stay the same: stateless app pods, external database, Redis and shared storage. Confirm the tier and its terms directly on the Enterprise pricing page, and confirm with Nextcloud whether your intended cluster layout is covered by the tier you choose.
Can the official All-in-One Helm chart replace a custom Nextcloud deployment?
It can fit some teams, but it is not a drop-in replacement for a custom design. Nextcloud All-in-One is the official installation method and includes a Helm chart for Kubernetes. It bundles components such as Redis and APCu caching, PostgreSQL, optional Office and Talk, BorgBackup-based backups, ClamAV and full-text search. That bundle is useful when you want a standard layout. A custom deployment makes sense when you must use an existing managed database, a corporate object store, your own ingress and certificate process, or specific network and logging controls. Compare the two against your requirements list and confirm which bundled components you would keep, change or disable.
Who owns Nextcloud upgrades after handover?
Ownership should be written into the handover before the project closes. Nextcloud publishes a new major version every four months and supports each for one year, so upgrades are routine, not occasional. Nextcloud does not allow skipping major releases, so upgrades must move one major version at a time, with a backup before each upgrade and third-party apps checked or disabled until confirmed compatible. Decide whether your team, DeployOpen under a retainer, or a mix of both will run these steps, who approves them and who tests them in a non-production environment. Ask for a written upgrade runbook as part of the deliverables.
What should we check first in a Nextcloud Kubernetes environment before go-live?
Start with the components that cause the most incidents when they are wrong. Confirm that the database version is on Nextcloud's supported list for your release, that PHP and the web server match the system requirements, and that every app pod uses the same external database, Redis and storage. Check that background jobs run outside the web requests, that file locking works across pods, and that a backup can be restored into a separate environment and tested. Verify identity logins, group mapping and deprovisioning with a small test group. Finally, confirm that the named owner can explain the upgrade and restore steps without help.
How DeployOpen scopes, builds, hands over and supports Nextcloud on Kubernetes
DeployOpen plans, implements, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Nextcloud on Kubernetes, we start from a written, fixed-scope agreement and deliver the Helm-based build, its dependencies and the runbooks your team needs to operate it after handover.
How we scope
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- The written scope names the cluster, namespaces, Helm chart version, database, Redis, and storage backend in use.
- We record which Nextcloud major version is targeted and confirm the upgrade path from any existing installation.
How we build
- We deploy stateless Nextcloud app pods and keep session state, locking and caching in external Redis.
- We connect an external database and confirm it against the database versions listed for the chosen Nextcloud release.
- We configure background jobs and test upgrade steps in a non-production environment before any production change.
How we hand over
- You receive the Helm values, manifests and configuration as code, with the version of each component recorded.
- Runbooks cover backup order, maintenance mode, one-major-at-a-time upgrades and app compatibility checks.
- Restore tests and verification steps are documented so your team can repeat them without DeployOpen present.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer agreed separately from the build.
- Support scope, response expectations and who performs each upgrade are written down before the retainer starts.
- Where you need vendor-backed Enterprise maintenance or clustering support, we will confirm which party provides it.
