MyPortal

Self-hosting

What a school needs in place to run MyPortal on its own infrastructure.

Not yet. MyPortal is under active development and is not ready to hold live school data. This page describes the intended shape of a deployment so you can plan and evaluate — not a supported production setup.

What you are running

A MyPortal deployment is three things:

  1. A SQL Server database. Holds everything. This is the thing to back up.
  2. The ASP.NET Core Web API. Stateless — scale or restart it freely.
  3. The Angular SPA. Static files, served by any web server or CDN.

Identity is delegated to an OAuth 2.0 / OpenID Connect provider, so your existing directory remains the source of truth for who people are.

Backups

Everything that matters is in the database. A standard SQL Server backup schedule — full plus differentials, tested restores — covers MyPortal entirely, with one exception: if you configure file storage on disk rather than in the database, back that location up alongside it.

Test the restore. A backup you have never restored is a hypothesis.

Upgrades

The migrations runner is idempotent and forward-only:

dotnet run --project MyPortal.Migrations

Run it against a copy of production first, then take a backup, then run it for real.

Data protection

Running MyPortal yourself means the personal data in it stays on infrastructure you control, which makes the school the sole data controller and processor. That is an advantage, and it is also a responsibility — the usual obligations around access control, retention, and breach reporting sit with you.

Because the source is public, your DPO can have the code reviewed independently. That is a genuinely unusual position to be in with an MIS, and worth using.