Deploy to Netlify
Publishing Chinaski’s built output to Netlify is possible (the builder already emits Netlify-format redirect rules), but the repo ships no Netlify-specific pipeline, so this page documents the verified mechanics and the two caveats to check before shipping there.
What the builder produces
On every build, the output root gains a _redirects file containing your redirect rules in Netlify’s own format: plain lines of old-slug new-slug status-code, wired to the redirects you manage in the admin (the build log says “N Netlify redirect rule(s) written” when rules exist). This is the main compatibility surface with static hosts: build, then upload the directory, and your simple path redirects work as-is.
Everything else is ordinary files: per-language output trees with index.html files, the PWA pieces (sw.js, manifest, offline page), sitemaps and feeds, and the media folder tree.
Caveat 1: the canonical-domain line
When a Site URL is set, the builder also appends a canonical-domain rule to _redirects that 301s the www/bare alternate host to your canonical one. Its trailing ! marker is Caddy redirect syntax, not Netlify syntax. If you deploy to a strict Netlify parser, review that generated line before shipping: drop or rewrite it per Netlify’s redirect rule grammar. (The rest of _redirects, plain path pairs with numeric status codes, is in the standard format.)
Caveat 2: pattern redirects aren’t in the file
Pattern redirects (wildcards with substitutions) are deliberately never written into _redirects: the simple file format can’t express them safely. If your site relies on pattern rules, those need implementing at the host rather than riding along in the file.
Static-hosting reach: what a pure static host can’t see
Two CMS features don’t exist in the static output and must reach the CMS itself:
- Form submissions POST to
/forms/<slug>on the CMS. On a static host there is no destination, unless you set the CMS base URL, in which case embedded[form:slug]shortcodes render as iframes pointing at the CMS-hosted form, and submissions land where the CMS is reachable. - Document downloads are served dynamically (download counting and publish state); a static-only deployment cannot serve them; documents feature requires the dynamic proxy route.
In short: Netlify hosting is viable for pure content sites; form- or document-heavy sites need the CMS reachable (via base URL) or another hosting model.
Pipelines
There is no built-in “push to Netlify” deploy target; the built-in outbound deploys are rsync-over-SSH and S3-compatible buckets (Settings → Deploy). To get builds onto Netlify you wire your own conveyor (netlify CLI/config, a repo-based pipeline, or scripted upload) triggered after each build: the output directory plus _redirects is the self-contained artifact, re-emitted fully on every build.
Language-mode caveats: a site deployed in subdomain URL mode need separate deploy targets per language subdomain; path-mode sites deploy as one tree.
A note on headers
Cache behaviors in the shipped static examples (short cache on HTML, immutable across .woff2 fonts, no-cache on sw.js) are implemented in the reverse-proxy example files for your own server, not baked into the build. On a managed static host, header rules are a host configuration concern; apply them there as appropriate to your provider’s rules system.