Migrating from Helm to Codiac

Simplify application deployments while optionally keeping Helm chart compatibility. Codiac is built for platform teams who want Kubernetes to be repeatable and boring—so they can focus on architecture, security, and scale.

Developers deploy with guided CLI commands or Web UI clicks. No values.yaml management. No template debugging. Platform teams still have full access to Helm when needed—but no longer have to use it for day-to-day operations.

Interactive CLI

The Codiac CLI guides you through each command interactively. You don't need to memorize flags—just run the command and answer the prompts.

Why Migrate from Helm?

Helm challenges Codiac solves:

Values.yaml complexity: Managing multiple values.yaml files across environments is cumbersome. Codiac uses dynamic configuration.
Templating confusion: Helm templates (Go templates) are hard to debug. Codiac eliminates templating for most use cases.
No system versioning: Helm tracks releases per chart, not entire system state. Codiac provides complete system snapshots.
Limited rollback: Helm rollback reverts one release. Codiac can rollback entire infrastructure.
Manual upgrades: helm upgrade requires careful values management. Codiac simplifies updates.

When to migrate:

✅ You're tired of debugging Helm template errors
✅ You want system-wide versioning (not per-chart)
✅ You need faster deployments without template rendering overhead
✅ You want to simplify deployments entirely

When to keep Helm:

❌ You're deploying third-party Helm charts exclusively
❌ Your team has extensive custom Helm charts
❌ You prefer templating-based configuration

Good news: Codiac can deploy Helm charts as assets, so you don't have to choose!

Key Differences

Feature	Helm	Codiac
Deployment unit	Chart (templated YAML)	Asset (container or chart)
Configuration	values.yaml files	Dynamic config (CLI/API)
Templating	Go templates (`{{ .Values.foo }}`)	No templating (or use Helm charts)
Versioning	Per-chart releases	System-wide snapshots
Rollback	`helm rollback` (single chart)	`codiac snapshot deploy` (entire system)
Multi-environment	Multiple values files	Hierarchical configuration
Package management	Chart repositories	Asset + kit libraries
Upgrade	`helm upgrade` + values	`codiac asset deploy` (select new version)

Migration Strategies

Strategy 1: Full Migration (No More Helm)

Best for: Custom applications you control.

Migrate your Helm chart to Codiac assets:

Before (Helm):

# Chart.yaml
name: my-web-app
version: 1.0.0

# values.yaml
replicaCount: 3
image:
  repository: myregistry/my-web-app
  tag: "1.0.0"
service:
  port: 8080
ingress:
  enabled: true
  host: app.mycompany.com
env:
  DATABASE_URL: postgres://prod-db:5432/app

After (Codiac - interactive CLI):

# Create asset from your container image
codiac asset create
# CLI guides you through registry, image, port configuration

# Deploy the asset
codiac asset deploy
# CLI prompts for asset, version, and target cabinet

# Configure environment variables
codiac config set
# CLI prompts for scope, key, and value

# Map your domain (automatic HTTPS)
codiac host map
# CLI guides you through domain configuration

The CLI guides you through each step-no flags to memorize.

Strategy 2: Hybrid (Deploy Helm Charts via Codiac)

Best for: Using third-party charts (PostgreSQL, Redis, etc.)

Deploy Helm charts as Codiac assets:

Before (Helm):

helm repo add bitnami https://charts.bitnami.com/bitnami
helm install postgres bitnami/postgresql \
  --version 12.1.0 \
  --set auth.username=admin \
  --set auth.database=myapp \
  --set primary.persistence.size=500Gi

After (Codiac):

codiac asset create
# Select "Helm chart" when prompted
# CLI guides you through chart repository, version, and values

Or continue using Helm directly and let Codiac manage the overall system versioning through snapshots.

Benefits:

System-wide versioning (Helm chart + other assets in one snapshot)
Unified management (Codiac CLI for everything)
Still use Helm charts when needed

Prerequisites (Get These Ready First)

Before you start, make sure you have:

Credential	Why You Need It
Cloud provider admin access	Create clusters, assign IPs, configure networking
Container registry credentials	Pull images (ACR, ECR, Docker Hub, etc.)
Helm repo access	If using private Helm repositories
DNS control	Point subdomain to cluster ingress

With these ready, you eliminate the back-and-forth that typically delays migrations.

Migration Process (Full Migration)

Step 1: Analyze Helm Chart (15 minutes)

1. List Helm releases:

helm list -A

2. Export current values:

helm get values my-web-app -n production > values-backup.yaml

3. Map Helm values to Codiac config:

Helm values.yaml	Codiac equivalent
`replicaCount: 3`	Scaling configured in web UI
`image.repository` + `image.tag`	Selected during `codiac asset create`
`service.port`	Configured during asset creation
`ingress.host`	`codiac host map`
`env.KEY`	`codiac config set`
`resources.requests.cpu`	Configured in web UI

Step 2: Deploy with Codiac (30 minutes)

Example: Migrating a Helm-deployed web app

Current Helm setup:

helm install my-web-app ./my-chart \
  --namespace production \
  --values prod-values.yaml

Codiac equivalent:

# 1. Create cabinet
codiac cabinet create
# CLI prompts for cabinet name and environment

# 2. Create and deploy asset
codiac asset create
# CLI guides you through registry, image, port configuration

codiac asset deploy
# CLI prompts for asset, version, and cabinet

# 3. Add configuration
codiac config set
# CLI prompts for scope, key, and value

# 4. Expose via ingress
codiac host map
# CLI guides you through domain configuration

Step 3: Migrate Multi-Environment Values

Helm approach (multiple values files):

charts/my-web-app/
├── Chart.yaml
├── templates/
│   ├── deployment.yaml
│   ├── service.yaml
│   └── ingress.yaml
├── values.yaml (defaults)
├── values-prod.yaml (production overrides)
├── values-staging.yaml (staging overrides)
└── values-dev.yaml (dev overrides)

Codiac approach:

# Deploy same asset to all environments
codiac asset deploy
# Select my-web-app and production cabinet

codiac asset deploy
# Select my-web-app and staging cabinet

codiac asset deploy
# Select my-web-app and development cabinet

# Environment-specific configuration
codiac config set
# Select environment scope → prod → DATABASE_URL → postgres://prod-db

codiac config set
# Select environment scope → staging → DATABASE_URL → postgres://staging-db

# Cabinet-specific overrides configured similarly

Result:

One deployment command
Clear configuration hierarchy
No values file duplication

Migrating Common Helm Patterns

Pattern 1: Upgrading Release

Helm:

helm upgrade my-web-app ./my-chart \
  --namespace production \
  --values prod-values.yaml \
  --set image.tag=1.1.0

Codiac:

codiac asset deploy
# Select my-web-app, version 1.1.0, and production cabinet

Pattern 2: Rolling Back

Helm:

# View history
helm history my-web-app -n production

# Rollback to revision
helm rollback my-web-app 3 -n production

Codiac:

# View snapshots
codiac snapshot list

# Rollback entire system
codiac snapshot deploy
# CLI prompts for snapshot version and target cabinet

Pattern 3: Managing Secrets

Helm (values.yaml):

secrets:
  apiKey: "abc123"  # Bad: secrets in values files

Helm (with secrets management):

helm install my-app ./chart \
  --set secrets.apiKey=$(kubectl get secret prod-api-key -o jsonpath='{.data.key}' | base64 -d)

Codiac:

Store secrets in your cloud provider's secret manager (AWS Secrets Manager, Azure Key Vault, or GCP Secret Manager). Reference them in your application using the cloud provider's SDK or Kubernetes CSI Secrets Store Driver.

Pattern 4: Conditional Resources

Helm (templates/ingress.yaml):

{{- if .Values.ingress.enabled }}
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: {{ include "my-chart.fullname" . }}
spec:
  rules:
  - host: {{ .Values.ingress.host }}
    ...
{{- end }}

Codiac:

# Ingress created automatically when hostname mapped
codiac host map
# CLI prompts for hostname and target asset

# Or skip ingress (don't run host map command)

Helm Chart Compatibility

Continue using Helm charts with Codiac management:

Deploying Third-Party Charts

Create assets from Helm charts using the interactive CLI:

codiac asset create
# Select "Helm chart" when prompted
# CLI guides you through:
# - Chart repository (e.g., bitnami)
# - Chart name (e.g., postgresql)
# - Version selection
# - Values configuration

Then deploy:

codiac asset deploy
# Select the Helm chart asset and target cabinet

Supported charts include: PostgreSQL, Redis, NGINX Ingress Controller, and any chart from configured Helm repositories.

Real-World Migration Timeline

Most platform migrations take months. Codiac is different. Helm charts can be deployed as-is through Codiac, or you can simplify to container assets.

Sample Timeline: Per Chart

Chart Complexity	Time
Simple chart (deployment + service)	30 min
Complex chart (multiple resources, dependencies)	1-2 hours
Third-party chart (PostgreSQL, Redis, etc.)	15 min (deploy as Helm asset)

Migration by Team Size

Team Size	Timeline	Notes
< 5 charts	1 day	Single session
10 charts	3-5 days	Phased rollout
20+ charts	1-2 weeks	Run Helm + Codiac in parallel

Compare this to typical platform migrations that take 3-12 months.

Keep Using Helm Charts

Codiac can deploy Helm charts as first-class assets. You don't have to rewrite your charts—just manage them through Codiac for versioning, rollback, and multi-environment configuration.

Comparison: Before & After

Before (Helm)

# Deploy to production
helm upgrade --install my-web-app ./chart \
  --namespace production \
  --values values-prod.yaml \
  --set image.tag=1.0.0

# Deploy to staging
helm upgrade --install my-web-app ./chart \
  --namespace staging \
  --values values-staging.yaml \
  --set image.tag=1.0.0

# Rollback
helm rollback my-web-app 5 -n production

# Update configuration
helm upgrade my-web-app ./chart \
  --namespace production \
  --values values-prod.yaml \
  --set env.NEW_VAR=value \
  --reuse-values

After (Codiac)

# Deploy to all environments
codiac asset deploy
# Select my-web-app, version 1.0.0, and production cabinet

codiac asset deploy
# Select my-web-app, version 1.0.0, and staging cabinet

# Rollback entire system
codiac snapshot deploy
# CLI prompts for snapshot version

# Update configuration
codiac config set
# CLI prompts for scope, key, and value

Cleaning Up Helm Releases

After successful migration:

# List Helm releases
helm list -A

# Uninstall old releases
helm uninstall my-web-app -n production

# Keep CRDs if needed
helm uninstall my-web-app -n production --keep-history

Note: Codiac-managed resources and Helm-managed resources can coexist. Remove Helm releases only after validating Codiac deployments.

Common Migration Questions

Q: Can I use my existing Helm charts?

A: Yes! Codiac can deploy Helm charts as assets. You don't have to rewrite everything.

Q: What about Helm dependencies (Chart.yaml dependencies)?

A: Codiac handles dependencies via sequential deployments. Deploy dependency charts first, then dependent charts.

Q: Do I lose Helm's templating power?

A: For custom applications, Codiac eliminates the need for templating. For complex third-party charts, continue using Helm via Codiac.

Q: How do I manage Helm repositories?

A: Add Helm repos normally (helm repo add). Codiac uses your configured Helm repos when deploying charts.

Q: Can I gradually migrate?

A: Absolutely. Migrate one chart at a time. Run Helm and Codiac side-by-side.

Getting Help

Contact Support for Helm migration consultation
Visit codiac.io to schedule hands-on migration workshop
Join Discord for community support

Last updated: 2026-01-23

Why Migrate from Helm?​

Key Differences​

Migration Strategies​

Strategy 1: Full Migration (No More Helm)​

Strategy 2: Hybrid (Deploy Helm Charts via Codiac)​

Prerequisites (Get These Ready First)​

Migration Process (Full Migration)​

Step 1: Analyze Helm Chart (15 minutes)​

Step 2: Deploy with Codiac (30 minutes)​

Step 3: Migrate Multi-Environment Values​

Migrating Common Helm Patterns​

Pattern 1: Upgrading Release​

Pattern 2: Rolling Back​

Pattern 3: Managing Secrets​

Pattern 4: Conditional Resources​

Helm Chart Compatibility​

Deploying Third-Party Charts​

Real-World Migration Timeline​

Sample Timeline: Per Chart​

Migration by Team Size​

Comparison: Before & After​

Before (Helm)​

After (Codiac)​

Cleaning Up Helm Releases​

Common Migration Questions​

Getting Help​

Related Documentation​

Why Migrate from Helm?

Key Differences

Migration Strategies

Strategy 1: Full Migration (No More Helm)

Strategy 2: Hybrid (Deploy Helm Charts via Codiac)

Prerequisites (Get These Ready First)

Migration Process (Full Migration)

Step 1: Analyze Helm Chart (15 minutes)

Step 2: Deploy with Codiac (30 minutes)

Step 3: Migrate Multi-Environment Values

Migrating Common Helm Patterns

Pattern 1: Upgrading Release

Pattern 2: Rolling Back

Pattern 3: Managing Secrets

Pattern 4: Conditional Resources

Helm Chart Compatibility

Deploying Third-Party Charts

Real-World Migration Timeline

Sample Timeline: Per Chart

Migration by Team Size

Comparison: Before & After

Before (Helm)

After (Codiac)

Cleaning Up Helm Releases

Common Migration Questions

Getting Help

Related Documentation