System requirements
This manual targets a single Linux VPS using a Node backend, a built frontend, and a persistent local SQLite database. Use a downloaded release with its matching migration history.
Required software
| Component | Requirement |
|---|---|
| Node.js | Node 24.12 or newer in the 24.x line for the deployment examples |
| pnpm | 12.14.0, matching the downloaded release |
| Application | A complete downloaded release, its lockfiles, shipped migrations, and installed dependencies |
| Database | Persistent local SQLite through the included libSQL client; no separate database server is needed |
| Resend or SMTP for verification and password-reset messages | |
| Production host | Linux with systemd, a reverse proxy, a domain name, and an HTTPS certificate |
Install Node and pnpm using your organization's approved method. Check node --version and pnpm --version before installation. Install all locked dependencies needed by the release's migration tooling.
For Docker installation, use a running Docker engine and an image for the host's platform. Node and pnpm are needed separately when applying migrations through the matching extracted ZIP release.
Optional media tools
| Feature | Additional requirement |
|---|---|
| Images | Sharp and its native runtime support, installed with backend dependencies |
| Audio uploads | Enable audio and provide ffprobe |
| Video uploads | Enable video and provide both ffprobe and ffmpeg |
| Required malware scanning | A reachable ClamAV daemon socket with service-user access |
Audio, video, and malware scanning are disabled in the supplied configuration. Startup checks enabled audio/video tools. Configure executable paths and scanner access before enabling these features.
Storage and capacity
Keep the database, media originals, profile images, and content-rebuild exports on persistent local storage outside replaceable application files. Keep backup storage separate from these paths and from public frontend assets. Source storage roots must be distinct and non-overlapping; backup validation rejects symlinks, hardlinked files, and special files.
Budget space for originals, image caches, database growth, completed backups, backup scratch space, and isolated restoration. Backup validation also needs a temporary database copy. A backup on the same disk does not protect against disk loss; copy validated bundles to independent storage.
Tested minimum CPU/RAM sizing is not specified. Measure representative uploads, transformations, traffic, and recovery drills. Set processing concurrency and storage limits to suit the host rather than assuming an untested capacity guarantee.
Network and deployment limits
Expose HTTPS through Nginx and keep the backend on loopback. Permit the outbound connections needed for email and configured public webhook destinations. Synchronize the server clock for schedules and signature verification.
The local database workflow supports one backend instance on one host. Do not run multiple application servers against the same SQLite file or use a shared network filesystem as a substitute for a supported multi-server design. The built-in backup CLI accepts plain persistent local file: URLs; remote libSQL/Turso, replicas, in-memory databases, encoded paths, and query-string connection options need a separate recovery design.
Continue with local installation or production deployment.