> ## Documentation Index
> Fetch the complete documentation index at: https://docs.slipway.sh/llms.txt
> Use this file to discover all available pages before exploring further.

# Service previews

> Preview one service per pull request, wired to the project's live siblings.

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.

| Generation | Behaviour |
| - | - |
| `automatic` | Every qualifying PR against this service's repo gets a preview of it. |
| `manual` | Only PRs that opt in, with the `slipway-preview` label or `[slipway preview]` in the title. |
| `off` | The default. |

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](/previews/pr-previews#two-tiers).

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`.

> [!WARNING]
>
> A preview can write to your production database. Use preview values for anything
> destructive, or use a [full-stack preview](/previews/pr-previews) 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](/previews/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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.