Deploy Topology
Deployment ordering, environment matrix, and why deploys are not atomic.
Matrix
| Env | Convex | Dashboard | Mobile |
|---|---|---|---|
| Production | precious-rat-335 | Vercel production (from main) | APP_ENV=production store build |
| Staging | agile-corgi-641 | Vercel previews (from staging) | APP_ENV=staging internal APK |
| Development | agreeable-canary-738 | next dev | dev client / simulator |
Ordering
Backend first, then dashboard. The dashboard bundles Convex response-type expectations; a backend deploy that lands second can 500 the dashboard in the gap. This is also why storage upload args are all optional by design — a required arg would break every running dashboard build during the deploy window.
Mobile ships through EAS and is always weeks behind — which is why backend changes must stay backward compatible (add fields first, remove last; see The Type Contract).
Non-atomicity rules of thumb
- New Convex function: deploy anytime; clients adopt when they update.
- New field: add optional → deploy → ship clients reading it → only then make it required.
- Removed/renamed field: ship clients that no longer read it → wait out the fleet → only then remove server-side.
- Webhook topics: deploy the backend before registering (see Webhook Pipeline).
The shared Shopify store
Every deployment writes to the same live Shopify store (see Environments). Voucher codes created from a staging dashboard appear in the live store's discount list. Rollback helpers exist (removeVoucherCodeFromShopify, pool purge) — know where they are before your first Shopify-touching change.