Local development orchestrator
Why fuku
Run all your services as native processes with proper startup ordering, readiness checks, and a live dashboard. No Docker required.
Memory comparison
When to use fuku
A backend and a frontend. Two terminal tabs. Done.
You don't need fuku.
- Multiple backend services with dependencies
- BFF layer between APIs and the UI
- Several frontends — SPA, docs, Swagger
- Gateways, mock servers, infrastructure
Local development tradeoffs
Compose runs containers. fuku runs native processes. Here's what that means day to day.
~2 GB+ container memory
Plus 2-4 GB for the Docker Desktop VM on macOS
~60 MB total
Native processes. No VM, no daemon, no overhead.
Minutes to start
Image pulls, layer extraction, network setup, cgroup init
Seconds to start
Native fork and exec. No container initialization.
Broken file watching
macOS VM proxies FS events. Latency. Missed changes.
Instant hot-reload
Native fsnotify. Debounced. Configurable per-service.
depends_on ≠ ready
Container started doesn't mean service is accepting requests
Real readiness gates
HTTP, TCP, and log pattern checks. Tier-based startup ordering.
Interleaved log noise
No overview. No controls. grep your way through stdout.
Live TUI dashboard
Per-service status, CPU/memory, restart controls, log filtering.
Feature matrix
| Foreman | Overmind | Compose | fuku | |
|---|---|---|---|---|
| Native processes | Containers | |||
| Startup ordering | depends_on | Tier-based | ||
| Readiness checks | Extra config | HTTP, TCP, log | ||
| Interactive TUI | ||||
| CPU/memory monitoring | docker stats | Built-in | ||
| Hot-reload | Volume mounts | Built-in | ||
| Service profiles | ||||
| Per-process terminal | tmux | docker exec | ||
| Log streaming | stdout | stdout | docker logs | Socket-based |
| Config format | Procfile | Procfile | YAML | YAML |
| Requires Docker | No | No | Required | No |
| Memory (~50 services) | ~60 MB | ~60 MB | ~2 GB+ | ~60 MB |
Try it out
Add a fuku.yaml to your project, list your services, and run fuku.