FULL-STACK APPLICATION
ANQ Server Ops
A practical journal for game-server inventory, maintenance, backups, and restore drills.
Live read-only demo
Fictional servers. The public workspace is read-only.

The problem
A game server has more history than its hostname: maintenance, incidents, backup attempts, and the last time somebody actually tested a restore. Those details are easy to lose between configuration files and chat messages.
ANQ Server Ops brings that record together without pretending to be a monitoring service. Its status is a person's recorded assessment. It never runs a command on a game server or tries to connect to a stored hostname.
The application
The React interface has searchable inventory, per-server details, an activity journal, backup records, and JSON export. An owner can add and edit servers, record work, and archive an inventory entry without losing its journal.
A completed backup and a completed restore drill are separate events. Failed or planned backups do not reset the backup timestamp. An interval target highlights overdue or missing records; it is not a claim that a backup repository is healthy.
Technical decisions
- TypeScript across a React client and a Fastify API, served from one origin.
- PostgreSQL constraints and parameterized SQL for the data boundary.
- Version counters reject stale inventory edits rather than overwriting newer work.
- Transactions and row locks keep archiving and journal writes consistent.
- A repeatable-read export captures inventory and journal from the same snapshot.
- Explicit owner mode with expiring sessions; a separate read-only demo mode.
The deployment image runs as an unprivileged user with a read-only filesystem. The publishing system backs up PostgreSQL before running a migration. Migrations are transactional, repeatable, and serialized by an advisory lock.
Evidence
Automated API and model tests run against real PostgreSQL. Browser checks exercise owner sign-in, server creation, restore recording, persistence after reload, archiving, export, logout, search, and demo restrictions. Responsive checks cover 390px and 768px; an automated WCAG A/AA scan checks the inventory page.
The live HTTPS demo runs a fictional, read-only workspace. Its deployment uses the same restricted SSH key, image digest, backup, migration, and health-check path as the publishing reference.
Boundaries and next decisions
The app is for one owner and a small fleet. There is no automatic monitoring, notification delivery, remote execution, or multi-user access model. The journal is append-only through the API, not tamper-proof against a database administrator.
The deployed demo has HTTPS, scheduled encrypted off-host database backups and host-level email alerts through the publishing system. Its database was restored into an isolated PostgreSQL instance and its table counts matched. Independent review and user feedback remain valuable checks beyond automated tests.
Implementation process
Developed with AI-assisted implementation. The repository includes the schema, design decisions, operations notes, and executable checks so the result can be reviewed and reproduced. The public demo contains no real server inventory.