· Fundacja Reborn

Self-hosting Reborn Apps z Docker Compose

Przewodnik krok po kroku, jak uruchomić własną instancję Reborn Apps za pomocą Docker Compose.

self-hosting docker poradnik
Read in English →

Jedną z głównych zalet oprogramowania open source jest możliwość uruchomienia go samodzielnie. Oto jak uruchomić Reborn Apps na własnym serwerze za pomocą Docker Compose.

Wymagania

  • Docker 25+ z Docker Compose
  • Serwer z co najmniej 2 GB RAM
  • Nazwa domeny i certyfikat TLS (jeśli wystawiasz instancję na świat)

Dwa scenariusze: dev vs produkcja

W repozytorium są dwa flow Docker Compose - trzeba świadomie wybrać ten odpowiedni.

FlowŹródła na hoście?ObrazCzas startuDo czego
Development (docker-compose.yml)Wymagane (sklonowane repo)node:alpine + bind-mount + pnpm install przy starcieWolny pierwszy start, HMR późniejPraca nad kodem
Produkcja (docker-compose.prod.yml.example)Niepotrzebne w runtimeObraz zbudowany z multi-stage Dockerfile<15 s, bez pnpm installWłasna instancja

Ważne: domyślny docker-compose.yml to dev. Wkleisz go do panelu typu Portainer/Coolify bez sklonowanego repo i pnpm install zwróci ERR_PNPM_NO_PKG_MANIFEST - bind-mount celuje w pusty katalog. Do self-hostingu używaj flow produkcyjnego poniżej.

Quick start (produkcja)

git clone https://github.com/fundacja-reborn/reapps.git
cd reapps

cp .env.example .env
cp docker-compose.prod.yml.example docker-compose.prod.yml

Wygeneruj sekrety i uzupełnij .env:

# Generator sekretów (każdy unikalny)
openssl rand -base64 48

Minimum, które musisz ustawić w .env:

PUBLIC_SITE_URL=https://twoja-domena.example.com   # lub http://twoj-ip
DB_USER=postgres
DB_PASSWORD=<silne-losowe-haslo>
DB_NAME=reborn
JWT_SECRET=<openssl rand -base64 48>
REFRESH_TOKEN_SECRET=<openssl rand -base64 48>
SESSION_SECRET=<openssl rand -base64 48>
RECOVERY_KEY_SECRET=<openssl rand -base64 48>

Build i start:

docker compose -f docker-compose.yml -f docker-compose.prod.yml \
  --profile with-notes up -d --build --wait

Po starcie kontenery nasłuchują na portach :4200 (re/task) i :4201 (re/notes) na hoście Dockera.

Reverse proxy i HTTPS

Aplikacje nie kończą TLS-a same - w produkcji trzeba postawić przed nimi reverse proxy, które terminuje HTTPS i zachowuje prefiksy /task oraz /notes (to dzięki nim działa SSO przez wspólny origin):

  • https://twoja-domena/task/http://127.0.0.1:4200/task/
  • https://twoja-domena/notes/http://127.0.0.1:4201/notes/

Nadaje się tu nginx, Caddy, Traefik albo Cloudflare Tunnel - w repo znajdziesz nginx/dev.conf jako punkt wyjścia (do produkcji dodaj listen 443 ssl;, ścieżki do certyfikatów, HSTS).

Plik docker-compose.proxy.yml w repo to deweloperski proxy na http://localhost:80 - przydaje się do lokalnych testów SSO, ale nie zastępuje produkcyjnego reverse proxy z TLS.

Smoke-test obrazu produkcyjnego lokalnie

Zanim skierujesz prawdziwą domenę na świeży obraz, możesz przetestować flow produkcyjny u siebie:

cp docker-compose.localprod.yml.example docker-compose.localprod.yml

docker compose -f docker-compose.yml -f docker-compose.localprod.yml \
  -f docker-compose.proxy.yml --profile with-notes -p reborn-localprod \
  up -d --build --wait
# → http://localhost/task i http://localhost/notes

Ten override używa http://localhost jako origin i lokalnych poświadczeń bazy - komponuje się czysto, bez dodatkowej konfiguracji.

Portainer, Coolify, Dokploy i inne panele

Same ramki YAML w panelu nie wystarczą - flow produkcyjny potrzebuje kontekstu builda (Dockerfile + drzewo źródeł). Skonfiguruj stack tak, żeby panel klonował repo z https://github.com/fundacja-reborn/reapps.git, a nie wklejał YAML do edytora - wtedy build ma wszystkie potrzebne pliki. Następnie wskaż dwa pliki compose:

  • docker-compose.yml
  • docker-compose.prod.yml.example (skopiowany jako docker-compose.prod.yml przed deployem)

i przekaż wartości z .env przez panelowy edytor zmiennych środowiskowych.

Dlaczego self-hosting?

Dla większości użytkowników nasza publiczna instancja jest najwygodniejszym wyborem - jest darmowa, zawsze aktualna i wspierana przez społeczność. Self-hosting to opcja dla osób i organizacji z konkretnymi wymaganiami:

  • Pełna kontrola - Twoje dane pozostają na Twoim sprzęcie
  • Własna domena - używaj własnej nazwy domeny
  • Wymogi regulacyjne - spełniaj wewnętrzne polityki przechowywania danych
  • To samo szyfrowanie - E2E encryption działa identycznie

💡 Niezależnie od tego, z której opcji korzystasz, rozważ wsparcie projektu - Twoja darowizna pomaga rozwijać Reborn Apps dla wszystkich.

Wsparcie

Jeśli napotkasz problemy, przejrzyj sekcję self-hostingu w README lub zgłoś issue na GitHubie. Społeczność jest tu, aby pomóc.