Everything Tenon Cloud runs on, handed to you: a static bundle you can serve from anything, and a Supabase backend that lives in the cloud region you pick or entirely inside your own network. Host it for your company. Or host it for every department, subsidiary or client you serve, each in its own isolated organization.
Tenon Cloud is the right answer for most teams. But data-residency law, procurement rules and plain instinct are pushing serious organizations toward running their own tools; Gartner expects more than 75% of enterprises to have a digital-sovereignty strategy by 2030. Here is what that looks like for a team workspace.
GDPR, Schrems II, in-country rules for public sector and finance: most of these questions disappear when the database sits in the region you chose, on an account you control. No subprocessor list, no transfer impact assessment for your own roadmap.
Tenon makes no calls home. The only outbound call is to the AI provider you configure, and with a self-hosted model, not even that. The "who else sees this data?" line in your questionnaire is one word long.
It's your Postgres. Back it up with your existing tooling, replicate it, query it with any BI tool, or walk away, with no export request, no notice period, no negotiation.
Four per-seat SaaS bills become one licence plus infrastructure you probably already run. A Supabase project or a small VM is a rounding error next to per-seat pricing across four tools.
Tenon is a Vite-built React bundle and a Supabase backend. There is no Node server to babysit, no queue, no cache layer, no Kubernetes.
Nginx, Apache, Caddy, IIS, an S3 bucket behind a CDN, a Raspberry Pi. If it can serve index.html, it can serve Tenon. Add a single rewrite rule so client-side routes work.
Either Supabase Cloud (pick your region) or the open-source Supabase stack self-hosted with Docker on your own machines. Tenon uses Postgres, Auth (GoTrue), Realtime, Storage, Edge Functions and pg_cron, all part of the standard stack.
server {
listen 443 ssl http2;
server_name work.example.com;
root /var/www/tenon/dist;
# SPA routes -> index.html
location / {
try_files $uri $uri/ /index.html;
}
# long cache for hashed assets
location /assets/ {
add_header Cache-Control "public, max-age=31536000, immutable";
}
}Supabase Cloud in the region you choose + Tenon on any static host or CDN. Fastest to set up; most teams start here. Backups, upgrades and scaling of Postgres are handled for you.
Self-hosted Supabase via Docker Compose on your own machines + Tenon behind your reverse proxy. You own backups and upgrades; nothing leaves your network except the AI calls you choose to make.
Self-hosted Supabase + a local OpenAI-compatible model (Ollama, vLLM) + email/password auth only. No outbound internet required for daily use. Common in defence, healthcare and critical infrastructure.
| Organization | Members | Identity | AI |
|---|---|---|---|
| Acme Retail | 48 | SAML · Okta | Gemini |
| Northwind Health | 212 | OIDC · Entra | Ollama (internal) |
| Internal - Studio | 19 | Gemini | |
| Client - Bluebird | 7 | None |
One deployment. Four tenants. Zero shared rows.
The multi-tenant architecture that runs Tenon Cloud is the one you deploy. Every client, department or subsidiary gets its own organization on your single deployment. Postgres Row Level Security guarantees each sees only its own data, and the self-hosted Enterprise edition puts no limit and no per-tenant fee on how many you create.
Standard Postgres backups plus the Storage bucket. Supabase Cloud does this daily; self-hosted uses pg_dump or your usual tooling.
Deploy the new bundle, run the new migrations, redeploy edge functions. Release notes list every step.
Supabase exposes Postgres and function logs; point your existing observability stack at them.
Standups, digests and briefings run on pg_cron inside the database. Nothing external to schedule.
Two things: somewhere to serve static files (Nginx, Apache, Caddy, an S3 bucket, any static host) and a Supabase project, either Supabase Cloud in the region you choose, or the open-source Supabase stack running on your own servers via Docker. The install guide walks through both.
Yes. That is what the self-hosted Enterprise edition is for. One deployment holds unlimited organizations, each fully isolated by Row Level Security, each able to connect its own SAML or OIDC identity provider. A superadmin role administers them all. Agencies use it for clients; IT teams use it for departments and subsidiaries.
Only what you explicitly configure. Self-hosted Tenon makes no calls home and sends no telemetry to us. The one external call is to the AI provider you select, and if you point it at a self-hosted OpenAI-compatible model, even that stays inside your network.
All organizations share one Postgres database, and every table has Row Level Security policies scoped to the organization. The database itself refuses to return rows that belong to another tenant, regardless of what the application asks for. A superadmin role can see across tenants for administration. There is a built-in RLS self-test you can run after deploying to prove isolation on your instance. Tenon Cloud runs on exactly this architecture.
Yes, with the self-hosted Supabase stack and a local OpenAI-compatible model (or AI disabled). Google sign-in and cloud AI providers obviously require outbound access; email/password auth does not.
Deploy the new static bundle, apply the new database migrations, redeploy edge functions. The Enterprise edition includes upgrade support and migration notes for every release.
The install guide takes you from an empty Supabase project to a working workspace, step by step. Or skip the servers entirely and start on Tenon Cloud.