Self-Host
Was eine Container-Installation heute kann, und was noch nur als SaaS dokumentiert ist.
Stedia soll als SaaS auf Vercel und als Container-Installation laufen. Diese Seite sagt ehrlich, was heute dokumentiert ist.
Was existiert
Das Produkt-Repo liefert docker-compose.yml für Hintergründe: Postgres (pgvector), Redis, S3-kompatiblen Objektspeicher und ein optionales Phoenix-Profil. Diese Compose-Datei startet weder die Stedia-Web-App noch die API.
Die API ist ein Nitro-Prozess. Lokal und Self-Host nutzen eine Postgres-gestützte Workflow-Queue und einen langlebigen Worker. SaaS nutzt die Workflow-Welt von Vercel.
Der Planer tickt standardmäßig jede Minute (SCHEDULER_TICK_ENABLED=true). Setze das auf false, wenn Jobs einen nächsten Lauf zeigen und nie feuern sollen.
Chat-Bots (Discord, Slack und der Rest) brauchen Zugangsdaten pro Umgebung. Der lokale Discord-Gateway ist opt-in (DISCORD_GATEWAY_ENABLED=true).
Konnektoren verschwinden aus dem Katalog, wenn ihre OAuth-Env-Vars fehlen. So versteckst du Gmail oder WHOOP auf einer Installation, die sie nicht anbieten soll.
Was noch fehlt
Es gibt kein Operator-Runbook für einen produktiven Self-Host. Kein dokumentiertes Image, das Web und API zusammen ausliefert. Secrets im SaaS-Pfad gehen über Infisical nach Vercel. Observability-Docs decken Vercel ab, keinen Self-Host-Log-Drain.
Wenn du eine Installation aufsetzt, starte beim README des Produkt-Repos und dem Env-Schema von apps/api. Kunden-How-to gehört in diese Docs. Client-IDs und Secrets bleiben von dieser Site fern.
Docs auf einem Self-Host
Diese Site ist eine eigenständige Next.js-App. Du kannst sie neben dem Produkt deployen oder als statische Dateien vom selben Origin ausliefern. Sie braucht die Stedia-API nicht, um zu rendern.