Skip to content
Docsv0.7.2

Introduction

Denvig is the developer environment envigorator. It gives you one consistent way to run actions, manage long-running services, inspect dependencies, and route local domains across every project on your machine — regardless of language or framework.

Denvig started life as a CLI, but it is now built in two layers:

  • @denvig/sdk — a programmatic, in-process API that contains all of denvig’s logic. Resolve a project, walk its worktrees, start a service, issue a certificate, or reconcile the gateway, all from TypeScript.
  • denvig (the CLI) — a thin command-line interface built directly on top of the SDK. Every command you run is a call into the same SDK you can use yourself.

This means anything the CLI can do, your own integrations can do too. The CLI is just the first consumer of the SDK — Raycast extensions, editor plugins, dashboards, and CI scripts are all equally valid.

A few ideas show up throughout the docs. Understanding them up front makes everything else click into place.

A project is a checkout on disk discovered under your configured project paths. Projects are identified by a slug derived from their git remote:

  • github:owner/repo — a project with a GitHub remote
  • local:/absolute/path — a project without a recognised remote

A project is really a family of git checkouts: the primary checkout plus any git worktrees you’ve created for feature branches. Denvig treats these as worktrees of a single project, so you can run the same service in main and a feature/x worktree side by side and address each one explicitly.

Actions are named commands defined in your project config (or detected by a plugin) — build, test, lint, and so on. They run in the foreground and stream their output to your terminal.

Services are long-running processes — web servers, workers, databases. Denvig supervises them with launchctl, keeps logs, and (optionally) routes them through the gateway on a custom local domain.

The gateway is a local nginx reverse proxy that maps friendly domains like api.local to whichever service currently owns them — including the ability to swap a domain between worktrees of the same project. See the Gateway & Worktrees guide.