FAQ

Quick answers to the questions that come up most often. Each answer links to the full page that treats the subject in depth.

Getting started

Where is my admin interface? Standard systemd installs bind the CMS to loopback only (127.0.0.1:3001 by default for instance 1) and put Caddy or nginx in front, so you reach the admin through your site’s admin domain. Quick and offline installs serve the admin directly at port 8080 of the host.

Does building the site happen automatically when I edit? No, builds are explicit operations, dispatched from the dashboard, via a configured build webhook, or run by hand. Every build is logged, and failure never overwrites your live site.

I installed and it keeps sending me to /setup. A fresh install ships with a placeholder admin password, and every request is redirected to the setup page until you set a real one (12+ characters with upper, lower, and digit). Once set, the setup page disappears.

The /health endpoint? Every instance exposes a health endpoint for monitoring: {"status":"ok","db":"ok"} on success, 503 when the database is unreachable.

Accounts and access

What’s the difference between admin and editor? Admins manage users, builds, settings, API keys, and all content. Editors can’t reach those; their access can be narrowed further by allowed content types and languages.

Why can’t an editor publish? If the approval workflow is enabled (Settings → Workflow), non-admin publish attempts become submit-for-review. Switch it off for direct publishing.

Why is everyone logged out after changing the secret? The CHINASKI_SECRET env var signs sessions and derives the key that encrypts stored credentials. Rotate it deliberately: sessions die immediately, and encrypted settings (SMTP password, secrets) must be re-saved afterwards.

I’m locked out by failed logins. Lockouts are fixed per IP: 60 seconds after 5 failures, 5 minutes after 10, 30 minutes after 20, and they survive restarts. They can’t be tuned in the admin area; the configurable failure-threshold setting is only for alerts in the event log.

Content and building

Changes aren’t showing on the site. Publishing content updates the database, not the static output; the site only changes when a build runs. Trigger one from the dashboard (or by API/webhook), then check build status and the build history, including any promotion-guard blocks.

A build finished but the site looks old. Builds promote only healthy output: render errors, quality-guard breaches (page-count drop, broken links, accessibility regressions), or manifest failures stop promotion and keep the previous site serving. The build history shows which check refused; you can force a promote for that build if you accept the regression.

How long can a build run? Builds have a hard ceiling of 30 minutes; a timed-out build is killed and leaves the live output untouched.

Where did my post go? Deleted content goes to trash, not straight out of existence; purges of trashed items run periodically. Check the Trash list to restore.

Backups and recovery

What gets backed up? The daily system backup captures the database (14-day default retention) and mirrors media. In-app backups create full tar.gz archives (database, media, themes, templates), verified after creation by default, optionally pushed to DigitalOcean Spaces.

Restoring into a new host: connection issues? Restore the old env file before anything else: the encryption key for stored credentials derives from your CHINASKI_SECRET, so a restored database opened under a different secret silently loses stored secrets; set the original secret first. Full runbook on the disaster-recovery page.

Security posture

Session cookies are signed, Secure, HttpOnly, and SameSite=Lax; CSRF tokens protect every state-changing admin request; a per-request CSP nonce blocks inline scripts.
Outbound integrations are validated against private/internal address ranges (webhooks can’t target your internal network), never follow redirects, and cap response size.
Uploads are identified by file content, not extension; SVG uploads are rejected outright; bulk CSV import is capped (4 MiB, 5,000 rows, single transaction).

Troubleshooting quick pointers

Logs go to the system journal (with structured JSON lines for high-signal events, including client IPs: README documents a journald retention policy snippet you can adopt to match your privacy policy).
A build is “busy” only while one runs; the lock expires on its own if a build dies without reporting.
Port conflicts / proxy mismatches have their own page (see Troubleshooting → Port Conflicts).

Feature map honesty

No plugin ecosystem, no hook architecture, no theme marketplace; no drag-and-drop editor; no Postgres (multi-tenancy is a roadmap item). Extending the system means code changes, not installs.
The core is MIT-licensed.

Language and multilingual questions

Multiple languages, path/subdomain URL modes, hreflang alternates and a static language switcher are built in and documented on their own pages. Per-language settings cover blog titles and cookie notice texts, and the admin UI itself ships localized.
Scheduled publishing respects the site timezone; content whose language you remove from the active set can’t be “orphaned”: the admin refuses removal until that content is deleted or reassigned.