Self-host
What a container install can do today, and what is still SaaS-only documentation.
Stedia is built to run as SaaS on Vercel and as a container install. This page is honest about what is documented today.
What exists
The product repo ships docker-compose.yml for backing services: Postgres (pgvector), Redis, S3-compatible object storage, and an optional Phoenix profile. That compose file does not start the Stedia web app or API.
The API is a Nitro process. Local and self-host use a Postgres-backed workflow queue and a long-lived worker. SaaS uses Vercel's workflow world.
Scheduler ticks every minute by default (SCHEDULER_TICK_ENABLED=true). Set it to false if you want jobs to show a next run and never fire.
Chat bots (Discord, Slack, and the rest) need per-environment credentials. Discord's local gateway is opt-in (DISCORD_GATEWAY_ENABLED=true).
Connectors disappear from the catalog when their OAuth env vars are unset. That is how you hide Gmail or WHOOP on an install that should not offer them.
What is not written yet
There is no operator runbook for a production self-host. No documented image build that ships web and API together. Secrets in the SaaS path go through Infisical to Vercel. Observability docs cover Vercel, not a self-hosted log drain.
If you are standing up an install, start from the product repository README and apps/api env schema. Put customer how-to in these docs. Keep client IDs and secrets out of this site.
Docs on a self-host
This site is a standalone Next.js app. You can deploy it next to the product, or export it as static files and serve it from the same origin. It does not need the Stedia API to render.