Skip to main content

​
Quick Comparison

Dev-Fast

~120s - Daily development

Cilium

~200s - CNI testing

Full

~250s - Full-stack validation

​
Feature Matrix

FeatureDev-FastCiliumFull
CNIkindnetdCilium + HubbleCilium + Hubble
Nodescontrol-plane × 1control-plane + worker × 1control-plane + worker × 2
Istio❌ None❌ None✅ Ambient mode
ArgoCD❌ None❌ None✅ GitOps
Warm Cluster✅ Hash-based❌ Not supported✅ Hash-based
Cold Start~120s~200s~250s
Warm StartInstant / 10-15sN/AInstant / reapply
Commandbootstrapbootstrap --fullfull-bootstrap

​
Timing Breakdown

​
Dev-Fast Mode (~120s)

PhaseDurationDescription
phase1-prep~12skind + manifests + OTel + images (parallel)
phase2-load~37sLoad images into kind
phase3-deploy~21sDeploy services (parallel)
phase4-wait~52sWait for pods
TOTAL~122s38% faster than Cilium

​
Cilium Mode (~200s)

Adds Cilium installation overhead but provides network observability.

​
Full Mode (~250s)

Adds Istio + ArgoCD + second worker node. Most complete but slowest.

​
Warm Start Comparison

​
Hash-Based Caching

Storage: .bootstrap-state/Scenarios:
  • ✅ Instant - No changes (hash match)
  • ⚡ 10-15s - Manifest changes only
  • 🔄 ~120s - Cluster config changes
Usage:
bootstrap           # Smart detection
bootstrap --clean   # Force rebuild

​
Network Stack

Dev-Fast

​
kindnetd

  • Default CNI
  • No overhead
  • Basic networking
  • Fastest startup

Cilium

​
Cilium + Hubble

  • eBPF-based CNI
  • Network policies
  • Traffic observability
  • Hubble UI included

Full

​
Cilium + Istio

  • Cilium CNI
  • Istio ambient mode
  • mTLS encryption
  • Service mesh

​
Use Case Guide

​
When to Use Dev-Fast

  • Rapid iteration cycles
  • Frequent restarts
  • Application development
  • Local testing
  • Limited RAM/CPU
  • Single control-plane
  • Minimal overhead
  • Laptop development
  • Fast feedback loops
  • CI/CD pipelines
  • Unit/integration tests
  • Demo environments

​
When to Use Cilium

  • Network policy validation
  • eBPF feature testing
  • CNI performance testing
  • Cilium-specific features
  • Traffic flow analysis
  • Service dependency mapping
  • Network bottlenecks
  • Policy troubleshooting
  • More realistic than dev-fast
  • Faster than full
  • No service mesh complexity
  • Network observability needed

​
When to Use Full

  • Production parity testing
  • Integration testing
  • End-to-end validation
  • Release candidates
  • Istio policy validation
  • mTLS testing
  • Traffic management
  • Security features
  • ArgoCD deployment testing
  • Multi-environment sync
  • Rollback scenarios
  • CD pipeline validation
  • Distributed workloads
  • Node affinity/anti-affinity
  • Pod spreading
  • HA validation

​
Command Reference

​
Dev-Fast

# Standard bootstrap (warm aware)
bootstrap

# Force clean rebuild
bootstrap --clean

# Switch to Cilium mode
bootstrap --full

​
Cilium

# Via bootstrap flag (recommended)
bootstrap --full

# Direct invocation
bootstrap-full

​
Full

# Standard bootstrap (warm aware)
full-bootstrap

# Force clean rebuild
full-bootstrap --clean

​
Exposed Services Comparison

ServiceDev-FastCiliumFull
ArgoCD❌❌✅ :30080
Grafana✅ :30300✅ :30300✅ :30300
Prometheus✅ :30090✅ :30090✅ :30090
Alertmanager✅ :30093✅ :30093✅ :30093
Hubble UI❌✅ :31235✅ :31235
Traefik✅ :30081✅ :30081✅ :30081

​
Resource Usage

Dev-Fast

​
Minimal

  • 1 node
  • kindnetd CNI
  • No service mesh
  • ~4-6GB RAM

Cilium

​
Moderate

  • 2 nodes
  • Cilium + Hubble
  • No service mesh
  • ~6-8GB RAM

Full

​
High

  • 3 nodes
  • Cilium + Istio
  • ArgoCD
  • ~8-12GB RAM

​
Decision Tree

​
Migration Between Modes

You can switch between modes by destroying and recreating: 
# From dev-fast to Cilium
cluster-down
bootstrap --full

# From dev-fast to full
cluster-down
full-bootstrap

# From Cilium to dev-fast
cluster-down
bootstrap

# From full to dev-fast
cluster-down
bootstrap
Switching modes destroys the existing cluster. Ensure you’ve saved any important data.

​
Performance Tips

  • Use warm cluster support (don’t use --clean unless necessary)
  • R2 OTel cache enabled via devenv.nix
  • Keep cluster running with cluster-stop instead of cluster-down
  • Pre-pull images before bootstrap
  • Use SSD for Docker storage
  • Increase Docker resource limits
  • Use warm cluster support
  • Pre-generate manifests
  • Keep cluster running between tests
  • Use --clean only when needed

​
Common Operations

​
Cluster Management

CommandEffectWhen to Use
cluster-stopPause containers (state preserved)Before reboot, save resources
cluster-startResume containersContinue work
cluster-downDelete cluster completelyReset environment

​
Benchmarking

# Run bootstrap 3 times and show statistics
benchmark 3
Results saved to logs/benchmark/ with phase timing and resource usage.

​
Next Steps

Dev-Fast Guide

Learn about dev-fast mode

Cilium Guide

Explore Cilium mode

Full Guide

Discover full mode

Build docs developers (and LLMs) love

Get started for freeTalk to us