Self-Hosting Multiforum
Multiforum now provides two supported self-hosting paths:
- Local quick-start for evaluation and development.
- Single-host production Compose for an operator-owned public instance.
Both paths use the official backend and frontend container images. Building two
repositories, manually creating ServerConfig with Cypher, and configuring
uploads before the first login are no longer required.
Choose a path
| Goal | Recommended path |
|---|---|
| Try Multiforum locally | Installation quick-start |
| Run on an existing Linux host | Production Compose |
| Provision an AWS host | AWS Terraform example |
| Develop Multiforum itself | Contributor guide |
Architecture
The image-based stack contains four production services:
Internet → Caddy (HTTPS) → Nuxt frontend → GraphQL backend → Neo4j
The browser uses the frontend's same-origin /api/graphql proxy. Only Caddy
publishes public production ports. The frontend, backend, and Neo4j host ports
remain bound to loopback for diagnostics.
The local quick-start omits Caddy and uses local-development authentication. Production uses Auth0 and automatic HTTPS.
Automatic first-run setup
When the database is empty, the backend can create:
ServerConfig;- the default user, moderator, elevated moderator, and suspended roles; and
- the first administrator relationship.
The quick-start supplies local bootstrap credentials. Production uses
MULTIFORUM_SUPERADMIN_EMAIL as a tightly controlled break-glass identity and
auto-provisions the server configuration. No manual Cypher bootstrap is needed.
Capability-aware integrations
Email, maps, geocoding, and object storage are optional. The backend exposes an instance setup status describing whether each capability is configured and enabled and which required variables are missing. The frontend uses that status for setup guidance instead of allowing unconfigured integrations to fail at runtime.
Review the same information in Admin → Instance Setup. Configure only the features your community needs:
Operational tooling
The repository includes tested commands for the single-host production path:
| Command | Purpose |
|---|---|
scripts/verify-self-hosting.sh | Verify selected images, container health, HTTPS headers, and GraphQL |
scripts/backup-self-hosting.sh | Create a consistent cold backup with checksums |
scripts/restore-self-hosting.sh | Guard and verify destructive volume restoration |
scripts/upgrade-self-hosting.sh | Pre-pull pinned images, take a safety backup, and recreate safely |
scripts/upload-self-hosting-backup.sh | Encrypt and copy the newest verified bundle with Restic |
scripts/check-self-hosting-backups.sh | Report local and off-site freshness and integrity |
See Backup and Restore for scheduling, encrypted off-site storage, health monitoring, and recovery drills.
Current scope
The production foundation intentionally targets one host and one frontend replica. It does not yet provide multiple application replicas, managed or clustered Neo4j, zero-downtime upgrades, unattended restores, or an open-source production OIDC provider. Auth0 is currently the supported production identity provider; local-development authentication must not be exposed publicly.
Kubernetes and a Rancher-like Slack/Discord integration surface are not part of the current self-hosting roadmap.