Server Deployment Report: VPS OVH vps-0836dabe.vps.ovh.ca

Status at 2026-11-06 00:38 UTC: DEPLOYED and VERIFIED, with access by IP. - Active release: 20261106T003554Z. - healthcheck.sh: health=OK warn=[] crit=[]. - Not available yet: a public HTTPS certificate. There is no domain, so the IP access uses an internal-CA certificate (§5).

1. Server

Initial audit (preflight, read-only)

The machine was blank: - no Docker, no existing services; - only our key in authorized_keys; - passwordless sudo for ubuntu; - 0 pending updates.

To fix: - UFW was inactive. - SSH accepted passwords (50-cloud-init.conf) and root by key. - There was no swap.

Report saved at /root/ao-preflight-20261106T001314Z.txt.

2. Architecture as deployed

Internet ─► Caddy 2.8.4 :80 → 308 → :443 (https://158.69.190.114, internal-CA certificate)
              ├─ /status, /api/health, /docs/*, /site/*   public
              └─ everything else ─► api   (HTTP basic auth)
 SSH tunnel ─► 127.0.0.1:8765 ─► api (FastAPI)
                 worker (collectors, hourly) · scheduler (jobs) · monitor (metrics 60 s)
                          └──► PostgreSQL 16.15 (internal network only, no published port)

• Docker networks:
• backend is internal (Postgres plus the app services);
• edge connects Caddy and the API;
• egress gives internet access to the collectors only.
• No Redis: a single API instance doesn't need it.
• Lightweight built-in monitoring instead of Prometheus/Grafana.

3. Versions and resources (measured after deployment)

• Whole host: about 0.9 GB RAM used out of 7.6 GB, load under 0.3, disk 10% (66 GB free), database 19 MB.
• Headroom: plenty for the planned SaaS growth.

4. Security (verified)

Earlier hardening had backed up every modified configuration file to /root/ao-config-backup/<ts>/.

5. Access without a domain

• Certificate: issued by Caddy's internal CA. A public CA can't certify a bare IP without a domain. The connection is encrypted, but the browser shows a warning the first time.
• Login details: user oracle. The password is stored root-only on the server; read it with ssh … "sudo cat /opt/auction-oracle/shared/app-access.txt", then save it in your password manager.
• Alternative with no browser warning: .\ao-remote.ps1 tunnel, then http://127.0.0.1:8765.

When you get a domain: point its A/AAAA records to the VPS and run update.sh --caddy (or deploy again). The auctionoracle.com / app. / api. / docs. / status. blocks switch on automatically, with Let's Encrypt, once DNS resolves to the server.

6. Backups (verified)

Your action: - Keep a copy of backup-identity.txt in a password manager. Without it, the off-site backups can't be decrypted. - The daily pull to the PC is still manual (.\ao-remote.ps1 pull-backups). Creating a Windows scheduled task needs your approval.

7. Deployments, rollback, restart (verified)

Deployments run as transient systemd units (run-detached.sh), so an SSH disconnect can't interrupt them.

8. Monitoring (verified)

• monitor service: CPU, RAM, swap, disk, network, DB size and connections, and API latency every 60 s, stored in the metrics table (30 days).
• Sample: cpu 11.6% · mem 11.6% · disk 9.1% · db 19.3 MB / 4 conns · api ok 14/14.
• System alerts: disk ≥ 70/80/90%, CPU ≥ 90% for 10 minutes, RAM ≥ 90% for 5 minutes, API failing, stale data.
• healthcheck.sh every 5 minutes writes to /var/log/auction-oracle/health.log and syslog. It checks:
• containers;
• API;
• data freshness and external sources;
• disk, RAM and load;
• age of the last backup and restore test;
• UFW and fail2ban;
• public listeners;
• pending reboot.
• Scheduler jobs: disk (10 min), sources (30 min), freshness (1 h), model evaluation (24 h), retention (24 h). All showed ok on first run.
• Fixed in release 3: a false "stale data" alert raised at startup, before the first collection.

9. Acceptance checklist

10. Pending / known limits

1. Domain + Let's Encrypt. Waiting for a domain. Everything is already configured.
2. Daily automatic pull of the off-site backups to the PC. Needs your approval for a Windows scheduled task, and depends on the PC being on.
3. Alternative: an S3 bucket (OVH Object Storage) to make it independent of the PC.
4. IPv6. SSH answers over IPv6, but HTTP/HTTPS is published over IPv4 only. Enable it if you need it (Docker ipv6 setting).
5. Basic auth until user accounts exist. SaaS authentication is phase 8 (see SAAS_ARCHITECTURE.md).
6. Third-party API keys. Blizzard, ForeverDB and Anthropic keys go in shared/app.env on the server. These sources are disabled until then.

11. Maintenance commands

From the PC (deploy\windows):

.\ao-remote.ps1 health         # health report + container usage
.\ao-remote.ps1 deploy         # new release (backup, tests on PostgreSQL, rollout, auto-rollback)
.\ao-remote.ps1 rollback       # previous release
.\ao-remote.ps1 backup         # backup now
.\ao-remote.ps1 restore-test   # restore test now
.\ao-remote.ps1 pull-backups   # copy encrypted backups to the PC
.\ao-remote.ps1 tunnel         # app at http://127.0.0.1:8765 over SSH

On the server:

sudo /opt/auction-oracle/bin/healthcheck.sh
sudo /opt/auction-oracle/bin/update.sh --system     # OS updates
sudo /opt/auction-oracle/bin/update.sh --caddy      # after pointing a domain
sudo /opt/auction-oracle/bin/restore.sh --file /opt/auction-oracle/backups/db/<dump> --confirm
sudo tail -f /var/log/auction-oracle/ops.log /var/log/auction-oracle/health.log
sudo cat /opt/auction-oracle/shared/app-access.txt