Skip to content

Choosing a deployment

There are three ways to run Plugboard, and only two of them are meant for production. Pick before you start, because moving later is possible but not free.

Portable bundleSelf-hostedManaged
Meant forEvaluation, training, a demoProduction, on your hardwareProduction, on ours
PrerequisitesNone at allNode and PostgreSQL, or DockerA browser
Who patches itYou, by running one commandYou, when you decideUs, on a ring schedule
Where the data isThe folder you unzippedYour serverThe region you chose
Who holds the keyYouYouUs, escrowed per deployment
Private network systemsDirectDirectVia a connector agent
HTTPSYour problemYour certificate or Let’s EncryptIncluded
BackupsThe folderYour responsibilityTaken and tested for you

If you are evaluating, do not deploy anything. Download the archive for your operating system, unzip it, double-click the launcher. It carries its own PostgreSQL and, optionally, its own Node runtime, creates a database inside its own folder, applies migrations, loads fictional sample data and opens at http://localhost:3000.

Everything works: every module, every screen, and every connector in demo mode. You can decide whether the product fits before anyone has to provision a server.

See the portable bundle.

You run it. This is the right answer when:

  • Your data cannot leave your premises, by policy or by a departmental rule.
  • The systems you most want connected (Active Directory, Synergetic on a local SQL Server, PaperCut, printers on SNMP) are on your network, and you would rather not run an agent.
  • You already run servers and a backup regime, and adding one more service is routine.
  • Your procurement prefers a perpetual or self-host licence to a hosted subscription.

What it asks of you, honestly:

  • A server that stays up. Two Node processes and a PostgreSQL database. A small VM is enough for a school of a couple of thousand devices.
  • A certificate. HTTPS is not optional for something handling student data. HTTPS and certificates covers the options, including an internal CA.
  • Backups you have actually restored. The application takes encrypted backups; getting them off the machine is yours.
  • Custody of SECRETS_MASTER_KEY. This is the one genuinely unforgiving part. A database restored without that key cannot decrypt its own connector credentials. Keep a copy somewhere other than the server.
  • Running the update when a release lands. One command, but somebody has to decide to run it.

Start at install it yourself.

We run it, on a host in a region you agreed during the sale. One stack per customer: your own containers, your own database, your own secrets, your own backups. Isolation is physical rather than a policy, so the answer to “is our data segregated from other schools” is “you have your own database, and here is its backup”.

This is the right answer when:

  • You would rather not own a server, a certificate renewal, or a patch cycle.
  • You want the update to have already run on somebody else’s instance first.
  • The data residency answer you need is a named country, and you want it in writing.

What it asks of you:

  • A DNS record, if you want your own hostname. See your own domain.
  • A connector agent if you want systems on your network connected. It is a single install, dials out only, and no inbound firewall rule is needed.
  • Confirmation of the onboarding page we send you, which is what triggers the deployment.

Start at what managed hosting is.

Where is our data held? Self-hosted: wherever your server is. Managed: the region on your deployment record, and only that region. Backups replicate within the region and never out of it. See regions and data residency.

Who can see it? Vendor access to a managed deployment is off by default and can be disabled outright by you. Every access is audited. Self-hosted, nobody but you has any path in at all.

What happens if you go away? Self-hosted keeps running; the licence check is local and offline. Managed customers can export a portable per-tenant copy at any time from Admin, Backups.

Can we get our data out? Yes, and without asking. The export is a normal feature, not a support request.

Is it audited? There is an append-only audit log covering every action, with configurable retention. See audit and retention.

Supported in both directions, and worth treating as a planned change rather than a surprise. It is an export, a provision, an import and a DNS change. The support page covers the sequence, including what to do about SSO redirect URIs, which are the part people forget.