Nextcloud Helm Chart: Deploy & Manage on Kubernetes
Complete guide to deploying Nextcloud on Kubernetes with the official Helm chart. Covers storage, database, ingress, TLS, cron jobs, and upgrades. Learn when to use Helm vs managed hosting.
- Official Nextcloud Helm chart (v9.4.1, Nextcloud v35.0.2) requires Kubernetes, persistent storage, and an ingress controller
- Deployment takes 3-5 steps: add repository, configure values.yaml, helm install, set up cron jobs, then manage upgrades via helm
- Operational burden includes monitoring, patching, backups, certificate management, and cost optimization; requires DevOps experience
- Self-hosting vs managed: choose Helm if you run Kubernetes in production; choose managed if Kubernetes is a distraction
Nextcloud on Kubernetes requires careful orchestration of storage, databases, networking, and ingress. The official Nextcloud Helm chart (529 GitHub stars) handles this complexity by templating deployment manifests into a reusable configuration. This guide shows you how to deploy it step-by-step, then helps you decide whether self-hosting via Helm is the right choice for your team.
What Is Nextcloud on Kubernetes? Why Use Helm?
Nextcloud is a file sync and collaboration platform similar to Dropbox or Google Drive, but open-source and self-hosted. Kubernetes is a container orchestration platform that automates deployment, scaling, and management of containerized workloads. Helm is the package manager for Kubernetes, which lets you define all the resources needed for Nextcloud (pods, persistent volumes, services, ingress) in a single values.yaml configuration file instead of writing dozens of raw YAML manifests by hand.
The official Nextcloud Helm chart does the heavy lifting. It abstracts the complexity of setting up Nextcloud alongside a PostgreSQL or MySQL database, configuring Redis for caching, managing persistent storage for file uploads, and exposing Nextcloud via an Ingress controller with TLS termination. You describe your needs in values.yaml, and the chart generates the manifests.
This is worth doing if you already run Kubernetes in production (e.g., on-premises with Rancher, or EKS/GKE/AKS in the cloud), and you want Nextcloud to coexist with your other workloads. If you do not already have Kubernetes, or if operational overhead concerns you, read the section below on when managed hosting makes more sense.
The chart is community-maintained (not by Nextcloud GmbH), actively developed (10+ releases in 2026), and licensed under AGPL-3.0. Latest version is 9.4.1, which bundles Nextcloud Server v35.0.2 (released Oct 18, 2026).
Prerequisites
Before starting, you need:
- A running Kubernetes cluster (1.19+). This can be Rancher, OpenShift, EKS, GKE, AKS, DigitalOcean Kubernetes Service, or your own on-premises cluster.
- kubectl installed and configured to access your cluster.
- Helm 3 installed on your machine.
- A storage class provisioner. Check what you have:
kubectl get storageclasses. Most cloud providers ship one; on-premises clusters might use Longhorn, NFS, or local-path provisioner. - An ingress controller running on your cluster. NGINX Ingress or Traefik are common. Check:
kubectl get ingressclasses. - (Optional but recommended) cert-manager installed for automatic TLS certificates via Let's Encrypt.
All of these are standard Kubernetes infrastructure. If you do not have them, setting them up is a project in itself. That is the operational burden we mention later.
Step 1: Add the Nextcloud Helm Repository
The official repository is hosted on GitHub Pages. Add it to Helm:
helm repo add nextcloud https://nextcloud.github.io/helm/
helm repo update
Verify the repository was added:
helm search repo nextcloud
You should see nextcloud/nextcloud in the output. This is the chart you will install.
Step 2: Create a Namespace and Configure Values
Create a dedicated Kubernetes namespace for Nextcloud to keep it isolated:
kubectl create namespace nextcloud
Now create a values.yaml file to customize the deployment. Here is a minimal production-ready example:
image:
tag: "v35.0.2"
frontend:
enabled: true
image:
tag: "v35.0.2"
nextcloud:
host: nextcloud.example.com
username: admin
password: "your-secure-password-here"
ingress:
enabled: true
className: nginx
annotations:
cert-manager.io/cluster-issuer: letsencrypt-prod
hosts:
- host: nextcloud.example.com
paths:
- path: /
pathType: Prefix
tls:
- secretName: nextcloud-tls
hosts:
- nextcloud.example.com
persistence:
enabled: true
storageClass: default
size: 100Gi
accessMode: ReadWriteOnce
postgresql:
enabled: true
auth:
username: nextcloud
password: "database-password"
database: nextcloud
redis:
enabled: true
auth:
enabled: false
resources:
requests:
memory: "512Mi"
cpu: "250m"
limits:
memory: "2Gi"
cpu: "1000m"
This configuration enables:
- PostgreSQL (bundled) as the database. For production, use an external managed PostgreSQL to avoid database restarts affecting your cluster.
- Redis for session caching and job queue.
- NGINX Ingress with automatic TLS via cert-manager and Let's Encrypt.
- 100 GB of persistent storage for Nextcloud data files.
- Resource requests and limits to keep the pod from consuming all cluster memory.
Replace nextcloud.example.com with your actual domain, and use a strong random password for both the Nextcloud admin and database.
If you want to use an external PostgreSQL database instead of the bundled one, set postgresql.enabled: false and add:
externalPostgresql:
host: your-postgres-host.rds.amazonaws.com
port: 5432
username: nextcloud_user
password: "your-postgres-password"
database: nextcloud
This is the recommended approach for production to decouple database scaling from pod restarts.
Step 3: Deploy and Verify
Install the chart into the nextcloud namespace:
helm install nextcloud nextcloud/nextcloud -f values.yaml -n nextcloud
Watch the deployment progress:
kubectl rollout status deployment/nextcloud -n nextcloud
Verify the pod is running:
kubectl get pods -n nextcloud
Check that the persistent volume claim is bound:
kubectl get pvc -n nextcloud
Check the ingress status (it may take a few minutes for the certificate to issue):
kubectl get ingress -n nextcloud
Once the certificate is ready, visit your Nextcloud domain in your browser. Log in with the admin username and password you set in values.yaml. You are now running Nextcloud on Kubernetes.
Step 4: Configure Background Tasks and Cron Jobs
Nextcloud performs background tasks like file indexing, clearing old sessions, and sending email notifications. By default, these run on-demand when a user visits Nextcloud, which slows down their experience.
Deploy a dedicated CronJob to run occ system:cron every 5 minutes:
apiVersion: batch/v1
kind: CronJob
metadata:
name: nextcloud-cron
namespace: nextcloud
spec:
schedule: "*/5 * * * *"
jobTemplate:
spec:
template:
spec:
serviceAccountName: nextcloud
containers:
- name: nextcloud-cron
image: nextcloud:v35.0.2-apache
command:
- sh
- -c
- exec su -s /bin/sh www-data -c "cd /var/www/html && php occ system:cron"
volumeMounts:
- name: nextcloud-data
mountPath: /var/www/html
volumes:
- name: nextcloud-data
persistentVolumeClaim:
claimName: nextcloud-nextcloud
restartPolicy: OnFailure
Apply this manifest:
kubectl apply -f cronjob.yaml -n nextcloud
Verify the CronJob is active:
kubectl get cronjobs -n nextcloud
kubectl get jobs -n nextcloud
After a few minutes, you should see completed jobs. Check the logs:
kubectl logs -l job-name=nextcloud-cron-<timestamp> -n nextcloud
This moves background task processing off the critical path, keeping user-facing requests fast.
Step 5: Upgrades and Maintenance
To upgrade Nextcloud to a newer version, update the image tag in values.yaml, then run:
helm upgrade nextcloud nextcloud/nextcloud -f values.yaml -n nextcloud
Helm performs a rolling update: the old pod is terminated, the new one is started, and traffic is re-routed. No downtime if your persistent volume supports read-write-many (most do not; read-write-once is typical, so there is brief downtime as the old pod drains and the new one starts).
To roll back a broken upgrade:
helm rollback nextcloud -n nextcloud
This reverts to the previous release. Verify the pod is running before going further.
Common issues:
- Database migration fails: If the new Nextcloud version requires a database schema change and the upgrade hangs, check the pod logs:
kubectl logs <pod-name> -n nextcloud. Run the migration manually with:kubectl exec -it nextcloud-<pod-id> -n nextcloud -- php occ db:convert-filecache-bigintor other required occ commands. - Cron jobs fail after upgrade: The CronJob image tag may be stale. Update it to match the new Nextcloud version in cronjob.yaml and re-apply.
- Storage fills up: Use
kubectl exec -it nextcloud-<pod-id> -n nextcloud -- du -sh /var/www/htmlto check disk usage. Consider increasing the PVC size or enabling automatic cleanup in Nextcloud admin settings.
For production deployments of Nextcloud, consider using managed Nextcloud hosting on Opsily. Managed hosting handles all of this: database tuning, automatic backups, certificate renewal, security patches, and scaling. You focus on Nextcloud features, not Kubernetes operations.
When to Choose Managed Nextcloud Instead
Self-hosting Nextcloud on Kubernetes works well if you already run Kubernetes and have a platform team managing it. If Kubernetes is new to you, or your team is lean, the operational burden is real.
Kubernetes clusters require:
- Monitoring and alerting (pods crash, storage fills up, database locks accumulate)
- Regular patching of the cluster itself
- Backup and disaster recovery procedures
- Certificate management (cert-manager helps, but failures still happen)
- Scaling policies and cost management (under-provisioned clusters are slow, over-provisioned ones are expensive)
For a 10-50 person company, this often means hiring a DevOps engineer or contractor. That costs USD 80k-150k per year, plus infrastructure costs.
Opsily offers managed Nextcloud hosting. You get a running Nextcloud instance with automated backups, TLS certificates, database tuning, and 99.9% uptime. No Kubernetes required. Visit Opsily's Nextcloud hosting page to compare costs and start with a free tier.
Ask yourself: Is self-hosting on Kubernetes a core competency for your team, or is it a distraction from your product?
Frequently Asked Questions
What are the prerequisites for Nextcloud Helm deployment?
You need a Kubernetes cluster (1.19+), kubectl, Helm 3, a storage class provisioner, and an ingress controller. Most cloud providers ship storage and ingress; on-premises clusters require additional setup. Check your cluster: kubectl get storageclasses and kubectl get ingressclasses.
How do I configure persistent storage for Nextcloud data?
Set persistence.enabled: true in values.yaml, specify the storageClass name, and the size (e.g., 100Gi). Kubernetes automatically creates a persistent volume claim and mounts it to the pod at /var/www/html.
How do I connect Nextcloud to an external PostgreSQL database?
Set postgresql.enabled: false in values.yaml and add externalPostgresql section with host, port, username, password, and database name. This decouples the database from the Nextcloud pod lifecycle.
How do I set up ingress and TLS with cert-manager?
Enable ingress.enabled: true, set className: nginx, add the cert-manager annotation cert-manager.io/cluster-issuer: letsencrypt-prod, and define hosts and tls sections with your domain. Cert-manager will automatically request and renew Let's Encrypt certificates.
How do I run occ commands in Kubernetes?
Use kubectl exec -it <pod-name> -n nextcloud -- su -s /bin/sh www-data -c "php occ <command>". For example, to enable an app: kubectl exec -it nextcloud-abc123 -n nextcloud -- su -s /bin/sh www-data -c "php occ app:enable deck".
What is the difference between the official Helm chart and Nextcloud AIO?
Nextcloud AIO (All-In-One) is a single container with PostgreSQL, Redis, Apache, and Nextcloud bundled. It is simpler to deploy but does not scale across multiple pods and is harder to integrate with existing Kubernetes workloads. The official Helm chart is modular and expert-oriented; it assumes you understand Kubernetes and want to manage each component separately.
How do I configure Redis for caching?
Set redis.enabled: true in values.yaml. The chart deploys Redis as a separate pod and configures Nextcloud to use it for sessions, locks, and job queue. This improves performance and stability under load.
How do I back up Nextcloud data and database?
For data files, use your storage provider's snapshot feature (AWS EBS snapshots, GCP persistent disk snapshots, or your NFS appliance). For the database, schedule regular backups: kubectl exec -it nextcloud-<pod-id> -n nextcloud -- mysqldump -u nextcloud -p nextcloud > nextcloud-backup.sql or use pg_dump if PostgreSQL. Store backups in object storage (S3, GCS, Backblaze B2). This is tedious and error-prone; managed hosting handles it automatically.
The Bottom Line
Nextcloud Helm deployment is technically feasible and gives you full control. But it requires Kubernetes expertise, ongoing maintenance, and careful operations. The official chart is mature (529 GitHub stars, active maintenance), and the Nextcloud Server itself is battle-tested (34.8K stars).
If you have a platform team and Kubernetes is already part of your infrastructure, go ahead. If Kubernetes feels like a distraction, managed Nextcloud hosting lets you skip the operations entirely and focus on using Nextcloud.