Pinbox24 — Analiza Systemu
Utworzono: 2026-07-01 Autor: Claude Code (p24-infra admin) Zakres: Architektura, aktywni klienci, analiza migracji na Vercel, rekomendacje Powiązane:
docs/evaluation/04-pinbox24-map-dr-audit.md— pełny audyt DR GitLab:gitlab.com/pinbox24/— dostęp przezGITLAB_ADMIN_PATwsecrets/administration.env.sops
1. Stan aktualny — przegląd
Środowiska produkcyjne
| Wersja | Frontend | API | Stack | Serwer | Status |
|---|---|---|---|---|---|
| W4 (v4.1/v4.2) | w4.pinbox24.com | api.w4.pinbox24.com | Angular + Node.js | bms-1 | Produkcja aktywna |
| W3 (v3.1/v3.2) | w3.pinbox24.com | api.w3.pinbox24.com | Angular + Node.js (legacy) | bms-1 | Legacy — 2 klientów |
Mikrousługi W4 (bms-1, wszystkie z AWS ECR)
| Kontener | Domena | Funkcja | Uptime |
|---|---|---|---|
v42-prod | api.w4.pinbox24.com | Główny backend Node.js | 3 mies. |
v41-prod | w4.pinbox24.com | Angular frontend | 14 mies. ⚠️ lokalny image |
s3-v42-prod | s3-api.w4.pinbox24.com | File storage API → Wasabi S3 | 3 mies. |
s3-v2-v42-prod | s3-v2-api.w4.pinbox24.com | File storage v2 → Wasabi S3 | 3 mies. |
mailgun-v42-prod | mailgun-api.w4.pinbox24.com | Wysyłka emaili (Mailgun EU) | 3 mies. |
pdf-gen-v42-prod | pdf-gen-api.w4.pinbox24.com | Generowanie PDF (wkhtmltopdf) | 5 lat |
v42-notify-prod | api-notify.w4.pinbox24.com | Push notifications | 5 lat |
wkhtml-v42-prod | wewnętrzny | wkhtmltopdf binary wrapper | 5 lat |
git-deploy-v42-prod | git-deploy-api.w4.pinbox24.com | GitLab CI webhook → deploy | 5 lat |
Baza danych — MongoDB rs0
| Member | Serwer | IP | Rola | Uwagi |
|---|---|---|---|---|
| bms-3 | OVH ns3129867 | 51.68.155.224 | PRIMARY/SECONDARY | Współdzieli RAM z kontenerami staging (21.7 GB / 32 GB) |
| bms-2 | OVH ns3087638 | 145.239.133.104 | SECONDARY (non-voting, priority=0) | Nie może samodzielnie zostać PRIMARY |
| bms-4 | OVH ns3101999 | 54.36.123.110 | ARBITER | Brak danych, tylko wybory |
Storage plików
Backend: Wasabi S3 — potwierdzony w p24-ms-mailgun i pinbox24-ms-s3-v2.
Pipeline: mailgun → p24-ms-mailgun → pinbox24-ms-s3-v2 → MongoDB (metadane) + Wasabi S3 (pliki).
Deployment pipeline
git push → GitLab CI (runner na bms-1, tag: autodeploy/prod-deploy-p24)
→ docker build → push AWS ECR (563740926945.dkr.ecr.eu-central-1.amazonaws.com)
→ webhook → git-deploy-api.w4.pinbox24.com
→ docker pull ECR → restart kontenera
→ nginx-proxy (jwilder) auto-routing via VIRTUAL_HOST env var
Znane repo GitLab (gitlab.com/pinbox24/):
pinbox24-ms-s3-v2— S3 v2 microservicep24-ms-mailgun— Mailgun microservicep24-server-scripts— skrypty serwerowen8n-code-automation— backup workflow n8n
Główne repo backendowe i frontendowe (Angular, Node.js v4/v3) — nazwy do ustalenia przez API GitLab (GITLAB_ADMIN_PAT).
2. Aktywni klienci
Metodologia: zapytania do
w4_db.regRecordsiw3_db.regRecords(polecreatedAt), wykonane 2026-07-01. SchematregRecords:_id, creatorEmail, creatorId, workspaceId, officeId, regId, modificatorLogin, modificatorId, year, month, formId, responsibleEmail, responsibleId, signature, recordData, createdAt, updatedAt, __v, instanceId, processId, processStatusId, processStatusLabel, statusInitTime, deleted
w4.pinbox24.com — produkcyjni klienci
7 aktywnych klientów (wg danych z ostatnich 18 miesięcy, stan 2026-07-01):
| Klient | officeId | Trend aktywności | Status |
|---|---|---|---|
| Eco-Trans | 5c752bbca20da35ca1b99083 | ~6 500 rek./mies., stabilny | ✅ Aktywny — własny klient |
| Keller | 5d36ccf9903f5002cca1e474 | ~750 rek./mies., stabilny 18 mies. | ✅ Aktywny |
| ZPK | 5ebb7e06cc4fa94598071c7c | ~370 rek./mies., stabilny 18 mies. | ✅ Aktywny |
| MOW Malbork | 5d40241715ec4a5764c2f914 | ~195 rek./mies., stabilny 18 mies. | ✅ Aktywny |
| Bibus Menos | 5d3ad60615ec4a5764c2d631 | ~150/mies. → 37/mies. od kwi’26 | ⚠️ Spadek aktywności |
| Zhonghua | 5d400a2415ec4a5764c2f321 | ~70/mies. → brak od kwi’26 | ⚠️ Prawdopodobny churn |
| Valmont | 5e2afb12ee340301e3453833 | ~45/mies. → 8/mies. cze’26 | ⚠️ Odchodzi |
Pivot: rekordy per klient per miesiąc (styczeń 2025 – czerwiec 2026)
| Klient | 01/25 | 02/25 | 03/25 | 04/25 | 05/25 | 06/25 | 07/25 | 08/25 | 09/25 | 10/25 | 11/25 | 12/25 | 01/26 | 02/26 | 03/26 | 04/26 | 05/26 | 06/26 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Eco-Trans | 5 850 | 6 262 | 15 486 | 5 806 | ⚠️ 157 156 | 3 684 | ⚠️ 23 843 | 15 648 | 5 487 | 5 809 | 6 343 | 9 210 | 8 115 | 5 107 | 5 889 | 6 030 | 8 768 | 6 897 |
| Keller | 784 | 725 | 844 | 789 | 724 | 762 | 782 | 752 | 715 | 798 | 727 | 959 | 647 | 697 | 662 | 727 | 851 | 660 |
| ZPK | 300 | 251 | 278 | 329 | 294 | 323 | 357 | 263 | 426 | 450 | 372 | 558 | 402 | 326 | 365 | 384 | 336 | 312 |
| MOW Malbork | 156 | 225 | 235 | 191 | 139 | 220 | 276 | 101 | 182 | 232 | 162 | 204 | 193 | 213 | 225 | 183 | 157 | 231 |
| Bibus Menos | 135 | 131 | 119 | 153 | 133 | 143 | 161 | 117 | 132 | 116 | 155 | 132 | 177 | 139 | 159 | 37 | 30 | 39 |
| Zhonghua | 71 | 72 | 99 | 70 | 69 | 82 | 99 | 64 | 49 | 70 | 40 | 53 | 52 | 45 | 34 | — | — | — |
| Valmont | 48 | 64 | 35 | 36 | 42 | 34 | 47 | 29 | 33 | 50 | 42 | 41 | 33 | 64 | 29 | 19 | 9 | 8 |
Anomalie Eco-Trans:
- Maj 2025: 157 156 rekordów — masowy bulk import (~25× normalny poziom). Prawdopodobnie historyczne dane wgrane jednorazowo.
- Lipiec 2025: 23 843 rekordów — kolejna fala importu.
Inne biura w danych (nieaktywni klienci / testy):
orgFlow24.com— sty–mar 2025 tylko (413 rek. szczytowo), brak od kwi’25Lib2/Library Mgmt System— grudzień 2025 tylko (383 + 24 rek.) — piloty, które nie przeszły do regularnego użycia- ~36 biur z losowymi nazwami (
gjfjcvdf,utfbtyfditp.) — konta testowe z onboardingu/demo 2025–2026, aktywne 1–2 miesiące dfdfdfdfdf— grudzień 2025: 83 346 rekordów — load test / stress test środowiska
w3.pinbox24.com — aktywni klienci
2 aktywnych klientów (dane z ostatnich 6 miesięcy, stan 2026-07-01):
| Klient | officeId | Rekordy (6 mies.) | Uwagi |
|---|---|---|---|
| RESO EUROPA | 590c6d334704d811efc9fd5a | 35 150 | ~86% ruchu W3 — integracja danych nieruchomości przez v32-prod-reso (w3.reso-integration-addrecords.pinbox24.com) |
| Gratus | 5bae738807770e585186308b | 409 | Klient legacy na w3.pinbox24.com |
Biura global office (6 rek.) i EAT 3.0 office (4 rek.) — praktycznie nieaktywne.
Uwaga techniczna W3: W3 była podłączona do zewnętrznego MongoDB na eat-hn1.artnet.pl:30071. Migracja v32-prod i s3-v32-prod na bms-2/w3_db zakończona 2026-07-01. Sterownik mongodb 2.2.11 (OP_QUERY) wymagał obejścia przez konfigurację serwera MongoDB; v42-prod i mikrousługi W4 nadal podłączone do artnet — dekomisja artnet wymaga ich wcześniejszej migracji.
3. Analiza migracji na Vercel
Kontekst biznesowy dla decyzji o migracji
Prawdziwa baza klientów W4 to 7 aktywnych biur (bez kont testowych):
- Eco-Trans (~6 500 rek./mies.) — własny klient; dominuje ruch
- Keller, ZPK, MOW Malbork — stabilni, łącznie ~1 300 rek./mies.
- Bibus Menos, Zhonghua, Valmont — malejąca aktywność; możliwy churn w 2026
W3 to 2 klientów: RESO EUROPA (data feed, 35k rek./6 mies.) i Gratus.
Implikacja: Skala klientów jest mała — migracja na Vercel nie jest dyktowana skalowalnością, tylko eliminacją ryzyka operacyjnego (bms-1 EOL, brak backupów) i uproszczeniem deploymentu.
Podsumowanie nakładu
| Kategoria | Nakład | Uwagi |
|---|---|---|
| Frontendy Angular (W4 + W3) | 1 tydzień | Statyczne SPA — trivial na Vercel |
| Backend Node.js v42-prod | 4–8 tygodni | Największy blok; wymaga audytu kodu z GitLab |
| Mikrousługi (S3, mailgun, git-deploy) | 2–3 tygodnie | Wasabi S3 potwierdzony ✅ — brak zależności lokalnych |
| PDF generator | 1–2 tygodnie | wkhtmltopdf nie działa serverless — wymiana na Gotenberg |
| WebSocket (v32-prod-socket, W3/RESO) | 2–3 tygodnie | Persistent connection — wymiana serwisu (Pusher/soketi) |
| Testy i cutover DNS | 2 tygodnie | |
| Razem | ~3–4 miesiące |
Co idzie na Vercel bezproblemowo
| Serwis | Forma na Vercel | Nakład | Uwagi |
|---|---|---|---|
v41-prod Angular W4 | Static build (next build lub ng build --prod) | 2–3 dni | CORS update, env vars dla API URL, DNS |
v31-prod Angular W3 | Static build | 1–2 dni | |
git-deploy-v42-prod | Vercel Function (1 endpoint webhook) | 1 dzień | Trivial — HTTP handler |
mailgun-v42-prod | Vercel Function | 2–3 dni | Bugs do poprawienia wg mailgun-flow-fix-plan.md |
Co wymaga refaktoryzacji, ale jest możliwe
| Serwis | Problem | Nakład | Rozwiązanie |
|---|---|---|---|
v42-prod Node.js backend | Serverless = brak persistent DB connections; limit 60s/request | 4–8 tygodni | mongoose connection caching pattern; każdy endpoint → osobna Function; sprawdzić czy nie ma long-running procesów |
s3-v42-prod / s3-v2-v42-prod | Proxy do Wasabi S3 — Wasabi potwierdzony ✅ | 1–2 tygodnie | Rewrite jako Vercel Functions (Node.js API routes → @aws-sdk/client-s3 z Wasabi endpoint) — brak zależności lokalnych, storage w chmurze |
v42-notify-prod push notifications | Jeśli SSE/polling → OK; jeśli WebSocket → problem | 1–3 tygodnie | Weryfikacja kodu; jeśli WebSocket → Pusher/Ably |
| Redis (bms-1 native) | Vercel nie ma własnego Redis | 1–2 dni | Upstash Redis (~$20–80/mies.) |
Czego nie da się przenieść na Vercel — wymagana alternatywa
| Serwis | Bloker | Alternatywa | Koszt alternatywy |
|---|---|---|---|
pdf-gen-v42-prod + wkhtml-v42-prod | Binary dependency — wkhtmltopdf nie działa w sandboxie serverless | Gotenberg (self-hosted na VPS) lub Browserless.io lub PDFShift API | 0 (Gotenberg) lub ~$50/mies. (SaaS) |
v32-prod-socket WebSocket | Persistent connection — Vercel Functions bezstanowe | Pusher / Ably / soketi self-hosted | ~$50–200/mies. (Pusher) lub 0 (soketi na VPS) |
| MongoDB rs0 | Baza danych na serwerach OVH — nie może być na Vercel | Zostaje na bms-2/3/4 lub MongoDB Atlas (+1500 EUR/mies.) | 0 (zostaje) |
Cron jobs (cron-v32-prod × 3) | Vercel Cron: max 1/minuta (Pro) | n8n na bms-4 lub cron na VPS | 0 (n8n już istnieje) |
| GitLab runner (bms-1 native) | Zewnętrzna infrastruktura CI | Zostaje na bms-1 lub migracja na GitHub Actions | 0 |
Diagram zależności (co blokuje co)
Równolegle (niezależne):
[A] Frontendy Angular W4 + W3 → Vercel Static
[B] Mailgun microservice → Vercel Function (+ bug fixes z mailgun-flow-fix-plan.md)
[C] git-deploy webhook → Vercel Function
[D] Wasabi S3 microservices → Vercel Functions (rewrite bez binarnych zależności)
[E] Znalezienie alternatywy dla PDF generator (Gotenberg)
[F] Znalezienie alternatywy dla WebSocket (soketi/Pusher)
Sekwencyjnie (po A–F):
[G] Backend v42-prod → Vercel Functions (wymaga audytu kodu z GitLab)
└── blokuje: znajomość actual endpoints, long-running jobs, file system usage
Pozostaje na serwerach (stale):
[H] MongoDB rs0 (bms-2/3/4) — bez zmian
[I] GitLab runner na bms-1 — bez zmian lub migracja na GH Actions
[J] Gotenberg/soketi — jeśli self-hosted, na vps-i1 lub bms-4
Analiza kosztów (miesięcznie)
| Składnik | Teraz | Po migracji |
|---|---|---|
| bms-1 (OVH Kimsufi) | ~50 EUR | Można częściowo odciążyć (GitLab runner + Gotenberg zostają) |
| Vercel Pro | — | ~$20/seat/mies. + invocations |
| Redis | 0 (natywny) | Upstash ~$20–80/mies. |
| PDF generator | 0 (wkhtmltopdf) | 0 jeśli Gotenberg self-hosted |
| WebSocket | 0 (własny) | 0 jeśli soketi self-hosted lub ~$50–200 SaaS |
| MongoDB rs0 | ~150 EUR (bms-2/3/4) | Bez zmiany |
| Oszczędność netto | Minimalna — bms-1 trudno w pełni odciążyć |
Wniosek: Migracja na Vercel nie przynosi znaczących oszczędności finansowych. Główna wartość to:
- Automatyczne skalowanie frontendów (CDN)
- Eliminacja Ubuntu 20.04 EOL na bms-1
- Lepsza observability (Vercel Analytics)
- Wyeliminowanie ryzyka operacyjnego związanego z ręcznym zarządzaniem kontenerami
Nieznane wymagające weryfikacji (przez GitLab API + code review)
Przed pełną migracją backendu konieczny audyt kodu v42-prod:
- Czy backend używa
require('fs')/ lokalnych plików? — jeśli tak, wymaga przepisania - Czy są długo działające procesy (>60 sekund)? — konieczne Edge Functions lub osobny worker
- Ile endpointów ma backend? — każdy staje się osobną Vercel Function
- Jakie cron joby uruchamia v42-prod? — przeniesienie na n8n lub Vercel Cron
- Wersja Node.js i zależności — sprawdzenie kompatybilności serverless
4. Ryzyka operacyjne (bieżące)
| Ryzyko | Priorytet | Status |
|---|---|---|
v41-prod frontend — lokalny image (untagged), nieodtwarzalny po zatrzymaniu | P1 | Otwarte |
| MongoDB backup — ostatni dump luty 2026 (4+ miesięcy temu) | P1 | Otwarte |
| W3 artnet → bms rs0 migracja — deadline 2026-07-31 | P1 | W toku |
| bms-1 Ubuntu 20.04 EOL | P2 | Otwarte |
| GitLab runner na bms-1 — zwraca 403 (od 2026-06-29) | P2 | Wymaga re-rejestracji |
v32-prod-socket i v32-prod-reso — untagged images | P2 | Otwarte |
Hardcoded credentials w docker-deploy-prod.sh (oba repo GitLab) | P1 | Tracking #2052 |
| bms-1 disk 85% | P2 | Otwarte |
| private-registry.dev.pinbox24.com — status nieznany | P2 | Otwarte |
Pełny audyt DR: docs/evaluation/04-pinbox24-map-dr-audit.md
5. Rekomendacje
Krótkoterminowe (ten tydzień)
- Wyeksportować untagged images z bms-1 do Wasabi (
v41-prod,v32-prod-socket,v32-prod-reso) — P1 - Uruchomić MongoDB dump na bms-3 i wgrać do Wasabi — P1
- Re-zarejestrować GitLab runner na bms-1 (playbook:
docs/playbooks/gitlab-runner-bms1-reregister.md) — P2 - Wylistować wszystkie repo GitLab przez API (
GITLAB_ADMIN_PAT) — potrzebne do audytu kodu
Średnioterminowe (migracja Vercel — strategia hybrydowa)
Faza 1 (1 tydzień) — już teraz:
- Frontendy Angular W4 i W3 → Vercel Static
- Natychmiastowe korzyści: CDN, HTTPS auto-managed, zero-downtime deploys
Faza 2 (2–3 tygodnie) — mikrousługi:
- S3 Wasabi microservices → Vercel Functions (brak binarnych zależności — trivial)
- Mailgun microservice → Vercel Function (+ wdrożenie bugfixes z
mailgun-flow-fix-plan.md)
Faza 3 (po audycie kodu GitLab) — backend:
- Klonowanie i audyt
v42-prodrepo - Identyfikacja endpointów, cron jobs, file system usage
- Decyzja: pełna migracja serverless vs. pozostanie na VPS z lepszym Docker setup
Pozostaje na serwerach (zawsze):
- MongoDB rs0 (bms-2/3/4)
- GitLab runner (lub migracja na GH Actions)
- Gotenberg (PDF) — self-hosted na vps-i1 obok monitoring stacka
Długoterminowe
- Wycofranie W3 po migracji klientów RESO i Gratus do W4 (lub sunset)
- Upgrade bms-1: Ubuntu 20.04 → 24.04 (playbook:
docs/playbooks/bms1-ubuntu-2204-upgrade.md) - Automatyczny MongoDB backup do Wasabi (nightly cron na bms-3)
6. Dostęp do GitLab
| Zasób | Lokalizacja |
|---|---|
| Personal Access Token (admin) | GITLAB_ADMIN_PAT w secrets/administration.env.sops |
| Znane repozytoria | gitlab.com/pinbox24/{pinbox24-ms-s3-v2,p24-ms-mailgun,p24-server-scripts,n8n-code-automation} |
| Główne repo app (nazwy TBD) | Wylistować przez GET /api/v4/groups/pinbox24/projects |
| Runner (bms-1) | Tag autodeploy, prod-deploy-p24; stan: broken 403 od 2026-06-29 |
| SSH z bms-1 | git@gitlab.com:pinbox24/... (HTTPS nie działa — brak SSL client cert) |
Playbook re-rejestracji runnera: docs/playbooks/gitlab-runner-bms1-reregister.md
Dokument żywy — aktywni klienci W4 zostaną uzupełnieni po wyniku zapytania MongoDB do w4_db.regRecords.