Own Your Content
No lock-in, no proprietary store. Everything that makes up your site (the content database, the generated HTML, the media files) is a plain file on your own server, in standard formats, that you can open, copy, or move with everyday tools.
Where your content lives
- A SQLite database file. All content (pages, posts, blocks, snippets, forms, media records, settings) is stored in SQLite. It is a single file with no server process to run, no special database software, and no credentials to manage. Copying that file to another location is a valid backup.
- A folder of generated HTML. The public site is static output written to disk, per language, on the same server.
- An ordinary media directory. Your images and uploads are regular files in the public media folder.
Theme files and the default site templates are plain folders on the filesystem too: they’re included in backups and restores like everything else.
Backing up is just copying files
Because content and media are plain files, backups amount to copying files. Deploy scripts create a database snapshot plus a media copy on a schedule, and each backup archive is stored as a dated tarball on your backup path. You control the location and the retention.
Beyond that, the CMS can produce a downloadable archive containing a verified snapshot of the database, the media directory, theme files and templates, plus a checksum manifest; the backup page has the details.
Getting everything out
Every business object has its own export endpoint, with JSON and CSV variants where they apply:
- pages and posts (all content fields, including scheduling and SEO fields, filterable by language and published state)
- blocks, snippets, and stacks
- categories, navigation items, and redirects
- media metadata
- form submissions (per-form CSV or JSON)
- documents, users, the audit log, and the calendar (iCalendar export)
- settings, as a JSON file
Settings exports exclude encrypted secrets like passwords and API keys; they are never written to the export. Where CSV is provided it is Excel-friendly (UTF-8 with a byte-order mark), and large exports stream rather than buffering in memory.
These exports are the same formats the importer takes on the way back in, so export pairs with import when you move data between instances.
Self-hosted by design
Chinaski is self-hosted by design: you own the server, the database, and the backups. Nothing relies on a service outside your machine, no telemetry, no license phone-home, and after installation it runs without internet access. Dependencies are ordinary system packages or open-source modules, so nothing about your setup is hidden from you.
License
The core of Chinaski is MIT-licensed. Planned commercial Pro modules are enforced via locally signed license files, no external validation and no phone-home, so they remain air-gap compatible.
Bottom line
Nothing that runs between you and your content is hosted anywhere else. Everything you author is in one readable database file and an ordinary folder of generated HTML, and every content type has a straightforward export path.