# DEPRECATED - HyperTwist old VPS reconstruction index

Last updated: `2026-05-29` (`Europe/Berlin`)

## Purpose

This note is the reconstruction index for the current old production/control-plane
VPS at `212.227.22.66`. It records the live host shape that must be preserved or
deliberately superseded during migration to the new IONOS `VPS 12-24-720`
Ubuntu `24.04` server.

This is non-secret inventory only. Secret-bearing values remain in the local-only
runbook under `docs/refs`.

## Host identity

- host IP: `212.227.22.66`
- observed hostname label: `ecstatic-morse.212-227-22-66.plesk.page`
- OS: Ubuntu `24.04.4 LTS`
- kernel: `6.8.0-107-generic`
- note: the `.plesk.page` hostname label still exists, but active Plesk services
  are not part of the live stack

## Active live responsibilities

The old VPS is currently carrying all of these responsibilities:

- Forgejo control plane
- Woodpecker server
- VPS-local ops-only Woodpecker agent
- ScriptoriumAI static site
- ScriptoriumAI app/API sidecars
- VerticalTension static site
- VerticalTension API and database sidecars
- NGINX reverse proxy and TLS termination
- backup scripts
- cron jobs
- ops guard scripts

## NGINX vhost inventory

Enabled vhost symlinks:

- `/etc/nginx/sites-enabled/scriptorium-app-api.conf`
- `/etc/nginx/sites-enabled/scriptorium-git-ci.conf`
- `/etc/nginx/sites-enabled/scriptorium-root.conf`
- `/etc/nginx/sites-enabled/verticaltension-api.conf`
- `/etc/nginx/sites-enabled/verticaltension-web.conf`

Observed server-name bindings:

- `scriptorium-git-ci.conf`
  - `git.scriptoriumai.io`
  - `ci.scriptoriumai.io`
- `scriptorium-root.conf`
  - `scriptoriumai.io`
  - `www.scriptoriumai.io`
- `scriptorium-app-api.conf`
  - `app.scriptoriumai.io`
  - `api.scriptoriumai.io`
- `verticaltension-web.conf`
  - `verticaltension.com`
  - `app.verticaltension.com`
- `verticaltension-api.conf`
  - `api.verticaltension.com`

Operational implication:

- if the new VPS is meant to replace the old host completely, these vhost roles
  must be either migrated or deliberately dropped
- the current operator decision is a **full-host replacement**, so these roles
  should now be treated as migration targets rather than optional leftovers

## TLS certificate inventory

Observed certbot certificates:

- `git.scriptoriumai.io`
  - covers:
    - `git.scriptoriumai.io`
    - `ci.scriptoriumai.io`
- `scriptoriumai.io`
  - covers:
    - `scriptoriumai.io`
    - `www.scriptoriumai.io`
- `app.scriptoriumai.io`
  - covers:
    - `app.scriptoriumai.io`
    - `api.scriptoriumai.io`
- `verticaltension.com`
  - covers:
    - `verticaltension.com`
    - `app.verticaltension.com`
- `api.verticaltension.com`
  - covers:
    - `api.verticaltension.com`

Certificate rule for reconstruction:

- reissuing matching SAN certificates on the new host remains the clean end
  state
- however, for currently covered names, copying the old VPS
  `/etc/letsencrypt/live`, `/etc/letsencrypt/archive`, and
  `/etc/letsencrypt/renewal` trees is an acceptable initial continuity bridge
- this certificate continuity posture is entirely VPS-side and does **not**
  depend on the IONOS DNS UI
- `www.verticaltension.com` is the explicit exception because it is not covered
  in the currently observed old-host certificate inventory

## Stack root inventory

Primary control-plane stack root:

- `/srv/scriptorium-stack`

Observed key contents:

- `/srv/scriptorium-stack/.env`
- `/srv/scriptorium-stack/docker-compose.yml`
- `/srv/scriptorium-stack/forgejo/data`
- `/srv/scriptorium-stack/postgres/data`
- `/srv/scriptorium-stack/woodpecker/server-data`
- `/srv/scriptorium-stack/woodpecker/agent-config/agent.conf`

Observed compose services inside the control-plane stack:

- `forgejo-postgres`
- `forgejo`
- `woodpecker-server`
- `woodpecker-agent`

Observed control-plane container ports:

- Forgejo HTTP: `127.0.0.1:3000 -> 3000`
- Forgejo SSH: `0.0.0.0:2222 -> 22`
- Forgejo Postgres: `127.0.0.1:5432 -> 5432`
- Woodpecker HTTP: `127.0.0.1:8000 -> 8000`
- Woodpecker gRPC: `127.0.0.1:9000 -> 9000`

Woodpecker agent behavior:

- image: `woodpeckerci/woodpecker-agent:latest`
- current filter labels: `role=ops,repo=*`
- current Docker API override: `1.44`
- current max workflows: `1`

## Other `/srv` application surfaces on the old VPS

Observed top-level service directories:

- `/srv/scriptorium-live`
- `/srv/scriptorium-live/ScriptoriumAI-Server`
- `/srv/scriptorium-app-api`
- `/srv/verticaltension-api`
- `/srv/verticaltension-postgres`
- `/srv/verticaltension-web`
- `/srv/backups/scriptorium`

These indicate that the old host is carrying more than only Forgejo/Woodpecker.

## `/var/www` live static roots

Observed static roots:

- `/var/www/scriptoriumai`
- `/var/www/verticaltension`

Observed ScriptoriumAI web-root files:

- `index.html`
- `config.json`
- `robots.txt`
- `sitemap.xml`
- `site.webmanifest`
- `assets/`
- `branding/`

Observed VerticalTension web-root files:

- `index.html`
- `robots.txt`
- `sitemap.xml`
- `assets/`
- `fonts/`
- `publisher_logo/`
- `.htaccess`
- additional content/media files

Operational consequence:

- for exact continuity, these static roots should be copied from the old VPS to
  the new one instead of rebuilt from local source during the first cutover

## Backup and cron inventory

Observed cron files:

- `/etc/cron.d/scriptorium-nightly-backup`
- `/etc/cron.d/scriptorium-ops-guards`
- `/etc/cron.d/scriptorium-maintenance`

Observed schedules:

- nightly backup:
  - `30 2 * * *`
- maintenance prune:
  - `35 2 * * *`
- disk guard:
  - `0 */8 * * *`
- Forgejo/DB health guard:
  - `0 */8 * * *`

Observed scripts:

- `/usr/local/bin/scriptorium-nightly-backup.sh`
- `/usr/local/bin/scriptorium-disk-guard.sh`
- `/usr/local/bin/scriptorium-forgejo-health-guard.sh`
- `/usr/local/bin/scriptorium-maintenance-prune.sh`
- `/usr/local/bin/scriptorium-ops-notify.sh`

Observed backup root:

- `/srv/backups/scriptorium`

Observed retention-related note:

- the current backup lane is already on a single-slot `latest` style for major
  streams

## Docker/container inventory beyond the control plane

Observed running containers:

- `forgejo`
- `forgejo-postgres`
- `woodpecker-server`
- `woodpecker-agent`
- `scriptorium-api`
- `scriptorium-app`
- `scriptorium-redis`
- `scriptorium-supertokens-core`
- `scriptorium-supertokens-db`
- `verticaltension-api`
- `verticaltension-postgres`

Migration implication:

- the old host is not only a Git/CI host
- if the replacement target is control-plane-only, these app-side containers stay
  on the old VPS for now
- if the replacement target is full-host replacement, they need their own
  migration sequence too

## DNS-facing host inventory

Currently pointed to the old VPS:

- `scriptoriumai.io`
- `www.scriptoriumai.io`
- `git.scriptoriumai.io`
- `ci.scriptoriumai.io`
- `app.scriptoriumai.io`
- `api.scriptoriumai.io`
- `verticaltension.com`
- `www.verticaltension.com`
- `app.verticaltension.com`
- `api.verticaltension.com`

Currently **not** pointed to the old VPS:

- `hypertwist.app`
- `vectorshell.com`

## Source-versus-production parity finding

This is the key reconstruction and safety rule.

Confirmed:

- local source-control heads are synced to their remotes for:
  - `HyperTwist`
  - `ScriptoriumAI`
  - `VerticalTension`

Not confirmed:

- current production web artifacts are **not** identical to the currently
  visible tracked local build outputs for `ScriptoriumAI`
- `VerticalTension` no longer shares that same uncertainty because a fresh
  detached `HEAD` build reproduced the live public asset hashes

Observed mismatch examples:

- production `scriptoriumai.io` serves asset `index-DKzZ39HF.js`
- current local `ScriptoriumAI` build references `index-B2KwrMUv.js`
- production `verticaltension.com` serves `index-CgVsNXoc.js`
- fresh detached `VerticalTension` build from repo `HEAD` also produced
  `index-CgVsNXoc.js` and `index-ismjD07_.css`

Reconstruction rule:

- for `ScriptoriumAI`, if exact production continuity matters, migrate deployed
  artifacts from the old server and preserve repo `HEAD` separately
- for `VerticalTension`, the current live public site is reproducible from a
  fresh `HEAD` build, but migrating the deployed web root is still prudent for
  rollback and zero-surprise continuity

## Minimum reconstruction set for a control-plane-only cutover

If the new VPS is only replacing Forgejo/Woodpecker first, reconstruct:

- `/srv/scriptorium-stack/.env`
- `/srv/scriptorium-stack/docker-compose.yml`
- `/srv/scriptorium-stack/forgejo/data`
- `/srv/scriptorium-stack/postgres/data` or equivalent Postgres dump/restore
- `/srv/scriptorium-stack/woodpecker/server-data`
- `/etc/nginx/sites-available/scriptorium-git-ci.conf`
- the corresponding enabled symlink
- control-plane certs for:
  - `git.scriptoriumai.io`
  - `ci.scriptoriumai.io`
- the three `scriptorium*` cron files
- the five `scriptorium*` ops scripts listed above

## Minimum reconstruction set for a full-host replacement

If the new VPS is replacing the old host completely, also reconstruct:

- `scriptorium-root.conf`
- `scriptorium-app-api.conf`
- `verticaltension-web.conf`
- `verticaltension-api.conf`
- `/var/www/scriptoriumai`
- `/var/www/verticaltension`
- `/srv/scriptorium-live`
- `/srv/scriptorium-app-api`
- `/srv/verticaltension-api`
- `/srv/verticaltension-postgres`
- `/srv/verticaltension-web`
- all matching certbot SAN certificates listed above

Additional full-host rule:

- the new VPS should explicitly cover `www.verticaltension.com` in the final
  NGINX/vhost/TLS shape because live inspection of the old host currently shows
  a certificate-name mismatch on that host

Additional remote-development rule:

- the new VPS should also receive the current local remote-development workspace
  payloads under a dedicated non-public root such as `/srv/dev`
- confirmed current seed set:
  - `C:\visual_studio_solutions\multi_project`
  - `C:\VectorShell`
  - `C:\HyperTwist`
  - `C:\ScriptoriumAI`
  - `C:\VerticalTension`
  - `C:\NyxOS`
  - `C:\Workspaces`
- the current local helper script
  `C:\ScriptoriumAI\ops\ssh\sync-vps-remote-dev-workspaces.ps1`
  now codifies that seed set

## Recommended next action

Before live migration:

1. restore working SSH access to the new `212.227.13.220` host
2. archive and copy the deployed web roots, app service directories, stack
   roots, cron jobs, scripts, and cert material from the old VPS
3. bootstrap the new host and restore the full selected role set
