Tenant isolation

Tenant-owned records are scoped to an institution. Authentication and permissions control which records a request may use; the hostname selects its tenant context.

Where it is enforced

The shared database wrapper adds tenant conditions and sets transaction-local tenant, campus and department context. Request guards establish the caller’s identity and permissions before the operation.

Production Compose runs the API as the restricted PostgreSQL app_user role and applies row-level security policies. These provide an additional database check on tenant access. Migration commands use a separate owner connection.

The supplied demo Compose and native launcher use a database-owner connection, which can bypass row-level security. Their application checks still run, but they do not provide the same independent database boundary. Verify the deployed database role and policies when assessing a particular installation.

What managed hosting adds

A server of your own. One customer per machine, in the region you chose. No other school’s deployment runs on it, and the provisioning system refuses to place one there. Your database, your secrets, your backups and your disk are on that machine.

That turns three answers from descriptions of our software into statements of fact:

• Where the data is is the physical location of one machine, not a setting in a shared system.
• What another school’s fault can reach is nothing of yours: a fault, a spike or an overloaded database on another customer’s deployment is on another customer’s machine.
• What deleting your data means is deleting the machine and its backups, rather than removing your rows from tables you share with other schools.

The questions procurement asks

“Can another school see our data?” No. On managed hosting there is no other school on your server to see it, and each customer has a separate database on a separate machine. The database-level separation described above applies as well, and is what keeps two campuses of one group apart within a single deployment.

“Can your staff see our data?” Managed deployments have a separate vendor support API protected by a per-deployment key and the product’s support-access setting. That setting does not remove hosting administrators’ access to the underlying server, database or escrowed deployment keys. Audit coverage and retention must be assessed alongside those infrastructure controls. Self-hosted provisioning does not issue a vendor control key; you control any access you separately arrange.

“What happens if there is a bug?” Independent database checks in production Compose reduce the consequences of application mistakes. They do not replace authorization tests, security updates or deployment review. Owner connections and infrastructure administrator access need separate controls.

“Where is the data?” Answered in regions and data residency.

Multi-campus

A group with several campuses can run several institutions on one deployment, which is what the included count on a plan refers to.

Each campus gets its own people, devices, workflow, branding and roles, and the separation between them is the same as between two unrelated schools.

If you want campuses to share data, make them one institution with several locations instead.

Which institution a request belongs to

A request is matched by hostname. If your desk is at helpdesk.yourschool.org, that address is recorded against your institution and every request to it lands in your data.

Two consequences:

• Changing your address is a real change. See your own domain.
• Unknown tenant means the address does not match the one recorded. It is a one-line fix, covered in troubleshooting.

Health and metrics endpoints skip this, so monitoring keeps answering when nothing else does.

Live updates

Live updates are filtered by institution before anything is sent, so you see only your own.