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, and S3-compatible object storage. 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.
Schedules are checked every minute by default (SCHEDULER_TICK_ENABLED=true). Set it to false if you want schedules 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).
Tools disappear from the catalog when their OAuth env vars are unset. That is how you hide Gmail or Outlook 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. 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.
Docs on a self-host
This site is a standalone Next.js app. You can deploy it next to the product. It does not need the Stedia API to render.