Deploys
Production changes only by a deploy: a copy of development's files at that moment, built and published at the production address. No data is migrated.
What a deploy does
- Copy. Development's files are copied into production as a new production file version, recording which development version it came from and which files changed. Pushes and deploys queue behind each other, so the copy is consistent.
- Build. Production is built from that version, with production's environment variables. Next.js type-checks the pages.
- Publish. When the build is ready, the router serves it at
<app>.inferencebureau.app. If it fails, the version that was live stays live. - Release to Shopify. For a Shopify app, production's Shopify app gets production's configuration and storefront blocks once the build is live. New scopes are approved by merchants on their next visit.
Each deploy is a deploy event in production's Logs, followed by its build. Settings → Deploys lists every deploy with how its build went. Your webhooks get deploy.succeeded or deploy.failed.
The deploy plan
Deploy in development's top bar opens the plan. Nothing changes until you choose Deploy on it. It shows:
| Part | What it lists |
|---|---|
| What will happen | The steps in order, marked Automatic or You: creating production's Shopify app if it's missing, copying files, reading records with the new schemas, building, and installing on the merchant's store if it isn't yet. |
| Model changes | Each field added, removed, renamed, retyped, newly required or newly unique, and each model added or removed, with what production's records will read like and how many of them each reaches as they're stored now. Records that a new required or unique rule finds empty or shared, and values a retype can't convert, also show as warnings at the top. None of them blocks the deploy. |
| Review readiness | Public Shopify apps only: what Shopify's app review checks, read from the app as it stands. It never blocks a deploy. See Custom or public. |
| Problems in development | Schemas that can't be read, a dev server that didn't start, and Shopify scopes that need protected-data approval. |
| Changes | Every file added, changed or deleted since the last deploy. |
Schema changes
Production reads its records through production's schema files, so a schema change takes effect the moment the new files go live. No DDL runs and no record is rewritten: a new field reads its default, a removed field is hidden with its values kept, a renamed field keeps its storage key, and a retyped field converts as it is read. See Changing a schema.
Production's records are the live app's data. A field that becomes required applies to the next write of each record, so make sure the app's code fills it before deploying the change.
From the CLI
In a linked folder, ib-apps deploy syncs first (so what ships is what's on your disk), then deploys and follows the build until it's live or failed. Elsewhere, pass --app <slug>. It needs a sign-in or a key with Apps Permissions: a key linked to one app can sync it but not deploy it.
$ ib-apps deploy
reviews · development v42 → production (3 files changed)
Building…………
✓ Live in production in 74s: https://reviews.inferencebureau.appA deploy with no file changes rebuilds the same files, which is how production picks up a changed environment variable.
A deploy is refused, with the reason, while the team's apps are in their grace period or paused, and on the Free plan for a second app: Free has one production app. See Plans and usage. Builds and deploys aren't billed.
The first deploy
The first deploy creates production: its files, records (empty), event log and address. For a Shopify app, production needs its own Shopify app (created with the development one by default, or from Settings → Shopify) and an install on the merchant's store, which the plan lists as steps for you.
Rolling back
Roll back to this on a row of Settings → Deploys points production at that deploy's build: its pages and actions, with the variables it was built with. Production's files stay as the latest deploy left them, so the records API keeps reading the latest schemas, and the next deploy builds development's current files as usual.