AppbricxDocs
PricingStart free

Start here

OverviewShip your first app with your agentBuild your first app in the browserBuild and change your app in the editor

Build

Describe your app in one fileAdd your own screens and brandUse your data from ReactConnect any MCP clientLet your agent into your workspaceBuild and deploy from your terminalAutomate with the HTTP APIUse your own AI keyWhich AI key is used

Data

What your app runs onREST API for your dataNamed queriesGive each user the right accessEnforce your business rulesFiles and paymentsData templatesKeep secrets safe

Logic

Run work in the backgroundConnect services and schedule jobsLive updatesConnect other appsAdd AI to your app

Sign-in

Let your users sign in

Ship and own

How every release is checkedPublish on a live linkBackups and rollbackUse your own domainTake your code with youRun in your own cloud

End-to-end walkthroughs

Lead intakeMulti-user TodoMulti-tenant SaaSSlack on signup

Developers

Developer guide

Backups and rollback

Shipping should never put your users' data at risk. Appbricx takes a snapshot of your production data before every publish, keeps the last 30, and lets you roll back in one click. Releases have their own history too, so a bad deploy is one step from being undone.

What is protected

  • A snapshot before every publish. A full database dump (pg_dump) is taken automatically before changes reach production.
  • The last 30 kept. Older snapshots roll off, so you can go back across many releases.
  • One-click rollback of data. Restore a snapshot and your production data returns to that point.
  • Deploy history. Every deploy is recorded, and you can roll back to an earlier one.

Publishing never drops data by accident

Your app has separate development and production databases. When you publish, Appbricx compares the two schemas and applies only additive changes to production: new tables, new columns, new indexes. A change that would delete data, such as dropping a column or a table, is held back unless you explicitly allow destructive changes for that publish (allow_destructive on the MCP deploy tool). Even then, the snapshot is taken first.

Roll back

Data

  1. Open the project in the editor and go to Backend → Production check. The database backups list shows each snapshot, when it was taken and why (for example, before a publish).
  2. Pick the snapshot taken before the change you want to undo.
  3. Click Restore. For production you confirm by typing restore.

A fresh snapshot is taken before the restore, so a restore can itself be undone. Anything written after the snapshot you restore is replaced, so roll back soon after a bad publish and tell your users if recent changes are lost. You can also take a snapshot by hand at any time from the same list.

A deploy

Open the Publish dialog and show the deploy history. Pick an earlier deploy and roll back to it. Your published link serves that release again.

Checked on every release

Verify checks that a backup exists as part of its data stage, so you know there is a way back before you ship.

Running it yourself? On a self-hosted install you own the database and its backups. The self-host guide covers scheduled dumps and off-site copies.

Related: Publish on a live link · Verify · Take your code with you

Appbricx

The backend, runtime and hosting for apps your coding agent builds. On our cloud, or run by us in yours.

Product

For coding agentsShowcaseHow it worksCapabilitiesPricingPrivate cloudBYOKFAQ

Resources

DocumentationBlogFor freelancersFor agenciesSupport

Company

ContactPrivate cloud / agencyPrivacyTerms

© 2026 Appbricx. All rights reserved.

TermsPrivacyCookiesAcceptable Use