Skip to main content
A service preview deploys a single service rather than the whole project. A PR against that service’s repo brings up a temporary copy on its own URL, updated per commit and archived when the PR closes. The rest of the project is not duplicated: the preview talks to the project’s live production services. This suits one service under active development against a stable stack, such as a frontend PR previewing against the real API.

​
Turning them on

Open the service’s Preview tab and choose a generation mode. The same escapes as project previews apply in every mode. [skip preview] in the title, or the slipway-preview-skip label, skips one PR, and bot-authored PRs never spawn. The project-level setting wins. While the project’s own preview generation is automatic or manual, every qualifying PR previews the entire stack and per-service settings are ignored. They take effect only while the project setting is off. See PR previews. Service previews are available only for services built from a git repository, because a pull request is what triggers them. Image-backed services, including managed databases, marketplace apps and zip uploads, have no Preview tab. They still ride along in project previews, which copy every enabled service.

​
How it reaches the rest of the project

Inside a service preview, sibling names resolve to the project’s production namespace. http://postgres reaches the real database, ${service.api.host} the real API, and ${service.web.public_url} the production URL. The preview inherits the base wiring, credentials included, with no setup. That is a deliberate trade: zero-config previews against real siblings, in exchange for the preview being able to touch production data. For anything that must not point at production, set a preview value on the variable or secret in Settings → Previews, or set per-service preview env on the service’s own Previews tab — those values apply only when the service runs inside a preview, and beat the same key in a committed previews.env.
A preview can write to your production database. Use preview values for anything destructive, or use a full-stack preview instead, which gets its own isolated copy of every service.
Two behaviours are worth knowing before relying on this wiring:
  • A production sibling that is paused is not woken by in-cluster traffic from a preview. Only edge requests wake a service.
  • A static-site sibling has no in-cluster name. ${service.<site>.public_url} still resolves to its production URL.

​
Everything else

URLs, the SLIPWAY_PREVIEW, SLIPWAY_PR_NUMBER and IS_PULL_REQUEST variables, PR comments and commit checks, sleep, expiry, access control, plan availability and billing all behave as they do for PR previews. The service’s Preview tab lists every preview it has spawned, with the same wake, redeploy, extend, destroy and recreate actions as the project’s Previews tab.