Deploy targets — where your published site goes

A StaticOwl build renders your content into plain static artifacts. A deploy target decides where those artifacts land. Most sites never choose one — the default serves the preview hosts and custom domains described in Publishing & environments — but it's worth knowing the options, because one of them is the reason your content is never locked in.

There are three, and they can run together.

Static export (the default)

The build writes ordinary files — one HTML page per URL, plus sitemap.xml, rss.xml, any rendered JSON endpoints, and your assets:

index.html
blog/post-1/index.html
sitemap.xml
rss.xml
assets/main.css

Because the output is just files, it serves from anything: StaticOwl's own hosting (the preview hosts and your custom domain), or S3 + CloudFront, Netlify, Vercel, Cloudflare Pages, GitHub Pages, or your own web server. This is the front-door promise — you can take your site and host it anywhere.

The one trade-off: a plain file sync has a brief window during a deploy where some pages are new and some are old. For most sites that's invisible; if you need atomic swaps, use the managed CDN below.

Git mirror — your content in a repo you own

The Git target pushes your compiled site and its metadata to a GitHub repository you control, one commit per deploy:

/index.html
/blog/post-1/index.html

/_meta/pages/blog/post-1.json     ← one sidecar per page
/_meta/types.json                 ← your content-type definitions
/_meta/theme.json                 ← your site theme
/_meta/routes.json                ← the route map
/_meta/release.json               ← what this deploy shipped

Each page gets a sidecar JSON next to the HTML with its full field values and references:

{
  "id": "article:my-post",
  "slug": "my-post",
  "title": "My Post",
  "contentType": "article",
  "path": "/article/my-post/index.html",
  "fields": { "...": "all field values" },
  "references": { "author": ["author:alice"] },
  "deployedAt": "2026-04-28T12:00:00.000Z"
}

Two things this buys you:

• No lock-in you have to take on faith. The repo is a git clone-able copy of your whole site — the rendered pages and the structured data behind them. You can reconstruct or move the site from these files without StaticOwl.
• Free hosting from anything that watches a repo. Point GitHub Pages, Cloudflare Pages, Vercel, or Netlify at the same repo and it auto-deploys on every push.

The mirror is push-only — StaticOwl writes to the repo and never reads it back, so if you edit the repo by hand your next deploy overwrites those edits. Connecting a repo needs a token with write access to it; your StaticOwl operator sets that up.

Managed CDN — atomic releases and replay

The managed CDN target stores every artifact by content hash and flips a single pointer to go live. That makes a few things possible that a plain file sync can't:

• Atomic deploys. The whole site swaps at once — no mixed-state window.
• Instant rollback. Reverting is a pointer change, not a rebuild or a re-upload.
• Efficient large-site rebuilds. Changing one article in a million-page site uploads only the handful of changed artifacts.
• Point-in-time replay. You can serve the site exactly as it stood at a past deploy — which, with the audit chain, lets you prove which bytes were live when.

The trade-off is that it runs on StaticOwl's CDN runtime rather than being plain files on any host. Running it alongside the static export (so you keep a portable copy too) is a supported combination.

Choosing

The deploy target is set at the account or install level, not per build — on StaticOwl's hosted plans it's managed for you, and on a self-hosted install your operator configures it. Day to day you just run builds; see Publishing & environments.

See also

• Publishing & environments — environments, build modes, custom domains.
• Redirects — real 301/302s that survive a host move.
• Audit chain — the tamper-evident history behind replay.