The origin's rules

The server that answers your visitors does exactly three things: match the host to a snapshot, match the path to an entry, and stream the stored bytes back. Everything below follows from that.

Paths are exact

A request path is looked up in the manifest as a key. There is no pattern matching and no filesystem walk, because there is no filesystem — the manifest is a table.

Index files. A request for / serves the / entry, which every site must have. A request for /about/ serves the /about/ entry if there is one; it does not fall back to /about/index.html unless you also published that key. Publish the keys you want served.

Case matters. /About.html and /about.html are different keys. If your source directory came from a case-insensitive filesystem, check the manifest rather than assuming.

Trailing slashes matter. /docs and /docs/ are different keys.

Unmatched paths serve your notFound resource if you declared one, and a plain not-found response otherwise.

Content type

The content type of a response comes from the contentType on the manifest entry when you set one, and otherwise from the blob's own recorded type. This is the one response header your record shapes.

Set it explicitly when the guess from a file extension is likely to be wrong — .mjs, .wasm, .webmanifest are the usual reasons. Everything else is normally right without your help.

Compression

An entry may declare contentEncoding — br, gzip, or zstd — meaning the stored bytes are already compressed in that encoding and are served as-is with that header. You upload the compressed bytes yourself. Do not declare an encoding for bytes that are not in it; the browser will fail to decode them and the page will not load.

The security policy is fixed

Every served site gets the same Content-Security-Policy, along with a fixed Referrer-Policy, Permissions-Policy, and X-Content-Type-Options. No field in your record influences any of them.

The policy forbids third-party scripts. A page you publish here cannot load a script, a stylesheet, a font, or an analytics bundle from another origin. This is not configurable, and it is the reason a tile from an author you have never met is safe to bind.

Same-origin requests are fine, which is what makes /_bard/params.json and its neighbours usable.

Caching

Responses carry cache headers appropriate to what they are. Nothing between the origin and your visitor caches — dids.lol runs its own edge and it does not cache — so a publish reaches the next request. There is no invalidation step and nothing to purge, because activation is a pointer swap.

Reserved paths

Two prefixes belong to the service and cannot be published to. /_bard/ carries the runtime contracts described in Tiles. /.well-known/ is served by the service for the entries you left enabled — see The site record — and by your manifest for everything else.

A manifest entry colliding with a reserved path is a validation error, not a silent override.

What never happens

No server-side rendering. No dynamic routing. No template evaluated at request time. No database read on the request path, no identity resolution, no call to your personal data server. A given path at a given revision resolves to exactly one blob, and that blob's bytes are verified against their hash before they are ever served.