Skip to main content
A static site’s redirects, rewrites and response headers can be set in three places. All three compile into one set of rules the CDN evaluates on every request.
These rules apply to type: static services only. A web service’s routing is its own application’s business.

​
The three sources

The console tabs are the only source that rebuilds nothing. A site’s compiled rules travel inside the pointer the CDN reads, so saving rewrites one record, the same single write that performs a rollback. Nothing is rebuilt or re-uploaded, and no cache is purged.

​
Which rule wins

Console rules win. They compile last, so where two rules cover the same path, the one set in slipway applies. Both tabs show your repo’s rules underneath your own, read-only, so you can see which rule is shadowing which.
Redirects list console rules first and headers list them last. The outcome is the same in both cases: the edge takes the first matching redirect and the last matching header.

​
Redirects and rewrites

A redirect sends the browser somewhere else. A rewrite, status 200, serves a different file without changing the URL.
In the spec:
slipway.yaml
Rules match top to bottom and the first match wins, so put specific rules above catch-alls. If you omit status, slipway uses 301.
A 200 rewrite can only point at a path on your own site. Rewrites are served by slipway from the target, so an external one would make the edge an open proxy serving someone else’s content on your bandwidth. A 301 or 302 to an external URL is fine, because the browser goes there itself.

​
Response headers

One row per header: a path to match, a header name and its value.
In the spec:
slipway.yaml
Later rules win, so a specific path below a broad one overrides it. These headers cannot be set: Content-Length, Content-Encoding, Transfer-Encoding, Connection and Host. The edge owns them, and overriding them produces a response that lies about itself.

​
SPA routing

For a single-page app, set notFound so unmatched paths serve the app shell:
slipway.yaml

​
When a change takes effect

About a minute at worst. The edge caches the routing record for up to 60 seconds, so a save reaches every location within roughly that. Nobody ever sees a half-applied set. The rules are written as one record, so every request is served with either all of your old rules or all of your new ones.

​
Deploys do not undo console rules

Rules set in the console are stored against the service rather than against a build, so they survive redeploys and rollbacks. A rollback restores the old files with your current rules, which is usually what you want, since a rollback is normally about the build rather than the routing.