Publishing, domains, backups and rollback

When your app is ready, publish it. It gets a public link straight away and can move to your own domain with HTTPS set up for you. Every publish is verified, snapshotted first and recorded, so a bad release is one step from being undone.

Publish

1. From your agent: deploy with a subdomain. From a terminal: appbricx deploy --subdomain stillwater. In the builder: Deploy.
2. Appbricx runs verify, snapshots production, applies the schema changes and builds the app.
3. The app is live at https://<subdomain>.apps.appbricx.com.

$ appbricx deploy --subdomain example-bookings
✓ deployed: https://example-bookings.apps.appbricx.com (live)

The preview keeps changing while you work; the published app only changes when you publish again.

What a publish changes

• Additive schema changes are applied to production: new tables, columns and indexes. Rows are kept.
• Destructive changes wait (dropping a column or table) until you publish with allowDestructive.
• Hand-made objects travel too: indexes, views, functions, triggers, enum types, constraints and policies you added in dev with SQL are carried to production in dependency order. See operating your app.

Use your own domain

1. Publish once, then open the project's Settings, Custom Domain and add a hostname such as book.stillwater.studio.
2. Create the DNS record it shows, usually CNAME book → sites.appbricx.com.
3. Wait for DNS (dig +short CNAME book.stillwater.studio), then click Verify. A certificate is issued on the first HTTPS visit.

• Apex domains (stillwater.studio): use an A record to the IP shown in Settings, or an ALIAS / flattened CNAME to sites.appbricx.com.
• Cloudflare: set the record to DNS only (grey cloud) unless Settings shows a tunnel target.
• A project can have several domains; the apps.appbricx.com link keeps working.
• Custom domains depend on your plan. See pricing.

Backups

• A full database snapshot is taken before every publish, before any hand-made change to production data (from the builder or an agent), and whenever you take one by hand.
• The last 30 are kept.
• Backend, Backups lists them with when and why each was taken ("Before publish", "Before a production edit", "Taken by hand").

Roll back

Data

1. Open Backend, Backups with the Prod switch on.
2. Pick the snapshot from before the change and click Restore, then confirm.

Agents: snapshots with { "action": "restore", "env": "prod", "id": "…" }. CLI: appbricx snapshots restore <id> --env prod.

A deploy

Backend, Backups, Deploy history lists every deploy. Roll back to this deploy serves that release again. Agents: deploys with rollback. A deploy rollback switches the served files; restore a snapshot to undo data.

Demo apps that reset every night

Publishing a public demo with shared logins? Deploy with "demoReset": true. Every night production is put back to the preview's data, visitor sign-ups are removed, demo passwords are restored, and every date and time is moved forward by the time since the data was seeded, so "tomorrow's class" is still tomorrow. The tutorial's booking app runs this way.

Gotchas

• A restore replaces everything written after the snapshot. A fresh snapshot is taken first, so a restore can be undone, but restore soon and tell your users.
• Subdomains are first come, first served. A taken name answers SUBDOMAIN_TAKEN.
• Origin errors after adding a domain? Click Verify once more (or publish again) so the domain is added to the app's allowed origins.

Related

• Verify
• Operating your app
• Export and self-host