Add old VPS reconstruction index

This commit is contained in:
axiomlogicnexus 2026-05-29 18:45:47 +02:00
parent 5b381dc33e
commit 0ea2656990
2 changed files with 342 additions and 0 deletions

View file

@ -0,0 +1,340 @@
# 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
- if only Forgejo/Woodpecker is moving first, leave the ScriptoriumAI and
VerticalTension vhosts on the old host until a later cutover
## 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:
- do not copy old Let's Encrypt files as the primary migration plan
- reissue matching SAN certificates on the new host after DNS points to it
## 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 local build outputs for `ScriptoriumAI` and `VerticalTension`
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`
- current local `VerticalTension` build references `index-ChYBuzHU.js`
Reconstruction rule:
- if exact production continuity matters, migrate deployed artifacts from the
old server
- do not assume a local rebuild reproduces the current public state exactly
## 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
## Recommended next action
Before live migration:
1. decide whether this is:
- control-plane-only replacement
- or full-host replacement
2. if exact continuity matters, archive and copy the deployed web roots and app
service directories from the old VPS
3. then bootstrap the new `212.227.13.220` host and restore only the selected
role set

View file

@ -24,6 +24,8 @@ Reason this companion is not pushed:
Current source runbook:
- `C:\HyperTwist\docs\refs\FORGEJO_WOODPECKER_VPS_A_TO_Z_SENSITIVE_RUNBOOK.md`
- old-host reconstruction index:
`C:\HyperTwist\docs\ops\HYPERTWIST_OLD_VPS_RECONSTRUCTION_INDEX_2026-05-29.md`
Current live control-plane shape documented there: