If you are searching for a self-hosted Supabase alternative, you probably already know the uncomfortable truth about self-hosting Supabase itself.
It exists. It is documented. And it is clearly not the product.
The hosted platform gets the polish. The self-hosted version gets a sprawling docker-compose stack with a dozen services to keep healthy, a dashboard that lags behind the cloud offering, and a support story that amounts to community forums and GitHub issues. None of that is a scandal — Supabase is a hosted business, and their self-hosting story reflects that honestly. But if you need self-hosting for real reasons — data sovereignty, compliance, cost control at scale, or simply not wanting your backend to depend on someone else's uptime — you are running their second-class citizen in production.
Magic Cloud starts from the opposite end. It is self-hosted first: one deployable unit, MIT-licensed, no open-core feature gating, no cloud version holding back the good parts. And it was built with a bet that matters more every month: that the next user of your backend is not a developer with an IDE, but an AI agent with a prompt.
This article is an evaluation, not a pitch. Supabase is a good product, and there are cases where you should still pick it. We will get to those.
What Magic Cloud actually is
Magic Cloud is an open-source backend platform that covers roughly the same ground Supabase does, in a single deployable unit.
- A database layer — SQLite by default, with MySQL, PostgreSQL, and SQL Server support.
- Auto-generated CRUD APIs — point it at a database and it generates secured HTTP endpoints for every table.
- Authentication and role-based access control, built into the platform rather than bolted on per project.
- A server-side file system, task scheduling, and logging.
- An AI layer — RAG-based machine learning types, embeddable chatbots, and a native MCP server that exposes the whole platform to AI agents.
The runtime underneath is Hyperlambda, a declarative language that executes as an abstract syntax tree rather than as text. Before that triggers a "not another language" reflex: you are not expected to write it. Hyperlambda is generated code. The platform ships with the Hyperlambda Generator, a fine-tuned model that compiles plain-language prompts into working endpoints, and the CRUD generator produces complete APIs without you writing a line. Think of Hyperlambda the way you think of the SQL that an ORM emits — it is there, you can read it, and you rarely need to author it by hand.
Deployment is one Docker container for the backend and one for the dashboard. No service mesh of gateways, realtime servers, storage daemons, and edge runtimes to babysit. That is not because Magic does less — it is because the platform was architected as one coherent system instead of a federation of acquired and assembled parts.
How Magic Cloud compares as a self-hosted Supabase alternative
| Supabase | Magic Cloud | |
|---|---|---|
| License | Open-core; some features gated to the hosted platform | MIT, everything included |
| Self-hosting story | Community-supported docker-compose stack, dashboard feature gaps | First-class; self-hosted is the primary deployment model |
| Database | PostgreSQL | SQLite by default; MySQL, PostgreSQL, MSSQL supported |
| API generation | PostgREST over your schema | Generated Hyperlambda endpoints per table, customizable after generation |
| Access control | Postgres row-level security, written per app | Framework-enforced RBAC, checked at execution time |
| AI and agent story | Client libraries, MCP as an add-on | Native MCP server, RAG types, and an endpoint generator agents drive directly |
| Ecosystem maturity | Large — SDKs, extensions, huge community | Smaller — one team, one architecture, longer history than you might expect |
Two of those rows deserve honesty in both directions.
Ecosystem: Supabase wins, clearly. There are client SDKs for every framework, thousands of tutorials, and an enormous community. Magic's community is smaller. If your evaluation weighs "how fast can I find a Stack Overflow answer," Supabase scores higher.
Database: if your requirement is literally PostgreSQL — extensions, replication topology, a DBA team that knows it — Supabase's all-in bet on Postgres is a feature. Magic treats the database as pluggable, which is more flexible but less deep on any single engine.
The row that matters most for 2026, though, is access control. That one needs its own section.
Access control when the developer is an AI agent
Here is the problem with per-app access control in the agent era.
Supabase's security model is row-level security: you write RLS policies in SQL, per table, per app. When a human developer writes the app, this works well — the human understands the policy, tests it, and knows which queries are supposed to bypass it and which are not.
Now let an AI agent write the app.
Every generated endpoint, every generated query, every generated edge function has to correctly reimplement or respect the access-control assumptions. The security boundary lives inside the generated code. Which means every generation is a new opportunity to get it wrong — a service-role key used where an anon key belonged, a policy that the generated query silently sidesteps, an endpoint that forgets the check entirely. The model does not have to be malicious. It just has to be wrong once, and probabilistic systems are wrong sometimes. You end up reviewing every line of generated code for security, which erases most of the point of generating it.
Magic inverts this. Hyperlambda is not text that gets executed — it is an AST, and every node in that tree must bind to a slot the runtime exposes. Access control is enforced at execution time by the runtime itself: endpoints declare the roles that may invoke them, and the whitelisting system can constrain exactly which slots a given piece of code is allowed to bind to at all. If io.file.delete is not whitelisted in an execution context, code running in that context cannot call it. Not "is instructed not to call it" — cannot bind to it. The invocation fails structurally, before anything executes.
This means an agent generating code on a Magic backend cannot generate its way out of its permissions. The worst a bad generation can do is fail. Security stops being a property of each generated application — reimplemented, per app, by a probabilistic author — and becomes a property of the runtime, implemented once, deterministically, in C#.
That is the actual reason to consider switching in 2026. Not the license, not the docker-compose fatigue — those are real but incremental. The structural difference is that Magic is a backend you can safely let an agent operate, because the platform, not the agent, holds the keys.
What that looks like in practice
This is not a hypothetical capability. Here is a build we ran recently, and which you can reproduce on any Magic cloudlet.
An AI agent — Claude, connected over Magic's MCP server — was given a single natural-language prompt describing a small product. Inside roughly ten minutes it created a database, generated a public API endpoint on top of it, wired up email notifications, built and embedded a chatbot widget, deployed a landing page, and verified every step by invoking the live endpoints over HTTP.
The most telling moment was a failure. The agent produced a malformed chatbot widget, and the platform rejected it. The agent then read Magic's built-in guides — served over the same MCP connection — corrected its own mistake, and redeployed successfully. No human intervened between the prompt and the working system.
Every one of those operations passed through the runtime's permission checks. The agent operated as an authenticated user with specific roles, and everything it built runs inside the same RBAC boundaries any human-built module would. That is what "agent-operable backend" means concretely: not a chatbot that emits code for you to review, but an agent that safely holds production credentials because the runtime bounds what those credentials can do.
When you should still pick Supabase
Being a good self-hosted Supabase alternative includes telling you when not to switch.
Pick Supabase if you need PostgreSQL specifically — you depend on Postgres extensions, you have Postgres operational expertise, or your data model is married to Postgres features. Magic supports PostgreSQL as a database, but it is not a Postgres-native platform the way Supabase is.
Pick Supabase if you rely on its ecosystem. The client SDKs, the auth helpers for every frontend framework, the community extensions, the sheer volume of examples — that gravity is real, and if your team's velocity comes from it, do not give it up lightly.
And pick Supabase if what you actually want is a managed service with a huge community behind it. Their hosted product is genuinely good. The pain described at the top of this article is specifically the self-hosted path — if you were never going to self-host, most of this comparison does not apply to you.
If none of those describe you — if you need self-hosting to be the first-class path, want MIT licensing with nothing gated, and expect AI agents to be building and operating your backend — the trade-offs point the other way.
Getting started
Magic Cloud is on GitHub at github.com/polterguy/magic — MIT-licensed, with Docker images for the backend and dashboard. The documentation lives at docs.ainiro.io, including guides for the CRUD generator, the Hyperlambda Generator, and the MCP server. If you want it managed instead of self-hosted, AINIRO runs hosted cloudlets with the same codebase — no feature differences, because there is nothing gated to gate.
FAQ
Is Magic Cloud really free and open source?
Yes. The entire platform is MIT-licensed — database layer, CRUD generation, auth, RBAC, the AI features, and the dashboard. There is no enterprise edition holding features back and no open-core split. The hosted cloudlets at ainiro.io run the same code you can deploy yourself.
Do I have to learn Hyperlambda?
No. Hyperlambda is the execution format, but it is generated — by the CRUD generator when you scaffold APIs from a database, and by the Hyperlambda Generator when you describe endpoints in plain language. It is readable and editable when you want to customize, but authoring it by hand is optional, not required.
Can Magic Cloud replace Supabase auth and row-level security?
For most applications, yes, with a different model. Magic ships JWT-based authentication and role-based access control as platform features: endpoints declare which roles may invoke them, and the runtime enforces this at execution time. Where Supabase expresses row-level rules in per-app SQL policies, Magic expresses access rules as endpoint and slot-level constraints enforced by the runtime. If your authorization logic is genuinely row-shaped — user A sees rows where owner = A — you implement that filter in the generated endpoint, where it is enforced server-side like everything else.
Does Magic Cloud work with Claude, MCP, and other AI agents?
Yes, natively. Magic includes an MCP server, so Claude and any MCP-capable agent can connect directly and use the platform's tools — creating databases, generating endpoints, managing files, scheduling tasks — all inside the RBAC boundaries of the authenticated user. Agents can also generate new tools for themselves through the Hyperlambda Generator, and everything they produce runs inside the same execution-time permission model.