Turn it into a product other people sign up to

Take the module

auth is opt-in, which means it is in the interactive picker but --yes never takes it on its own — it needs a Supabase project, and that is not something to arrange behind somebody's back. Name it:

npx @chatfuel/wizard --modules auth,livechat,contacts

It is also a hidden module: no rail item, no /auth address. It wraps the whole shell in its gate instead, puts the user menu in the top bar and answers /team. The one npm package it brings is @supabase/supabase-js.

Adding it to an app that already exists is the --embed story rather than this one — see Add a module.

Point it at a Supabase project

The users live on your Supabase project, not ours. The free plan is enough, and the wizard offers two ways to reach it.

In a scripted run, --supabase-create <name> reuses a project already carrying that name instead of making a second one, so re-running the script does not spend the account's other free project on a duplicate. And a project that already carries a Chatfuel install is named out loud before anything is applied: re-running for the same deployment is the update path, while a second deployment on one project shares its accounts, its bots and its publish queue.

Set the variables

Two of them decide whether the gate exists at all:

VITE_SUPABASE_URL=https://<ref>.supabase.co
VITE_SUPABASE_ANON_KEY=<publishable key>

Both set turns the gate on. Neither is open mode. One without the other is fail-closed — every proxied request answers 500 ProxyAuthMisconfigured, because the proxy refuses to guess which half you meant.

Two more do not touch the gate but decide whether it is any use:

CHATFUEL_WORKSPACE_ID is unrelated to VITE_CHATFUEL_WORKSPACE_ID, which stops meaning anything once this module is on: the workspace picker disappears and the bots come from the session. Environment variables has the full table.

The wizard tells you how much room the workspace has when it asks which one to use, and warns you outright when it holds a single bot — then only the first account through the door gets one.

Run the migrations

Your app has a supabase/ directory, and it is yours. On the access-token path the wizard has already run these against the project; on the manual path nobody has.

supabase/migrations/
  0001_chatfuel_auth.sql        the whole schema: cf_profiles, cf_tenants, cf_members,
                                cf_bots, cf_bot_members, cf_invites, cf_migrations,
                                cf_invite_probes, cf_recovery_events, cf_resource_owner,
                                cf_admin_attempts and every cf_* RPC
  0010_chatfuel_publishing.sql  only with the publishing module: the publish queue
  0020_chatfuel_admin.sql       only with the admin module: its service-role functions

Apply them in name order — everything above 0001 reads what 0001 makes — by pasting each into the SQL editor at https://supabase.com/dashboard/project/<ref>/sql. Every file is create … if not exists / create or replace throughout, so a second run changes nothing. The wizard's own run stops at the first failure rather than attempting the rest, for the same reason.

There is nothing to seed. A workspace appears when somebody signs up.

Later schema changes go in a new file, 0002_….sql — editing one that already ran makes two deployments drift. The numbering leaves each module a block of ten, which is why the publishing module's file arrives as 0010_ and the admin module's as 0020_.

The two bot caps live in 0001_chatfuel_auth.sql as one-line functions. Setting CHATFUEL_BOT_CAP or CHATFUEL_BOT_TOTAL_CAP in the environment of this wizard run writes your own numbers into the file as it is applied; afterwards they are SQL in your database, and re-running the create or replace is what changes them.

Finish the Supabase settings

On the access-token path the wizard configures sign-in for you, on a project it created, and asks who may open an account:

On a project you brought, the wizard leaves all three alone and says so — a closed sign-up stays closed and a turned-on confirmation stays on. Then, by hand or to check:

1. Authentication → Providers → Email. "Confirm email" off is what open means; with it on, the default provider rejects addresses it considers undeliverable and caps the rest at two emails an hour.
2. Authentication → URL configuration. The redirect allowlist has to hold http://localhost:5173/** and your deployed origin, https://app.example.com/**. The wizard merges the app origin either way, and adds the localhost entry only to a project it made.
3. SUPABASE_SERVICE_ROLE_KEY in the app's .env (Project Settings → API Keys → secret). The cf_bot_created function is granted to service_role and to nobody else.

Password-reset mail needs your own SMTP (Authentication → SMTP). Until you configure it, admins issue reset links from the row menu on the Team page — those open in any browser, while the emailed link on a free project carries a PKCE code that only works in the browser that asked. That route delivers by writing the link to the server log, so it is off unless you turn it on: AUTH_RECOVERY_LINK_LOG=true, plus PUBLIC_URL for the address the link points at. The wizard asks about it once, and the reasoning is on Accounts.

Sign up as your own first customer

Start the app and open /sign-up. Do this before you share the URL.

npm run dev

Three things prove it. The account exists: sign-up returns a session immediately, with no email round-trip. The bot exists: the app calls POST /chatfuel/auth/provision, the server creates a real Chatfuel bot in CHATFUEL_WORKSPACE_ID with your master token, and the bot appears in the top-bar switcher — go and look at it in the Chatfuel dashboard, it is really there. The gate is on: read the startup line, which begins chatfuel proxy: auth gate on (bots per account in workspace and then names the workspace and every route it mounted.

The startup log is the only place the mode is named. The health route is the same path on every host — the dev server, the bundled Node server and the Vercel function — and answers liveness and nothing else, because it is open to anyone who can reach the deployment:

GET /chatfuel/healthz  →  {"ok":true}

It answers 503 with {"ok":false} when the proxy found a configuration problem at startup, and a missing CHATFUEL_WORKSPACE_ID is one of them. Which problem it is, is in the log beside the mode.

Then open /team, invite a second address, and check that the invited account lands in your workspace rather than getting one of its own.