Magic Cloud vs Supabase, honestly

Seventeen rows: twelve to Magic, two to Supabase, three too close to call. Ecosystem and Postgres depth go to them, and we say so.

Access control when the developer is an AI agent

Supabase security is row-level security: SQL policies written per table, per app. When a human writes the app, this works — the human understands the policy and knows which queries respect it. When an AI agent writes the app, every generated endpoint and query must correctly reimplement those 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 where an anon key belonged, a query that silently sidesteps a policy, a check that a generation simply forgot. The model does not have to be malicious. It has to be wrong once.

Magic inverts this. Hyperlambda is not text that gets executed — it is an AST, and every node must bind to a slot the runtime exposes. Endpoints declare the roles that may invoke them, and whitelisting constrains exactly which capabilities a piece of code can bind to at all. 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, structurally, before execution. Security stops being a property of each generated app and becomes a property of the runtime, implemented once, deterministically.

The deep dive is in why secure AI code execution requires runtime whitelisting — and there is a standing $100 bounty on breaking the sandbox. Nobody has, and that same sandbox takes sentences from anyone on the Natural Language API.

React, Angular and Vue deploy here too

An agent writing plain HTML is the fast path, not the ceiling. When the frontend is a real application, you build it the way you already build it and deploy the output here. Generate a long-lived access token on the cloudlet, keep it as a GitHub secret, and let GitHub Actions check out the repository, run the production build, zip the output and send it to the cloudlet on every commit — the target folder is replaced with the new build. No SSH key, no deploy agent, nothing installed on the server, because the endpoint was already there.

CI is one option, though, not a requirement. Git and GitHub are built into the dashboard: add a GitHub access token to your configuration and you can clone a repository onto the cloudlet, branch, commit, push, pull, and create or delete GitHub repositories without leaving the platform. For a site with no build step that is the entire workflow — clone once, pull to deploy, no workflow file and no runner anywhere. A framework app still needs its build run somewhere, so either a workflow does it or you commit the built output and pull that. And because every one of those Git operations is also an MCP tool, the agent doing the work can handle the version control itself.

The web server handles both shapes of site. A single-page app has its unmatched URLs handed to the client-side router, so deep links and refreshes resolve instead of breaking. A normal multi-page site returns real 404s for URLs that do not exist, which is what a content site needs. Compiled assets are cached for a year while the HTML shell is never cached — the correct policy for hashed bundles, configured out of the box.

And because the same cloudlet serves the API, the app calls its backend on its own origin — no CORS configuration, no second hostname, no third product in the stack. The walkthrough is in deploy to a cloudlet on every git push.

Four capabilities Supabase has no answer for

Rewind, a debugger that works backwards. Run a file with Debug rather than Invoke and you get the entire execution recorded: every operation in order, the time each took, and your program’s whole state at every single step. When it throws, the failing statement is marked and everything built up before it is still sitting there to inspect. A stack trace tells you the last thing that happened; this tells you everything that led to it. Nothing is written to disk and nothing records unless you ask, so there is no performance question and no secrets left lying around. The full write-up is here.

The Hyperlambda Generator. Describe an endpoint in a sentence and get a verified, saved, live endpoint in about three seconds — role-gated, readable afterwards, and immediately a tool your agents can call. Not a snippet pasted into your editor for you to wire up: a running part of your backend. The overview is here.

OpenAPI import. Point a cloudlet at any OpenAPI specification and the operations in it become endpoints on your own backend, role-gated and published as MCP tools. The integration you were going to spend a week writing a client for is a URL you paste.

A plugin bazaar that installs into the runtime. Stripe, HubSpot, Shopify, WooCommerce, WordPress, Slack, NetSuite, SERP API, and LLM providers from OpenAI to a local Ollama model. These are not services phoning your project from outside — they land inside it as endpoints, workflow actions and slots, which is why your agents can use them the moment they are installed.

When you should stay on Supabase

You need PostgreSQL specifically. If you depend on Postgres extensions, replication topology, or a DBA team that knows it deeply, Supabase’s all-in bet on Postgres is a feature. Magic supports Postgres as one engine among four; it is not a Postgres-native platform.

You rely on the ecosystem. Client SDKs for every framework, auth helpers, community extensions, an enormous volume of examples. That gravity is real, and if your team’s velocity comes from it, do not give it up lightly.

You want a managed service with a huge community. Supabase Cloud is genuinely good. The pain described on this page is specifically the self-hosted path — if you were never going to self-host, most of this comparison does not apply to you.