Docs

Deploy

From repo to a live client domain — one container, any host.

Docker (recommended)

$ docker build -t noodleverse .

$ docker run -d -p 80:3300 \

-v ./content:/app/content noodleverse

The scaffold ships a Dockerfile. One container holds the site, studio, API and database — including a framework mounted via the site module; the content/ volume holds the SQLite file and uploads — back it up by copying the folder.

Headless frontends

Went fully headless (no site:)? Deploy the CMS container as above and the frontend wherever it lives — Vercel, a CDN, anywhere that can fetch. Set webhooks: { onPublish: "https://…/api/revalidate" } in cms.config.js: every publish POSTs { event: "publish", type, slug, id } to it, so cached pages revalidate. Set siteUrl: so the CMS knows where the live site is.

Environment variables

Variable

Purpose

PRELO_CONFIG

Path to the config file. Defaults to ./cms.config.js.

NODE_ENV

Set to “production” by the Dockerfile.

your own, via env: […]

Names listed under env: in cms.config.js are required at boot — a missing one fails loudly with the exact fix.

There is no secret to manage: sessions and API keys are random values stored hashed in the database, so Prelo needs no signing key of its own.

Where to run it

Anywhere a container runs: a $6 VPS with docker compose or Coolify, Fly.io (fly launch works as-is), or the client’s existing cloud. Put hosting on the client’s card on handover day — it’s their site.

Updates and backups

$ npm update prelo && docker compose up -d --build # update

$ cp -r content backup-$(date +%F) # backup

Custom fields live in JSON columns, so updates never need a database migration. A backup is one folder copy; a restore is one folder copy back — prelo export does the same from the CLI.

Previous← Embed & one process NextCLI →