Instances

A Chinaski instance is one complete site: its own app process, its own database, its own files, its own backup set, its own secret. Running several sites means running several instances; side by side on the same server if you like. This page explains the model and, importantly, what’s isolated and what isn’t.

One instance, one site

Every instance is a full, standalone copy:

Its own admin app process (a systemd service like chinaski@1, chinaski@prod, chinaski@staging: the same unit pattern runs any number)
Its own SQLite database file: content, users, forms, logs, everything
Its own output directory: the static files your web server publishes
Its own media directory
Its own master secret (in a permission-locked file created at install)
Its own port (3001, 3002, …; each unique on the host)
Its own backups directory and schedule
Its own domains (via the reverse proxy, or managed through the Manager)

Nothing is shared between instances: no content, no users, no forms, no logs, no sessions. Sites can’t see each other, and neither can their admins.

Why this design

The software’s stated audience makes the reasoning plain: “Agencies managing multiple client sites: one instance per client, identical stack, reproducible deployment, clean audit log, no vendor lock-in.” Duplicating whole stacks is more disk, less risk: a breakout, a bad deploy, or a single bad actor in one instance touches that site and nothing else. When one client wants to leave, you hand them their database, output, and media directory: they’re all in one folder.

Isolation in practice

The process: each instance’s app is sandboxed by systemd to read/write only its own directory, even a bug in one site’s CMS code cannot touch another site’s files.
The database: each site has its own SQLite file, stored with user-only readability. There is no shared database server to break into, and credentials from one instance are meaningless on another.
Secrets: every instance has a unique master secret; leaked credentials are scoped to one site.
Sessions: admin sign-ins live entirely in one instance’s database and are signed with that instance’s secret; an admin for one site simply has no session for another.
Ports and domains: each instance listens on its own loopback port behind the proxy; if the optional Chinaski Manager is used, port uniqueness across instances is enforced by the Manager itself.
Backups and deploys: backups and build/deploy jobs are per instance; a failed build on one site never affects another.

Running many sites

Two ways, and they cooperate:

By hand: the shipped systemd unit pattern plus the one-command installer. Each install is an instance; upgrade sites one at a time with the per-instance deploy script.
With the Manager (separate product): a control panel that provisions instances, runs their lifecycle (build, deploy, roll back, start/stop), attaches domains (regenerating the web-server config automatically), takes per-instance backups, and monitors instance health. Its Discovery feature finds instances already running on the server (set up with systemd, like the ones above) and imports them for management.

One efficiency option exists for many-instance hosts: Perl dependencies may optionally be installed into a shared library so each instance’s deploy doesn’t re-download them (opt-in, and each instance’s unit must include the path).

What “multi-tenancy” doesn’t mean here

There’s no multi-tenant database: every site keeps its own data file, per the project’s own design statement (“one instance per client”). An in-app multi-tenant tier with Postgres is on the roadmap and unshipped.
The Manager’s “tenants” is a manager-level grouping for organizing instances and permissions; it does not put several sites into one database.

The one-line summary

Ten sites = ten small, identical, isolated stacks plus one optional control panel; each site can be backed up, restored, upgraded, deployed, transferred, or deleted individually, and a problem in one never holds the others hostage.