The rules a request meets.

1. 1

   The secure address, always

   A plain http:// address is sent straight to the https:// one, at the edge, before anything else happens.

2. 2

   Which host answers

   The apex address and the www one are both live and both covered by the certificate — see the apex/www row below for what that does and doesn't mean.

3. 3

   The URL rules

   Redirects, trailing slashes, a missing page, a page taken down on purpose — checked in the order they're listed below.

4. 4

   The cache lookup

   Checked before anything is fetched fresh, so most requests never reach storage or an instance at all.

5. 5

   The origin fetch

   Only on a genuine cache miss — from durable storage for a static site, or from your own instance for anything dynamic. Full path on Platform.

6. 6

   The response headers

   Added to whatever comes back, before it leaves — the same set on every response, plus anything you've asked us to add.

• Files whose name changes with their content

  Your stylesheets and scripts get the content written into their filename. A changed file gets a new address instead of overwriting the old one, so holding onto a copy of it anywhere is always safe.

• Pages

  Held at the edge too, but every deploy clears the whole cache before it finishes. A change is visible right away — nobody has to wait for an old copy to expire on its own.

• Anything an app computes per request

  Not held by us at all. On a dedicated instance, your app decides what — if anything — it caches.

A browser's own cache, and any network in between, are separate from ours — see the honest limits below for what that means in practice.

On by default, on every response:

• Strict-Transport-Security

  Tells a browser to skip the plain http:// address on every visit for a year. It doesn't need to trust that address again, or wait for a redirect first.

• X-Content-Type-Options

  Stops a browser guessing a file's type from its content. It has to trust what the server actually said the file was, which closes off one class of trick that relies on the guess.

• X-Frame-Options

  Stops another site from loading your page inside a frame of its own. It's the standard defence against your page being silently reused as someone else's.

• Referrer-Policy

  Limits how much of a page's own address gets passed to the next site a visitor's browser talks to.

• X-XSS-Protection

  A legacy header, kept for older browsers that still read it. Current browsers ignore it and lean on the other headers here instead.

Also on by default, below the header layer — true of the connection itself rather than of any one response:

• TLS 1.2 as the floor

  A connection asking for anything older is refused outright, rather than allowed through on a weaker cipher.

• IPv6

  Reachable equally well over the newer internet addressing scheme, not only the older one.

• Compression

  Text responses leave compressed when a browser asks for it, so a visitor's connection carries fewer bytes for the same page.

Read how a change gets briefed in the first place on Brief a change, and how it ships on The Loop.

• No web-application firewall or rate limiting as standard

  A standard plan checks the rules on this page and nothing more. Filtering traffic by pattern or capping request rates is a real thing we can build — just not something included by default.

• No per-request compute beyond resolving the address

  The check that matches a URL to a rule runs at the edge. It doesn't run your code. Anything that computes an answer per request needs an instance behind it.

• A browser's own cache, or a proxy in between, isn't ours to purge

  Clearing our own cache on every deploy is real and automatic. What a visitor's own browser, or a network in between, decides to hold onto afterwards is outside anyone's control, ours included.

• We won't write a Content-Security-Policy blind

  A policy written without seeing what a real page actually loads breaks it more often than it protects it. This is why it's a briefed change, not a default.

• On a dedicated instance, the app sets its own headers

  The rows above are what a static site gets by default. On a dedicated instance, your app or its own reverse proxy is what actually sets response headers — we help set that up rather than guessing at it from outside.

• DNS-level geo-routing or traffic-splitting is a custom quote

  Same as on Domains: a standard plan points a domain at one place. Splitting traffic by region or condition at the DNS layer is real work we can do, just not a standard-plan default.

1. 01Will my old URLs keep working after a move?

   Only if a redirect map is set up for them — it isn't automatic. A redirect map for retired URLs is a briefed change under the Agentic iteration — CodeHerder add-on: an agent opens the pull request, a human merges it, and the old addresses start forwarding to their new homes.

2. 02Will I lose search rankings when I move?

   Not if the old addresses forward to their new ones with a permanent redirect (301) before the old ones go dark. That's exactly what the redirect map above is for — see Migrations for the cutover itself.

3. 03How fast does a deploy reach visitors?

   Right away. A deploy clears every cached copy across the whole edge network before it finishes, rather than waiting for old copies to expire on their own.

4. 04Can I set my own Content-Security-Policy?

   Yes, but not out of the box. We don't ship a default one, because a policy written blind breaks a working page more often than it protects it. Brief us on what your page actually loads from and we'll write one with you.

5. 05My app is a single-page app. Will deep links work?

   Not automatically today. A direct link to one of its inner pages needs a fallback rule set up against your app's own routes, so it loads the app instead of hitting a 404 — a briefed change, not a default.

6. 06How do I take a page down properly?

   Mark it gone with a 410 if there's nothing to replace it with, or redirect it if there is. Either is a single rule, and either is an ops request — no charge.

7. 07Who'd be doing this if I ran it myself?

   The application-routing side — writing, testing, and reviewing a redirect map or a real policy change. The hours ledger prices "shipping the small changes you'd make if there were time" at around 2 hours a change, assuming about 3 changes a month — here, that row moves to the Agentic iteration — CodeHerder add-on instead.

8. 08Does this apply to every site on my account?

   Each one gets its own set. If you run more than one site under additional static site, a rule added to one is reviewed and set up on its own — it never quietly applies to the others.

9. 09What happens when someone hits a URL that doesn't exist?

   Your own not-found page comes back, with a real 404 status code attached — not a generic error document from somewhere else in the stack.

10. 10Do you redirect www to the bare domain, or the other way round?

    Not unless you ask for it. Both addresses are live, and both sit on the certificate. Picking one as canonical, and setting up the single redirect that enforces it, is an ops request — at no charge.