Almost every cloud school platform is multi-tenant: many institutions run on one shared system. It is how the economics work, how improvements reach everyone at once, and why you are not quoted separately for a server.
It also means your school's records sit on the same application infrastructure as institutions you have never heard of. That is not a reason for alarm: shared infrastructure is normal for cloud software in every industry, including ones regulated more strictly than education. It is a reason to understand what keeps tenants apart, because the difference between a boundary that holds and one that only appears to is narrower than most buyers assume.
ScolaOS is a multi-tenant cloud platform. Multiple institutions operate on shared application infrastructure while their data, users, files and operations remain separated by enforced tenant boundaries. We use logical isolation rather than a separate database per customer, and this article explains exactly what that means, because the distinction is where the real questions live.
So the useful question in a procurement conversation is not "are we sharing infrastructure". It is "what prevents one tenant from reaching another tenant's data?" This article is written for the person answering that to a board or an IT committee, not for an engineer, and it ends with things you can verify rather than take on trust.
Publisher disclosure: ScolaOS is published by Terra System Labs Pvt Ltd, which is ISO 9001:2015 compliant and ISO 27001:2022 compliant.
What multi-tenant means in school software
A tenant is one customer: a school, a college, or a trust that operates several campuses. In a multi-tenant system, one running application serves many tenants, and every piece of data carries the tenant it belongs to so that requests can be confined to it.
Multi-tenancy is not, in itself, a security property. It is an operating model. Whether it is safe depends on one thing: multi-tenancy is secure when tenant boundaries are enforced rigorously at every layer that touches data. A platform that enforces them consistently is sound. A platform that enforces them in most places is not, because attackers and accidents both find the exception.
That is the honest framing, and it cuts against the marketing on both sides. Multi-tenancy is not inherently safer than a dedicated system, and a dedicated system is not inherently safer than multi-tenancy.
Three ways schools can be isolated
Separate infrastructure
Each institution gets its own database, often its own application instance. This is the model people picture when they ask for isolation, and it does give strong architectural separation.
The trade-offs are usually understated. Updates roll out institution by institution, so fixes reach some estates later than others. Monitoring fragments. Lifecycle management, from certificate renewal to version upgrades, multiplies by the number of instances. It costs more, and vendors offering it price accordingly.
It is a legitimate architecture rather than an obsolete one, suited to institutions with a genuine requirement for dedicated infrastructure, particular regulatory obligations, or dedicated performance characteristics.
Shared system, separated data
One application and one database, where every tenant-scoped record carries the tenant it belongs to, and every query is confined to the tenant established for that request. Isolation is enforced by application, authorization and data-layer controls rather than by separate hardware.
This is the ScolaOS architecture. We would rather state it plainly than let "enterprise-grade isolation" imply something we do not do.
Interface-only separation
The backend returns more than the user should see, and the interface filters it before display. This is the fragile model, and it usually works, right up until a report, an export, a search result, a direct link or a background job skips the filter.
The principle worth carrying into any evaluation: a hidden record is not an inaccessible record.
The question that decides it
If you ask one technical question in a procurement process, ask this:
"Where does the system decide which school I am?"
It sounds academic. It is the whole thing.
Every web application must work out which customer a request belongs to. The convenient way is to read it from something the browser sends: a header, a parameter, a value in the address bar. The problem is that anything a browser sends, a browser can be told to send differently. If the system trusts that value, then changing it becomes an attempt to read another institution's data, and whether it succeeds depends entirely on a second check existing somewhere.
The sound approach is that after authentication, tenant context is established from trusted server-side session identity rather than from client-controlled request values. The user cannot alter that identity without invalidating their session.
In ScolaOS, the institution is initially resolved from the subdomain, which is what makes the correct login page appear. After authentication, the tenant identifier is taken from the authenticated session token rather than from the request header, so a modified header does not reach another institution's data. The header is no longer what the system trusts once you are logged in.
Ask every vendor this question. The answer matters, and so does whether they immediately understand why you are asking.
Tenant boundary versus interface boundary
This deserves stating on its own, because it is the single most common way isolation fails in practice.
A dropdown that lists only your campuses, a menu that hides another institution's module, a URL structure that looks scoped, a frontend filter applied before rendering: none of these is a security boundary. They are presentation. UI separation is not authorization.
The security boundary has to exist server-side, in the code that decides whether to return data at all. If the only thing standing between two institutions is what the interface chooses to draw, then the boundary disappears the moment anything reaches the data another way, and plenty of things do: an export, a report, an API client, a scheduled job.
Tenant vs branch: two different security problems
Schools routinely conflate two boundaries that a platform must treat differently.
A tenant is the customer boundary: one school or one trust. It is a security boundary, and cross-tenant access should never occur through normal institutional operations. There is no legitimate business case for it.
A branch is an operational boundary: a campus or organisational unit inside the tenant. Separation here is the normal rule, but it has deliberate, authorised exceptions:
- A branch head sees their own campus.
- A teacher sees their assigned branch and classes.
- A group administrator works across several branches.
- Finance leadership needs consolidated reporting across all of them.
The principle worth taking into an evaluation: tenant isolation should be absolute; branch isolation is policy-driven and can have deliberate, authorised exceptions.
These require different mechanisms, and a platform that models a campus the way it models a customer will frustrate any trust that needs group reporting. In ScolaOS, most records carry branch context alongside tenant context, and branch scope is resolved on the server rather than accepted from the client. Administrators can switch branches or work across all of them; other users are confined to their assigned branch. That is enforced in code, not by hiding a dropdown.
If you run a group, test this specifically. Sign in as a branch head and try to reach another campus's data through a report, an export and a direct link, not only through the menu.
Tenant isolation must follow the data
Database queries are the obvious surface, and the one every vendor has thought about. The principle that separates a mature platform from an adequate one is broader: tenant isolation must follow the data, not just the database query.
Every one of these paths touches tenant data and needs the boundary applied:
Database queries, APIs, reports, search, exports, file storage, caches, queues, scheduled jobs, notifications, analytics, integrations, logs, and administrative tooling.
Four of those deserve particular attention, because they are asked about least.
Files. Uploaded documents often escape the isolation applied to database rows, because they may be served by a web server rather than the application. In ScolaOS, file paths are tenant-scoped and include unguessable identifiers, and serving a file validates the session rather than treating the path itself as the secret. Ask any vendor how uploaded files are access-controlled, because "the URL is hard to guess" is not access control.
Caches and background jobs. Data cached for speed, or queued for later processing, must carry the same boundary. A cache key that omits the tenant will eventually serve one institution's data to another, and it presents as a display bug rather than a breach, which is what makes it dangerous.
Reports and exports. These are where filters get forgotten, because they are often written later, by different people, against different queries. They also have the highest impact when they go wrong, since an export is a complete file rather than one screen.
Vendor and platform tooling. Support consoles cross tenants by design. That is legitimate and it needs bounding. In ScolaOS, platform routes use separate authentication and bypass tenant context deliberately rather than incidentally, and cross-tenant access attempts through the normal application path are audit-logged.
A mature platform layers its defences rather than relying on a single check: authentication establishes who you are, tenant context establishes which institution the request belongs to, authorization decides what you may do, data-layer scoping confines what a query returns, resource-level checks confirm the record is yours, file access is authorized rather than assumed, background jobs carry the same context, audit logging records what happened, and testing verifies it still holds after the next release.
How to evaluate a multi-tenant school platform
Take this into the demo. It is short enough to work through in a meeting, and the answers are more revealing than any architecture diagram.
| What to ask | Why it matters |
|---|---|
| Where is tenant identity established? | Prevents client-controlled tenant switching |
| Is tenant scope enforced server-side? | Prevents UI-only isolation |
| Are reports tenant-scoped? | Prevents forgotten query filters |
| Are exports tenant-scoped? | Catches high-impact data leakage paths |
| Are uploaded files access-controlled? | Prevents direct-file exposure |
| Are background jobs tenant-aware? | Prevents asynchronous cross-tenant leakage |
| Is vendor administrative access controlled and logged? | Creates accountability |
Then verify rather than accept. Ask for a trial account with restricted permissions, ideally a branch head or a class teacher, and check what that account can actually reach:
- Direct links to records outside your scope
- Reports, particularly ones that aggregate across campuses
- Search results
- Exports and downloaded files
- Branch switching, where the interface offers it
- Whether altering client-controlled identifiers changes what comes back
This is ordinary procurement diligence rather than penetration testing, and any vendor should welcome it on a trial tenant with test data. Reluctance to let a customer check that scoping holds in reports and exports is itself information.
What multi-tenancy gives schools
Multi-tenancy is often discussed as a compromise. It has real advantages, worth stating without overselling them.
Consistent platform operations. Centralised operations allow security fixes and improvements to be deployed across the shared platform without each institution independently maintaining and patching its own application environment. In the separate-instance model, someone must upgrade each estate, and in practice some lag.
Consistent monitoring. One platform watched properly is easier to run well than many watched occasionally.
Group operations become possible. Multi-campus reporting, moving a student between campuses, or a staff member shared across sites work because they sit inside one system.
Lower infrastructure cost. You are not funding dedicated infrastructure, which is why per-student pricing in this market is what it is.
The trade is that isolation is enforced by software discipline rather than physical separation. That is a legitimate trade, made by nearly every cloud product in every industry. It has to be done properly, and verified.
How ScolaOS approaches multi-tenancy
ScolaOS is built as Education Infrastructure as a Service: institutional systems run as a continuously maintained platform rather than an installed application, connected across modules, campuses and branches. Multi-tenancy is what makes that possible, so the tenant boundary is treated as a security boundary rather than a convenience.
In practice: tenant context comes from the authenticated session rather than client-supplied values; scoping is applied in the data layer rather than the interface; branch scope is resolved server-side, with group-level access as a deliberate permission; file paths are tenant-scoped and file serving is authenticated; platform tooling authenticates separately; and cross-tenant access attempts through the application path are audit-logged.
Logical isolation does not mean informal or weak isolation. It means the boundary is enforced through application, authorization and data-layer controls rather than through separate physical infrastructure. That distinction is worth holding onto, because "logical" is sometimes read as "loose", and the two are not the same thing.
Frequently asked questions
What does multi-tenant mean in school software? Many institutions run on one shared application, with every tenant-scoped record carrying the institution it belongs to. It is the standard model for cloud software, and it is why improvements reach everyone at once and why per-student pricing is affordable.
Is multi-tenancy less secure than a dedicated system? Not inherently. A dedicated instance separates better architecturally, but is often patched, monitored and maintained less consistently, which is its own risk. What matters is whether isolation is enforced in the data layer or only in the interface, and where the system decides which institution you are.
Does ScolaOS use a separate database for every school? No, and we would rather say so plainly. ScolaOS uses a shared database with tenant context on tenant-scoped records, enforced server-side. Isolation is logical rather than physical.
Where is tenant identity established? After authentication, from the trusted session rather than from client-controlled request values. In ScolaOS the institution is initially resolved from the subdomain so the right login page appears, but once you are authenticated the tenant identifier comes from the session token, so a modified request header does not reach another institution's data.
What is the difference between a tenant and a branch? A tenant is a customer, and that boundary should be absolute. A branch is a campus within the customer, where separation is the rule but authorised exceptions exist, such as consolidated financial reporting for a trust. They require different mechanisms.
How do we test tenant isolation ourselves? Ask for a trial tenant and a restricted account, then check what it reaches through direct links, reports, search, exports and file downloads rather than only through the navigation. Menus hide things; reports and exports are where scoping is most often forgotten.
Are reports and exports isolated? They should be, and they are worth asking about separately from ordinary screens, because they are often built later and against different queries. An export leaks a whole file rather than one view, so the impact is higher when scoping is missed.
Are uploaded files isolated? Ask specifically, because files often sit outside the protection applied to database records. In ScolaOS, file paths are tenant-scoped with unguessable identifiers, and serving a file validates the session. Treat "the URL is impossible to guess" as an answer that avoids the question.
What about caches and background jobs? They must carry tenant context too. A cache key or a queued job that loses the tenant can surface one institution's data inside another's session, and it typically looks like a display glitch rather than a security event, which is exactly why it deserves a direct question.
Can vendor staff see across schools? In every multi-tenant product some tooling can, and that is normal for support. Ask whether that access is bounded, whether it is logged, and whether you can establish afterwards that it happened. In ScolaOS, platform tooling authenticates separately, and cross-tenant access through the application path is audit-logged.
In summary
Multi-tenancy is not a compromise to apologise for. It is why your institution gets consistent platform operations and per-student pricing rather than a server quotation.
What matters is whether the tenant boundary is enforced where it cannot be argued with: server-side, in the data layer, across every path that touches data, including the ones nobody demos. Architecture should follow requirements rather than terminology.
So do not simply ask whether a vendor is multi-tenant. Ask where the system decides which school you are, then verify it as a restricted user through a report rather than a menu.
If you are evaluating a school platform, ask vendors to demonstrate tenant isolation rather than describe it. To see how ScolaOS approaches tenant, branch and access boundaries, read our security page, explore the platform, or speak with our team.