Deploy and test

How it works

A workspace's Previews page (it was called Deploy; ?tab=deploy still opens it) has two halves that answer two questions.

Preview (this branch) runs the workspace's whole repo set as live containers on DevBench's own compute, with the shared database and each repo's seed environment variables, so you can click through the branch. It is throwaway: replaced by the next deploy, stopped when idle, reaching nobody. It costs nothing and it is open to everybody, it is the test loop the whole team works in, and it is what an agent uses to check its own work.

Environments is the other half: one row per branch, saying where that branch actually runs. A row's target is one of

• Deployed elsewhere, the default. DevBench does not deploy this; the row is the team's record of an environment somebody else's pipeline builds.
• DevBench compute, the container preview, as a named environment.
• AWS or a provider connection, a static site in S3 behind CloudFront, an EC2 or Lightsail instance, a machine of your own over SSH, and so on.

Multi-cloud falls out of storing this per environment: staging on a rented box and production in an AWS account is two rows with different targets.

Three properties are worth knowing before you press anything:

• Refusals happen before anything is created. A disconnected account, a capability nobody switched on, or an IAM policy missing a permission comes back as a sentence in the response to the button, not as a deployment that fails ninety seconds after you have walked away.
• A redeploy is an update. DevBench records what it made, bucket and prefix, distribution id, instance id, and the next deploy overwrites that site and reuses that distribution and that instance. Recreating a distribution means a new domain and a quarter-hour of propagation; recreating an instance doubles the bill and leaves the old one serving the old code.
• Stop does not delete. For a published site, a box you own or an instance, Stop marks the deployment stopped and touches nothing. A button in a list is not consent to take a production site off the internet.

Deploying to a machine runs an update script your team writes, on the environment. DevBench did not build that box and will not guess whether the app is behind systemd, pm2, docker compose or a Makefile, every wrong guess restarts something in production. What it adds over an SSH client: the host key is pinned, the script runs under set -euo pipefail so a failed git pull stops rather than restarting a service with the old code still on disk, and $DEVBENCH_BRANCH, $DEVBENCH_REPO, $DEVBENCH_ENVIRONMENT and friends are exported so one script serves every environment.