Self-hosting overview

Plugboard is a normal Node application backed by PostgreSQL. There is no proprietary runtime, no clustering requirement and no dependency on a cloud service. If you can run a web application on a virtual machine, you can run this.

Four ways in

Method	Prerequisites	Best for
Portable bundle	None	Evaluation, training, a small site that wants one folder to back up
Installed as a service	None (uses the bundle)	Production on a single Windows, Linux or macOS server
From source	Node 20.9+, pnpm, PostgreSQL	Sites that already manage Node applications, or want to run from a checkout
Docker Compose	Docker and Compose	Sites standardised on containers, and anyone who wants digest-pinned updates

Most schools should use the service install. It is the portable bundle plus a platform service registration, an HTTPS certificate and an overnight update check, which is what “production” actually means for a single-server deployment.

Docker is the right answer if you already run containers, because updating becomes a digest change and rolling back becomes the previous digest.

What gets installed

Whichever route you pick, you end up with the same three things:

• The API process, listening on 4000 by default. Every /api endpoint, the connector host, and the in-process schedulers for SLA checks, monitors, backups and scheduled reports.
• The web process, listening on 3000 by default. Server-rendered pages for the console and the self-service portals.
• A PostgreSQL database. Supplied by the bundle, by your own server, or by the Compose stack.

Redis is optional. It is only used by the legacy people-sync and daily-digest worker; everything else runs on timers inside the API. Object storage is optional too, and only needed if you upload logos, photos or export files.

The shape of a production install

        Internet or your LAN
                 |
        [ reverse proxy / TLS ]      Caddy, nginx, IIS, or the API's own TLS
                 |
        +--------+--------+
        |                 |
   web :3000          api :4000
        |                 |
        +--------+--------+
                 |
           PostgreSQL

One origin serves both: /api/* goes to the API, everything else goes to the web process. Keeping them on one origin avoids cross-origin problems entirely, which is why every example in these docs is written that way.

The one path that needs special handling is /api/events/*. It carries server-sent events, so any proxy in front of it must not buffer, or realtime updates arrive in bursts instead of immediately.

Sizing

Plugboard is not demanding. The dominant cost is PostgreSQL, and school-sized data is small.

School size	Suggested	Notes
Up to 1,000 devices	2 vCPU, 4 GB RAM, 40 GB disk	Comfortable, including the database
1,000 to 5,000 devices	4 vCPU, 8 GB RAM, 100 GB disk
Above 5,000 devices	4 to 8 vCPU, 16 GB RAM, 200 GB+	Consider a separate database host

Disk grows with the audit log more than anything else. Retention is configurable; see audit and retention.

What you own

Running it yourself means owning five things. None of them are hard, but all of them are yours.

1. The certificate, and its renewal.
2. Backups, and having restored one.
3. SECRETS_MASTER_KEY, kept somewhere other than the server.
4. Deciding when to update, and running the command.
5. Noticing when it is down, before your users tell you.

Each has a page: HTTPS, backups, secrets and keys, updating, and keeping an eye on it.

Next

Start with what you need, then pick an install method.