SivitasDeployment
What Sivitas is made of, what it needs to run, how it is deployed on-premises or in the cloud, and how the AI components are configured.
Components
| Component | Technology | Role |
|---|---|---|
| Web application | PHP 7.4+ on Laravel, MySQL 8 or compatible, Redis | The Sivitas API and the browser front end |
| Solver service | Python (FastAPI, Google OR-Tools CP-SAT) | Timetable and allocation optimisation; called by the application over HTTP on the same host, no database access |
| Language model | Anthropic Claude via API, or a local CLI driver | Calendar parsing, teaching-interest mapping, the scheduling assistant, constraint text refinement |
| Web server | Nginx or Caddy with PHP-FPM | TLS, static assets, routing |
| Queue and scheduler | Laravel queue workers on Redis, cron | Imports, notifications, daily data sync |
Sizing
A single virtual machine serves a faculty of several thousand students. The solver benefits from cores: with 16 vCPU and 32 GB RAM a full term solves in well under a minute; with 2 vCPU it still completes, in minutes. Memory limits on the solver service are set as a percentage of RAM so a resize needs no reconfiguration.
Deployment options
- On-premises. Plain Linux server (Ubuntu recommended) with the packages above, or containers with Docker Compose. Obfuscated builds are available for client installations.
- Cloud. The same in your cloud tenancy. Sivitas can also host the instance for you.
- Data residency. All data stays on the server you choose. The only outbound calls are the ones you configure: your source system, Google, the language-model API and notification channels.
AI configuration
Environment settings choose the language-model driver (API with your own key, or CLI), the model per task (main, parser, refiner), and the solver limits: outer time limit, stall time, optimality gap and worker count (automatic by default). A gate requires an approved model specification before any solve. See AI scheduling.
Backups
Back up the MySQL database nightly with a consistent single-transaction dump and keep the binary log for point-in-time recovery. Back up the storage directory (attachments, generated documents, progress logs). Test a restore each term.
Updates
Application updates are pulled from the release repository, followed by database migrations and a front-end version bump that busts browser caches. The instance configuration file is not touched by updates. Plan updates between terms or at least outside grading and publish windows.
Monitoring
Errors report to Sentry when configured. The solver writes a heartbeat to each run's progress log; an integration check on the daily sync alerts the integration team on failure. The Audit trail records user-level changes.