Run it on a platform service

Platform services run your program for you and give you HTTPS and a public address. This page lists what the site needs from such a host. It is for a technical person choosing one.

On a site we host

Not relevant to a site we host.

warning

No platform-specific guide has been tested. There is nothing here for Fly.io, Railway, Render or any other service in particular, and no recipe that has been run on one. What follows is what the software needs, taken from how it works. Check each against your host's documentation.

What the host must provide

The site needs	Detail
A way to run Node 22.13 or newer, or a container	For a container, use the Dockerfile in Run it in Docker. The host then needs to build or pull the image you give it.
A start command	npm start, or node server/launcher.js. The launcher is what allows one-click updates. The container's own command is the same launcher.
Real environment variables	Set the site's settings in the platform's settings page, not in a file. PORT and DATA_DIR must be real environment variables, because the launcher reads them before the server starts.
The port the platform expects	The server listens on PORT, which defaults to 3001. If the platform sets PORT itself, the server uses it; if it expects a fixed port, set PORT to match.
HTTPS	The platform normally provides it. Set SITE_URL to the public address, with https://, and see Put it behind HTTPS for why.
A health check	GET /api/health answers 200 with {"status":"ok", ...}. Give the platform that path.
Somewhere to keep data	One of the two choices below.

Where the data lives

By default the database, the uploaded files and the downloaded updates are all in a ./data folder beside the code. Choose one:

1. A persistent volume mounted where ./data is. Mount it at the data folder in the working directory, or set DATA_DIR, SQLITE_PATH and STORAGE_LOCAL_DIR to paths on the volume. Run exactly one instance, because SQLite and local files cannot be shared between instances.
2. No persistent disk at all. Use an external database (PostgreSQL or MySQL, see Choose a database) and S3-compatible file storage (see How files are stored). Then the host can replace the program freely, and you can run more than one instance. With a database but no S3, uploaded files would be lost with the disk.

Updates on a platform

If the disk is throwaway, or there is more than one instance, or the platform replaces the program from an image on each deploy, set:

UPDATE_MODE=notify

The site then tells you in its admin panel when a new version is out, and you update the way you deploy (a new image or a new copy of the code). Without this, a one-click update would unpack a release onto a disk that may be wiped at the next restart. See How updates work and Update a Docker site.

Settings to set

At least SITE_URL, ADMIN_USERNAME, ADMIN_PASSWORD, LICENSE_KEY, an email provider and its keys. See The settings every site needs. Secrets can come from the platform's own secret store as ordinary environment variables, or from a secrets manager: see Use a secrets manager.

Check afterwards

After the first deploy, open the platform's console for the program and read the log. Look for:

[db] schema is up to date (...)
[server] version 1.6.12 listening on http://localhost:... (production)

Any [config] line names a setting to fix. Then open https://your-address/api/health, and finish with After installing: first login and go-live checklist.