denvig gateway

The gateway command manages a local nginx-based reverse proxy that routes traffic to your development services using custom domains and TLS. It maps a friendly domain such as api.local to whichever service currently owns it.

Tip

For the conceptual overview — running the same service across multiple worktrees and swapping a domain between active services — read the Gateway & Worktrees guide.

Usage

denvig gateway <subcommand>

Global options

Option	Description
--project	The project slug to run against. Defaults to the current directory.
--json	Output in JSON format.

Subcommands

status

Show the current gateway configuration status — the nginx process state, the config paths, and the gateway-configured services for the resolved project:

denvig gateway status

status is the default subcommand, so denvig gateway on its own does the same thing.

configure

Reconcile launchctl with denvig’s recorded state (~/.denvig/state.json) and rebuild every nginx config from the current service definitions:

denvig gateway configure

Run this after editing service http settings in your config, or any time the gateway and your running services drift out of sync.

How domains are configured

Domains come from each service’s http configuration. A service with an http.domain is routed through the gateway; with http.secure: true it is served over HTTPS using a certificate from the local CA.

services:
  api:
    command: pnpm dev
    http:
      port: 3000
      domain: api.local
      secure: true

When you start a service you can override the configured domains for that run with --domains, which claims the domain from any current owner and hands it back on stop. This is the mechanism behind swapping a domain between worktrees.