deven is a Rust CLI that boots a full local development environment from one YAML file.
It manages setup tasks, Docker containers, local services, readiness checks, logs, and runtime state.
Local dev stacks are often split between Docker infrastructure and app processes running directly on your machine. That usually leads to ad-hoc scripts, manual startup order, and inconsistent stop/restart behavior across a team.
deven gives you one repeatable workflow: define your stack once, start it in dependency order, wait for readiness, and manage logs/state from a single CLI.
- Starts containers and services in dependency order
- Runs one-time setup tasks before long-running workloads
- Waits for readiness (port checks and/or command checks)
- Aggregates logs from local services and Docker containers
- Stores project-local runtime state in
.deven/ - Supports profile-based subsets of your environment
- Forwards unknown subcommands to
deven-<name>plugins
- macOS or Linux
- Rust toolchain (
cargo) - Docker CLI plus a running Docker daemon
- POSIX shell (
sh) onPATH
Run from source:
cargo run -- --helpInstall locally:
cargo install --path .
deven --helpBuild a release binary:
cargo build --release
./target/release/deven --help- Create
deven.yamlin your project root.
env:
APP_ENV: development
tasks:
migrate:
run: echo "running migrations"
containers:
postgres:
image: postgres:15
ports: ["5432:5432"]
readiness:
ports: [5432]
timeout_secs: 30
services:
api:
run: python3 -m http.server 8080
depends_on: [postgres]
env:
PORT: "8080"
readiness:
ports: [8080]- Start everything.
deven up --detach- Check status and logs.
deven status
deven logs --tail 200- Stop or reset.
deven stop
deven reset --yesGlobal flag:
--project-dir <path>: project directory to run against (default.)
Commands:
deven up [--profile <name>] [--detach]deven stopdeven run <service>deven restart <name>deven logs [--service <name>] [--tail <n>] [--no-follow]deven statusdeven reset --yes
Notes:
deven upalways starts from a clean tracked state by callingstopfirst.deven run <service>runs one service in the foreground.deven logsfollows logs by default; use--no-followfor snapshot output.
Config discovery order:
deven.yamldeven.yml
Top-level keys:
env: global env vars merged into every task/service/containertasks: one-time commands executed before containers and servicescontainers: Docker workloadsservices: long-running local processesprofiles: optional filtered subsets of tasks/containers/serviceswatch: optional file watcher that triggersdeven restart <service>
Environment merge precedence:
- Host process environment
- Top-level
env - Per-task/per-service/per-container
env
services:
api:
run: cargo run -p api
cwd: .
env:
PORT: "8080"
depends_on: [postgres, redis]
readiness:
ports: [8080]
command: curl -fsS http://127.0.0.1:8080/health
timeout_secs: 30
interval_ms: 500containers:
redis:
image: redis:7
ports: ["6379:6379"]
env:
REDIS_PASSWORD: secret
volumes:
- "redis-data:/data"
depends_on: [postgres]
readiness:
ports: [6379]tasks:
migrate:
run: cargo run -p migrate
cwd: .
env:
DATABASE_URL: postgres://localhost:5432/appprofiles:
minimal:
services: [api]
containers: [postgres]
tasks: [migrate]watch:
paths: ["src", "config"]
restart: ["api"]
debounce_ms: 750watch only runs when deven up is started without --detach.
- Load config and apply profile (if set)
- Stop previously tracked services and containers
- Run all tasks
- Start containers in dependency order
- Start services in dependency-aware batches
- Run readiness checks after each start
- Save runtime state in
.deven/state.json - Stream logs (unless
--detach) - Start watcher (if configured and attached mode)
Unknown subcommands are forwarded to executables named deven-<subcommand>.
Example:
deven doctor --verboseRuns:
deven-doctor --verbosedeven keeps project-local runtime data in:
.deven/state.json.deven/logs/*.log
These files drive status, logs, stop, and restart.
Run checks before opening a PR:
cargo fmt --all -- --check
cargo clippy --all-targets --all-features
cargo test --all-targets --all-featuresCI runs the same checks on Ubuntu and macOS.
- Fork the repository
- Create a feature branch
- Add tests when applicable
- Run formatting, linting, and tests
- Open a pull request with a clear description
For bugs or feature requests, open a GitHub issue.
Licensed under MIT. See LICENSE.