The shape of the whole thing
A Tadabase AI app is not one thing. It is a short stack of layers, each doing one job, each replaceable without disturbing the ones above or below it. Read the diagram from the bottom up and it is the story of your data; read it from the top down and it is the story of a single click.
Most people meet these layers in the wrong order — they build a screen first and only later wonder where the data lives, or who is allowed to see it. Taking them in order makes the rest of the documentation fall into place, because almost every question ("why can this user see that record?", "why is my domain not working?", "can I move my app somewhere faster?") is really a question about which layer owns the answer.
The backend: one system of record
At the bottom is your Tadabase app. It is easy to think of this as "the database," but it is more than storage — it is storage plus everything that governs storage:
| What it holds | What that means |
|---|---|
| Tables and fields | The records themselves, and the shape they have to keep. |
| Relationships | Which record belongs to which — an order to a customer, a task to a project. |
| Workflows | Server-side logic: send this email, stamp that date, roll up a total. |
| Users and roles | Who the people using your app are, and which group each belongs to. |
| Row-level security | The rules that decide which records and fields each role may read or write. |
| Files and PDF templates | Uploads, and the documents you generate from records. |
The backend has no screens of its own. It never decides what a page looks like. That separation is what lets you put several very different-looking apps on top of one dataset without ever duplicating it.
The one door in front of your data
Nothing talks to your database. Every read and every write — from a Vibe app, from a phone, from a script, from an AI feature — goes through the same API, and that API does three jobs before it will run anything.
- Who are you?A person signs in and gets a token. Every later request carries it. No token, no data — except on the endpoints you deliberately made public.
- What may you see?Your row-level security rules run for that specific person. The response is filtered before it is built, so a record they may not see never leaves the server.
- How often?Rate limits apply per signed-in person — around 120 data requests a minute — so one busy user cannot degrade the app for everyone else. Sign-in endpoints are throttled harder to blunt password guessing.
This is why the layer exists at all. If each interface enforced its own rules, you would have as many security models as you have front-ends, and they would drift apart the first time someone shipped a fix to one of them. Instead there is one door and everything queues at it.
Interfaces: the apps people actually touch
An interface is one front-end of your app. One backend can carry several, and they do not have to be the same kind of thing — a polished customer portal, an internal back-office screen, and a script that syncs to your accounting system are all interfaces onto the same data.
| Kind of interface | What it is | How it reaches the backend |
|---|---|---|
| Vibe interface | A React app the studio agent builds for you, deployed to its own address. | The SDK that ships in every Vibe project, using the signed-in person’s token. |
| Classic Tadabase Pages | Pages and components built in the classic Tadabase builder. | Directly, inside Tadabase. Nothing to wire up. |
| Your own code | Anything you write and host yourself — a site, a mobile app, a nightly script. | The API. Per-user tokens for anything a person operates; an app key and secret for machine-to-machine integrations. |
| AI tools | Claude, ChatGPT, Cursor, and friends, driving your app while you build. | Our hosted MCP server. One address, a browser sign-in, nothing to install. |
Hosting: where an interface runs
A Vibe interface is real code, so something has to run it. When you publish, your project is built into a container image and started somewhere. That "somewhere" is a choice, not a fixed part of the product — and it is a separate choice from what the interface is.
Tadabase AI’s own managed hosting is the default and covers almost every app. Fly.io runs your app closer to users who are far from us. Cloudflare scales down to nothing when nobody is using the app and wakes on the next request. You are not choosing once and forever: the same release can be live on more than one at a time.
The address: domains and certificates
The top of the stack is the part your users actually type. Every published app gets a working address for free, and you can put your own in front of it.
| Address | Where it comes from | Use it for |
|---|---|---|
| A preview address | Created while you build, and put to sleep when idle. | Showing work in progress. It is temporary by design. |
| Your app’s Tadabase AI address | Assigned on your first publish. | Internal tools, early users, anything that does not need branding. |
| Your own domain | A CNAME you add at your DNS provider, then attach in the project. | Anything customer-facing. The certificate is issued and renewed for you. |
A domain is a pointer, not a possession of the app — that is the whole reason this is its own layer. You can move an interface to a different host, or replace it with a rebuilt one, and the domain keeps working because it points at our edge rather than at a specific machine.
Add a custom domainThe three-step version: CNAME, attach, wait for SSL.Where the AI fits
There are two different AI layers in a Tadabase AI app and it is worth not confusing them. One builds the app — you chat with it in the studio and it writes code and can create tables and workflows. The other lives inside the published app and belongs to your users, answering their questions about live data and running actions you enabled.
They sit at opposite ends of the stack, but they reach the data through the same door as everything else. Neither is a back channel.
Where the AI connectsBuild-time versus run-time AI, and why the AI your users talk to never gets a key of its own.Why the layers are kept apart
The separation is not architectural tidiness for its own sake. Each seam buys you a specific thing you would miss the moment it was gone:
| Seam | What it lets you do |
|---|---|
| Backend / interfaces | Add a second front-end for a new audience without migrating, copying or re-securing any data. |
| Interfaces / hosting | Move an app to a faster or cheaper host by re-publishing. No code change, no data change. |
| Hosting / address | Rebuild or relocate what serves the app while the URL your customers bookmarked keeps working. |
| Everything / the one door | Fix a permission once and have it hold everywhere — including in places you have not built yet. |
A worked example
A field-services company runs jobs, technicians and customers in one Tadabase app. Over eighteen months it grows through every layer without the data ever moving:
- Month one — the backendTables for Jobs, Technicians and Customers, a workflow that emails a receipt when a job closes, and roles for Admin, Tech and Customer. No screens yet.
- Month two — the first interfaceA Vibe app for technicians: today’s jobs, a photo upload, a Complete button. Row-level security means a tech only ever loads their own jobs — the app does not have to filter anything.
- Month four — a second interfaceCustomers start asking where their technician is. Rather than bending the tech app into a customer app, they add a separate customer portal on the same backend. Different look, different sign-in page, same Jobs table, same rules.
- Month seven — the addressThe portal moves from its Tadabase AI address to status.theircompany.com. One CNAME, one attach, one certificate. Nothing else changes.
- Month eleven — hostingThey win a customer in Australia and page loads feel slow there. They publish the same portal release to a host with a presence closer to those users. Same code, same data, better latency.
- Month eighteen — the AI layerThey switch on Ask inside the portal so customers can type "when was my last service?" instead of hunting. It answers as the signed-in customer, so it can only reach that customer’s jobs — a rule written back in month one, still holding.
At no point did anyone migrate data, duplicate a table, or write a permission twice. That is what the layering is for.