Skip to content

What managed hosting is

Managed hosting means we run your deployment on a server of its own. No other school is placed on it. Your database, your secrets, your backups and your disk are on that machine and nowhere else.

So the answer to “is our data segregated from other schools” is not a description of how our software separates records. It is “we have our own server, in the region we chose, and here is its backup”.

Your own server. One customer per machine, in the region you named. Nothing another school does can consume the memory, disk or processor your desk is running on, because no other school is on it.

Your own database, rather than a share of somebody else’s.

Your own upgrade moment. One school can sit on the previous release while another takes the new one. Nothing forces every customer through the same change on the same night.

A named region. Chosen during the sale, recorded on your deployment, and shown back to you during onboarding to confirm. Backups replicate within that region and nowhere else. See regions and data residency.

Backups taken and tested. Including a restore drill, which is the part in-house regimes usually skip.

Certificates and renewal. Yours to name, ours to issue and keep current.

Updates handled for you. Every version runs on our own instance before it reaches any customer, and you are told before anything that changes the database. See updates.

Being hosted does not make these somebody else’s problem.

The configuration. Modules, workflow, roles, connectors, email templates. This is your service desk and it is set up the way you run it.

Your identity provider. SSO and SCIM connect to your Entra or Google tenant. We cannot configure that from our side.

Connector credentials. You paste them in; we never see them in the clear. They are encrypted before they touch the database.

A connector agent, if you want private systems connected. Active Directory, a local SIS database, PaperCut and printers on SNMP live inside your network. A managed deployment reaches them through an agent you install. It dials out only, so there is no inbound firewall rule to ask for. See connector agents.

Deciding who has access. Roles and accounts are yours, and so is vendor access, which you can switch off.

Counts, versions and billing records. No names, no records, no ticket content.

Your deployment reports count-only telemetry to it: technician accounts, managed devices, enabled modules, version. That is what the plan is measured against.

Licensing, and what happens if billing goes wrong

Section titled “Licensing, and what happens if billing goes wrong”

Entitlement lives in the signed licence your deployment already holds, not in the billing system. A school’s service desk keeps working through a billing outage, an expired card or a failed webhook.

Nothing in the billing path revokes anything. A failed payment starts a conversation. Revocation is a deliberate act, not an automatic consequence.

Annual billing is the default, with automatic collection off, because most schools pay by transfer against a purchase order. Monthly billing is also available at a 15% uplift on the base price; see plans. A hosted payment page is available for anyone who would rather use a card or direct debit.

Overage accrues on the licence and is trued up at renewal as a single line, rather than raising a small invoice every month that finance has to process against a fresh purchase order.

Admin, Backups exports a portable copy of your institution at any time, without asking us.