Static First

The Chinaski public site is plain static HTML served from disk, and the database is only touched while you author content. This page explains why it is built that way and what it means for your daily work.

How your site is actually delivered

Chinaski runs as two cooperating pieces:

• The CMS: a private admin application where you write and organize content. It stores everything in a built-in database and ships with the site’s admin interface.
• The builder: a separate process that reads that database, renders your pages through templates, and writes plain static HTML files to disk.

Your web server serves those static files directly. The CMS application is never in the public request path. In the stock deployment the public hosts are static file servers, and the server configuration backs this architecture up; it serves the generated output directory from disk, with a narrow exception described below.

Why it’s static, not dynamic

Because the published site is just files:

• No trackers can slip in. Nothing executes on the public site by default, and there is no mechanism that could inject a beacon into your pages.
• Attack surface stays small. The admin application runs bound to a loopback address (localhost only), not a public interface.
• Nothing to leak. The database (content, accounts, drafts) lives on the authoring side and is not exposed to public requests.

Builds are explicit

Saving or publishing content does not automatically rebuild the site. A build is triggered when you start one from the admin dashboard, via a configured webhook, or by running the builder yourself. Builds are deliberate operations with a visible log, not background side effects. Each build is logged so you can review exactly what was written.

Only one build runs at a time; a second trigger reports the build is already in progress rather than racing. Builds are incremental by default, with a full rebuild available when needed.

The site never goes down mid-update

Writing output is deliberately defensive:

• Files are written atomically: new content is staged and renamed into place, so the public server never serves a half-written file.
• If the build fails or times out, the previously built site stays live, untouched and intact.
• Before a new build goes live, the builder compares it against the last good build. If something went wrong (a sudden page-count drop, a counted spike of broken links), the builder declines to promote it and the previous site keeps serving. Stale output is the worst case, not a broken one.
• Builds are capped at a 2 GiB write budget, with automatic cleanup so an overflow aborts the build rather than filling the disk.

The one exception: forms

Because the public site is static, form submissions can’t be handled by the file server. This affects forms on contact and newsletter blocks: submissions POST to /forms/<the form's address>, which the web server proxies to the CMS app. The stock deployment config includes this proxy; removing it is only safe if the site has no forms.

Pages that are password-protected are also static: the protected content ships inside the HTML file and is unlocked in the visitor’s browser by a password check. That means the content is technically present in the page even while the gate is locked; a visitor who reads the raw HTML can extract it.