K-12 operations platform
Every department. One system of record.
Helpdesk, assets, facilities, safety, HR, transportation, reservations, records and finance — sixteen modules in one application, sharing one user directory, one permission model and one audit log. Self-hosted on your servers.
Built by Melton Electronics for public school districts. Runs on district infrastructure — your database, your backups, your data.
- 16
- modules, individually toggled
- 1
- sign-on, one cookie, one origin
- 10
- first-party integrations
- ~30 min
- to a clean install
The problem
A district does not run on one system. It runs on eleven.
Each was bought to solve one department's problem, and each solved it. What none of them solved is the part that spans departments — and almost everything consequential in a district spans departments.
The Chromebook in a helpdesk ticket, the damage fee against it, the student who was holding it and the incident report that mentions all three are four records in four systems, joined together only by somebody remembering.
- A helpdesk system that has never heard of the asset register
- Facilities work orders in a shared inbox
- Drill logs in a binder and safety plans on a shared drive
- Rentals tracked in a spreadsheet with a separate invoice book
- Seniority in a workbook only one person can open
- Contract renewals remembered by whoever signed the last one
What is in it
Sixteen modules, six areas of the district
Turn on the ones you need. Every module shares the same directory, the same permissions and the same audit trail, so adding one in January does not mean another migration.
Technology
Helpdesk, devices, fees and account provisioning.
Facilities & operations
Work orders, preventive maintenance, custodial supply, projects.
Safety & security
Incidents, drills, plans, chemical registers, camera footage.
People
HR requests, onboarding, seniority, payroll inquiries, PD.
Students & community
Transportation, facility reservations, ID badging.
Records & finance
Student records, public records requests, contracts, finance.
Why it holds together
The four things that make it one platform
A suite is several products with a shared login page. This is one application — which is why a permission granted in one place is respected everywhere.
One directory
Every person exists once. A teacher who files a ticket, requests PD, books the library and holds a Chromebook is one record — not four accounts in four systems that drift apart the day someone changes buildings.
One permission model
Three layers: permission primitives, editable roles, and scoped grants. A substitute Principal at one building for two weeks gets exactly that, with an expiry date, and no cleanup task for anyone to forget.
One audit log
Every module writes to the same immutable log through one function. When a board member asks who released that footage or approved that payment, the answer is a filter, not an investigation.
One toggle per module
Turn on what you use. Disabling a module hides its navigation and dashboards and keeps its data intact, so a district can start with the helpdesk and add facilities in January.
Controls that survive an audit
The frictions are deliberate
Districts do not fail audits because software let them do too little. They fail because nobody can show who decided what, and when.
- Four-eyes co-sign. Protected permission changes and sensitive payments wait for a second administrator. The person who raised an item cannot be the one who approves it.
- Multi-factor on irreversible steps. Releasing an off-cycle payment asks you to prove it is you, because releasing is the step that cannot be undone.
- Dual-approval footage releases. Camera footage moves Principal → Safety Director → extract, and scrubs itself after 90 days.
- Break-glass, logged. Emergency elevated access exists, is time-bounded, and writes a record that is read afterwards.
- Scoped, expiring grants. Access tied to a building and a date, so temporary access actually ends.
Integrations
It joins the systems you already pay for
Apps install into CampusLink and declare typed contracts — identity source, SSO, device sync, data egress, service status. They never touch the core schema directly, so an integration cannot quietly become a dependency.
Where it runs
On your server, under your control
CampusLink is single-tenant and self-hosted. Student data stays on district infrastructure, inside district backups, subject to district retention — not in a vendor's multi-tenant database.
- Ubuntu, nginx, MariaDB, PM2. One host, one Next.js process, one background worker. A clean install takes about thirty minutes.
- Your SAML IdP. Entra, Okta or Google Workspace. Group and title claims map to roles at login.
- Your database, not ours. Student records sit in a MariaDB instance you administer and back up. There is no vendor-side copy, and no subprocessor holding your data.
- One profile per district. Customers are configuration, never a fork — so every district keeps receiving upstream fixes.
See it running against your own district
A 45-minute walkthrough on your buildings, your roles and the modules you would actually turn on. No slide deck.