Quasar is an API-first supervisor and management stack for Space Engineers (version 1)
dedicated servers, with an optional Blazor Server UI. It supervises multiple DS
processes on a single host — starting, stopping, health-checking, configuring, and
auto-updating them through goal-state reconciliation — while an in-process plugin
(Quasar.Agent) attaches to each server to report telemetry and execute commands.
It runs on Linux (systemd service) and Windows (Scheduled Task), in foreground console or unattended background mode.
Each server uses the Magnetar plugin loader and launcher. Quasar deploys an agent plugin which connects back to Quasar.
Quasar downloads Magnetar and the Dedicated Server builds automatically and caches it locally until there is an update.
You can register new plugins by making PRs to the MagnetarHub. Quasar UI plugins are discovered and managed through QuasarHub.
See the Quick Start guide to download a release, run Quasar from the terminal, install it as a background service, or run the GHCR image.
| Page | What it covers |
|---|---|
| Quick Start | Download, run from the terminal, and install as a background service (systemd / Scheduled Task). |
| Docker Deployment | Run the versioned GHCR image with Compose, persistent state, environment configuration, and upgrades. |
| Architecture | Supervisor design, runtime ownership, process supervision, configuration model, and self-update. |
| Configuration | API/UI host and port, headless mode, browser behavior, and optional instance health notifications. |
| Analytics CPU Usage | Why CPU usage can exceed 100% and how it differs from Shift+F11 simulation CPU load. |
| Quasar Plugin System | Planned UI plugin loader, hub manifest model, component replacement points, companion data channel, and MudBlazor expectations. |
| Entity Viewer | Fullscreen metadata-only entity viewer, local Space Engineers Content folder requirement, and fallback behavior. |
| Building & Development | Project layout, build setup, managed-runtime selection, and developer utilities. |
| Phase 4 Integration | Cluster release integration, verified package staging, upstream requirements, and acceptance plan. |
| Cluster Integration Verification | Implementation checks, review package provenance and remaining live acceptance gates. |
| Guided Cluster Setup | Machine enrollment, local/SSH/command installation, automatic provisioning and release prerequisites. |
| Cluster Terminology | Terminology occurrences and continuity findings across cluster setup, hosts, controls and contracts. |
| Cluster Conversion | Guided standalone/cluster conversion, backups, resume and plugin configuration limits. |
| Cluster Plugins | One-server plugin/config consistency, Agent monitoring, existing SDK compatibility and remaining integration work. |
| Cluster Content Updates Plan | Proposed Workshop byte pinning, scheduled mod/plugin notices, explicit maintenance updates and compatible rollovers including World Authority. |
| Linux Deployment & Updates | systemd install, release assets, and the auto-updater flow. |
| Windows Deployment & Updates | Scheduled Task install, release assets, and the auto-updater flow. |
| State Machine Diagrams | Object states and state machines (server lifecycle, agent connection, self-update, runtime provisioning, backups, …) as Mermaid + PNG. |