White-label for agencies
Your name in the tab, your mark in the top bar, your address in the URL — a panel your team runs every client account from, and one a client signs in to and finds only their own bot in.
A panel with your name on it
The wizard builds an app your agency owns outright, wired to your Chatfuel account. One deploy can run your whole book of clients, or you can run the same app again and give a client an address of their own.
Your name in the tab, your mark in the top bar
The wizard asks what the app is called and takes a logo file — sixty characters, and any image a browser can draw under a megabyte. The tab title and icon are written into the page itself, because the head is parsed before a build setting can be read.
An address you pick, in one command
One command from inside the app puts it up, and the project name you type is the address it answers on. No repository, no dashboard, no button to click.
Every client bot in the same panel
The top bar moves between the workspaces your Chatfuel account owns and the bots inside them, asked live rather than baked into the build. A bot created after the app went up is there without a rebuild.
A client reaches their own bot and no other
With the accounts module in, every request is checked on your server against the bots that session may open, before it leaves for Chatfuel. A client who somehow learns another client’s bot id is still refused it.
An operator panel your clients cannot find
Bots, access and health, reached by typing /admin and never listed in the nav rail — the rail is where your clients go. It creates, renames and deletes client bots, and opens any of them in the app.
Every line of it in your repository
MIT, with the component library, the API client and the proxy copied into the app rather than installed from us. Nothing you hand a client depends on this project still existing.
Any feature, any design — it is your codebase
A screen a client asks for that exists nowhere else is a directory you add and a line in the menu table, and making the whole thing look like your studio rather than ours is an edit in your own repository. Nothing here is a plugin slot with a ceiling on it.
Deploy again as often as you like
A second run reuses the project it already linked, overwrites the variables it pushes and deletes nothing it did not put there. Twelve settings go to production and preview, four of them write-only.
Vercel is the default, not the requirement
A Dockerfile ships in the app, and one command runs a plain node server over the built files and the same proxy. A client’s panel can live wherever you already host things.
A push can be the release
The wizard will create the repository and push it, through the GitHub CLI or a token you paste, then connect it to the Vercel project. After that, git push is how a client’s panel changes.
From the command to the client’s first sign-in
Four things happen once, in this order. Everything after them is a bot and a person.
- 01
Run the wizard
It asks which modules the panel should carry, takes your Chatfuel token, then asks what the app is called and where its logo file is. Both are judged before anything is written, so a mistyped path is answered by the command line rather than two minutes into a scaffold.
- 02
Give it an address
The deploy command ships inside the app, so it keeps working long after the wizard is gone: it checks for the Vercel CLI, signs you in, links the project, pushes the environment to production and preview, deploys, works out which of the deployment’s addresses is the public one, and then asks the deployment itself whether its configuration arrived. The project name you type is the address.
- 03
Add the client
In the operator panel, create the bot in the workspace whose plan pays for it and attach it to that client’s account. The record is reserved before Chatfuel is asked and dropped again if Chatfuel refuses, so a bot never exists on one side and not the other. Rename it, grant a colleague access to it, or delete it from the same table.
- 04
The client signs in
They open your address and find your name and mark above the form, then the bots they were granted and nothing else. They do not see the operator panel, another client’s bot, or the token all of it runs on.
What carries your name
One name and one image, asked once. The tab is the only place written into a file rather than read from a setting, because the head is parsed before any build value exists.
| Name | Where it comes from |
|---|---|
| Browser tab | The title tag in index.html, rewritten on disk while the app is being made. |
| Tab icon | The icon link in the same file, pointed at your image through the app’s base path so a sub-path mount still finds it. |
| Top bar | Your mark beside your name on every screen inside the app. Below a phone’s width the name drops and the mark carries the bar alone. |
| Sign-in screens | The same mark and name above every signed-out form. With no mark configured, a shield stands in. |
| The image itself | Copied byte for byte into the app’s public folder as logo plus its own extension. The mark the template ships is removed when yours is not an SVG. |
| The address | The Vercel project name, asked at deploy time — it becomes the host the panel answers on. |
| Changing them later | The name and the logo are environment values pushed to production and preview with the rest, so the top bar and the sign-in screens follow a change without a code edit; the tab title and icon are edited in index.html. |
FAQs
Yes — the panel runs at whatever address you point at it, and nothing in the app assumes a Vercel one. Attaching the domain is a step in the Vercel dashboard, though, and it is worth being plain about that: no code here touches DNS or claims a hostname. The deploy script only reads the addresses a deployment already answers on, so it can tell you which of them is the public one.