Hosting · Self-hosted
Your server, your data, your rules.
Run Webrack entirely on your own infrastructure from a self-contained Docker bundle. Student data never leaves your premises, it works air-gapped, and you control updates, identity, and backups. The strongest answer to data residency.
Architecture
Everything inside your trust boundary.
The bundle ships the application, its database, and object storage as containers you run behind your own reverse proxy and TLS. Classroom browsers reach it over your network; nothing in the core path calls out to us.
What you deploy
A self-contained container bundle.
The application
A containerised web application that serves the rack editor and manages accounts, classes, and saved patches. Runs on a single VM or your container platform.
Its own data store
A bundled database and object storage for rosters and patches. No external managed service is required; back it up with your standard tooling.
TLS + your identity
Terminate TLS at your reverse proxy and wire staff sign-in to the identity option you choose. Student join stays code-and-name, no email.
Requirements
What it asks of your environment.
| Host | A Linux host able to run containers — a single VM suffices for most schools; scale out for larger cohorts. |
| Networking | A hostname and TLS certificate; reachable from classroom devices on your network. No inbound internet required. |
| Outbound access | None needed for core function. Optional licence checks can run online or be issued offline for air-gapped sites. |
| Storage & backups | Disk for the database and saved patches, plus your normal backup process. Sizing guidance in the pilot pack. |
| Maintenance | Pull and apply new images to update, on your schedule. We supply the runbook and release notes. |
Exact CPU / memory / storage sizing depends on your peak concurrent students and is documented in the pilot pack.
Data & compliance
Residency, answered outright.
- Student data stays on your premises — it never reaches our systems
- Runs air-gapped with an offline licence
- You own backups, retention, and deletion end to end
- Student join needs only a code and display name — no email
- No telemetry by default; any diagnostics are opt-in
- No secondary use, profiling, ad-targeting, or model training on student work
The strongest residency story
When the application and all its data run on your hardware, questions about cross-border transfer and foreign legal reach largely disappear. Nothing leaves the building.
Paperwork still included
Self-hosting does not mean going it alone — a signable DPA and a plain-language privacy fact sheet come with the pilot, the same as the hosted tiers.
Best for
Who chooses self-hosted.
Strict data-residency rules
Districts and institutions whose policy requires student data to remain on-premises or in-country.
Universities & colleges
Departments that already run infrastructure and want full control for teaching and research deployments.
Capable IT teams
Schools and districts comfortable running a container or two and applying updates on their own cadence.
Run it on your own server.
Start a self-host pilot and we will share the bundle, the runbook, and the privacy paperwork.
FAQ
IT questions.
Can it run fully offline / air-gapped?
Yes. The core application needs no outbound internet access to function — audio is computed in the browser and the application talks only to its own database and storage. With an offline licence it runs on an isolated network, which is the strongest possible answer to data-residency and CLOUD-Act questions.
What do we need to run it?
A Linux host that can run containers (a single VM is enough for most schools), a TLS certificate, and somewhere to keep backups. The pilot pack documents exact CPU, memory, and storage sizing for your expected number of concurrent students.
How do students sign in?
Students join a class with a code and a display name — no accounts. Staff accounts can use the identity option you configure. Because you run the deployment, authentication and network access are governed by your own policies.
Who handles updates and backups?
You do, on your schedule. Updates are published as new container images you pull and apply; backups are standard database and object-storage backups you run with your existing tooling. We provide the runbook.