Deployment Overview

This deployment section describes the single standard production workflow operators should follow for a school deployment.

It does not describe the older process of cloning source repositories onto a school machine and deploying from raw project files.

Standard production path

Makronexus school production deployment should be run from the backend school bundle.

This is the one artifact schools should receive for normal installs and normal updates.

Artifact	Repository owner	Role	What it deploys
Backend school bundle	mn-school-be	Standard production artifact	Backend, frontend, PostgreSQL, Redis, MinIO, migrations, reverse proxy, health checks, optional license and signature validation

Support-only exception

The frontend deployment pack still exists, but it is not the normal operator workflow.

Use it only when support explicitly instructs the site to use that support workflow.

Why there is one default path

The backend school bundle is the standard because:

• it is the comprehensive appliance-style release
• it includes the reverse proxy and health-check flow
• it is the main on-prem operator path for a full school install
• it already pins both backend and frontend images in one release manifest

What changed from the older docs

The older self-hosting section mixed together several workflows that are no longer the recommended production path, including:

• cloning the frontend repository directly onto the school machine
• running npm install on the school machine just to deploy
• treating deployment as a phase-by-phase source checkout exercise
• updating image tags manually without using the packaged release artifact

Those steps have been removed from this deployment section.

Deployment sequence at a glance

1. Receive the release artifact from support.
2. Confirm you were given the backend school bundle for the site.
3. Review the artifact checklist and trust material.
4. Run preflight before extraction or install.
5. Extract or enter the provided release directory.
6. Fill in the site-specific environment values, including TENANT_ID, LOCAL_SCHOOL_ID, and SITE_ID.
7. Run the packaged install command.
8. Verify frontend access, backend health, and operator records.
9. Use the packaged update command for future releases.

Before install, operators must know exactly where those identity values come from:

• TENANT_ID: provided by the cloud-side provisioning handoff
• LOCAL_SCHOOL_ID: provided by the cloud-side school record created for that school
• SITE_ID: generated once for the physical appliance and then kept stable

The full operator instructions, including how bootstrap pull uses those values, are documented in Deploy with the Backend School Bundle.

Read next

• Release Artifact Policy
• Deploy with the Backend School Bundle
• Validation, Updates, and Rollback

For the frontend deployment pack, use the support-only note in Frontend Deployment Pack.

One school, one deployment directory

Each school should receive its own release handoff and its own school-specific configuration values. Do not reuse a configured release directory across different schools.