karim fb54f22e0c Compose-Stack-Stabilisierungen + Gitea-Registry-Image
- App-Image wird jetzt aus Gitea-Container-Registry gepullt
  (git.kgva.ch/karim/rapport-app:main) — kein lokaler Build mehr noetig.
  build:-Section bleibt fuer Dev-Workflow.
- DB-Port nur noch auf 127.0.0.1 gebunden — kein direkter LAN-Zugriff
  zur Postgres mehr (Kong-Proxy ist der einzige Weg).
- DB-Healthcheck: start_period 30s + 20 retries — Migrations + Schema-Init
  brauchen beim Erst-Start laenger als 50s.
- Realtime: DB_AFTER_CONNECT_QUERY zeigt jetzt auf 'realtime' (ohne Underscore).
- App-Image-HEALTHCHECK: wget http://127.0.0.1/ statt localhost (IPv6-Fall).
- Init-Setup: zz-rapport-post-init.sh statt 00-init.sh, plus
  rapport-migrations als separater Mount unter /rapport-migrations.
2026-05-24 16:09:26 +02:00

RAPPORT-SERVER

⚠️ Status: Alpha — noch nicht End-to-End-getestet. Die Files in diesem Repo sind ein Skelett (Docker-Compose, Init-Skripte, Frontend-Build), aber der Stack startet noch nicht out-of-the-box. Vor produktivem Einsatz ist die Supabase-Init-Reihenfolge auszubauen (siehe «Bekannte offene Punkte» unten).

Self-Hosting-Stack für Rapport — die Studio-Management-Software für Architekturbüros.

Dieses Repo enthält alles, um Rapport auf eigenem Server (Linux-VM, NAS, Mac Mini) zu hosten:

  • Postgres (Datenbank)
  • GoTrue (Auth — Email-Login, Passwort-Reset, …)
  • PostgREST (REST-API auf der DB)
  • Realtime (Live-Sync zwischen Geräten)
  • Storage (Bilder, Quittungen)
  • Kong (API-Gateway)
  • Rapport-Frontend (nginx mit dem React-Build)

Alles als Docker-Compose. Komplett Open-Source.


Voraussetzungen

OS Container-Runtime
Linux (Ubuntu 22.04+, Debian 12+, …) Docker Engine + Compose v2
macOS (Mac Mini etc.) Colima + Docker CLI — vollständig Open-Source

Auf macOS funktioniert auch OrbStack oder Docker Desktop, beide sind aber proprietär. Colima ist die OSS-Alternative und für Selfhost ausreichend.

Plus: ein erreichbarer DNS-Name (für TLS) — z.B. rapport.studio.ch. Optional: Nginx Proxy Manager oder Caddy als Reverse-Proxy für SSL.


Setup

1. Repo klonen + Frontend-Sources holen

git clone https://git.kgva.ch/karim/rapport-server.git
cd rapport-server

2. .env erstellen

cp .env.example .env

In .env müssen mindestens diese drei Werte ersetzt werden:

  • POSTGRES_PASSWORD — Datenbank-Passwort (mind. 32 Zeichen zufällig)
  • JWT_SECRET — JWT-Signatur-Secret (mind. 32 Zeichen zufällig)
  • SITE_URL — die öffentliche URL deiner Rapport-Instanz (z.B. https://app.rapport.studio.ch)

Zufallswerte generieren:

openssl rand -hex 32   # für POSTGRES_PASSWORD und JWT_SECRET

3. Migrations holen

Die SQL-Migrations stammen aus dem App-Repo. Einmal initial holen:

./scripts/sync-migrations.sh

(Bei späteren Rapport-Updates sync-migrations.sh erneut ausführen, dann docker compose down && docker compose up -d.)

4. Stack starten

docker compose up -d

Erststart dauert ~1 Minute (Postgres initialisiert sich, Migrations laufen, Container starten).

5. Health-Check

docker compose ps

Alle Container sollten healthy zeigen.

Frontend ist erreichbar auf http://localhost:8080 — direkt im Browser öffnen oder über deinen Reverse-Proxy auf eine Domain mappen.


Reverse-Proxy + HTTPS

Empfohlen: Nginx Proxy Manager (OSS, Web-UI, Let's-Encrypt automatisch) oder Caddy (config-as-code, vollautomatisch).

Beispiel Caddy:

app.rapport.studio.ch {
  reverse_proxy localhost:8080
}

api.rapport.studio.ch {
  reverse_proxy localhost:8000   # Kong-Gateway
}

In .env dann SITE_URL=https://app.rapport.studio.ch und API_EXTERNAL_URL=https://api.rapport.studio.ch setzen.


Updates

git pull
./scripts/sync-migrations.sh   # falls neue Migrations
docker compose pull             # neueste Container-Versionen
docker compose up -d            # neu starten

Daten bleiben erhalten (Volume postgres-data wird nicht angetastet).


Backup

Komplettes Postgres-Dump:

docker compose exec -T db pg_dumpall -U postgres > backup-$(date +%Y%m%d).sql

Empfohlen: per cron täglich + auf externe Disk/S3/Backblaze sichern.

Storage (Quittungen, Logos):

docker compose exec storage tar -czf - /var/lib/storage > storage-$(date +%Y%m%d).tar.gz

Bekannte offene Punkte

Beim ersten End-to-End-Versuch (lokal mit Docker Compose + alternativen Ports) sind diese Probleme aufgefallen:

  1. auth.users-Schema fehlt beim Postgres-Init: Die Rapport-Migrationen (0001_initial.sql) referenzieren auth.users(id) als Foreign Key. In Karims supabase start-Setup wird das von der Supabase-CLI vorab initialisiert; hier in docker-compose muss das per Init-Script (vor den App-Migrationen) explizit angelegt werden — analog zum offiziellen supabase/supabase Self-Host-Setup. Stub-Variante in volumes/db/init/00-init.sh ist drin, aber nicht ausreichend.
  2. Healthcheck-User: supabase/postgres Image hat als Default-User supabase_admin (nicht postgres). Compose-Healthchecks und SQL-Skripte müssen das berücksichtigen.
  3. auth.uid() und auth.role() als Stub-Funktionen brauchen Pre-Migration, damit RLS-Policies + RPCs (is_studio_member, create_studio_with_admin, …) im Init durchlaufen.
  4. Standard-Init-SQL aus dem offiziellen Supabase Self-Host kopieren: roles.sql, _supabase.sql, realtime.sql, webhooks.sql, jwt.sql, logs.sql — diese fehlen aktuell.

Diese Punkte sind in einer separaten Iteration zu adressieren, nicht in einem Schritt. Empfehlung: Sich Schritt für Schritt am offiziellen Supabase-Self-Host-Compose orientieren.

Lizenz

GNU AGPL-3.0-or-later — identisch zur Rapport-App.

S
Description
Self-Hosting-Stack für Rapport — Docker-Compose mit Supabase + Frontend für eigene Architekturbüro-Server
Readme 54 KiB
Languages
Shell 45.1%
JavaScript 32.2%
Erlang 22.7%