Your prototype has users. Nobody is operating it.
Bring an existing schema under governance (REST, policies, monitoring and an audit trail) without a rewrite and without giving up direct database access.
- Who this is for
- Teams whose AI-built product now has real users
- What you already have
- A working product and live data
- What you need
- An operator, not a rebuild
The problem
The tools that got you here optimised for generating, not operating. A builder provisioned a database, an agent wrote the schema in bulk, and it worked. Now there are real users, real rows, and real consequences, and nobody owns the migration that breaks, the policy that leaks, or the error spike at 2 a.m. The thing that made you fast quietly made you on-call.
What you would normally build
Either you hire the operator, or you rebuild on something governed and pay for the migration in downtime and lost data fidelity. Both are expensive at exactly the moment the product starts working.
What Backenly does
Connect
Take a direct connection string
get_database_credentials returns a real PostgreSQL connection string for the project schema. Read-only is SELECT-only and provisions on request with no human in the loop. Read-write is returned only after the project owner arms it in the dashboard, and every response reports whether write access exists so an agent can check without requesting it.
Migrate
Run your own migrations if you want to
psql, an ORM, your existing migration tool. DDL you run over the read-write connection is observed by the drift watch rather than fought.
Adopt
Reconcile the schema into the governed contract
adopt_external_schema registers new tables with their REST surface, RLS, and realtime, refreshes altered ones, prunes dropped ones, re-baselines the schema snapshot, and re-syncs grants. It is bookkeeping only and never executes DDL.
Verify
Prove the access rules actually hold
The isolation check creates a second end-user, signs in, and asserts they receive zero of the first user's rows. On an inherited backend this is usually the first time anyone has tested that behaviourally rather than reading the policy text.
Operate
The loop takes the night shift
One-minute cadence on every plan. It applies the reversible safe band and queues auth, credential, and destructive changes for you, with a receipt and an undo where the engine can honour one.
What you end up with
The same PostgreSQL, now with a REST surface derived from the catalog, policies you can read, verified isolation, monitoring on real traffic, and a change ledger. When an engineer joins, they inherit standard Postgres and REST with a history, not a mystery. pg_dump still works, in both directions.
Who owns what
Backenly does
- Provisions scoped Postgres roles through SECURITY DEFINER functions, read-write only after a human arms it.
- Reconciles out-of-band DDL into the governed contract without executing DDL itself.
- Verifies cross-user isolation behaviourally and shows the evidence.
- Monitors real traffic and repairs the reversible safe band, with everything else queued.
You own
- The data migration itself, and choosing when to cut over.
- Re-authoring access rules that were previously enforced in application code.
- Approving anything the loop queues rather than letting it sit.
- Product decisions. The loop fixes operational problems, not product ones.
What this is built on
The tools, routes and modules involved, by name, so you can go and check each one.
| Capability | What it does here |
|---|---|
| get_database_credentials | Read-only on demand; read-write only after the owner arms it in the dashboard. Carries readWriteArmed and an arming URL. |
| adopt_external_schema | Registers, refreshes, and prunes to match reality. Never emits DDL. Dispatchable but not advertised: ask for it by name. |
| Drift watch | Observes schema changes made outside the governed path so they can be reconciled rather than silently diverging. |
| Behavioural verification | CRUD lifecycle, auth flow, two-user RLS isolation, and live HTTP checks, each returned with its evidence. |
| Autonomy loop | One-minute cadence on every plan, uncapped, applying only reversible snapshotted changes on its own. |
| pg_dump export | Full export of your workspace schema at any time, so adoption is reversible. |
Known limitations
Where this workflow stops. If one of these is load-bearing for you, it should decide it.
- Adoption is reconciliation, not a migration tool. Moving the data is your job; Backenly makes the resulting schema governed.
- adopt_external_schema is not on the advertised 20-tool surface. Reach it through backend_chat by name.
- Structure mutates only through governed actions afterwards. If your workflow depends on arbitrary DDL from application code, that path is closed by design.
- Deployment rollback and full deployment history are plan-gated and not available on Free. Check the pricing page before relying on them.
- The autonomy loop sweeps a project that shows a sign of life within 30 days: traffic, a governed change, or a conversation. A completely dormant project is not being checked.
Common questions
No. Your tables are served over REST from the catalog, and if the frontend was written against supabase-js there is a compatibility entry point that emits PostgREST directly. What usually does change is authorization: rules previously enforced in application code become row-level security policies in the database.
Yes. Take a read-write connection string once the owner arms it, run your migrations, then reconcile with adopt_external_schema so the platform and your schema agree. If you only need to inspect or export, a read-only string is provisioned on request without any arming step.
Take a full pg_dump of your workspace schema whenever you want. The platform is also open source under Apache-2.0, so self-hosting the same codebase is an option rather than a negotiation.
Try it on one free project
No credit card. Connect your agent over MCP and judge it by the verification evidence.