The Backend of a Sovereign AI Product: Building a Self-Hosted Stack
By Anis Hammouche·June 7, 2026
An AI product is a backend before it is a model: a database, accounts, files, server functions and a vector database for search. You can rent all of it from an American service, or self-host it with open-source building blocks like Supabase. Self-hosting keeps the data with you, but running it becomes your job.
Take Samir, a freelancer who wants to sell accounting firms a small AI tool that finds a piece of information in their clients' files (an invented character). His first question is about the model: GPT, Mistral, an open model. That is the visible part. The question that decides what comes next follows right after: where do the files of his clients' clients live? The accounts, the files, the history of questions, the search vectors, none of that is the model. It is the backend, and that is where it is decided who holds this data.
The backend, the question everyone postpones
An AI prototype fits in a script and an API key. A product does not. As soon as you have real users, you need to handle accounts, permissions, files, a history, and often a semantic search over documents. That plumbing is most of the real work, and it is what everyone underestimates at the start.
The most common reflex is to plug everything into a turnkey service. It works and it is fast, but your clients' data and their vectors end up on an infrastructure you do not control, under a jurisdiction that is not yours. That is the heart of the debate on where your clients' data goes. For a prototype or a consumer app, the trade-off is acceptable. For files your clients entrust to you, it is paid for later.
What an AI product demands of its backend
Before choosing a tool, you need to know what it has to cover. An AI product needs five building blocks, almost always the same ones. This breakdown is mine, not a standard.
| Block | Role | What it does in an AI product |
|---|---|---|
| Database | Store structured data | Accounts, content, metadata |
| Authentication | Manage users and permissions | Login, roles, permissions |
| File storage | Keep documents | PDFs, images, attachments to analyze |
| Server functions | Run code on demand | Model calls, processing, webhooks |
| Vector database | Similarity search | Semantic search over documents |
The last row is the only one truly specific to AI. The other four are the foundation of any serious application: a good AI backend looks first like a good backend, period.
The self-hosted option: Supabase and its alternatives
These five blocks exist as open source, hostable on your own infrastructure.
Supabase is the most complete example. Built on PostgreSQL, it provides the database, authentication, file storage, server functions and, with the pgvector extension, similarity search. Its documentation describes self-hosting with Docker as the easiest path: under 15 minutes to get started, on a machine with at least 4 GB of RAM, 2 cores and 40 GB of disk for development or small to medium production. Your data stays on your server, in the jurisdiction of your choice.
It is not the only option. Appwrite targets a similar scope and presents itself as self-hostable on infrastructure you control. PocketBase packs everything into one program written in Go, with a SQLite database and user and file management: ideal for a light product, but its repository warns that backward compatibility is not guaranteed before version 1.0.
Self-hosted does not mean free
This is the classic mistake: "open source and self-hosted" too quickly turns into "free". The license is free, the operation is not.
According to the Supabase documentation, when you self-host you are responsible for the server and its maintenance, security and updates, configuration, Postgres maintenance, high availability, backups and disaster recovery, and monitoring. Managed backups and point-in-time recovery are among the hosted platform's features that are not available when self-hosting.
| Rent a hosted service | Self-host | |
|---|---|---|
| Where the data lives | With the provider, under its jurisdiction | On your server, in the jurisdiction of your choice |
| Backups | Handled by the provider | Yours to set up and test |
| Updates and security | Handled by the provider | Yours |
| Time to get started | Short | Longer, plus ongoing upkeep |
| When to choose it | Quick test, product with no sensitive data | Client data to protect, contract constraint |
The real trade-off is therefore not "free versus paid", but "I rent and hand over control" versus "I host and keep control, paying for the operation". For a quick test, the rented service is often the right choice at the start. The trap is choosing by default, without having asked the question.
What I did myself
For Studo, my mobile chat app, I plugged a React Native app into an OpenWebUI engine that I host myself, instead of a third-party service: the conversations do not go to a third party. The limit is that of any self-hosting: I am the one running that server. I do not draw a general rule from it: a product for your own needs does not have the same constraints as a tool you sell to accounting firms.
A sheet to decide before choosing a model
Fill it in before writing the first line of code. It tells you whether to rent or to host.
Product: [e.g. search across an accounting firm's client files]
Data handled: [e.g. invoices, attachments, client names]
Sensitivity: [public, internal, confidential]
What the client's contract says about hosting: [nothing, EU required, no third parties]
Who runs the server if I host: [me, a provider]
Who tests the backups: [name and frequency]
Decision: [rented to test, self-hosted from the start]
A self-hosted backend with accounts, files and vector search, plugged into an agent, is a dev project I take on. It is also an automation job when the backend has to be connected to existing tools, as in Automating without code: n8n, Make or Zapier.
Key takeaways
An AI product is first a solid backend, and only then a model. The choice of that backend decides who holds your data.
- An AI product needs five blocks: database, authentication, storage, functions, vector database.
- Self-hosted open source (Supabase, Appwrite, PocketBase) keeps your data with you.
- Self-hosting has a real running cost: backups, security and updates are yours.
- The right trade-off is made before choosing a model, based on how sensitive the data is, not by default.
FAQ
What is a backend for an AI product?
Everything that runs the product behind the model: database, user management, file storage, server functions and a vector database for search. The model answers requests, the backend holds everything else.
Why host it yourself instead of renting a service?
To keep the data on your infrastructure, in your jurisdiction. It is decisive when the data is sensitive or when a client's contract requires it. Renting is faster, but you hand control to someone else.
Is self-hosting really free?
No. The open-source license is free, but running it has a cost: server, updates, backups, security, monitoring. You no longer pay a subscription, you pay for hosting and upkeep. The advantage is control, not price.
Do I need a different tool for the AI part of the backend?
Not necessarily. An extension like pgvector, built into PostgreSQL, is often enough for semantic search. The backend of an AI product looks first like a good classic backend, with a vector database added.
Sources
- Supabase, Self-Hosting and Self-Hosting with Docker, read on 1 November 2026
- Supabase, pgvector: Embeddings and vector similarity
- Appwrite, GitHub repository, read on 1 November 2026
- PocketBase, official site, read on 1 November 2026
The next step is planning a fallback for when your AI provider is cut off. I share this kind of choice in my newsletter, you can sign up right below.
