---
okf: "0.1"
type: decision
visibility: private
status: active
updated: 2026-07-09
links:
  - ../services/nextcloud.md
  - ../runbooks/nextcloud-cutover.md
---

# Nextcloud — decyzja: host = PIHA

## Decyzja: host = PIHA

Moduł 4 skłaniał się ku SOLARIA (mocniejszy host, bez wpływu na KB — patrz
niżej), ale Oskar zdecydował inaczej: **Nextcloud jest używany aktywnie**
(telefon, sync, rodzina) — sesyjna dostępność SOLARII (sync dogania się
dopiero po wybudzeniu hosta) nie jest akceptowalna dla tego workloadu.
Nextcloud musi być **always-on**, więc ląduje na PIHA mimo ciaśniejszego
RAM/CPU.

| | PIHA (wybrane) | SOLARIA |
|---|---|---|
| Dostępność | 24/7 (sync zawsze działa) | sesyjna — sync dogania się po wybudzeniu |
| RAM/CPU | ciasno nawet po module 0 (Nextcloud+PHP ≈ 0.5–1 Gi+) | 62 Gi RAM, 24 rdzenie — bez znaczenia |
| Storage | NVMe 477 G (dzielone z resztą) | NVMe 2 T |
| Ingress | npm lokalnie (ten sam host) | npm@PIHA proxuje po LAN do 192.168.31.70:8220 |
| Wpływ na KB | żaden — KB czyta własną kopię z archiwum na PIHA w obu wariantach | jw. |

`service.yaml` ma `owner_node: piha`; `env.example` ma `LAN_BIND_IP` PIHA
(192.168.31.5) i `TRUSTED_PROXIES` pod docker bridge (npm i nextcloud na
tym samym hoście — patrz komentarz w `env.example`). Compose zostaje
przenośne (ścieżki po konwencji `/opt/homelab/data`), gdyby host kiedyś
się zmienił.