sw CLI to exercise a feature branch end-to-end. It builds every component from a committed ref (default: your current branch), gets its own isolated environment and public URLs, and stays alive only as long as the CLI keeps it alive — when you press Ctrl-C (or the CLI loses its connection) it’s reaped automatically.
It’s the same idea as a PR preview, but on demand and bound to your terminal session rather than a pull request.
Spin one up
Runsw dev up from inside a repo checkout:
sw dev up:
- Detects the environment from your repo’s
originremote — it matchesowner/nameagainst each base environment’s components. Pass--env <slug>to choose explicitly; if more than one environment includes the repo you’ll be prompted to pick. - Detects the ref from your current git branch. Override with
--ref <branch|tag|sha>. - Builds from the committed ref — exactly like every other slipway deploy, cloning from your provider. Uncommitted local changes are not uploaded; commit and re-run
sw dev upto pick them up. - Prints every service URL once the instance is healthy.
- Forwards every service to
localhostautomatically (see below) so you can reach them directly — including internal services like databases. Pass--no-forwardto skip, or--forwardto pick specific ones. - Heartbeats every ~30s to keep the instance alive, until you press Ctrl-C — then it stops the forwards and tears the instance down on the way out.
The instance copies the base environment’s component shape, variables, and
secrets. The component bound to your repo is re-pointed to your ref; sibling
components stay on the base environment’s tracked refs.
Flags
Automatic port-forwarding
Once the instance is healthy,sw dev up forwards every service that declares a port to localhost and keeps the tunnels open for the life of the session — so localhost:5432 hits the instance’s database, localhost:3000 hits your web service, and so on. Internal services (no public URL) are forwarded too; that’s usually exactly what you want to connect to from your machine.
- Local port defaults to the service’s own port. If that port is already in use on your machine, slipway picks the next free one and prints the real mapping — it never fails the bring-up over a port clash.
- Tunnels close on Ctrl-C, right before teardown.
sw dev up stays scriptable:
--forward entry is <service>:<local>[:<remote>]. Use <component>/<service> when the same service name exists in more than one component. With no :<remote>, the service’s declared container port is used. Giving any --forward flags replaces the auto-forward-everything default with exactly your list.
You can still open additional or ad-hoc forwards by hand against a running instance with sw port-forward.
Lifetime: heartbeat + TTL
Dev instances don’t live forever, and they don’t depend on a healthy network either:- While
sw dev upruns, it sends a heartbeat every ~30s that pushes the instance’s expiry forward by the rolling TTL (5 minutes by default). - When you press Ctrl-C, the CLI tears the instance down immediately.
- If the CLI crashes or loses connectivity, heartbeats stop, the TTL lapses, and the server reaps the instance within a few minutes — nothing is left running.
- A hard maximum lifetime (8 hours) caps any instance regardless of heartbeats, so a forgotten
sw dev upcan’t keep one alive indefinitely.
List and tear down
sw dev ls shows the owner, ref, status, and time-to-expiry for each live instance:
Tail logs
Stream a component’s container logs — the same stream as the dashboard log viewer:Working against the instance
Services are already forwarded tolocalhost while sw dev up runs, so you can hit them directly. For an extra forward against an already-running instance, or to run commands inside a container, use sw port-forward and sw exec: