Migrating from kubectl to Codiac

Stop managing Kubernetes with manual kubectl commands and YAML files. 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 YAML editing. No kubectl expertise required. Platform teams still have full access to kubectl 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 kubectl?

Manual kubectl challenges Codiac solves:

YAML maintenance: Manually editing and applying YAML files is error-prone. Codiac simplifies configuration for most use cases.
No versioning: kubectl doesn't track what was deployed when. Codiac provides complete system versioning.
Manual rollbacks: Reverting changes requires finding and reapplying old YAML. Codiac offers one-click rollbacks.
Configuration sprawl: Managing configs across environments means dozens of YAML files. Codiac uses dynamic configuration.
No audit trail: Who deployed what? When? Why? Codiac tracks everything.
Manual scaling: Adjusting replicas, resources, autoscaling requires YAML edits. Codiac provides simple commands.

When to migrate:

✅ You're managing 5+ services manually with kubectl
✅ You have multiple environments (dev, staging, prod)
✅ You're tired of debugging YAML syntax errors
✅ You want deployment history and rollback capabilities
✅ You need team collaboration with audit trails

When to stick with kubectl:

❌ You have 1-2 simple services
❌ You're a Kubernetes expert and prefer raw control
❌ You enjoy writing YAML (we don't judge!)

Key Differences

Task	kubectl	Codiac
Deploy application	`kubectl apply -f deployment.yaml` (write YAML first)	`codiac asset deploy` (CLI guides you)
Update image	Edit YAML, `kubectl apply`	`codiac asset deploy` (select new version)
Set env var	Edit ConfigMap YAML, reapply, restart pods	`codiac config set` (CLI prompts for key/value)
Expose service	Write Service + Ingress YAML, apply	`codiac host map` (CLI guides you)
SSL certificates	Install cert-manager, write Certificate YAML	Automatic (Let's Encrypt)
Rollback	Find old YAML, reapply	`codiac snapshot deploy` (select version)
View logs	`kubectl logs -f pod-name`	`codiac asset view --type logs` or kubectl

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.)
kubectl admin access	Capture existing cluster
DNS control	Point subdomain to cluster ingress

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

Migration Process

Step 1: Install Codiac (15 minutes)

1. Install CLI:

# Requires Node.js v20.13.1+
npm install -g @codiac.io/codiac-cli

# Authenticate to Codiac
codiac login

# Authenticate to your cloud provider
codiac csp login

2. Capture your existing cluster:

codiac cluster capture

The CLI guides you through provider selection and cluster identification.

Scripted mode (for automation)

# AWS
codiac cluster capture -n my-cluster -p aws -s 123456789012 -l us-east-1

# Azure
codiac cluster capture -n my-cluster -p azure -s your-subscription-id -l eastus -g your-resource-group

What this does:

Installs lightweight Codiac relay agent in your cluster
Registers cluster with Codiac control plane
Does not disrupt existing workloads

Step 2: Migrate First Application (30 minutes)

Example: Migrating a web application

Current setup (kubectl):

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-web-app
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-web-app
  template:
    metadata:
      labels:
        app: my-web-app
    spec:
      containers:
      - name: web
        image: myregistry/my-web-app:1.0.0
        ports:
        - containerPort: 8080
        env:
        - name: DATABASE_URL
          value: postgres://prod-db:5432/app
        resources:
          requests:
            memory: "256Mi"
            cpu: "200m"
          limits:
            memory: "512Mi"
            cpu: "500m"
---
# service.yaml
apiVersion: v1
kind: Service
metadata:
  name: my-web-app
  namespace: production
spec:
  selector:
    app: my-web-app
  ports:
  - port: 80
    targetPort: 8080
---
# ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-web-app
  namespace: production
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  tls:
  - hosts:
    - app.mycompany.com
    secretName: my-web-app-tls
  rules:
  - host: app.mycompany.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-web-app
            port:
              number: 80

Codiac equivalent (interactive CLI):

# 1. Create cabinet (namespace equivalent)
codiac cabinet create
# CLI prompts for name and environment

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

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

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

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

Result:

✅ CLI guides you through each step-no flags to memorize
✅ Ingress + SSL certificate automated
✅ Deployment versioned in Codiac (automatic snapshots)
✅ Configuration separated from deployment

Step 3: Migrate Configuration Management

kubectl approach:

# configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: my-app-config
  namespace: production
data:
  DATABASE_URL: postgres://prod-db:5432/app
  REDIS_URL: redis://prod-redis:6379
  LOG_LEVEL: info
  API_KEY: abc123  # Bad: secrets in ConfigMap!

Codiac approach:

# Set configuration (CLI prompts for scope, key, value)
codiac config set

# For secrets, first capture your secret store
codiac secretStore capture
# Then reference secrets using #REF syntax in config values

Benefits:

Clear separation of config vs secrets
Secrets never in Git or kubectl
Easy environment overrides
CLI guides you through each step

Step 4: Migrate Multiple Environments

kubectl approach:

k8s/
├── prod/
│   ├── deployment.yaml
│   ├── service.yaml
│   ├── ingress.yaml
│   └── configmap.yaml
├── staging/
│   ├── deployment.yaml  (duplicate with small changes)
│   ├── service.yaml
│   ├── ingress.yaml
│   └── configmap.yaml
└── dev/
    └── ... (more duplicates)

Codiac approach:

# Deploy to each environment (CLI guides you through selection)
codiac asset deploy
# Run multiple times, selecting different cabinets

# Set environment-specific configuration
codiac config set
# Select environment scope, then set DATABASE_URL for each

Or use snapshots for consistent multi-environment deployments:

codiac snapshot deploy
# Select a snapshot version and target cabinet

Result:

One asset definition, multiple configurations
Snapshots ensure consistency across environments
Clear configuration hierarchy

Migrating Common kubectl Patterns

Pattern 1: Updating Image / Deploying New Version

kubectl:

kubectl set image deployment/my-web-app web=myregistry/my-web-app:1.1.0 -n production

Codiac:

codiac asset deploy
# Select asset, new version, and target cabinet

Pattern 2: Adding Environment Variable

kubectl:

# Edit deployment YAML manually
kubectl edit deployment my-web-app -n production
# Add env var, save, exit

Codiac:

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

Pattern 3: Rolling Restart

kubectl:

kubectl rollout restart deployment/my-web-app -n production

Codiac:

codiac asset recycle
# CLI prompts for asset and cabinet selection

Pattern 4: Viewing Logs

kubectl:

kubectl logs -f deployment/my-web-app -n production

Codiac:

codiac asset view --type logs
# CLI prompts for asset and cabinet, then streams logs

Pattern 5: Viewing Deployment Status

kubectl:

kubectl get deployments -n production
kubectl describe deployment my-web-app -n production

Codiac:

codiac asset view --type status
# Or view in web UI at app.codiac.io

What Stays the Same (kubectl still useful)

Debugging commands: Continue using kubectl for:

# View logs
kubectl logs -f deployment/my-web-app -n production

# Execute commands in pods
kubectl exec -it my-web-app-xxx-yyy -- /bin/sh

# Port forwarding for debugging
kubectl port-forward deployment/my-web-app 8080:8080 -n production

# View events
kubectl get events -n production

# Check pod status
kubectl get pods -n production

Codiac doesn't replace kubectl for debugging - it replaces it for deployment and configuration management.

Migration Checklist

For each application:

Export current YAML files (backup)

kubectl get deployment my-web-app -n production -o yaml > backup/deployment.yaml
kubectl get service my-web-app -n production -o yaml > backup/service.yaml
kubectl get ingress my-web-app -n production -o yaml > backup/ingress.yaml

Document current configuration

kubectl get configmap my-app-config -n production -o yaml > backup/configmap.yaml
kubectl get secret my-app-secrets -n production -o yaml > backup/secrets.yaml

Create Codiac cabinet

codiac cabinet create
# CLI prompts for cabinet name and environment

Deploy with Codiac

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

Migrate configuration

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

Migrate secrets to cloud provider

Store secrets in 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.

Test application functionality
Delete old kubectl-managed resources

kubectl delete deployment my-web-app -n production
kubectl delete service my-web-app -n production
kubectl delete ingress my-web-app -n production

Rollback Strategy

Test rollback before full migration:

Codiac automatically creates snapshots on each deployment. To rollback:

# View available snapshots
codiac snapshot list

# If something goes wrong, rollback
codiac snapshot deploy
# CLI prompts for snapshot version and target cabinet

Common Migration Questions

Q: Can I use kubectl commands after migrating to Codiac?

A: Yes! Codiac deploys standard Kubernetes resources. You can still use kubectl for debugging, but use Codiac for deployments.

Q: What happens to my existing deployments?

A: Nothing. Codiac can coexist with kubectl-managed resources. Migrate at your own pace.

Q: Do I lose YAML files?

A: Codiac generates YAML under the hood, but you don't maintain it. If you need to see generated YAML for audit purposes, use:

cod asset export my-web-app --format yaml

Q: How do I handle custom Kubernetes resources (CRDs)?

A: For now, continue using kubectl for CRDs. Codiac focuses on standard workloads. CRD support coming in future release.

Q: Can I gradually migrate?

A: Absolutely. Migrate one application at a time. Run kubectl and Codiac side-by-side.

Real-World Migration Timeline

Most platform migrations take months. Codiac is different. With kubectl-managed applications, you're already on Kubernetes—Codiac just makes management easier.

Sample Timeline: First Application

Step	Activity	Time
1	Install CLI & capture cluster	15 min
2	Export existing workloads	5 min
3	Create cabinet	5 min
4	Deploy assets	5 min/asset
5	Configure environment variables	10-30 min
6	Validate	10 min

Total for first application: ~1 hour

Migration by Application Count

Applications	Timeline	Notes
1-3 apps	2-3 hours	Single session
10 apps	1-2 days	Phased rollout
20+ apps	3-5 days	Run kubectl + Codiac in parallel

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

The Cluster Export Accelerator

Since you're already running on Kubernetes, codiac cluster export reads your running workloads and generates CLI commands for all your images, ports, and environment variables. What would take hours of manual YAML analysis takes 5 minutes.

codiac cluster export --namespace my-app

Getting Help

Contact Support for migration assistance
Visit codiac.io to schedule a hands-on workshop
Join Discord for community help

Release Management & Environment Promotion - Use snapshots for perfect staging→prod workflows
Asset Management Guide
Configuration Management
System Versioning
FAQ: kubectl vs Codiac

Last updated: 2026-01-23

Why Migrate from kubectl?​

Key Differences​

Prerequisites (Get These Ready First)​

Migration Process​

Step 1: Install Codiac (15 minutes)​

Step 2: Migrate First Application (30 minutes)​

Step 3: Migrate Configuration Management​

Step 4: Migrate Multiple Environments​

Migrating Common kubectl Patterns​

Pattern 1: Updating Image / Deploying New Version​

Pattern 2: Adding Environment Variable​

Pattern 3: Rolling Restart​

Pattern 4: Viewing Logs​

Pattern 5: Viewing Deployment Status​

What Stays the Same (kubectl still useful)​

Migration Checklist​

Rollback Strategy​

Common Migration Questions​

Real-World Migration Timeline​

Sample Timeline: First Application​

Migration by Application Count​

Getting Help​

Related Documentation​

Why Migrate from kubectl?

Key Differences

Prerequisites (Get These Ready First)

Migration Process

Step 1: Install Codiac (15 minutes)

Step 2: Migrate First Application (30 minutes)

Step 3: Migrate Configuration Management

Step 4: Migrate Multiple Environments

Migrating Common kubectl Patterns

Pattern 1: Updating Image / Deploying New Version

Pattern 2: Adding Environment Variable

Pattern 3: Rolling Restart

Pattern 4: Viewing Logs

Pattern 5: Viewing Deployment Status

What Stays the Same (kubectl still useful)

Migration Checklist

Rollback Strategy

Common Migration Questions

Real-World Migration Timeline

Sample Timeline: First Application

Migration by Application Count

Getting Help

Related Documentation