Skip to main content
You can require visitors to sign in before they reach a service. The wall runs at the edge, in front of the service’s hostname, so requests never reach your container until the visitor is authenticated. Access is set per service. An admin dashboard can be gated while the API next to it stays open. It applies wherever the service runs, including its pull request previews. Access controls are available on paid plans. See Plans.

Turning it on

Open the service, then Auth, and switch on the methods you want. The change applies to the running service immediately with no redeploy.

Sign-in methods

Turn on either method or both. A visitor gets in through whichever one they can satisfy.

token

Visitors paste a token that slipway generates. The token belongs to the project, so one token opens every service in it that is gated this way. Switching token on for a service generates the project token if it does not have one yet. View, rotate and delete it under the project’s Settings → Access. Rotating invalidates the old token immediately and applies to running services without a redeploy. A service that asks for token while the project has no token stays open rather than rejecting everyone. This is only reachable by declaring auth: token in slipway.yaml for a project whose token was deleted; the Auth tab flags it.

members

Visitors sign in with GitHub or GitLab and must belong to the upstream account your slipway organization is connected to: the GitHub organization, or the GitLab group. There is no token to distribute or rotate.

Signing in

An unauthenticated visitor is redirected to a slipway sign-in page carrying the service name and host. After signing in they are sent back to the URL they asked for, with a cookie scoped to that hostname. One sign-in covers every gated service of the same deployment. Signing in to admin.acme.com also cookies dashboard.acme.com if both belong to the same deployment and both are gated. Signed-in slipway users who are members of the owning organization are let through without a second prompt. Requests that are not top-level navigations receive a 401 instead of a redirect, so a fetch or an EventSource from your app surfaces a real error rather than an opaque CORS failure.

Per-deployment tokens

Under Settings → Access, switch on Per-deployment token to mint a fresh token for every deploy instead of using one project token. Retrieve a deployment’s token from its detail page. The project token is ignored while this is on.

Previews

A pull request preview inherits the access settings of the service it was built from. A gated service comes up gated in its preview, checked against the same project token. To gate a preview differently from production, open that preview’s own service and change it there.

Where it does not apply

Access controls need a public hostname to sit in front of. auth: on any of these is a validation error, and the console does not show an Auth tab for them.

Downgrading a plan

Losing the capability stops you gating anything new. Services that are already gated stay gated, and you can always switch one off.