Self-hosting
Install & deploy
Run the whole platform on your own infrastructure. You need a Supabase project for the database and auth, and either Docker or Node.
One-command setup#
The setup script scaffolds .env, generates the encryption secrets, applies database migrations and starts the stack.
bash scripts/setup.shpowershell -ExecutionPolicy Bypass -File scripts\setup.ps1Every service is installed and wired — the Office renderer, the JS sandbox, the Developer-workspace Python runtime and its egress proxy, the lakehouse catalog and its object store, the vector store, the feature store and the Spark cluster — and .env points at all of them. There are no profiles and nothing to opt into: a feature that depends on which flag an installer was given is a feature most installs never see. Budget about 5 GB of images and 8 GB of RAM. --dev runs the app on this host with a dev server and starts the same services beside it, reached on loopback.
It cannot create your Supabase project or guess its keys — it writes the .env, tells you which values to fill in, and you re-run it.
In this guide#
Setup and the deployment targets are on this page. The reference and the operating detail have pages of their own.
Configuration
Every variable, and the settings for each way of running it.
Kubernetes
Manifests, then EKS, GKE, AKS and OKE step by step.
Operations
Scaling, availability, residency, hardening.
Manual setup#
- 1
Create a Supabase project
It provides Postgres, authentication and storage. Note the project URL, publishable key and service-role key. - 2
Fill in .env
Copy.env.exampleand set the required values below. - 3
Apply migrations
npx supabase link --project-ref <ref>thennpx supabase db push. This creates every table, policy and storage bucket. - 4
Start it
docker compose up -d --build, ornpm install && npm run dev. Openhttp://localhost:8080.
Migrations are not optional
npx supabase db push before concluding a feature is broken.The services#
| Service | Container | What it adds |
|---|---|---|
| Doc-gen renderer | docgen | Server-side PowerPoint/Word/Excel via python-pptx, python-docx, openpyxl and LibreOffice — the "Deep" generation mode. |
| Notebook runtime | notebook-gateway | Real Python kernels for the Developer workspace, with a gateway and a default-deny egress proxy. |
| JS sandbox | js-sandbox | Runs Function nodes and custom components in deployed and scheduled swarms, in a locked-down container instead of next to the app's credentials. |
| Lakehouse catalog | lakehouse-catalog | A Postgres of its own holding the lakehouse's table definitions. Without one — this, or your own in LAKEHOUSE_CATALOG_URL — the lakehouse, SQL models and ML stay off. |
| Object store | minio | Where the lakehouse Parquet files live. Replace it with S3, R2 or GCS by pointing LAKEHOUSE_S3_* at them. |
| Spark cluster | spark-connect | A Spark Connect endpoint for the ETL Spark engine and lakehouse queries on Spark. Idle until SPARK_CONNECT_URL names it; the image is about a gigabyte and it downloads its connector jars on first use. |
| Vector store | qdrant | Qdrant, for deployments whose knowledge-base index has outgrown the application database. Idle until VECTOR_STORE=qdrant names it, and retrieval stays on pgvector until it does. |
| Online feature store | valkey | Valkey, holding a feature view's latest row per key so a prediction answers in milliseconds instead of reading the lakehouse. Idle until FEATURE_STORE_URL names it; every lookup reads the lakehouse until it does, which is correct and about sixty times slower. |
docker compose up -d --buildOr let the setup script start everything: bash scripts/setup.sh (powershell -File scripts\setup.ps1 on Windows).
Every one is optional, and each degrades to something rather than breaking. Without the renderer, documents are generated in the browser and Deep mode is greyed out with the reason. Without the notebook runtime, opening a notebook shows a panel saying a runtime is required — there is no in-browser fallback. Without the sandbox, custom code still runs on the canvas and the Deploy dialog says plainly that it will fail in headless runs. Without the feature store, feature lookups read the lakehouse exactly as they did before it existed. The last four are inert until an environment variable points at them: start the Spark or vector profile without setting SPARK_CONNECT_URL or VECTOR_STORE and the container runs while nothing uses it.
Observability → Monitoring (superadmin) shows which of these are actually up on this deployment, with the address that answered and live CPU, memory and disk. A profile you chose not to start reads “Not running” rather than as a failure.
Deployment targets#
- Docker Compose
- The default. Every service on one host, started by one command. Good to a substantial team on one host.
- Node behind a reverse proxy
- Build and run the server directly. Terminate TLS at your proxy.
- Autoscaled VMs behind a load balancer
- The app tier is stateless, so run as many identical containers as you need. Set DISABLE_INPROCESS_SCHEDULER=1 and drive background work from one external cron.
- Kubernetes
- Reference manifests ship for the app (
deploy/k8s/app/) and the notebook runtime (deploy/k8s/notebooks/), including the egress policy that keeps kernels off the open internet. Three things bite in practice: setresources.limits.cpu, because the worker count follows it; probe liveness on/api/healthand readiness on/api/health/ready, which answer different questions; and strip the quotes from.envbeforekubectl create secret --from-env-file— unlike Docker Compose it keeps them, and every pod then fails readiness withInvalid supabaseUrl.
Kubernetes — the manifests and a walk-through per cloud — has its own page.
Note
docs/INSTALL.md in the repository, which is kept up to date as issues are found.