CleanStart Helm charts directly replace Bitnami charts with known differences and testing checklists for each swap. CleanStart images are 100% API-compatible with Bitnami but offer 10x smaller images, FIPS compliance, real-time vulnerability scanning, and cryptographic attestations.

Quick Compatibility Matrix

Apache: Bitnami → CleanStart

Before (Bitnami)

helm install my-apache bitnami/apache \  --set auth.username=user \  --set auth.password=password123 \  --set containerSecurityContext.enabled=true

After (CleanStart)

helm install my-apache cleanstart/apache \  --set auth.username=user \  --set auth.password=password123  # Security context already enabled by default!

Testing Checklist

Perform a Network Test with curl http://SERVICE_IP/, which should return the Apache welcome page. Verify Module Loading by running kubectl exec POD -- apachectl -M to check that mod_ssl, mod_rewrite, and mod_proxy are loaded. Test Configuration by mounting a ConfigMap with .htaccess and httpd.conf overrides and verifying it loads correctly. Compare Performance to ensure response times are faster due to the Alpine base image. Verify the Security Context by running kubectl exec POD -- id to confirm it's running as UID 65532. Test Storage by running kubectl exec POD -- ls -la /var/www/html if using persistent volumes.

Known Differences include the Base OS (Debian for Bitnami, Alpine for CleanStart, resulting in 80 percent smaller images). The UID differs (1001 for Bitnami, 65532 for CleanStart, which may affect filesystem permissions). Included modules differ (many for Bitnami, essential only for CleanStart, requiring custom module additions if needed). Package managers differ (apt for Bitnami, apk for CleanStart with different package names). Init systems differ (systemd for Bitnami, OpenRC for CleanStart, though startup behavior is identical).

PostgreSQL: Bitnami → CleanStart

Before (Bitnami)

helm install postgres bitnami/postgresql \  --set auth.username=myuser \  --set auth.password=mypassword \  --set auth.database=mydb \  --set persistence.size=10Gi

After (CleanStart)

helm install postgres cleanstart/postgresql \  --set auth.username=myuser \  --set auth.password=mypassword \  --set auth.database=mydb \  --set persistence.size=10Gi  # Literally identical interface!

Testing Checklist

Perform a Connection Test by running a test pod with psql and connecting to the database with psql -h postgres.default.svc.cluster.local -U myuser -d mydb -c "SELECT 1", which should return 1. Verify Database Functions by running CREATE TABLE, INSERT, and SELECT commands to ensure basic SQL operations work. Test Replication by checking that pods include a primary (postgres-0) and replicas (postgres-1, postgres-2), verifying WAL replication in logs. Verify Backup by checking that backup files appear in the destination (e.g., gsutil ls gs://my-backup-bucket) on the expected schedule. Test Restore by performing a pg_dump backup and verifying that standard psql restore commands work. Verify Security by running kubectl exec postgres-0 -- id, which should return uid=65532(appuser) gid=65532(appuser).

values.yaml Differences

# Bitnami (optional security config)securityContext:  enabled: true  runAsNonRoot: true  runAsUser: 1001 # CleanStart (always secure, not configurable)# Security context hardcoded to:# - runAsNonRoot: true# - runAsUser: 65532# - capabilities: dropped ALL# - readOnlyRootFilesystem: true

Result: You can DELETE all securityContext blocks from Bitnami values — CleanStart handles it automatically.

MySQL: Bitnami → CleanStart

Before (Bitnami)

helm install mysql bitnami/mysql \  --set auth.rootPassword=rootpass \  --set auth.database=myapp \  --set auth.username=appuser \  --set auth.password=apppass

After (CleanStart)

helm install mysql cleanstart/mysql \  --set auth.rootPassword=rootpass \  --set auth.database=myapp \  --set auth.username=appuser \  --set auth.password=apppass

Testing Checklist

Perform a Connection Test using the mysql client to connect to the database running mysql -h mysql.default.svc.cluster.local -u appuser -papppass myapp -e "SELECT 1". Test SQL Commands by running mysql -u root -prootpass -e "SHOW DATABASES" to verify database operations. Verify Replication by checking that pods show mysql-0 as the primary and mysql-1, mysql-2 as secondaries. Verify Binary Logging by running mysql -u root -prootpass -e "SHOW MASTER STATUS" to confirm replication is enabled.

Known Differences

Redis: Bitnami → CleanStart

Before (Bitnami)

helm install redis bitnami/redis \  --set auth.enabled=true \  --set auth.password=redispass \  --set replica.replicaCount=2

After (CleanStart)

helm install redis cleanstart/redis \  --set auth.enabled=true \  --set auth.password=redispass \  --set replica.replicaCount=2

Testing Checklist

Perform a Connection Test using redis-cli with redis-cli -h redis-master.default.svc.cluster.local -a redispass PING, which should return PONG. Test SET/GET operations by setting a key, retrieving it, and verifying the value. Verify Replication by running redis-cli -a redispass INFO replication and checking that the master shows the correct number of connected slaves. Verify Sentinel health (if enabled) by running redis-cli -p 26379 SENTINEL masters. Check Persistence by verifying that RDB snapshot files exist in /data with ls -la /data.

Known Differences

Kafka: Bitnami → CleanStart

Before (Bitnami)

helm install kafka bitnami/kafka \  --set broker.replicaCount=3 \  --set zookeeper.enabled=true \  --set persistence.size=10Gi

After (CleanStart)

helm install kafka cleanstart/kafka \  --set broker.replicaCount=3 \  --set zookeeper.enabled=true \  --set persistence.size=10Gi

Testing Checklist

Check Broker Health by examining logs for "started" message indicating successful broker initialization. Create a Test Topic with 3 partitions and replication factor of 2. Test Producer/Consumer functionality by producing messages to the topic and consuming them from the beginning. Verify Broker Replication by describing the topic and confirming that all brokers are in the In-Sync Replicas (ISR) list. Verify Zookeeper Health by running the broker API versions command to confirm the Zookeeper connection is working.

Template values.yaml Comparison

Identical Between Bitnami and CleanStart

# These fields work identicallyauth:  username: myuser  password: mypassword persistence:  enabled: true  size: 10Gi  storageClassName: default replica:  replicaCount: 2  persistence:    size: 10Gi service:  type: ClusterIP  port: 5432 metrics:  enabled: true

Fields to REMOVE (CleanStart Handles Automatically)

Remove the following fields from Bitnami values since CleanStart handles them automatically: securityContext fields (enabled, runAsNonRoot, runAsUser) since CleanStart always has secure context enabled with non-root running as UID 65532. podSecurityPolicy settings since CleanStart is compliant by default. containerSecurityContext configuration since it's always enabled.

Fields That Might Need Adjustment

# Check these - may differ by application:resources:  # CleanStart defaults are tighter - adjust if needed  requests:    memory: "256Mi"    # May be too low for production    cpu: "100m" readinessProbe:  # Defaults differ - test and verify  initialDelaySeconds: 10  periodSeconds: 5

Migration Playbook

Step 1: Backup Current Data by exporting all resources in the namespace and creating a database backup with the stateful service's backup command.

Step 2: Uninstall Bitnami Release using helm uninstall RELEASE_NAME -n NAMESPACE --keep-history to preserve the release history for potential rollback.

Step 3: Keep the PVC by ensuring the Persistent Volume Claim remains after helm uninstall so your data is preserved.

Step 4: Install CleanStart Chart using the values from the Bitnami installation but specifying the existing PVC claim with --set persistence.existingClaim=EXISTING_PVC_NAME.

Step 5: Verify Data Integrity by checking logs and running verification commands to ensure the data has been correctly migrated and the service is functioning properly.

Step 6: Update Clients by checking if service names changed (usually they don't) and updating any client applications if DNS names differ.

Zero-Downtime Migration (Optional)

For mission-critical services, implement a zero-downtime migration by first running parallel deployments temporarily with both Bitnami and CleanStart running simultaneously. Replicate data from the Bitnami instance to the new CleanStart instance. Switch traffic to CleanStart by patching the service selector to point to the CleanStart pods. Finally, uninstall the Bitnami release after confirming successful operation.

Rollback Procedure

If issues occur after migration, revert to the previous release using helm rollback RELEASE_NAME -n NAMESPACE. Monitor the rollback process by watching the statefulset status. Verify data integrity by running verification commands on the rolled-back pods.

Size Comparison Examples

PostgreSQL 15.2

Total Kubernetes Cluster Benefit

Storage saved: 50% (fewer large images), Network bandwidth: 60% reduction, Pull latency: 3-4x faster deployment, and Security: Real-time vulnerability updates vs. annual Bitnami patches.

Reference

For detailed Bitnami Helm chart value mappings and migration configuration options, see Helm Chart Reference.