Built on Perl

Chinaski’s whole architecture (a Perl CMS, a Perl static-site builder, and an SQLite database) rests on a deliberate bet: boring technology outlives exciting technology in production. This page explains the reasoning behind that choice, in the project’s own words, and what it means for you as an operator.

A decades-stable language

Perl 5 is boring in the right ways. The binary interface has not broken between minor releases in decades. Dependencies don’t rename themselves. The language ships on Debian by default, with no compiler added on top. A Perl program written in 2005 still runs today. In the project’s view, that is the correct engineering choice for infrastructure software that needs to be debuggable at 2am by someone who didn’t write it.

The attack surface argument likewise favors stability: a fixed language with Debian-packaged dependencies is smaller and more auditable than a stack whose node_modules tree or requirements.txt shifts underneath you between releases.

What the project itself uses

The admin application (Mojolicious), the static builder (Template Toolkit), the embedded database layer (DBI with DBD::SQLite), and the image processing (Imager; no ImageMagick shell-out) are the practical choices. Security pieces are also standard: password hashing by bcrypt through Crypt::Passphrase, AES-256-GCM encryption for stored credentials and HMAC session signing via CryptX, and DateTime with DateTime::TimeZone using the IANA timezone database for correct scheduling.

Wherever a subsystem needs optional power (the Markdown importer, for example), those modules load lazily and only at the moment they’re needed. A site missing one of them boots and serves everything else; only that one route degrades, with a clear message in the admin area.

The dependency bet

Most content management systems accumulate surface area: plugins, integrations, analytics endpoints, CDN assets. Each addition bets the added capability is worth the added complexity and attack surface, and as the project’s README puts it, most bets pay off in demos and lose in production. Chinaski makes the opposite bet.

Working outcomes of that bet, as the project documents them:

• A small dependency list contained entirely in Debian stable: a fresh install resolves wholly from system packages, with no compilation.
• Zero runtime JavaScript on public output: a structural guarantee rather than a policy promise. The Caddy web server serves static files from disk; the Perl app is never in the public request path, so there is no mechanism for a beacon to ship with your pages.
• Air-gap compatible by default: no telemetry, no license validation against an external server, no CDN fonts or icons. Once installed, Chinaski doesn’t need the internet. All outbound-capable integrations (update checks, SMTP, webhooks, cloud backups) ship off until you deliberately turn them on.

Built with AI, runs without AI

Chinaski was written with AI assistance (Claude Code and Kimi) and is expected to be maintained the same way. Perl’s stability makes this unusually auditable: the language hasn’t changed its idioms in thirty years, so generated code reads cleanly top to bottom. The project’s stance is that AI fluency is the relevant contribution skill; Perl fluency is not required to maintain Chinaski.

Honest tradeoffs

The minimalism has real costs, which the project states plainly:

• There is no plugin ecosystem: no hook architecture, no plugin registry, no theme marketplace.
• The database is SQLite, not Postgres (Postgres is planned for a future multi-tenant tier).
• It remains operationally involved work: you own the server, the database, and the backups.

If you run many client sites and want identical stacks you can rebuild confidently, that trade is appealing. If you need the ecosystem a bigger platform brings, that’s exactly what Chinaski declines to provide.

What it means for you

The practical payoff of the language choice appears in operations, not marketing:

• Install once, reboot less. The stack ships as distro packages; no framework churn between system updates.
• Read the code. The implementation lives in a small number of files, written comment-first and structured so that fixes don’t require archaeology; the language’s thirty stable years of idioms keep everything plain.
• Auditable output. The security-relevant claims (session handling, at-rest encryption, no telemetry) are all enforced in single places in the code; nothing to audit across five directories.
• The core is MIT-licensed; future commercial Pro modules are planned to use locally signed license files with no phone-home, in keeping with the air-gap promise.