- Krok 9 (tmux): tee -> tee -a (nie nadpisuj configu), dodano focus-events on, poprawiono nazwę sesji na "bootstrap" - Krok 10: struktura katalogów odzwierciedla stan faktyczny (/srv i /srv/infra już istnieją, brakuje apps i data) - Krok 12: Claude Code oznaczony jako wykonany 20-08-2026, instalator natywny bez Node.js - Nowy Krok 14: audyt po bootstrapie (SSH, ufw, fail2ban, unattended-upgrades, swap, Docker, porty, klucze) - HANDOFF.md: poprawiona numeracja sekcji 6
5.7 KiB
HANDOFF.md — przekazanie kontekstu
Dokument jednorazowy. Powstał w rozmowie na claude.ai przed pierwszym uruchomieniem serwera i przenosi ustalenia do sesji Claude Code na maszynie.
Czytasz go raz, na starcie pierwszej sesji. Trwałe zasady są w CLAUDE.md,
stan serwera w docs/SERVER.md, procedury w docs/runbooks/.
Po zakończeniu bootstrapu ten plik można usunąć.
1. Z kim pracujesz
Kacper, k.kruszka@hotmail.com. Pracuje z macOS, Windows i iOS.
Kluczowe: to projekt edukacyjny z produkcyjnymi konsekwencjami. Kacper uczy się pracy z Claude i administracji serwerem — więc tłumaczysz co robisz i dlaczego, nie tylko wykonujesz. Ale docelowo mogą tu stanąć rzeczy komercyjne, więc traktujesz maszynę jak produkcję od pierwszego dnia.
Prosił wprost, żeby proaktywnie podpowiadać o narzędziach, skillach i funkcjach, które mogą pomóc — nie czekać, aż sam zapyta.
2. Maszyna
| OVH VPS-2 2026 | 6 vCore, 12 GB RAM, 100 GB SSD |
| Host | vps-c936b594.vps.ovh.net, IPv4 54.38.159.156 |
| System | Ubuntu 24.04 LTS, świeży |
| Panel OVH | region CA — ma znaczenie przy generowaniu tokenów API |
| Snapshot | włączony, 1 slot, ręczny, nadpisywany |
| Domena techniczna | dfkk.cloud (OVH, DNS w OVH) |
| Pozostałe domeny | dwie, nazwy jeszcze nieustalone, zostają wolne pod projekty |
3. Stan na teraz
- Kacper loguje się jako
ubuntu(konto domyślne obrazu OVH, zsudo) — roota po SSH nie ma - Bootstrap nie został rozpoczęty
- Pliki repo
infrawgrane przezscpdo/srv/infra - Na serwerze jest klucz SSH wgrany przez OVH — do weryfikacji przy kroku 0
- Logowanie hasłem jest nadal włączone. Windows łączył się hasłem, więc nie ma tam jeszcze klucza. Krok 2 bootstrapu musi to domknąć przed krokiem 3.
- Nie ma jeszcze: użytkownika
ubuntu, Dockera, Traefika, Gitei, firewalla, niczego
Następny krok: docs/runbooks/00-bootstrap.md, krok 0.
4. Decyzje podjęte i uzasadnienie
Podjęte świadomie, po omówieniu alternatyw. Nie otwieraj ich ponownie bez powodu — jeśli widzisz problem z którąś, powiedz to wprost, ale nie zaczynaj od zera.
| Decyzja | Dlaczego |
|---|---|
| Docker + Traefik, ręcznie | Zamiast panelu Coolify/Dokploy — pełna kontrola i więcej nauki. Świadomy wybór trudniejszej drogi. |
| Gitea self-hosted na tej maszynie | Wybór Kacpra. Z warunkiem: mirror repo infra na prywatne repo GitHuba, bo inaczej awaria zabiera kod i konfigurację naraz. |
| Certyfikaty przez DNS-01 (API OVH) | Wildcard *.dfkk.cloud — nowa subdomena nie wymaga żadnej akcji przy certyfikacie. Możliwe też usługi niepubliczne. |
| Praca przez SSH + tmux | Sesja przeżywa rozłączenie. Ten sam tmux attach z Maca, Windowsa i iPhone'a. VS Code Remote SSH jako dodatek, nie zamiennik. |
| Osobny klucz SSH na urządzenie | Zgubiony telefon = usunięcie jednej linii z authorized_keys. |
Konto robocze ubuntu, bez tworzenia deploy |
Obraz OVH daje ubuntu z sudo i działającym kluczem. Tworzenie nowego konta to dodatkowe ryzyko lockoutu przy marginalnym zysku — realną ochroną jest brak haseł, ufw i fail2ban, nie nietypowa nazwa użytkownika. |
| Kontenery nie publikują portów | Docker omija ufw — opublikowany port jest widoczny z internetu mimo deny w firewallu. Wejście wyłącznie przez Traefika. |
Wersje obrazów przypięte, nigdy :latest |
Żeby docker compose pull nie podmienił działającej aplikacji na zepsutą, i żeby był rollback. |
| Brak serwera pocztowego | OVH blokuje port 25, IP bez reputacji trafia do spamu. Maile przez zewnętrzny SMTP (Resend/Brevo). |
| Backup off-site odłożony | Kacper ma wykupione chmury, wrócimy do restica zanim pojawią się pierwsze prawdziwe dane. Do tego czasu snapshot OVH wystarcza. |
| Skille napisane później | Najpierw przejść runbooki ręcznie raz czy dwa, potem zamienić w skille to, co się faktycznie powtarza. |
5. Decyzje otwarte
sudoz hasłem czyNOPASSWDdlaubuntu? Do rozstrzygnięcia w kroku 2 bootstrapu. Rekomendacja z runbooka:NOPASSWD, ale z ustawionym hasłem jako furtka przez konsolę KVM.- Nazwy dwóch pozostałych domen — do wpisania w
SERVER.mdgdy będą potrzebne. - Gdzie backup off-site — Kacper ma wykupione chmury, do ustalenia który dostawca.
6. Rzeczy, o których trzeba pamiętać
Wynikły z rozmowy, łatwo je przeoczyć:
- Kacper nie zna jeszcze wszystkich mechanizmów. Warto przy okazji wyjaśniać —
np. dlaczego
claudeodpalamy z/srv/infra(inaczejCLAUDE.mdsię nie załaduje), po co/contexti/memory. - Repo
infrato kanał między rozmowami. Ustalenie, które nie trafi doCLAUDE.md,SERVER.mdalbo runbooka, umiera razem z sesją. Ta zasada jest powodem, dla któregoSERVER.mdma być aktualizowany w tej samej sesji, co zmiana. scpbył jednorazowy. Od momentu postawienia Gitei repo idzie przez git. Ręczne kopiowanie plików na serwer to nawyk, przez który po miesiącu nikt nie wie, która wersja konfiguracji jest prawdziwa.- Lista braków jest w
docs/SECURITY.md, sekcja 8. Najpilniejsze: mirror na GitHub i 2FA na koncie OVH — panel OVH może maszynę zreinstalować, więc w praktyce jest ważniejszy niż dostęp SSH.
7. Czego nie robić
- Nie startuj bootstrapu bez potwierdzenia — Kacper może chcieć najpierw przeczytać runbooki
- Nie zmieniaj
sshd_configbez otwartej drugiej sesji SSH - Nie zakładaj, że coś działa — sprawdzaj (
curl,docker ps, logi) - Nie rób
docker system prune -a --volumesodruchowo - Nie wracaj do rozstrzygniętych decyzji z sekcji 4 bez konkretnego powodu