Skip to main content
Self-hosting is for operators who are comfortable owning a web application, database, migrations, secrets, queues, storage, domains, and third-party provider approvals. Before deploying, inspect the repository’s docs/upstream-source.json. It records the hosted source snapshot used for that public release; hosted features shipped later may not be present yet.

Start locally

1

Clone the public repository

Install Bun and the Supabase CLI, then clone the release:
2

Create a Supabase project you control

In your Supabase project, collect its project reference, API URL, publishable key, service role key, and PostgreSQL connection URL. Use credentials from the same project. The database URL is used only for migrations; the service role key must stay on the server.
3

Open the self-hosted setup screen

Start the app, then visit http://localhost:8080/self-hosted-setup. An unconfigured instance also sends visitors there before sign-up.
Enter the required Supabase and instance values. The screen explains what each key does and which feature uses it. It can generate a random WORKSPACE_COOKIE_SIGNING_KEY. Expand an optional feature group only when you plan to configure that provider.
4

Download and install the configuration

Click Download configuration. The browser generates bento-surf.env without submitting the entered keys to Bento. Rename it to .env at the repository root, keep it out of Git, and restart the app after changing it. The download also fills the matching public Supabase values and MIGRATION_CONFIRMATION=MIGRATE:<SUPABASE_PROJECT_ID>.If you already have an .env, merge new values into it. The setup screen cannot read your installed secrets back, and a fresh download will not contain values you entered during an earlier visit.
5

Preview and apply database migrations

Check the dry-run target before applying migrations. The guard requires the database URL to identify your SUPABASE_PROJECT_ID and the matching migration confirmation.
6

Create the first creator account

Restart with bun run dev, open /signup, and complete the creator onboarding. Run the repository checks before deploying:

What the required settings do

All other available settings are listed in the repository configuration reference. The setup screen groups them by feature and explains each field.

Add only the providers you need

Optional email, payment, social, calendar, analytics, AI, and media features stay unavailable until you supply your own credentials and complete each provider’s setup. Missing providers fail closed; the open-source edition does not fall back to Bento-owned accounts. Each optional setting has its own purpose text in the setup screen. You can return to /self-hosted-setup from the sign-in or sign-up page when adding features later; merge any new values into your existing configuration.

Deploy and verify

For Cloudflare, follow the repository’s deployment guide for Workers, R2, queues, and secrets. Set server-only credentials in the host’s secret store. Set VITE_ public values for the browser build, then rebuild and redeploy after changing them. The setup screen generates configuration locally; it does not install secrets into your host. Review the configuration reference and verification boundary. A compatible coding agent can also follow skills/deploy-bento/SKILL.md. You remain in control of paid resources, secrets, domain changes, OAuth consent, provider review, and live publishing.
Do not call an instance production-ready until you have tested a fresh migration, two-tenant data isolation, customer checkout and fulfilment, email delivery, provider callbacks, MCP authorization, and browser WebMCP on the exact domains you will use.

Free Forever edition

You supply and pay for your own infrastructure and any providers you choose to enable. Check the .env.example and migrations in the exact public release you deploy. If that release includes BENTO_EDITION and the public.bento_instance_settings migration, set the trusted server-only variable BENTO_EDITION=self_hosted. After applying migrations, run this once through your database administrator connection, never from the browser:
Both settings are needed in releases with database edition checks: the environment variable selects the application behavior, while the database row controls billing and access rules. Earlier releases without that table must not run the SQL. The AGPL-3.0 license is unchanged.