The browser holds a key to your database
Your anon key ships to every visitor. What stops one user reading another's rows is a policy you wrote, on every table, correctly, the first time.
So you add Vercel for the app, Upstash for a queue, Resend for email, Cloudflare for the domain — and now it's five dashboards, five bills, five places for a secret to go stale. AnyHost runs all of it as one account, and still hands you the Postgres connection string, because it was never ours to hold.
Free tier, no card. Postgres, Redis, storage, email and domains included · pricing
Supabase is built for apps without a backend: the browser talks to Postgres directly, and row-level security is the thing standing between one user's data and everyone else's. That works — right up until a policy is missing, or enabled but too broad. AnyHost assumes you have a backend, because it runs one for you.
Your anon key ships to every visitor. What stops one user reading another's rows is a policy you wrote, on every table, correctly, the first time.
Your backend holds DATABASE_URL and nobody else does. A permission check is an if in code you already know how to read, review and test.
Neither model is universally right. If your app genuinely has no server-side logic, Supabase's is less to run. The moment you need a webhook handler, a scheduled job or a third-party API call with a secret in it, you are writing a backend either way — and then the question is only where it runs.
If a comparison page only lists what its author wins at, it isn't a comparison. Three rows below go to Supabase, and one of them may be the reason you stay.
| Capability | Supabase | AnyHost |
|---|---|---|
| Managed Postgres | Yes | YesDATABASE_URL injected per environment; time-limited direct-access profiles for humans |
| Runs your own backend code | Edge FunctionsDeno, per-function, request-scoped | Container runtimebuilt from a pushed commit, with logs, health checks and redeploy to a known-good commit |
| Hosted auth service | Yesproviders, sessions, JWTs, user table | Noyou implement auth in your backend, or keep using an auth provider |
| Realtime subscriptions | Yes | No |
| Object storage | Yes | Yesper-environment buckets, private by default, optional public delivery path |
| Managed cache / Redis | Notypically added via Upstash or similar | Yesencrypted at rest and in transit; connection and key prefix injected |
| Transactional email | Notypically added via Resend or similar | Yescustom sending-domain verification, delivery events, suppression handling |
| CDN, custom domains, certificates | Partialstorage and API surfaces; app hosting is elsewhere | Yesapex support, DNS validation, HTTPS smoke check after cutover |
| Separate dev and production state | Branchingpaid feature | By defaultevery project gets dev and prod with separate URLs, secrets and resources |
| Driven by your coding agent | MCP server | CLI + installed skillmachine-readable results, production confirmation at the mutation boundary |
| Your data stays portable | Yesstandard Postgres | Yesstandard Postgres; take the connection string and go |
Supabase capabilities as documented publicly at the time of writing — check their docs, they ship fast. AnyHost rows correspond one-to-one with our services page.
Builds from an immutable commit, structured failure reasons instead of a wall of log, health checks tied to the deployed URL, and redeploy to a known-good commit when a change goes wrong.
Dev and prod get separate URLs, separate secret sets and separate resources. Values are masked by default, and production mutations require explicit confirmation.
Postgres, Redis and object storage, each scoped to one project environment, with connection variables generated and injected rather than copied between dashboards.
Global CDN, managed HTTPS, custom domains with DNS validation and apex support, and a public HTTPS smoke check after the cutover moves traffic.
Deployment evidence, runtime logs, health responses, and usage attributed down to project, environment and resource — readable by you or by your coding agent through the CLI.
No signup needed to start. The prompt below points your agent at our bootstrap instructions; it installs the CLI and a project-local skill package, then works inside your repository. Keep your Supabase project running until you've verified the new one — nothing here touches it.
Fetch https://anyhost.app/agent-setup/prompt.md and follow it to set up Anyhost in this repository. Then move this app off Supabase onto Anyhost: provision Postgres, port the schema and data, move storage objects, replace the client-side Supabase calls with calls to our own backend running on Anyhost, and keep auth working. Verify everything end to end against the dev environment first. Ask me to confirm before anything touches production. Leave the existing Supabase project untouched until I say otherwise.
Your agent will ask you before it changes anything in production — that confirmation boundary is enforced by the CLI, not just by the prompt.
It depends on where you are. If your app is a frontend talking straight to Postgres, Supabase Auth is doing real work for you and swapping it out is a rewrite you may not want. If you already have a backend — or you're about to write one for webhooks, jobs or third-party calls — then auth is a library in that backend, and you get to keep sessions, roles and checks in code you can read and test. Plenty of teams also keep an external auth provider and point it at their AnyHost backend.
Yes. Nothing requires you to move your data. Put DATABASE_URL in your environment and point at whatever Postgres you like. People often start that way and move the database later, once the app has been running here for a while.
A real one. It's standard managed Postgres — your app gets DATABASE_URL injected, and humans get time-limited direct-access profiles that can be revoked. If you leave, you take the database with you the same way you would from anywhere else.
We don't have an equivalent. If your product depends on Postgres change subscriptions, that's a genuine reason to stay on Supabase, or to run both. We'd rather say so here than after you've moved.
Free covers one development runtime with managed database, storage, CDN and email inside fixed limits, with no invoice. Pro is $20 per workspace per month and includes $20 of monthly infrastructure credit plus production environments, with pay-as-you-go beyond that. Full rates are on the pricing page, itemized per resource.
Move one app over and keep the old stack running until you're satisfied. Nothing about this is one-way.
Get the migration prompt