Kubernetes-native school software.

Each school runs in its own Kubernetes namespace with its own services, its own databases and its own network policies. Student, Fee and the other services each own their data, and no school's records sit inside another school's database.

• Isolation you can describe. A namespace, a set of databases and the rules for which services may talk to which.
• One owner per record. Other screens read from the owner and never keep a second copy.

A school is described once, in a contract. Aurora renders every Kubernetes resource it needs from that contract and validates the result against the Kubernetes schemas, strictly, before anything is applied.

• Backups and health checks are part of the render. A school is protected because it was created that way, not because somebody remembered.
• No hand-edited manifests. Change the contract and render again, so what the repository describes is what the cluster runs.

Aurora care places, updates, observes and recovers schools from one console. It knows how large a school is and whether its services are healthy. It does not hold a copy of the student roll, the fee ledger or the marks.

• Counts and health, not records. A school reports restricted, credential-bound summaries to care.
• A care outage does not stop a school. Staff keep using their school's environment.
• Built to manage more than one school from the same console, for trusts and school groups.

Container images come from a private registry and are pinned by digest. A release is a named, signed bundle. It is installed into one school at a time, and what ran, and where, is recorded.

• Image-only updates and updates that move a database schema are handled as different, checked paths.
• Nothing reaches a school without a name, a version and a record.

Kubernetes restarts services that fail and sends traffic only to services that report ready. Metrics and dashboards (Prometheus and Grafana) show how each school is doing.

• Readiness, not hope. A service that is not ready is kept out of rotation until it is.
• Backups are checked by restoring them and comparing row counts with the original.

A module is installed per school, from a reviewed release, by name. Installing it never loads or runs code that was handed to the system. That is how Academics arrives as an add-on beside the Console core, and how report packs are installed.

• Its own database. An add-on lives beside Student and Fee, not inside them.
• The same sign-in. Staff do not get a second login.

See the Console core and the Academics add-on

Aurora installs into a Kubernetes cluster. Today that is RKE2 with Cilium for networking, a private Harbor registry, and Prometheus and Grafana for metrics. It is built from standard Kubernetes resources.