Self-hosting a team workspace: what you actually need

"Self-hosted" conjures a weekend of YAML, a Kubernetes cluster you didn't want, and a Slack channel called #why-is-it-down. For some software that's accurate. For a team workspace it doesn't have to be. This is a plain-language guide to what self-hosting Tenon actually involves, written for the person who has to decide whether it's worth it, or whether to just use Tenon Cloud and let us run it.

First: why bother?

Three reasons come up over and over.

• Where the data lives. EU data-residency rules, sector regulation, or a customer contract that says "no third-party cloud". Elestio's 2026 overview of EU sovereignty rules is a good primer on how this went from niche to mainstream.

• Who else can see it. Self-hosting collapses your subprocessor list. There's no vendor to breach, subpoena, or acquire.

• Getting out. As one self-hosting guide puts it, you already hold the database, so there is no vendor to negotiate an export from.

Gartner's forecast that over 75% of enterprises will have a digital-sovereignty strategy by 2030 (cited in Atolio's self-hosted vs. SaaS guide) suggests this isn't a fad.

What Tenon actually is, physically

Two things:

1. A folder of static files. The frontend is a React app built with Vite. After npm run build you get a dist/ folder: HTML, JavaScript, CSS. It runs entirely in the browser.

1. A Supabase project. Supabase is an open-source bundle of Postgres (the database), Auth (logins), Realtime (live updates for chat), Storage (files), Edge Functions (small server-side pieces) and pg_cron (scheduled jobs). Tenon uses all of them, and nothing else.

There is no Tenon server process. No Node app to keep alive, no Redis, no message queue. The "backend" is Supabase, which you can either rent as a managed service or run yourself.

Three ways to host it

What "operating it" means in practice

Backups

Postgres plus a Storage bucket. On Supabase Cloud, it's done for you daily with point-in-time recovery available. Self-hosted, it's pg_dump on a cron and a copy of the storage volume, the same thing your team already does for any database.

Upgrades

Replace the dist/ folder, run any new migrations, redeploy changed edge functions. Release notes list the steps. If you can deploy a website, you can upgrade Tenon.

Monitoring

Supabase exposes logs for the database and functions. Point whatever you already use (Grafana, Datadog, a log shipper) at them.

Scheduled jobs

Standup digests, morning briefings and webhook retries run on pg_cron inside the database. There is nothing external to schedule and nothing to forget.

The multi-tenant part

This is where Tenon differs from most self-hosted tools, which assume one company per installation. Tenon assumes many organizations per installation (clients, departments, subsidiaries) on one database, isolated by Postgres Row Level Security. We wrote a separate piece on what that means; the short version is that the database itself refuses to return another tenant's rows.

For an agency, that means one deployment for all clients. For an IT team, one platform for all departments. For a software company, the ability to offer Tenon to customers.

What could go wrong

• You forget the SPA rewrite. Deep links 404. It's one line of web-server config; the install guide has it for Nginx, Apache and Caddy.

• Email isn't configured. Invitations silently fail. Run the built-in test-email function before inviting anyone.

• Nobody set an AI provider. Every AI feature says "not configured". That's intentional, better than a fake result, but it surprises people. A superadmin sets it in Admin Settings.

• You don't run the RLS self-test. You should, after every deploy. It proves isolation and gives you evidence for audits.