Backenly

Backenly is an autonomous backend platform built for AI coding agents. Its premise is direct: your coding agent builds the backend over MCP, and Backenly maintains it on its own, fixing what it can verify and undo and holding anything risky for you. Everything a production backend needs is wired to one Postgres schema per project from the first table: Postgres, REST APIs, auth, storage, functions, realtime, row-level security, branches and teams. It is aimed at developers and teams who let Claude Code, Cursor, Codex, Antigravity, Cline, GitHub Copilot, Zed or another MCP host write their backend, and who want that backend to be real production infrastructure rather than a prototype that quietly degrades after the agent disconnects. The problem Backenly addresses is the second half of agent-built software: upkeep. Generating tables and endpoints is the easy part; keeping a running backend healthy, safe and reversible is where things break. Backenly draws an explicit contrast with Supabase and Firebase, which it says hand you excellent parts and leave the assembly, configuration and upkeep to you, making you the operator. Backenly does not just generate resources; it manages backend change safely. Changes are planned, destructive ones wait for your approval, schema changes are read back from the live database before they count as done, and a resident autonomy loop keeps fixing the running backend, with receipts, when no one is at the keyboard. The other half of the problem is risk: an agent issuing a DROP TABLE or dropping a column can take live rows with it, so Backenly treats those requests as things that park and wait for a person. The data layer is standard PostgreSQL with a schema of your own per project. Tables, relations, indexes, constraints and pgvector live in a PostgreSQL schema per project, and isolation is a Postgres grant rather than a WHERE clause, with no shared tables between projects. Backenly exposes direct connection strings and pg_dump exports, so psql, TablePlus or any BI tool can connect, and an export restores on any Postgres. On top of that schema, REST APIs are served by PostgREST for every table from the catalog, including filters, ordering, pagination, embedded resources and OpenAPI documentation, so endpoints exist as soon as tables do. Auth covers sign-up, OAuth, magic links and verification emails for your users, and each project signs with its own secret so a JWT signing key is never shared across projects. Storage provides buckets, uploads, metadata and expiring signed URLs on local disk or any S3-compatible provider, including private buckets with no public read. Realtime delivers inserts, updates and deletes as they land, plus presence and broadcast, delivered over SSE with no socket server to run. Functions and triggers run code on insert, update, delete or signup, or on a cron schedule, with webhooks and rate limits included and every run logged. Beyond the core primitives, Backenly builds in row-level security by description: you say who can read and write what and Backenly writes and enforces the Postgres policies. Branches support risky work, letting you clone the backend, let your agent experiment, review the diff and merge what works. Teams and organizations let you invite teammates with roles, and every actor writes to the same change ledger. The dashboard exists for oversight: inspecting every table, user, file and function, approving or rejecting destructive requests under Waiting on you, reading the agent journal and autonomy receipts, managing keys, teams and branches, and restoring earlier versions from restore points. The unique approach is the autonomy loop attached to the live backend. Backenly checks the backend every minute against 26 guarantees in a five-stage cycle: observe, detect, propose, apply, verify. Verify feeds the next observe, and no human sits at the top of the loop. Safe, additive fixes ship on their own because each is snapshotted first, and undo restores the exact state captured before the fix ran. Autopilot mode lets safe fixes ship while everything risky waits for you, and the safety floor never moves: auth, destructive and irreversible changes always need your approval in every mode. Dropping or emptying a table, dropping a column, deleting files and revoking keys do not run; each parks as an approval request with the impact laid out, including how many live rows are affected and whether the data is recoverable. The agent's key can request and poll, never approve. Schema changes are verified on the live database, and schema restructuring follows a notice, rehearse, approve, move, open sequence: the change runs first on a copy of the real rows and rolls back, nothing runs until you approve that exact plan, the new table is built beside the old one with columns kept in step both ways, and nothing is removed from the original table so old and new code both keep working. For users, the outcome is a backend that keeps working when nobody is asking. Every automated repair leaves a receipt in a guardrail log, every change is versioned and undoable, and risky operations are surfaced rather than silently executed. Because the contract is standard REST plus a typed SDK and the database is standard PostgreSQL, teams are not locked in: direct read-only and read-write connection strings and pg_dump exports are available on every plan, including Free, and the platform itself is open source, so the exit path includes running Backenly on your own servers. Concrete workflows look like this. In the documented example, a coding agent builds the UrbanCart store backend through Backenly MCP tools, creating the products, orders, order_items and users tables, enabling email/password auth, applying an RLS policy on orders, connecting Stripe with the key verified and stored encrypted, and enabling realtime on orders, with each change verified on the live database before it is considered done. Later, Backenly adds an index on orders.customer_id after a slow query is detected, then re-checks to confirm the fix. When the agent asks to drop the carts table, it stops at an approval gate with all 1,284 rows untouched, and when a relation on order_items has no foreign key, that change waits because adding one alters which writes are accepted. Teams also clone the backend into branches for risky experiments and merge what works, and review the agent journal to see exactly what happened while they were away. Target users are developers and teams using MCP-capable coding agents, from solo builders to organizations that need roles, change ledgers and review. Integrations and technical context mentioned include MCP hosts such as Claude Code, Cursor, Codex, Antigravity, Cline, GitHub Copilot and Zed, the CLI (npx @backenly/cli) for schema, generated types, CI diffs, logs and read-only SQL, a canonical agent skill at backenly.com/skill.md, PostgREST, pgvector, S3-compatible storage and Stripe. Backenly Cloud runs in Mumbai, Frankfurt, US East, US West and Singapore, while self-hosted Backenly runs wherever your servers do. Self-hosting is free under Apache-2.0, with an AI provider key needed only for model-based features such as natural-language build tools, since the self-healing fixes are rule-based. On Backenly Cloud the Free plan is genuinely free with no credit card and includes a real, permanent backend plus the self-healing loop every minute; Pro is $25/month and raises capacity rather than the self-healing, which is never capped on any plan; Enterprise is custom. Driving the backend from your own coding agent through the typed MCP tools is never metered as AI, and autonomy is included on every Cloud tier. The platform is open source under Apache-2.0, including the autonomy engine, and the SDK, CLI, MCP server and agent skill are MIT. In short, Backenly is the autonomous backend that lets a coding agent do the building while the platform does the keeping: real Postgres and production primitives, a self-healing loop that repairs what it can prove and undo, and an approval gate in front of anything that could break your data.