Launched this week
Backenly
The autonomous backend for AI coding agents
270 followers
The autonomous backend for AI coding agents
270 followers
Backenly is an autonomous backend platform built for coding agents. Your agent builds the backend over MCP, from Postgres to sign-in, storage, functions and realtime. Then it maintains itself: every minute a self-healing loop repairs missing indexes, RLS gaps and dead realtime triggers, verifying each fix live. As your app grows, it restructures its own schema once you approve. Risky changes wait for you, and every change is versioned with rollback.
Free Options
Launch Team / Built With
AWS Startup AdvisorPersonalized AWS guidance that meets you where you’re already building
Promoted
Hey Product Hunt 👋
I'm Adarsh, cofounder of Backenly with @lakshmi_sunil
AI coding agents can now build an application in an afternoon. But once that application goes live, the backend still works the old way: it waits for a person to notice what broke.
APIs break. Schemas drift. Permissions leak. Migrations go wrong. Patches pile up. Eventually, someone has to stop building and start debugging the backend.
We started Backenly around one question:
If software is increasingly built by AI agents, why should the backend still depend on humans to keep it alive?
So we built an autonomous backend platform for AI coding agents.
Through MCP, agents can create and work with:
Postgres databases with row-level security
Authentication
Storage
Realtime
Functions
But the part we care about most begins after deployment.
Every minute, Backenly checks the running backend, works out what has gone wrong, fixes what it can verify and roll back, and confirms the fix worked. Anything it can't fix safely waits for your approval.
And we didn't want "autonomous" to mean endlessly applying patches.
If Backenly keeps finding problems in the same part of a table, or changes to it keep locking a table serving live traffic, that table might be doing two jobs.
Instead of adding another patch, Backenly can rehearse splitting it on a copy and show you the proposed change. Once you approve, it moves the data while your app keeps working.
That's the idea we're most excited about: a backend that repairs itself and changes shape as your application grows.
Of course, giving software this much autonomy creates a different problem: trust.
Every change Backenly makes autonomously must be reversible, verified after execution, and recorded in one history so you can see what changed and why.
Destructive changes, like dropping a table, always wait for your approval. Your coding agent cannot approve them on your behalf.
Getting started with Backenly
Start free at backenly.com and connect Claude Code, Cursor or Codex in one command: backenly.com/docs/connect
🎁 Launch offer: Use code PRODUCTHUNT50 for 50% off monthly Pro for three months.
We're still early, and that's exactly why we wanted to launch here.
I'd especially love feedback from people building with Claude Code, Codex, Cursor, and other coding agents:
What would you trust an autonomous backend to change completely on its own, and what should always require your approval?
Lakshmi and I will be here all day answering questions. Really excited to hear what you think! 🚀
@lakshmi_sunil @adarsh_cj Love the idea of making backend fixes automatic but keeping humans in control how do you handle rollbacks if something goes worng?
@shivam_kushwaha16 Thanks Shivam, we actually take a checkpoint before every fix and verify the change right after. If verification fails, Backenly rolls back to that checkpoint automatically, but only if no rows written after the fix would be affected. If some would, the rollback waits for your approval and shows you exactly what it would change. You can also roll back any change yourself from History.
@lakshmi_sunil @adarsh_cj Building everything from Postgres to authentication through MCP sounds incredibly useful. Great work, team!
@vipul_kumar1280 Hi Vipul, thanks for the kind words on our launch. Use code PRODUCTHUNT50 for 50% off Pro for 3 months, until Nov 7. What project are you building?
@adarsh_cj What happens if an AI agent makes an incorrect schema change ? Can developers easily roll it back ?
@dipanshu_kushwaha5 Hey Dipanshu, yes, you can rollback it. Every change the agent makes is saved in your project's History, so you just pick the change and restore the state before it. Your app's data isn't lost, and the agent can ask for a rollback, but you're the one who approves it.
The rehearsed split on a copy is the part I am most curious about. What does the rehearsal actually validate before it shows you the proposal, and does a split still wait for approval like other destructive changes?
@jcbuilds Hey JC , Before you ever see a split, we run the actual migration on a copy of your real rows, inside a transaction that always rolls back. We check the old and new tables stay identical as data gets written, and that permissions behave exactly like before. If anything fails, it never gets proposed. And yes, it always waits for your approval. Your agent can't approve it, and we never drop the old columns. That part's always your call.
Well, finally someone takes care about what happens after deployment. Defo bookmarked for my next project! Congrats on launching this very useful product.
@artstavenka1 Thank you Stavenka, after deployment is where most backends quietly break, so that's where we focused and want Backenly to prove itself. Would love to hear how it goes on your next project😄
@balaji_rao1 Thank you :)
To your question: I'd let it add a missing index or fix a dead realtime trigger on its own, but anything touching row-level security on orders or payments should wait for me, even when it looks like a fix. In a multi-store setup, one wrong policy means one merchant can see another merchant's customers. Can approval rules be set per table, so a few tables always need a human while the rest repair themselves?
@ahmed_khaled32 Ahmed, that's a good call on orders and payments, and you're right that one bad policy there is the real risk. Not per table yet, right now it's one setting for the whole project. But if you have your coding agent write the RLS policies for those tables, Backenly won't change them on its own. Tightening a policy always waits for you. It only adds a policy to tables that have none. Per table "always ask" is exactly the right idea, and we're building it🙌
Nice launch Adarsh. On fintech projects our clients’ auditors want every production schema change tied to a ticket. Can the self-healing loop be limited to staging, so production only changes through a migration someone has reviewed?
@skalmurad Good question, Murad. Actually the self healing loop doesn't run on branches yet, it only watches production. But you can still lock production down the way your auditors want.
There is an option for you to turn autonomy Off on the production project (your agent can set it for you). It keeps checking and flags issues, but won't change anything by itself. Basically a watch and report mode.
With Protected production on, agents can't touch the production schema directly. Changes get built on a preview branch and only go live when someone approves the merge. Each change is logged with who made it and the exact SQL that ran. There's no ticket field yet, so for now just name the branch after the ticket.
@adarsh_cj Thanks, that works. Protected production plus naming the branch after the ticket covers what our auditors ask for. A ticket field later would be a nice addition.
@skalmurad Glad it covers it, Murad. I'll add a ticket field within the next few weeks, so each change in the log shows its ticket next to the SQL. If you try it on one of your fintech projects, I'd love to hear what the auditors think.