Host resolution first
Sign-in does not start before the target school is known.
Security
Privacy and isolation built into the request path
The school context is selected before authentication, then connections, storage, and permissions operate inside the correct boundary.
School host
Tenant resolution
Connection switch
School database
Cross-school lookup: denied
How every request and school is isolated
The school host is resolved first, then the database connection, storage namespace, and authentication context are selected.
School host
Tenant resolution
Connection switch
School database
Cross-school lookup: denied
- Resolve school host before authentication
- Dedicated contextual database connection
- School-scoped storage and cache namespaces
- Server-enforced authorization
- Bounded and audited support access
Protection across the school lifecycle
Separate database
School models use a contextual, dedicated connection.
Server authorization
The interface is not the security boundary; the server enforces decisions.
Storage and cache scope
Paths and cache keys belong to the active school context.
Domain verification
Custom domains activate only after control is proven.
Support access
Time-bounded, scoped, and audited support sessions.
Lifecycle controls
Suspension, recovery, and retention without silent data deletion.
Review trail
Sensitive control-plane actions produce reviewable records.
Hosting and compliance
Hosting location is agreed and configured explicitly
We do not publish an unapproved region or provider. Location and compliance requirements are set during deployment planning.
Security and privacy questions
The SaaS design connects each school to a separate database and selects that connection after host resolution.
Review the isolation architecture with your technical team
We will explain request resolution, connections, authorization, and support boundaries without unverified claims.