Configuration Profiles¶
Overview¶
Profiles provide baseline configurations for different deployment scenarios, offering sane defaults for resources, probes, persistence, and other settings. This allows you to quickly deploy Nextcloud instances optimized for specific use cases without manually configuring every detail.
How Profiles Work¶
Profiles use a four-layer configuration system (last wins):
- Built-in profile defaults (lowest priority) — Baseline from
production,testing, ordevelopment - NextcloudProfile CRD — Custom profile that overrides or extends built-in profiles
- Spec fields (medium priority) — Your database, redis, s3, admin, mail configurations
- Helm values (highest priority) —
helm.valuesoverrides everything
This layering allows you to:
- Start with sensible defaults from a profile
- Customize via NextcloudProfile CRDs for organization standards
- Add your infrastructure specifics (database credentials, etc.)
- Fine-tune with custom Helm values when needed
Available Profiles¶
production¶
Purpose: Production-ready configuration with high availability, security hardening, and resource limits.
Key Features:
- Replicas: 2 pods for high availability
- Resources: 500m-2000m CPU, 512Mi-2Gi memory
- Persistence: 20Gi storage
- Probes: All probes enabled with production-safe timeouts
- Database: External database required (internal disabled)
- PHP: Optimized with opcache settings (512M memory limit)
- Security: Pod security contexts and fsGroup set
- Strategy: RollingUpdate with zero downtime
Example:
apiVersion: k8s.bnerd.com/v1alpha1
kind: NextcloudInstance
metadata:
name: nextcloud-prod
spec:
profile: production
database:
type: postgresql
credentialsSecret: db-creds
testing¶
Purpose: Testing and staging environments with moderate resources.
Key Features:
- Replicas: 1 pod
- Resources: 250m-1000m CPU, 256Mi-1Gi memory
- Persistence: 10Gi storage
- Database: External database by default (internal disabled)
Example:
apiVersion: k8s.bnerd.com/v1alpha1
kind: NextcloudInstance
metadata:
name: nextcloud-staging
spec:
profile: testing
database:
type: postgresql
credentialsSecret: staging-db-creds
development¶
Purpose: Local development with minimal resources and fast startup.
Key Features:
- Replicas: 1 pod
- Resources: 100m-500m CPU, 128Mi-512Mi memory
- Persistence: 5Gi storage
- Probes: Liveness disabled, minimal readiness (fast startup)
- Database: Internal SQLite enabled (no external database needed)
Example:
apiVersion: k8s.bnerd.com/v1alpha1
kind: NextcloudInstance
metadata:
name: nextcloud-dev
spec:
profile: development
# That's it! Uses SQLite, minimal resources, default credentials
Profile Comparison¶
| Setting | production | testing | development |
|---|---|---|---|
| Replicas | 2 | 1 | 1 |
| CPU Request | 500m | 250m | 100m |
| CPU Limit | 2000m | 1000m | 500m |
| Memory Request | 512Mi | 256Mi | 128Mi |
| Memory Limit | 2Gi | 1Gi | 512Mi |
| Storage | 20Gi | 10Gi | 5Gi |
| Liveness Probe | 120s delay | 60s delay | Disabled |
| Readiness Probe | 60s delay | 30s delay | 10s delay |
| Startup Probe | 30s delay | 10s delay | Disabled |
| Internal DB | No | No | Yes (SQLite) |
| PHP Memory | 512M | 256M | 128M |
| Security Context | Yes | No | No |
| Opcache | Yes | No | No |
Configuration Layering Examples¶
Profile + Database Override¶
spec:
profile: production # Get production defaults
database: # Override to use your database
type: postgresql
credentialsSecret: my-db-creds
Result: Production resource limits and probes + your PostgreSQL database
Profile + Helm Values Override¶
spec:
profile: production
database:
credentialsSecret: my-db-creds
helm:
values:
replicaCount: 5 # Override profile's 2 replicas
resources:
requests:
cpu: "1000m"
memory: "1Gi"
limits:
cpu: "4000m"
memory: "4Gi"
Result: Custom replicas and resources, but keeps production probes and PHP configs
Custom Profiles (NextcloudProfile CRD)¶
The operator supports custom profiles via the NextcloudProfile CRD, which is cluster-scoped. Custom profiles take precedence over built-in profiles of the same name.
Creating a Custom Profile¶
apiVersion: k8s.bnerd.com/v1alpha1
kind: NextcloudProfile
metadata:
name: enterprise
spec:
description: "Enterprise profile with HA and backups"
defaults:
replicaCount: 3
resources:
requests:
cpu: "1000m"
memory: "1Gi"
limits:
cpu: "4000m"
memory: "4Gi"
persistence:
enabled: true
size: "200Gi"
storageClass: "fast-ssd"
internalDatabase:
enabled: false
helm:
version: "5.0.0"
Using a Custom Profile¶
apiVersion: k8s.bnerd.com/v1alpha1
kind: NextcloudInstance
metadata:
name: my-instance
spec:
profile: enterprise
database:
type: postgresql
credentialsSecret: db-creds
Overriding Built-in Profiles¶
Create a NextcloudProfile with the same name as a built-in profile:
apiVersion: k8s.bnerd.com/v1alpha1
kind: NextcloudProfile
metadata:
name: production # Overrides built-in 'production'
spec:
description: "Our customized production profile"
defaults:
replicaCount: 3 # Different from built-in (2)
Profile Management Notes¶
- Updates don't auto-apply: Existing instances must be reconciled (e.g., update a spec field or add the
k8s.bnerd.com/reconcileannotation) to pick up profile changes. - Don't delete in-use profiles: Instances will fail to reconcile until the profile is recreated or the profile field is changed.
- Validation: Invalid Helm values in profiles will cause HelmRelease failures. Test profiles in a non-production environment first.
Troubleshooting¶
Profile Not Applied¶
Symptom: Resources don't match expected profile values
Check:
- Verify profile field:
kubectl get nci <name> -o yaml | grep profile - Check for
helm.valuesoverrides that might be taking precedence - Look at generated HelmRelease:
kubectl get helmrelease <name> -o yaml
Profile Conflicts with Helm Values¶
Helm values have highest priority and will override profile defaults:
spec:
profile: production # Sets replicaCount: 2
helm:
values:
replicaCount: 1 # This wins! Final result: 1 replica
Invalid Profile Name¶
Use one of: production, testing, development (case-sensitive, lowercase), or the name of a custom NextcloudProfile CRD.