Home
Welcome to the Chinaski documentation; the complete, source-verified manual for the self-hosted CMS and static site builder called the boring-but-bulletproof option. Everything in the tree was fact-checked against the version of the code it documents; nothing hypothesized ships.
Sections
The convictions behind Chinaski and why it is built the way it is.
Install Chinaski and publish your first page.
The architecture and content model underneath Chinaski.
Everything about creating and managing content (pages, posts, blocks, stacks, forms, media, documents).
Run a site in multiple languages.
Build and customize themes with Template Toolkit.
Canonical URLs, social tags, sitemaps, and redirects.
Run Chinaski in production.
Accounts, authentication, and the security model.
Protect and restore your content.
Automate Chinaski via MCP and webhooks.
Exhaustive reference material (builder, app, env vars, settings, schema, templates).
Step-by-step walkthroughs for common goals.
Diagnose and fix common problems.
Project meta, releases, and how to contribute.
Which section for your question?
- “Can I use it / will it fit?”: start in Getting Started and Philosophy; the Requirements page is the fastest honest check.
- “How do I write/publish/schedule X?”: the Authoring section has one page per flow (pages, posts, forms, calendar, bulk, import/export).
- “How does the machine work?”: Core Concepts for the model; Reference for the exact facts (env vars, settings keys, schema).
- “How do I run it in production / serve it / keep it safe?”: Deployment & Operations, Backup, and Security.
- “Something’s not behaving”: Troubleshooting first, then the relevant section’s reference.
The things the product does by design
- Self-hosted, air-gap aware. Fresh installs run fully disconnected (no telemetry, no phone-home); connectivity features (email, webhooks, update checks, cloud backups) are opt-in.
- The public site is static output: work is database edits plus explicit builds; everything in the Authoring section edits the database, and every build either promotes completely or keeps serving what was live.
- Two roles + per-user scoping by language and content type; everything security-shape relevant is recorded in an audit trail plus auth/event logs.
- API + AI automation: REST with read/write API keys for scripts; the built-in MCP server so assistants work the CMS directly.
The fastest honest check for fit is reading what Chinaski is not for; if you need a plugin marketplace, that’s the door out.