Should I vibe code
Self-host a Postgres backend with auth, storage, and a small API surface
Postgres you can run. Auth is the part where confident code is quietly wrong.
?
Their verdict, the Pro price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-03.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
Self-hosting the database is reasonable. Rebuilding auth, row-level security and storage policies around it is the single most generated and least reviewed code in the entire ecosystem.
What actually breaks
not "if". the specific failures.
- Row-level security policies that look right and are not
- Session handling with a subtle flaw that grants access across accounts
- Password reset flows that leak account existence, or worse, allow takeover
- The database, when nobody is patching it
A user emails to say they can see someone else’s data. One row-level security policy was written with a permissive USING clause, and it has been live for three months. You now have to work out who saw what, and then tell them.
Is that you?
the verdict is a default, not a law
- Authentication is delegated to a real identity provider
- It is internal, behind a VPN, with no public signup
- You have tested the access rules from an unauthenticated session
- You are writing your own session, password or token logic
- Anyone can sign up
- You cannot articulate exactly which rows an unauthenticated request can reach
If you build it anyway
the checklist, then the prompt that enforces it
- Do not write auth. Delegate to an identity provider and consume tokens.
- Deny by default at the database level, then grant narrowly.
- Write tests that assert an unauthenticated and a wrong-tenant request get nothing.
- Never trust a client-supplied user id. Derive identity from the verified token, server-side.
- Automate backups and test a restore before you have data worth restoring.
I am self-hosting a Postgres backend with auth. Auth is the part that gets silently, catastrophically wrong, so: 1. Do not implement authentication. Integrate an existing provider and consume its tokens. If I insist on rolling my own, refuse and explain the specific failure modes: session fixation, timing attacks on comparison, reset token reuse, and account enumeration. 2. Row-level security is deny-by-default. Enable RLS on every table at creation time, then add narrow policies. Never leave a table with RLS off. 3. Identity always comes from the verified token, server-side. Never accept a user id from a request body or query parameter — flag any code that does. 4. Write an access test suite before the features: for each table, assert that an anonymous request returns nothing and a request authenticated as tenant A cannot read tenant B. Fail CI on a gap. 5. Secrets come from the environment. Nothing hardcoded, nothing in the repo, and add a pre-commit check for it. 6. Set up automated encrypted backups and write the restore procedure. Then tell me to perform a restore into a scratch database before going live. 7. Enable connection limits, statement timeouts and query logging. 8. In the README, list the exact things I am now responsible for that a hosted provider was doing: patching, backups, upgrades, monitoring, and incident response.
That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
As soon as there is public signup. Hosted auth is cheap, audited and boring, and boring is the correct property for the component that decides who sees what.
Keep schema and migrations in version control and avoid provider-specific extensions where you reasonably can. A plain Postgres dump should be enough to move to a managed host, which is the escape hatch you will eventually want.
Active open-source self-hosting platform for applications, databases, and services.
Questions
Is self-hosting the database itself the risky part?
No, running Postgres is well-understood and reasonable. Auth and row-level security are the risky parts, and they are also the parts AI agents write most confidently and least correctly.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
last reviewed 2026-08-03 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice