Comparison to Local DDEV¶

This guide is for teams and developers familiar with local DDEV who are evaluating this Coder template or planning migration.

Executive Summary¶

Local DDEV:

Runs on your laptop/desktop
Uses local Docker Desktop or Docker Engine
Direct filesystem access
Local port binding (*.ddev.site domains)
No authentication, single user

DDEV in Coder:

Runs in cloud workspace (remote container)
Uses Docker-in-Docker via Sysbox runtime
Remote filesystem (persistent volumes)
Port forwarding via Coder proxy
Multi-user, authenticated, team-managed

Architecture Comparison¶

Local DDEV Architecture¶

┌─────────────────────────────────┐
│ Your Local Machine              │
│                                 │
│ ┌─────────────────────────────┐ │
│ │ Docker Desktop / Engine     │ │
│ │ ┌─────────────────────────┐ │ │
│ │ │ DDEV Containers         │ │ │
│ │ │ - Web (PHP/Node)        │ │ │
│ │ │ - Database              │ │ │
│ │ │ - Router (*.ddev.site)  │ │ │
│ │ └─────────────────────────┘ │ │
│ └─────────────────────────────┘ │
│                                 │
│ Local filesystem                │
│ ~/projects/my-site/             │
└─────────────────────────────────┘

Key points:

DDEV talks directly to local Docker
Project files on local filesystem
*.ddev.site domains via ddev-router
No network latency

DDEV in Coder Architecture¶

┌─────────────────────────────────────────┐
│ Coder Workspace (Cloud Container)      │
│                                         │
│ ┌─────────────────────────────────────┐ │
│ │ Docker Daemon (Sysbox)              │ │
│ │ ┌─────────────────────────────────┐ │ │
│ │ │ DDEV Containers                 │ │ │
│ │ │ - Web (PHP/Node)                │ │ │
│ │ │ - Database                      │ │ │
│ │ │ (No router, port forward)       │ │ │
│ │ └─────────────────────────────────┘ │ │
│ └─────────────────────────────────────┘ │
│                                         │
│ /home/coder/ (persistent volume)       │
│ └── projects/my-site/                  │
└─────────────────────────────────────────┘
         │
         ▼ (Coder proxy)
┌─────────────────────────────────────────┐
│ Your Browser                            │
│ - VS Code for Web                       │
│ - Forwarded ports (HTTP/HTTPS)          │
└─────────────────────────────────────────┘

Key differences:

Nested Docker (Docker-in-Docker via Sysbox)
Remote filesystem (persistent across sessions)
Port forwarding instead of *.ddev.site
Network latency for file operations

Detailed Differences¶

1. Docker Runtime¶

Local DDEV:

Uses Docker Desktop (macOS/Windows) or Docker Engine (Linux)
DDEV talks to Docker socket: /var/run/docker.sock
Privileged operations allowed

Coder DDEV:

Uses Docker-in-Docker via Sysbox runtime
Each workspace has isolated Docker daemon
Sysbox provides security without --privileged
Docker data in dedicated volume: /var/lib/docker

Implications:

✅ Better isolation (workspaces can’t interfere)
✅ Multi-user safe (no shared Docker daemon)
⚠️ Slightly slower Docker operations (nested overhead)
⚠️ Can’t access host Docker from workspace

2. Networking¶

Local DDEV:

Uses ddev-router container for *.ddev.site domains
Direct port binding to localhost
mDNS for .ddev.site resolution
LAN access possible (optional)

Coder DDEV:

No ddev-router (not needed)
Port forwarding via Coder proxy
Access via DDEV Web app URL: https://ddev-web--workspace--owner.coder.example.com/
*.ddev.site URLs don’t work

Migration:

# Local .ddev/config.yaml (not needed in Coder)
router_http_port: "80"
router_https_port: "443"
use_dns_when_possible: true

# Coder .ddev/config.yaml (simplified)
# router_disabled: true  # Optional

Access patterns:

# Local DDEV
curl https://my-site.ddev.site

# Coder DDEV
# Use Coder UI port forwarding or:
coder port-forward my-workspace --tcp 80:80
curl http://localhost:80

3. Filesystem¶

Local DDEV:

Project files on local filesystem (e.g., ~/projects/my-site)
Mounted into containers via Docker bind mounts
Fast file operations (native filesystem)
NFS option for macOS (optional)

Coder DDEV:

Project files on remote volume (/home/coder/projects/my-site)
Persistent across workspace restarts
Mounted into DDEV containers (nested mount)
Network latency for file operations

Performance comparison:

Operation	Local DDEV	Coder DDEV
Read file	~1ms	~5-20ms
Write file	~1ms	~10-50ms
Composer install	Fast	Slower
npm install	Fast	Slower
Database query	Fast	Similar
Page render	Fast	Similar

Optimization:

Use NFS mount in Coder: nfs_mount_enabled: true in .ddev/config.yaml
Disable Xdebug when not needed: ddev xdebug off
Use Docker layer caching for builds

4. IDE and Development Environment¶

Local DDEV:

Desktop IDE (VS Code, PHPStorm, Sublime)
Direct filesystem access
Local terminal
Native performance

Coder DDEV:

VS Code for Web (browser-based)
Remote filesystem (via Coder agent)
Remote terminal (via SSH or VS Code)
Network latency for file operations

Desktop IDE with Coder:

# Configure SSH
coder config-ssh

# VS Code Remote-SSH
# Connect to: coder.my-workspace

# PHPStorm
# Tools → Deployment → Add Server
# Type: SFTP, Host: coder.my-workspace (from SSH config)

Tradeoffs:

Aspect	Desktop IDE + Local DDEV	VS Code Web + Coder DDEV
Latency	None	10-100ms
Extensions	All available	Most available
GPU features	Full support	Limited
Offline work	Yes	No
Setup time	Manual Docker install	Zero (pre-configured)
Team consistency	Varies	Identical

5. Team Collaboration¶

Local DDEV:

Each developer has own setup
Configuration drift possible
Manual environment setup (documentation)
No centralized management

Coder DDEV:

Identical environments for all users
Centralized template management
Zero-setup onboarding (create workspace)
Admin controls resources, versions

Example: Onboarding time¶

Local DDEV:

Install Docker Desktop (5-10 min)
Install DDEV (5 min)
Install IDE (5-10 min)
Clone repository (5 min)
Install dependencies (10-30 min)
Configure environment (10-30 min)
Troubleshoot issues (0-120 min)

Total: 40 minutes to 3+ hours¶

Coder DDEV:

Get Coder credentials (1 min)
Create workspace (2 min)
Clone repository (5 min)
Start DDEV (2 min)

Total: 10 minutes¶

6. Resource Management¶

Local DDEV:

Uses local machine resources (RAM, CPU, disk)
Limited by laptop/desktop specs
Must manage Docker resource limits
Affects battery life (laptops)

Coder DDEV:

Uses cloud resources (configurable)
Scalable per project needs
Doesn’t affect local machine
Can use powerful cloud machines for heavy workloads

Example configurations:

Local laptop:

16GB RAM, 4-core CPU
Supports 2-3 DDEV projects simultaneously
Docker Desktop limit: 8GB RAM, 2 cores

Coder workspace:

Default: 8GB RAM, 4 cores
Configurable: up to 64GB RAM, 32 cores
Dedicated Docker volume (no local disk impact)
Stop workspace when not in use (save costs)

7. Persistence and Backup¶

Local DDEV:

Projects on local disk
Time Machine / manual backups
Git for code (must push)
Database snapshots: ddev snapshot

Coder DDEV:

Projects on persistent remote volume
Volume survives workspace stop/restart
Git for code (must push)
Database snapshots: ddev snapshot (works same)
Admin can backup volumes (host-level)

Data loss scenarios:

Local DDEV:

❌ Disk failure (no backup)
❌ Laptop stolen/lost
✅ Git push before failure
⚠️ Database not in Git (use snapshots)

Coder DDEV:

✅ Workspace stop/restart (data preserved)
✅ Volume backed up (admin configured)
❌ Workspace deletion (permanent)
⚠️ Database not in Git (use snapshots)

Best practices:

Always commit and push code regularly (both)
Use ddev snapshot before risky operations (both)
Export databases periodically (both)
Don’t store secrets in workspace (both)

Benefits of Coder DDEV¶

1. Team Consistency¶

Problem with local DDEV:

Developer A: macOS, Docker Desktop, DDEV 1.23, PHP 8.1
Developer B: Windows, Docker Desktop, DDEV 1.24, PHP 8.2
Developer C: Linux, Docker Engine, DDEV 1.22, PHP 8.1

Result: “It works on my machine” syndrome.

Solution with Coder:

All developers: Ubuntu 24.04, DDEV 1.24.10, PHP 8.1 (same image)
Update template → everyone gets update
No configuration drift

2. Zero-Setup Onboarding¶

Local DDEV onboarding:

# Developer's first day
brew install docker  # or download Docker Desktop
# Wait for Docker to install...
# Configure Docker resources...
brew install ddev
ddev config --auto
ddev start
# Troubleshoot Docker networking issues...
# Troubleshoot permissions...
# Troubleshoot port conflicts...

Coder DDEV onboarding:

# Developer's first day
coder create --template freeform my-workspace --yes
# Done!

3. Powerful Resources¶

Local laptop limitations:

Building large Docker images: slow
Running multiple projects: swapping
Composer/npm with many packages: slow
Database imports: slow

Coder workspace:

Configurable resources (8GB, 16GB, 32GB RAM)
Fast cloud CPUs
SSD storage
Run intensive tasks without affecting local machine

4. Remote Work Friendly¶

Local DDEV on weak laptop:

Slow Docker performance
Limited battery life
Can’t work from tablet/Chromebook

Coder DDEV:

Access from any device with browser
Work from iPad, Chromebook, hotel computer
Same performance regardless of device

5. Centralized Management¶

Admins can:

Update DDEV version for all workspaces (rebuild image)
Set resource limits (prevent abuse)
Backup all workspaces (host-level)
Monitor usage and costs
Enforce security policies

Not possible with local DDEV.

Tradeoffs of Coder DDEV¶

1. Internet Dependency¶

Local DDEV:

✅ Works offline (once installed)
✅ No network latency

Coder DDEV:

❌ Requires internet connection
⚠️ Network latency (10-100ms)
⚠️ Slow/unreliable internet = bad experience

Mitigation:

Use fast internet (50+ Mbps)
Deploy Coder close to users (low latency)
Cache Docker images in workspace

2. Filesystem Performance¶

Local DDEV:

Fast file operations (native filesystem)
composer install: 30 seconds

Coder DDEV:

Slower file operations (remote volume)
composer install: 60-90 seconds

Mitigation:

Use NFS: nfs_mount_enabled: true
Use Docker layer caching
Accept tradeoff for benefits

3. IDE Limitations¶

Local DDEV:

Full desktop IDE (PHPStorm, VS Code, Sublime)
All extensions available
Native performance

Coder DDEV:

VS Code for Web (most extensions work)
Some extensions unavailable (require desktop)
Network latency

Mitigation:

Use desktop VS Code with Remote-SSH
Use PHPStorm with SFTP deployment
Most developers adapt to VS Code for Web

4. *.ddev.site URLs Don’t Work¶

Local DDEV:

Access via: https://my-site.ddev.site
Multiple projects: https://site1.ddev.site, https://site2.ddev.site

Coder DDEV:

Access via port forwarding: https://coder.example.com/port/12345
Multiple projects: different ports

Mitigation:

Use Coder UI to find port links (bookmark them)
Configure custom domains (admin)
Accept tradeoff for remote access benefits

5. Cost Considerations¶

Local DDEV:

Free (uses your hardware)
One-time laptop/desktop cost

Coder DDEV:

Cloud compute costs (per workspace per hour)
Storage costs (per GB per month)

Example costs (AWS us-east-1, 2024):

4 vCPU, 8GB RAM: ~$0.15/hour = $110/month (24/7)
Stop when not in use: ~$30/month (8 hours/day, 5 days/week)
Storage (50GB): ~$5/month

Mitigation:

Stop workspaces when not in use
Use smaller workspaces for simple projects
Savings from reduced onboarding time, consistency, IT support

Migration Guide¶

For Organizations¶

1. Evaluate:

Try Coder with 2-3 developers
Test typical workflows
Measure onboarding time improvement
Compare costs vs benefits

2. Plan:

Choose cloud provider (AWS, GCP, Azure, on-prem)
Install Coder server
Install Sysbox on agent nodes
Build and deploy the freeform template

3. Pilot:

Onboard 5-10 developers
Collect feedback
Iterate on template configuration
Document workflows

4. Rollout:

Onboard remaining developers
Deprecate local DDEV (optional)
Monitor usage and costs

For Individual Projects¶

1. Clone project:

# In Coder workspace
cd ~/projects
git clone git@github.com:org/project.git
cd project

2. Copy DDEV config:

# Local machine (if you have custom .ddev/config.yaml)
scp -r .ddev my-workspace:~/projects/project/

# Or commit to Git:
git add .ddev/
git commit -m "Add DDEV config"
git push

3. Adjust config for Coder:

# .ddev/config.yaml

# Remove local-specific settings
# router_http_port: "80"  # Not needed in Coder
# router_https_port: "443"  # Not needed in Coder

# Optional: disable router (saves resources)
# router_disabled: true

# Optional: enable NFS (if file operations slow)
# nfs_mount_enabled: true

# Keep all other settings

4. Start project:

ddev start

5. Test:

Access via Coder port forwarding
Run tests: ddev exec phpunit
Check database: ddev mysql
Import production database: ddev import-db --url=...

6. Document differences:

# Project README update

## Local DDEV
Access: https://project.ddev.site

## Coder DDEV
1. Create workspace: `coder create --template freeform my-workspace`
2. Clone project: `git clone ...`
3. Start DDEV: `ddev start`
4. Access via Coder UI port forwarding (port 80/443)

Common Migration Issues¶

Issue 1: Custom local configuration¶

# Local .ddev/config.yaml
web_environment:
  - API_KEY=local-secret-key  # Don't commit secrets!

# Solution: Use .ddev/.env (gitignored)
# .ddev/.env
API_KEY=secret-key

# .ddev/config.yaml
web_environment:
  - API_KEY=${API_KEY}

Issue 2: Local file paths¶

// Local code
require_once '/Users/john/projects/library/autoload.php';

// Solution: Use relative paths
require_once __DIR__ . '/../library/autoload.php';

*Issue 3: .ddev.site hardcoded

// Local code
const API_URL = 'https://api.ddev.site';

// Solution: Use environment variable
const API_URL = process.env.API_URL || 'https://api.ddev.site';

Issue 4: Performance-sensitive operations¶

# Local: fast
npm install  # 30 seconds

# Coder: slower
ddev npm install  # 60-90 seconds

# Solution: Accept tradeoff or cache node_modules in Docker image

When to Use Which¶

Use Local DDEV when¶

✅ Solo developer, personal projects

No team coordination needed
You control your machine
Offline work required

✅ Optimal performance critical

Heavy file operations
Real-time compilation watchers
Can’t tolerate network latency

✅ Very limited budget

Cloud costs not acceptable
Have powerful local machine

✅ Fully offline work

No reliable internet
Security requires air-gapped dev

Use Coder DDEV when¶

✅ Team development

Multiple developers
Need consistent environments
Onboarding time matters

✅ Remote work

Distributed team
Work from multiple locations/devices
Weak laptops, tablets

✅ Centralized management

IT wants control
Compliance/security requirements
Resource quotas needed

✅ Fast onboarding

High turnover
Contractors/interns
Training environments

✅ Scalable resources

Projects need more than laptop can provide
Heavy builds, large databases

Hybrid Approach¶

Some teams use both:

Developers choose:

Local DDEV for daily work (fast)
Coder DDEV for testing, demos, reviews
Coder DDEV for onboarding new team members

Projects decide:

Simple projects: local DDEV
Complex projects: Coder DDEV
Prototypes: local DDEV
Production-like environments: Coder DDEV

Frequently Asked Questions¶

Q: Can I use my existing .ddev/config.yaml?

A: Yes, mostly. Remove local-specific settings like router_http_port. Most settings work identically.

Q: Do all DDEV project types work?

A: Yes, all 20+ project types work (WordPress, Drupal, Laravel, etc.). DDEV is identical; only access method changes.

Q: Can I use Xdebug?

A: Yes, ddev xdebug on works. Configure your IDE for remote debugging via SSH.

Q: What about PHPStorm?

A: Use PHPStorm with SFTP deployment mode and remote interpreter. Not as seamless as local but works.

Q: Is it slower?

A: File operations are slower (network latency). Database queries and page loads are similar. Tradeoff for remote access and team consistency.

Q: Can I work offline?

A: No, internet required. Local DDEV better for offline work.

Q: What if workspace is deleted?

A: All data lost (like deleting local project). Always commit and push to Git. Admins can backup volumes.

Q: How much does it cost?

A: Depends on cloud provider and usage. ~$30-110/month per workspace. Stop when not in use to save costs.

Q: Can I migrate back to local DDEV?

A: Yes, easily. Clone Git repo, use same .ddev/config.yaml, run ddev start.

Conclusion¶

Coder DDEV is not a replacement for local DDEV in all cases. It’s a different deployment model with different tradeoffs.

Best for:

Teams prioritizing consistency and onboarding speed
Remote/distributed teams
Organizations with centralized IT management
Projects needing more resources than laptops provide

Local DDEV still best for:

Solo developers with good local setup
Performance-critical workflows
Offline work requirements
Budget-constrained personal projects

Key insight: Most teams value consistency, onboarding speed, and remote access over filesystem performance. But evaluate based on your specific needs.

Additional Resources¶

DDEV Documentation - Official DDEV docs
Coder Documentation - Official Coder docs
Getting Started Guide - New to Coder DDEV
Operations Guide - Deployment and management
GitHub Issues - Ask questions, report issues