How Backenly works

1. 1

   Your agent, over MCP

   A scoped key, a manifest of 20 tools, and a request. Either a specific tool like `apply_migration`, or plain English through `backend_chat`.

2. 2

   Planning turns intent into typed actions

   A classifier routes the turn — build, modify, fix, destructive, question — and a planner derives entities, relations, columns, and policies. The output is a plan of discrete actions, not SQL text handed to the database.

3. 3

   The kernel applies it

   `executeAction` is the only path that mutates structure. Every action is validated, audited, and applied all-or-nothing, and schema-mutating actions snapshot the schema before they run so the change can be rolled back to a saved version. An operation outside the vocabulary does not run.

4. 4

   PostgreSQL takes the write

   Into that project's own schema. Grants and row-level security are installed as part of the same change, not as a follow-up someone has to remember.

5. 5

   Verification exercises the result

   Real HTTP against the live runtime: CRUD lifecycle, auth flow, two-user isolation. Evidence comes back with the result.

6. 6

   The autonomy loop takes over

   From here the change is something the loop monitors, and something you can revert.

A language model asked to run twenty interdependent DDL statements will get most of them right. The failure is not dramatic — step fourteen names a column slightly differently than step three assumed, and you get a backend that looks correct and breaks at runtime. Retrying with a better prompt does not fix a class of error that comes from unbounded execution.

So the model plans and the platform executes. `apply_migration` accepts ordinary PostgreSQL DDL and translates it into typed actions; anything it cannot map is refused with the route forward rather than silently dropped. The consequence is a real constraint, and worth stating plainly: operations outside the vocabulary are not available, and a patch that writes DDL around the kernel is rejected in this codebase no matter how correct the SQL is.

What you get for that constraint is that the agent's model of the database and the database itself cannot silently diverge, and every change — from you, from your agent, or from an automated repair — arrives through the same audited door.

Tables are served by PostgREST, reading the PostgreSQL catalog directly. There is no API registry to keep in sync: `/db/<table>` is live the moment the table exists, which is why there is no "generate API" step in the tool surface. Authorization is Postgres grants plus row-level security, so an embedded resource is subject to the same privileges as a direct read.

One consequence is a shape you should expect: requests PostgREST cannot model — nested paths beyond the supported depth, `/search`, `/bulk` — return 404 rather than degrading into something with different semantics. A 404 there is the contract telling you where the boundary is.

A Backenly deployment is two Node processes behind a reverse proxy, against a PostgreSQL instance:

The split matters for a reason that is easy to miss: your app's end-users and your Backenly account are two completely isolated auth systems. Platform sessions are signed with the deployment secret; end-user sessions are signed with your project's own secret and live in your project's schema. They share no tables and no JWTs. An end-user of your app has no relationship to Backenly at all.

After a change lands, a closed monitor-analyze-plan-execute loop keeps watching. It observes telemetry, runs probes for schema drift, missing indexes, slow queries, RLS gaps, broken triggers, and stuck deployments, and proposes fixes in the same typed vocabulary the agent uses.

It runs no language model. That is a design property with two visible consequences: it draws no AI credits on any plan, and it can be run at a one-minute cadence for everyone rather than rationed as a paid feature.

The loop applies only the reversible safe band. Auth changes, external credentials, destructive operations, and anything irreversible always wait for a human — that floor is not a setting. What the loop applies on its own is snapshotted before the fix and revertible afterward. The operations guide covers the dial, the review queue, and the activity gate that decides which projects get a pass.

The honest summary of what this replaces: not the work of deciding what to build, and not the code your agent is good at writing. It replaces the operator — the person who would otherwise own the migration, the policy, the monitoring, and the 3 a.m. page.