Replace Bitnami PostgreSQL and Redis charts in Gitea application

[adamancini]

Summary

The Gitea application depends on four Bitnami Helm charts for its database and cache backends. These must be replaced before Bitnami's transition to a paid subscription model (September 29, 2025).

Current Bitnami Dependencies

Helm Chart Dependencies (all conditional)

Chart	Version	Repository	Condition
postgresql	15.5.20	oci://registry-1.docker.io/bitnamicharts	postgresql.enabled
postgresql-ha	14.2.16	oci://registry-1.docker.io/bitnamicharts	postgresql-ha.enabled
redis	19.6.4	oci://registry-1.docker.io/bitnamicharts	redis.enabled
redis-cluster	10.3.0	oci://registry-1.docker.io/bitnamicharts	redis-cluster.enabled

Bitnami Container Image

Image	Tag	Usage
bitnami/kubectl	1.33.4-debian-12-r437	Admin/utility operations

Affected Files

• applications/gitea/charts/gitea/Chart.yaml - all 4 chart dependencies
• applications/gitea/charts/gitea/Chart.lock - lock file
• applications/gitea/charts/gitea/values.yaml - configuration for all backends
• Any KOTS manifests referencing these values

Recommended Replacements

PostgreSQL: CloudNativePG (CNPG)

CloudNativePG replaces both postgresql and postgresql-ha:

• Already used in storagebox and mlflow applications in this repo -- establishes a consistent pattern
• Provides HA natively via the operator (replaces the need for separate postgresql and postgresql-ha charts)
• CNCF Sandbox project with strong community adoption
• Declarative PostgreSQL clusters via Cluster CRD
• Built-in backup, recovery, and monitoring capabilities
• Helm chart: https://cloudnative-pg.github.io/charts

Migration approach:

1. Install CNPG operator (as an EC extension or subchart dependency)
2. Replace both postgresql and postgresql-ha subcharts with a CNPG Cluster CR template
3. Update Gitea's database connection configuration to point to the CNPG-managed PostgreSQL service

Redis/Cache: DragonflyDB Operator or Community Alternative

Option A: DragonflyDB (recommended)

• Drop-in Redis replacement with 240+ Redis commands supported
• Multi-threaded architecture -- up to 25x throughput vs Redis
• Kubernetes operator actively maintained (dragonfly-operator)
• Replaces both redis and redis-cluster with a single deployment
• Simpler operations than Redis Cluster

Option B: OpsTree Redis Operator

• Supports standalone, cluster, replication, and sentinel modes
• Listed on OperatorHub
• Built-in monitoring via redis-exporter
• Stays with traditional Redis if API compatibility is a concern

Option C: Community Valkey chart

• Source a non-Bitnami Valkey Helm chart
• Valkey is the Linux Foundation fork of Redis (post-license change)
• Lowest migration effort but may face chart availability issues

Container Image Replacement

Current	Replacement
bitnami/kubectl:1.33.4-debian-12-r437	registry.k8s.io/kubectl:v1.33.4 (official)

Migration Considerations

Upstream Gitea Chart

This is the upstream Gitea Helm chart (maintained by Gitea authors). The Bitnami dependencies are part of the upstream chart itself. Options:

1. Fork and modify - Fork the Gitea chart and replace dependencies (more maintenance burden)
2. Override with operators - Disable all Bitnami subcharts (postgresql.enabled=false, redis.enabled=false, etc.) and deploy operators separately, pointing Gitea at operator-managed services
3. Wait for upstream - Check if the Gitea chart maintainers are planning their own migration

Option 2 (disable subcharts + operators) is likely the cleanest approach and aligns with how storagebox and mlflow already handle PostgreSQL.

Conditional Dependencies

The chart supports multiple backend options. The replacement should maintain flexibility:

• PostgreSQL OR PostgreSQL-HA → CNPG (inherently HA, single replacement)
• Redis OR Redis-Cluster → DragonflyDB or Redis Operator (single replacement)

Scope of Work

1. Evaluate upstream Gitea chart's roadmap for Bitnami replacement
2. Add CNPG operator installation (EC extension or dependency)
3. Create PostgreSQL Cluster CR template for Gitea's database
4. Add DragonflyDB operator or Redis operator installation
5. Create cache backend CR template
6. Disable Bitnami subcharts in values
7. Update Gitea's externalDatabase and externalCache configuration
8. Replace bitnami/kubectl image reference
9. Update documentation

[adamancini]

Update: Upstream Gitea chart v11 migrated away from Bitnami

The upstream Gitea Helm chart v11 release includes migration away from Bitnami dependencies. Updating to the upstream v11 chart may handle the PostgreSQL and Redis replacements.

This should be investigated before doing a custom migration -- the upstream may have already solved this problem.