Skip to main content
This page is for operators running their own Switchbord deployment. If you’re using a hosted Switchbord instance, your admin has already handled this configuration — you can skip to Setup to connect your WhatsApp channel. Self-hosting Switchbord requires setting environment variables across a few deployed services. The variables below control how the operator app connects to Supabase, how it authenticates with Meta, and how the first workspace owner gains access.
Workspace-managed secrets — your Meta access token, webhook signing secret, and verify token — are entered through the product UI, not as environment variables. See Setup for those. The variables on this page are infrastructure-level configuration that you set when deploying the application.

Supabase connection

These variables are required for any Switchbord service that reads or writes data.
VariableDescription
NEXT_PUBLIC_SUPABASE_URLYour Supabase project URL. Required by all services.
NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEYSupabase publishable key for browser and request-scoped clients.
SUPABASE_SECRET_KEYServer-side Supabase admin key. Keep this out of browser contexts.
SUPABASE_DB_URLDirect Postgres connection string. Required for the Setup wizard to store provider secrets in Vault, and for the Settings → Provider rotation flow.
SUPABASE_DB_URL must be set on the operator app server if you want the in-product Setup flow to work. Without it, the app can’t write credentials to Vault and the setup checklist won’t complete.

Meta and webhook credentials (bootstrap fallbacks)

These variables act as platform-level fallbacks before a workspace stores its own credentials through the UI. Once a workspace has saved its provider secrets through Setup, those Vault-backed values take precedence over these environment variables for that workspace.
VariableDescription
WHATSAPP_META_ACCESS_TOKENMeta Graph API token for outbound message sends. Used by the worker service.
WEBHOOK_SIGNATURE_SECRETValidates the X-Hub-Signature-256 header on inbound webhook payloads.
META_WEBHOOK_VERIFY_TOKENUsed for the Meta webhook challenge handshake.

Workspace bootstrap and access control

These variables control how the first workspace owner gains access, which is important for new deployments where no members exist yet.
VariableDescription
WORKSPACE_BOOTSTRAP_ADMIN_EMAILSComma-separated list of email addresses that are granted admin access during workspace bootstrap, without needing an invite.
WORKSPACE_ALLOW_FIRST_CLAIMSet to true to allow the first authenticated user to claim workspace ownership when no members exist. Defaults to false. Disable this after the first owner is established.
If a user signs in to a fresh deployment and lands on /pending-access, the workspace has no members yet. Set WORKSPACE_BOOTSTRAP_ADMIN_EMAILS to their email address (or temporarily enable WORKSPACE_ALLOW_FIRST_CLAIM=true) and have them sign in again. You don’t need to delete and recreate the auth user.

Data mode

VariableValuesDescription
WHATSAPP_PLATFORM_DATA_MODEmock (default) or supabaseControls whether the operator app reads and writes data against the typed in-memory mock store or the real Supabase-backed data path. Set to supabase for production deployments.
If this variable is omitted, the app runs in mock mode — useful for evaluating Switchbord locally without a Supabase project, but not suitable for real traffic.

Default channel variables

These variables pre-populate the default workspace channel context. They are useful for single-tenant deployments where the channel identity is known at deploy time.
VariableDescription
DEFAULT_WORKSPACE_SLUGSlug for the default workspace.
DEFAULT_CHANNEL_WABA_IDWhatsApp Business Account ID for the default channel.
DEFAULT_CHANNEL_PHONE_NUMBER_IDMeta phone number ID for the default channel.
DEFAULT_CHANNEL_PHONE_E164E.164-formatted phone number for the default channel.
DEFAULT_CHANNEL_DISPLAY_NAMEHuman-readable display name for the default channel.

Backward compatibility

Switchbord accepts NEXT_PUBLIC_SUPABASE_ANON_KEY and SUPABASE_SERVICE_ROLE_KEY as aliases for the publishable key and secret key respectively. New deployments should use the names listed above.