devflow

Why devflow?

devflow is a workspace orchestrator for local development. It connects materialized Git worktrees or jj workspaces with per-workspace state: service containers, connection strings, lifecycle hooks, generated env files, and stable HTTPS URLs. Work on multiple features, reviews, migrations, or agent tasks in parallel — without sharing a database or stashing state.

devflow switch -c feature/auth
# → VCS ref created, worktree at ../myapp.feature_auth_fc659bd73585
# → postgres workspace cloned from main (Copy-on-Write, near-instant)
# → hooks wrote .env.local with the new DATABASE_URL
# → your shell is now inside the worktree

Workspace isolation

Each workspace gets its own services — physically (a Copy-on-Write container per workspace) or logically (one shared engine, one database/bucket/DB-index per workspace). PostgreSQL, ClickHouse, MySQL, Redis, RustFS, or any Docker image.

Git worktrees, managed

Every additional Git workspace gets a linked worktree — env files, gitignored caches, and AI tool configs copied in automatically with CoW reflinks. Plain git worktree add works too: devflow’s hooks set it up.

Native project processes

App servers, frontend dev servers, workers, and schedulers run directly on the machine per workspace — with ready checks, dependency ordering, logs, optional native supervision, and service URL interpolation.

Lifecycle hooks

MiniJinja-templated commands and built-in actions run at every lifecycle phase — write env files, run migrations, open tmux sessions. With conditions, approvals, and installable recipes.

Auto-HTTPS proxy

Every Docker container and port-backed devflow process gets a trusted https://name.local URL the moment it starts. No /etc/hosts edits, no certificate warnings.

Built for AI agents

--json --non-interactive everywhere, workspace helper skills, llms.txt, and a worktree-per-task pattern that lets parallel agents work without stepping on each other.

CLI, TUI, and desktop GUI

Drive everything from the terminal, an interactive dashboard (devflow tui), or a native desktop app — all sharing the same core, including process status/log/start/stop controls.

The core loop

1. devflow switch -c feature-x creates a Git worktree or jj workspace from the selected parent; switch feature-x reuses or materializes an existing ref.
2. devflow creates or switches the matching service workspaces across all configured providers.
3. Lifecycle hooks fire in the target directory — update .env.local, run migrations, trust mise configs.
4. If configured, workspace processes start there with service URLs injected.
5. The shell wrapper cds you into that directory.

Every workspace’s app is reachable at a predictable HTTPS URL, every workspace’s database at its own connection string — and devflow remove cleans all of it up.