Raport: Migracja Railway → Mikrus

2026-07-18 v1.0 jash90 (bartekziimny90@gmail.com) Mikrus kate102 (Ubuntu 24.04, 8 GB RAM, 68 GB dysk)

Przygotowane przez: Hermes Agent · Źródła: railway list, railway metrics, GitHub API, Mikrus wiki

1. TL;DR

Railway miesięcznie
$16.78
3.3× hobby plan ($5)

Realnie zużywane

3.4 GB

z 8 GB dostępnych na Mikrusie

Projektów

9 Postgres · 4 Redis · 1 Qdrant

Przydzielone w Railway

128 GB

RAM + dysk, 97% zmarnowane

Werdykt: da się. Mikrus (8 GB RAM) udźwignie wszystko po optymalizacji, zostanie ~5 GB zapasu. Squash-tm (1.23 GB RAM, 22 GB obrazów) — zdecydować czy zostawić na Railway, eksportować do Notion, czy migrować. Kluczowe: Cloudflare Tunnel (bo brak publicznego IPv4), 1 Gbps shared łącze Hetzner, brak limitu transferu.

2. Co jest na Railway

11 projektów, każdy na jednym env production, region europe-west4-drams3a (Frankfurt). Wszystko replicas=1. Billing period: 2 lip – 2 sie 2026. Workspace jash90's Projects.

#	Projekt	Serwisy	Custom domain	Status
1	squash-tm	squash (Java) + Postgres	—	Online
2	vasculitis-xai-api	FastAPI (Python ML)	—	Online
3	accounting prod	api (NestJS) + Postgres	—	Online
4	ai-gateway	backend + Postgres + Redis	—	Online
5	accounting dev	api (NestJS) + Postgres	—	Online
6	sesja-master	Next.js 15 + Bun	—	Sleeping
7	description-generator	api + web + Postgres	—	Sleeping
8	health-monitor	api (Formendo) + Postgres + Redis	`api.formendo.pl`	Online
9	citygame-backend	api (NestJS) + Postgres + Redis	—	Online
10	pkd-search	backend + frontend + Postgres + Qdrant	`kodypkd.app` + `www.kodypkd.app`	Online
11	ai-projects	backend + frontend + Postgres + Redis	—	Sleeping frontend

Wolumeny (faktyczne użycie vs przydzielone)

Projekt	Wolumen	Używane	Przydzielone	% marnotrawstwa
squash-tm	postgres-volume	403.8 MB	5000 MB	92%
accounting-prod	postgres-volume	224.9 MB	5000 MB	95%
accounting-dev	postgres-volume	231.1 MB	5000 MB	95%
ai-gateway	redis-volume	496.1 MB	5000 MB	90%
ai-gateway	postgres-volume	217.6 MB	5000 MB	96%
ai-projects	postgres-volume	117.8 MB	500 MB	76%
ai-projects	redis-volume	48.8 MB	500 MB	90%
citygame-backend	postgres-volume	218.8 MB	5000 MB	96%
citygame-backend	redis-volume	150.1 MB	5000 MB	97%
description-generator	postgres-volume	216.1 MB	5000 MB	96%
health-monitor	postgres-volume	244.9 MB	5000 MB	95%
health-monitor	redis-volume	200.6 MB	5000 MB	96%
pkd-search	qdrant-volume-hqoS	161.5 MB	5000 MB	97%
pkd-search	postgres-volume	120.3 MB	500 MB	76%
RAZEM		3.05 GB	55.18 GB	94% zmarnowane

Kluczowa obserwacja: Railway zlicza przydzielone, nie używane. Te 9 małych Postgresów zajmuje 2.7 GB, ale przydzielone jest 45 GB. Po migracji i konsolidacji do 1 współdzielonego Postgresa z wieloma bazami, zejdziemy do ~2 GB.

3. Co jest na Mikrusie `kate102.mikrus.xyz`

Zasób	Wartość	Wniosek
OS	Ubuntu 24.04.4 LTS	świeży
Kernel	`7.0.12-1-pve` (Proxmox VE)	VM, nie CT — pełny kernel
RAM	8 GB (7.5 GB free)	wystarczy na 12 kontenerów
Dysk	79 GB total / 68 GB free	zmieści 9× Postgres po 5 GB + system + image cache
Publiczny IPv4	BRAK (NAT 192.168.1.102)	→ Cloudflare Tunnel
Publiczny IPv6	`2a01:4f9:3070:2844::102/128`	dostęp do świata
Łącze	1 Gbps shared (Hetzner Helsinki)	brak twardego limitu transferu, fair-use
Sprzęt fizyczny	Hetzner EX52-NVMe / AX-41 (128 GB RAM, NVMe, i7-8700 / Ryzen 5)	współdzielone z innymi VPS
Docker	MISSING	do zainstalowania
Compose / Podman	MISSING	Docker + Compose v2
Reverse proxy	MISSING	Caddy (auto-TLS)
IPv4 forward	2 porty ogólne + 1 SSH + do 7 dodatkowych TCP/UDP	plan B, jeśli CF Tunnel zawiedzie
`codex` / `claude`	✅ zainstalowane	do późniejszej automatyzacji
`gh`	✅	klonowanie repo
`railway` CLI	✅ `~/.railway/bin/railway 5.27.0`	do dalszego odpytywania
Strych (backup)	200 MB/serwer, rsync przez SSH	za mały na moje potrzeby → R2
Storage	dodatkowy dysk 125-1000 GB	już mam `/storage`

4. Realne zużycie RAM (z `railway metrics --since 24h`)

Railway domyślnie daje 8 GB RAM per serwis. Mierzyłem średnie z 24h.

Projekt	Serwis	RAM avg	Limit Railway	% limitu
squash-tm	squash (Java)	1.23 GB	8 GB	15%
squash-tm	Postgres	211 MB	8 GB	2.6%
vasculitis-xai-api	api (Python)	300 MB	8 GB	3.7%
accounting-prod	api (NestJS)	192 MB	8 GB	2.4%
accounting-prod	Postgres	48 MB	8 GB	0.6%
ai-gateway	backend	101 MB	8 GB	1.3%
health-monitor	api (Formendo)	356 MB	8 GB	4.5%
health-monitor	Postgres	97 MB	8 GB	1.2%
health-monitor	Redis	11 MB	8 GB	0.1%
citygame-backend	citygame-api	65 MB	8 GB	0.8%
pkd-search	backend	109 MB	8 GB	1.4%
pkd-search	frontend	87 MB	32 GB	0.3%
pkd-search	Qdrant	367 MB	8 GB	4.6%
pkd-search	Postgres	35 MB	8 GB	0.4%
ai-projects	backend	81 MB	8 GB	1.0%
ai-projects	Redis	9.5 MB	8 GB	0.1%
description-generator	api	33 MB	8 GB	0.4%
RAZEM		~3.4 GB	128 GB	2.7%

Realne zużycie 3.4 GB. Mikrus (8 GB) udźwignie wszystko z 4.6 GB zapasu. Squash sam zjada 36% — albo zostaje na Railway, albo kosztem bufora.

5. Czym naprawdę są te aplikacje

Logi Railway i publiczne repo ujawniły, że aplikacje są czymś więcej niż myślałem.

accounting-app — to NestJS, nie plain Node

Logi Railway: [Nest] 1 - LOG [TaskDeadlineNotificationsService] Found 0 tasks due soon. Wbudowane schedulery:

TaskNotificationService co 60 min (overdue tasks)
TaskDeadlineNotificationsService co 5 min (due-soon tasks)
CustomFieldReminderService co 15 min

Wniosek: kontener musi być włączony 24/7. Schedulery działają wewnątrz procesu API.

health-monitor — to pełna apka medyczna "Formendo", nie monitoring

Integracje w env vars:

P24_* — Przelewy24 (płatności polskie)
RC_API_KEY — RevenueCat (subskrypcje iOS/Android)
EXPO_ACCESS_TOKEN — Expo Push (notyfikacje)
OPENAI_API_KEY — parsowanie głosu (/api/diet/parse-voice)
SENTRY_DSN — błędy

Logi Railway: ComplianceAlertService, DishCacheService, MealReminderService, MotivationalService. User-Agent: Formendo/1 CFNetwork/3860.500.112 Darwin/25.4.0 (apka iOS).

Wniosek: Produkcyjna płatna aplikacja dla użytkowników. NIE zamieniamy na Uptime Kuma.

pkd-search — hardcoded Qdrant

Backend jash90/pkd-search-backend ma @qdrant/js-client-rest w zależnościach i używa go w src/services/. Nie da się pgvector bez przepisywania.

Frontend jash90/pkd-search-frontend ma już gotowy multi-stage Dockerfile (Node 22 + Caddy 2 alpine + SSG). Drop-in template.

vasculitis-xai — Python ML stack

Publiczne jash90/vasculitis-xai: FastAPI + XGBoost/LightGBM/CatBoost + SHAP + LIME + LangChain + ChromaDB. Image python:3.11-slim ≈ 2-3 GB.

ai-gateway — Raccoon AI Gateway, publiczny SaaS

Publiczne jash90/ai-gateway: NestJS 11 + Fastify + Prisma + Redis + BullMQ + Stripe. Multi-tenant BYOK proxy dla OpenAI/Anthropic/OpenRouter. AES-256-GCM envelope encryption dla kluczy klientów.

citygame — NestJS 10 + R2 + Socket.IO

Publiczne jash90/citygame: NestJS 10 + Prisma + Socket.IO + Cloudflare R2 (już używają). Ma swój docker/ i własny compose.

ai-projects — NX monorepo z własnym compose

Publiczne jash90/ai-projects: Nx + NestJS + Next.js + Bun. Ma już docker-compose.yml i docker-compose.monitoring.yml (Prometheus + Grafana + node-exporter + cadvisor) — to autor wiedział, że będzie migrował.

sesja-master — Next.js 15 + Bun

Publiczne jash90/sesja-master: Next.js 15 + Bun, ma własny Caddyfile z dynamic port routing. Śpi na Railway.

6. Kody źródłowe — co publiczne, co prywatne

Publiczne (clone bez auth)	Prywatne (wymaga `gh auth`)
`jash90/sesja-master` (583 MB) `jash90/citygame` (3.7 MB) `jash90/ai-gateway` (616 KB) `jash90/ai-projects` (5.9 MB) `jash90/pkd-search-frontend` (1.3 MB) `jash90/pkd-search-backend` (198 KB) `jash90/vasculitis-xai` (6.8 MB)	`jash90/accounting-app` (2 środowiska: prod+dev) `jash90/description-generator` `jash90/health-monitor` user potwierdza dostęp

Domeny:

kodypkd.app — DNS na OVH (ns100.ovh.net), A=66.33.22.67
formendo.pl — DNS na home.pl (dns.home.pl), A=46.242.240.126

7. Squash TM — szczegółowa analiza

Połączony bezpośrednio z Railway Postgres Squash TM przez railway variable list -s Postgres → psql do maglev.proxy.rlwy.net:37929.

Test cases
690
100% WORK_IN_PROGRESS (drafty)

Test steps

2199

3.19 step/TC średnio

Execution count

nikt nigdy nie wykonał TC

DB size

151 MB

tabela action_test_step = 34 MB

Rozkład ważności (importance)

Ważność	Liczba	%
HIGH	304	44%
MEDIUM	279	40%
LOW	107	16%

Zawartość kroków (expected_result)

Bucket	n
< 100 znaków	819
100-500	525
500-2k	165
2k-10k	0
10k-100k (screenshoty)	689
> 100k (duży obraz)	1

Wniosek: 690/690 expected_result ma data:image/jpeg;base64,… — każdy test case ma embedded screenshot oczekiwanego widoku ekranu z aplikacji. To są TC dla health-monitor (Formendo).

Co to mówi o użyciu

Squash TM jest WYŁĄCZNIE repozytorium test cases dla Formendo. Nie był używany jako TMS:

0 wykonań (executions) w 12+ miesięcy

0 kampanii, 0 iteracji

0 traceability do requirements

0 automation (nic nie zautomatyzowane)

Wszystkie 690 TC = WORK_IN_PROGRESS

To jest wiki/list do manualnej weryfikacji, nie aktywne narzędzie do zarządzania testami.

Sample TC (2167: STRUKTURA NAWIGACJI - DOCK)

Prerequisite: Pacjent zalogowany, dock widoczny (natywny), język PL.

Step 1: Odczytaj jej etykietę.
  Expected: (pusty)

Step 2: Otwórz dock i zlokalizuj trzecią widoczną zakładkę (po Dziś i Postęp).
  Expected: 📷 Oczekiwany widok ekranu (zrzut z aplikacji): [screenshot base64]

Step 3: Wejdź w tę zakładkę i sprawdź, czy prezentuje benefity, zniżki
  i marketplace zgodnie ze specyfikacją.
  Expected: WYMAGANIE WG SPEC (do uruchomienia po implementacji):
  trzecia zakładka docka nazywa się "Korzyści…"

Porównanie z alternatywami

Narzędzie	Free tier	Czy zmieści 690 TC	Migracja effort
Squash TM (teraz)	∞ self-host	✅, ale overkill	—
Notion	1 GB	✅ (po wyciągnięciu base64 obrazów)	30 min
Airtable	1 GB / 5 users	✅	2h
TestRail	trial 30 dni	✅	1-2h
Qase	3 users	✅	1h
GitHub Issues	∞	✅ (TC jako issues)	30 min
Postgres + Next.js	∞	✅ (pełna kontrola)	1-2 dni

Rekomendacja: 3 opcje

A. Zostawić Squash na Railway (0 roboty, $0.5-1/mies) — jeśli nie przeszkadza koszt i ktoś może kiedyś wrócić do TC
B. Eksport do Notion / Airtable (2-4h, darmowe) — uwalnia 1.23 GB RAM na Mikrusie, lepszy UX
C. Postgres + custom UI (1-2 dni, $0) — pełna kontrola, API do automatyzacji

Najprostsze: Zostawić Squash na Railway + eksport XLSX do Notion jako archiwum. Łączny koszt: 30 min + grosze.

Jak wyciągnąć TC ze Squash (na wypadek migracji)

# Schema + data dump
railway connect Postgres -- pg_dump -Fc \
  -t test_case -t test_step -t action_test_step \
  -t test_case_steps -t test_case_library_node \
  squash > squash-data.dump

# Albo CSV per tabela
psql "$DBURL" -c "\COPY test_case TO '/tmp/test_case.csv' CSV HEADER"
psql "$DBURL" -c "\COPY action_test_step TO '/tmp/steps.csv' CSV HEADER"

# Squash TM sam ma eksport UI: Settings → Export → Excel

8. Plan migracji

8 faz, 5-6 dni. Squash na końcu (po decyzji).

Faza 0 — Przygotowanie hosta (Dzień 0, ~30 min)

apt update && apt upgrade -y
apt install -y docker.io docker-compose-plugin
systemctl enable --now docker
docker network create proxy

# Cloudflare Tunnel (poza agentem — wymaga konta CF)
cloudflared tunnel login
cloudflared tunnel create hermes-tunnel
cloudflared service install
# DNS: kodypkd.app, www.kodypkd.app, api.formendo.pl
#   → CNAME <tunnel-id>.cfargotunnel.com

Faza 1 — squash-tm (rozgrzewka)

1 kontener + Postgres. Najprostszy przypadek. Albo zostaje na Railway (rekomendacja).

Faza 2 — vasculitis-xai, sesja-master

Zero custom env vars. Wszystko w railway.toml/nixpacks.toml w repo. gh clone + budowa.

Faza 3 — accounting-dev

Ten sam jash90/accounting-app (NestJS). Test migracji na dev przed prod.

Faza 4 — description-generator

2 serwisy (api + web) + Postgres, monorepo jash90/description-generator.

Faza 5 — ai-gateway

Kod publiczny. Raccoon BYOK SaaS. Prisma + Redis + BullMQ + Stripe. Wymaga ostrożności z szyfrowaniem AES-256-GCM.

Faza 6 — health-monitor (Formendo), citygame, ai-projects

Schemat powtarzalny. Health-monitor ma custom domenę api.formendo.pl — trzeba zmienić A/AAAA w home.pl na nowy endpoint.

Faza 7 — pkd-search

Najtrudniejszy: Qdrant + Postgres + 2 serwisy + custom domeny kodypkd.app + www.kodypkd.app.

Qdrant snapshot z Railway (REST API)
Postgres restore
Cutover domeny w panelu OVH
Smoke test: pełen flow wyszukiwania PKD

Faza 8 — accounting-prod (cutover produkcyjny)

Krytyczny. W piątek po południu (bufor weekendowy na rollback):

pg_dump prod, restore
DNS cutover api-production-ffd9.up.railway.app → nowy endpoint
Rotacja WSZYSTKICH sekretów (JWT, ENCRYPTION, AI_API_KEY) — stare wyciekły w dumpie CLI
Czyszczenie Railway po 7 dniach stabilności: railway delete -p accounting-prod

9. Optymalizacja zasobów

A. Współdzielony Postgres (1 zamiast 9)

Każda baza < 250 MB, sumarycznie 2.3 GB → mieści się w jednym kontenerze. Każda ma własnego usera i hasło. Backup per-baza.

postgres-shared (1 kontener, image postgres:17-alpine)
├── baza: accounting_prod     (user: acc_prod)
├── baza: accounting_dev      (user: acc_dev)
├── baza: ai_gateway          (user: ai_gw)
├── baza: citygame            (user: citygame)
├── baza: description_gen     (user: descgen)
├── baza: health_monitor      (user: hmon)
├── baza: pkd_search          (user: pkd)
├── baza: ai_projects         (user: ai_proj)
├── baza: vasculitis          (user: vasc)
└── baza: sesja               (user: sesja)

Wyjątek: accounting_prod dostaje osobną instancję postgres-prod dla izolacji (krytyczny).

B. Współdzielony Redis (1 zamiast 4)

DB 0-3 dla 4 projektów. Konfiguracja per-projekt: REDIS_URL=redis://redis-shared:6379/N.

# redis.conf
maxmemory 256mb
maxmemory-policy allkeys-lru

C. Qdrant dla pkd-search (NIE pgvector)

Backend ma hardcoded @qdrant/js-client-rest. Snapshot via REST API:

curl -X POST "http://qdrant:6333/collections/pkd/snapshots"
curl "http://qdrant:6333/collections/pkd/snapshots/<id>" -o /opt/backups/qdrant/pkd-<date>.snapshot
curl -X PUT "http://qdrant:6333/collections/pkd/snapshots/upload?priority=snapshot" \
  --data-binary @/opt/backups/qdrant/pkd-<date>.snapshot

D. Squash TM — zostaje na Railway

1.23 GB RAM = 18% Mikrusa. Koszt $0.5-1/mies Railway. Lepiej zostawić niż rezygnować z 18% bufora RAM.

E. Health-monitor (Formendo) — pełen stack

NIE zamieniamy na Uptime Kuma. Produkcyjna płatna apka medyczna.

F. Multi-stage Dockerfiles

FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build && npm prune --production

FROM node:20-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
USER node
EXPOSE 3000
CMD ["node", "dist/main.js"]

Rezultat: 1.2 GB → 200 MB per obraz. Warstwy współdzielone między serwisami.

G. Backupy — 7 dni lokalnie + 1× tygodniowo R2

#!/bin/bash
DAY=$(date +%u)
DEST_LOCAL="/opt/backups/pg"
DEST_R2="r2:hermes-backups/weekly"

for db in accounting_prod accounting_dev ai_gateway citygame description_gen health_monitor pkd_search ai_projects vasculitis sesja; do
  pg_dump -U postgres -Fc -Z 9 -d "$db" > "$DEST_LOCAL/${db}-$(date +%F).dump"
done

find "$DEST_LOCAL" -name "*.dump" -mtime +7 -delete

if [ "$DAY" = "7" ]; then
  rclone copy "$DEST_LOCAL" "$DEST_R2/$(date +%G-W%V)/" --transfers 4
fi

pg_dump -Fc -Z 9 = custom + max compression. 230 MB text → 50 MB compressed. ~4.5× mniejsze.

H. Profile on-demand dla serwisów sleeping

4 serwisy śpią. Nie trzymać ich w pamięci. Compose profiles:

services:
  sesja-master:
    profiles: ["on-demand"]
    # ...

Użycie: docker compose --profile on-demand up sesja-master

Finalny stack

#	Kontener	Image	RAM	Dysk
1	`postgres-shared`	postgres:17-alpine	200 MB	1.5 GB
2	`postgres-prod`	postgres:17-alpine	200 MB	500 MB
3	`redis-shared`	redis:7-alpine	50 MB	200 MB
4	`qdrant-pkd`	qdrant/qdrant	50 MB	200 MB
5-11	7× Node serwisy	node:20-alpine multi-stage	2 GB	1.5 GB
12	`caddy`	caddy:2-alpine	30 MB	50 MB
13	`cloudflared`	cloudflare/cloudflared	30 MB	30 MB
RAZEM			~2.7 GB	~4.2 GB + image cache

Zostaje ~5.3 GB RAM i ~63 GB dysk. Dużo zapasu na logi, backupy, przyszłe projekty.

10. Disaster Recovery (minimum)

Bez tych elementów Mikrus jest jednopołówkowy: awaria = utrata wszystkiego.

Co wdrażam w Fazie 0

Offsite backup na Cloudflare R2 (10 GB darmowe, S3-compatible). Bez tego: utrata Mikrusa = utrata wszystkich danych Railway.
Test restore co miesiąc — wpis w kalendarzu, skrypt restore-test.sh.
Monitoring + alerty — Uptime Kuma + Telegram/Discord webhook. Sprawdza co 60s, alert po 2× failure (3 min opóźnienia).
SSH przez Tailscale (nie wystawiamy portu 22 na świat). 100 urządzeń za darmo.
Dokumentacja odtwarzania — RUNBOOK.md w /opt/hermes-config/notes/railway-migration/.
Sekrety poza serwerem — po migracji do bitwarden albo /opt/hermes-config/secrets/ z chmod 600 + age szyfrowanie.

RTO/RPO po Fazie 0

Awaria	RTO	RPO
Utrata pojedynczej bazy	15 min	0-24h
Utrata całego serwera	1-2h	0-24h
Włamanie	3-4h (reinstall + restore + rotate)	0-24h
Utrata Mikrusa (firma padnie)	= postawienie nowego VPS + restore	0-7d

Czego NIE daję (koszt)

PITR (point-in-time recovery) — wymaga ciągłego WAL archiving, dodaje 30 min konfiguracji. Realnie potrzebne tylko dla accounting-prod.
Multi-region — wymaga drugiego VPS. Niepotrzebne.
Replikacja baz w czasie rzeczywistym — komplikuje deployment, daje RPO ~sekundy.

11. Ryzyka i mitygacje

Ryzyko	P	Mitygacja
Brak publicznego IPv4 na Mikrusie	pewne	Cloudflare Tunnel (HTTPS-only, zero open portów)
68 GB dysku nie starczy na 9× Postgres 5GB	średnie	2 GB per baza + R2 backup (wystarczy)
8 GB RAM nie udźwignie wszystkich Node + DB	średnie	uruchamiać wg potrzeby; squash zostaje na Railway
Kod repo niepubliczny (3 prywatne)	pewne	`gh auth login` (user potwierdza dostęp)
Sekrety wyciekły w dumpie Railway CLI	wysokie	pełna rotacja po migracji
Cutover domeny `kodypkd.app` — downtime	średnie	DNS TTL=60 przed cutover, CF Load Balancer (stary+nowy) na przejście
vasculitis-xai image 2-3 GB	średnie	multi-stage slim, cache warstw współdzielony
Włamanie na Mikrusa (SSH exposed)	średnie	Tailscale SSH, klucze tylko, fail2ban

Sekrety do rotacji PO migracji

JWT_SECRET, JWT_REFRESH_SECRET (accounting, citygame, health-monitor)
ENCRYPTION_KEY, ENCRYPTION_SECRET (accounting, ai-gateway)
AI_API_KEY_ENCRYPTION_KEY (accounting)
MASTER_ENCRYPTION_KEY (ai-gateway — Raccoon BYOK!)
SENTRY_DSN (wszystkie)
SMTP_* (accounting, health-monitor)
P24_*, RC_API_KEY, REVENUECAT_WEBHOOK_SECRET (health-monitor)
OPENAI_API_KEY (health-monitor, pkd-search)
EXPO_ACCESS_TOKEN (health-monitor)
Hasła seed: SEED_ADMIN_PASSWORD, SEED_EMPLOYEE_PASSWORD, SEED_OWNER_PASSWORD

12. Do zrobienia (checklist)

Przed startem Fazy 0

Decyzja Squash — zostawić na Railway, eksportować, czy migrować?
DNS provider — przenieść kodypkd.app i formendo.pl na CF NS, czy zostawić obecne NS-y i tylko dodać CNAME?
Cloudflare konto — założyć jeśli nie masz (potrzebne do tunelu + R2)
gh auth login — dla 3 prywatnych repo (accounting, description-generator, health-monitor)

W trakcie Fazy 0 (poza agentem)

cloudflared tunnel login + cloudflared tunnel create hermes-tunnel
DNS records: kodypkd.app, www.kodypkd.app, api.formendo.pl → CNAME tunelu
Cloudflare R2: bucket hermes-backups
Tailscale: instalacja + połączenie
Bitwarden/Pass: repo dla sekretów

Po migracji (musisz zrobić)

Rotacja WSZYSTKICH sekretów (JWT, ENCRYPTION, Sentry, SMTP, P24, RevenueCat, OpenAI)
CORS: dodaj nowe URL Mikrusa do CORS_ORIGINS/CORS_WHITELIST w accounting, Formendo, citygame
Stripe webhook URLs → nowy endpoint (jeśli ustawione na Railway)
RevenueCat / Przelewy24 callback URLs → nowy endpoint
Expo push certificate → regeneracja po zmianie domeny API (apka iOS w App Store)
Test restore co miesiąc: restore-test.sh accounting_prod

Po 7-14 dniach stabilności

railway delete -p accounting-prod i reszta projektów
Anuluj subskrypcję Railway Hobby plan