Durability

Chinaski is designed to outlive trends: of software fashion, platform churn, vendor lock-in, even the internet itself. This page explains what that means in concrete terms: durable URLs, durable content, and durable output formats, and what makes them that way.

Durable URLs

Links are promises. Chinaski keeps them like this:

Renames never break links. When you rename a published page or post, or change the blog’s URL prefix, redirects for every old address are generated on the next rebuild, automatically. Old URLs keep working as long as your site exists.
One domain is enforced with a built redirect: whichever spelling of your host you didn’t choose (www or apex) sends visitors to the one you did, preserving the page.
URLs are files. Each page statically exists as an HTML directory on disk. Readers reach them through any web server that can serve a file: the content system doesn’t need to be alive, or even running, for the site to work. There are no framework-specific URL schemes to rot.
Translations and alternative links stay coherent. Each language has its own sitemap, redirect rules, and cross-marked hreflang tags; discoverability survives redesigns of menu structure above it.

Durable content

One file, no servers. All content (pages, posts, media metadata, accounts, audit history) lives in a single SQLite database file. Backing it up is copying a file; there is nothing to rediscover or reconfigure during a restore. No credentials, no network path, no migration ceremony between minor releases.
History is built in, not purchased. Every save takes a revision snapshot; every content mutation is recorded in an audit log; form submissions and their metadata are retained per your retention rules. Restoring to yesterday is a supported operation that doesn’t require forensic archaeology.
Backups are verified, not assumed. Each archive is smoke-tested after creation, and each scheduled run records its outcome in a log: success, failure, and verification result per backup.
Drafts survive crashes. Unsaved edits live server-side as you work, so closing a browser tab or losing a session after a long stretch of writing doesn’t eat the afternoon.
No internet ever required. Installation can be done from an offline bundle; after that, no telemetry, no license phone-home, no CDN dependencies. If the network disappears, your site exists on disk and the admin on your server: planned, not accidental continuity. There is an “end of the world” deployment mode: the server answers plain HTTP forever, nothing to renew, nothing to expire.
Dependencies are boring on purpose. Everything the software depends on ships in the stable OS release, so major rewrites of third-party libraries can’t vaporize behavior. The dependency list is short by design: nine modules, kept deliberately small.
Even the docs ship with the instance. Help articles visible in the admin area are stored in the same database, so they travel with your backups.

Durable output formats

The site’s published output sticks to the formats the web has never deprecated:

Plain HTML, generically styled, no required runtime: the public site has zero runtime JavaScript, by construction rather than by policy. Nothing for a tracker to attach to; nothing to break when a third-party vendor changes its terms.
Standard feeds and files, regenerated on every build: sitemap.xml, RSS feeds, robots.txt, a security policy file (security.txt), and redirect rule files in portable formats other servers can use.
Structured data (JSON-LD) is written directly into pages as plain HTML, readable for decades, by search engines or scripts you haven’t written yet.
Offline-first optional extras: a service worker and offline page are part of the generated output when PWA features are enabled.
The admin server itself can survive without internet: plain HTTP, no certificate to renew, no external service to fail.

What we deliberately don’t do

Honesty about trade-offs is part of the same principle:

There is no drag-and-drop visual page builder. Body content uses a rich-text editor; everything else is structured forms. A visual builder is on the roadmap; it does not exist today.
There is no plugin ecosystem or marketplace, no hooks, no registries, no chains of third-party code that silently change what your site does next year.
The database is SQLite, one file per instance. A multi-tenant tier with Postgres is on the roadmap, not shipped today; the migration path is not yet defined.
You own the server, the database, and the backups. Durability here means your responsibility, not our custody.

The quiet bet underneath

Underneath all of this is one bet: stable tools outlast clever ones. The language the system is written in (Perl) has broken no compatibility in decades of minor releases; the SQL engine (SQLite) treats your database as a file; the output is HTML files on disk; the admin interface avoids frameworks that rewrite their idioms every two years. It’s boring on purpose; a site built on Chinaski should still render fine in a decade with zero maintenance, and the content should be exactly where you left it.