Why this matters
Most Base44 production incidents we audit could have been caught by a 15-minute pre-deploy checklist. The platform's "publish" button is one click and ungated; nothing stops a regression from going to production. Defense is your discipline.
This article is the checklist we run on every client deploy. It is not aspirational. It is the working list, refined over hundreds of real deploys, with explicit go/no-go gates and the rollback procedure for when something goes wrong despite the checklist.
When to deploy
Before the checklist, the meta-rule: control the timing.
- Tuesday–Thursday morning is the safe window. Two business days to respond to issues.
- Never on Friday afternoon. The platform has no SLA and slow support; weekend incidents are expensive.
- Never within four hours of a public holiday. Same reason.
- Hotfixes anytime, with a human on-call and a tested rollback path.
- Routine content (text, images) anytime. Low-risk.
If you must deploy Friday, post in your team channel that someone is on-call through the weekend. If nobody volunteers, the deploy waits to Tuesday.
The pre-deploy checklist
Run every item. Don't skip "the small ones."
1. Code snapshot
Confirm the current Base44 version history has a snapshot of the pre-deploy state. If the deploy goes sideways, this is your code rollback target. If you also mirror to GitHub, push to a deploy branch and confirm the commit hash.
2. Data snapshot for any schema-touching change
If the deploy includes schema changes (added field, removed field, type change), run your snapshot backend function for the affected entities first. We covered this in schema migration best practices. No snapshot, no deploy. This is non-negotiable.
3. AI-agent regression check on critical paths
If the deploy includes AI-agent-generated changes, manually click through the critical paths the agent shouldn't have touched. Login, signup, checkout, payment, password reset. The agent regularly emits changes outside the requested scope; this is your last chance to catch them.
4. Hostile second-account data isolation test
Already covered, but worth repeating. Log in as a fresh account that owns nothing. Click through every list, every detail page, every search. Confirm zero unexpected data appears. This catches the highest-severity bug class in 5 minutes.
5. Webhook signature validation still works
For any deploy that touches webhook handlers or Stripe/payment flow, send a test webhook from the sender's dashboard and confirm your handler accepts and processes it correctly. Stripe's CLI and dashboard both support this. If signature validation has been accidentally removed, you find out now.
6. Security headers intact
If you have a CDN proxy adding HSTS, CSP, X-Frame-Options, run a quick check that those headers still appear on a sample response. A curl -I https://your-domain.com from your laptop is enough. The proxy can be regressed by a config change without anyone noticing.
7. Core Web Vitals hasn't regressed
Run PageSpeed Insights on your top 3 routes. Compare against baseline. If LCP, INP, or CLS regressed by more than 200ms (LCP) or 50ms (INP) or 0.05 (CLS), investigate before deploying.
8. Smoke test the top 5 user flows
Log in, perform the top 5 things a real user does, log out. Every flow. Every step. If any flow is broken, do not deploy. This is 10–15 minutes; the alternative is a customer-reported regression.
9. Backend function deploys completed
If the deploy includes new or changed backend functions, confirm each function shows as deployed in the IDE. Missing or stale function deploys cause the most confusing post-deploy bugs because the frontend looks right but the backend hasn't actually changed.
10. Environment variables verified
Confirm all environment variables (Stripe keys, OpenAI keys, third-party tokens) match the expected values for the target environment. A test-mode Stripe key in production is a common cause of "checkout looks fine but no money arrives."
11. External integrations not interrupted
If the deploy interacts with Stripe, Auth0, Twilio, or other senders, verify that no upstream maintenance or planned outage is happening at the deploy time. Their status pages tell you. Coordinating around upstream events avoids confused troubleshooting.
12. Rollback procedure documented and confirmed
The on-call person knows: how to revert via Base44 version history, how to restore entity data from snapshot, who has access to the CDN proxy. A quick verbal rehearsal — "if X breaks, you do Y" — saves hours when something actually breaks.
13. Communication
Announce the deploy in your team channel. Include: what's changing, the rollback owner, the expected window. If the deploy is customer-visible, also schedule a customer-facing announcement (changelog, email) for after smoke verification.
Post-deploy verification
Within 15 minutes of clicking publish:
14. Deployed code matches expectation
In an incognito window, hit the production URL and verify the new behavior is live. Hard refresh if cached. If the new behavior isn't appearing, the deploy may be partial or cached; resolve before declaring done.
15. Synthetic monitor green
Your external synthetic monitor (BetterStack, Checkly, custom) shows green on all critical endpoints. If any endpoint flipped red within 5 minutes of deploy, investigate before walking away.
16. No new error spike
Sentry, your structured-log dashboard, or your error-tracking shows no new error class introduced. A 2x increase in error volume in the 15 minutes after deploy is a signal to investigate; a 10x increase is a rollback signal.
17. Credit-burn anomaly check
For deploys that touch AI agent prompts, integration calls, or backend functions: verify credit consumption hasn't spiked. A bad prompt loop in a function can drain credits in minutes.
18. Webhook traffic looks normal
Inbound webhook receive rate from the last 15 minutes should match the trailing baseline. A drop to zero suggests routing or signature issues; a spike suggests retries from a previous deploy that broke something.
19. Customer-facing channels quiet
No new tickets, no new Discord/Slack reports. Five minutes of quiet after deploy is encouraging. Twenty minutes of quiet is sufficient for routine deploys.
20. Mark the deploy in your changelog
A simple note in the team's deploy log: timestamp, deployer, summary of changes, rollback target. When something goes wrong tomorrow, this is the data that lets you triage.
Rollback procedure
When the smoke test fails or post-deploy errors spike:
Layer 1: code revert via version history
Open the Base44 IDE, navigate to version history, restore the pre-deploy snapshot. Re-publish. Verify with a smoke test.
This works for code-only regressions. Time to recover: 5–15 minutes typical.
Layer 2: data restore from snapshot
If the deploy included a schema change that broke entity data, restore the entity from the pre-deploy snapshot. This may require running the import side of your snapshot procedure. Test this once a quarter so it works when needed.
Time to recover: 30–120 minutes depending on entity size.
Layer 3: traffic redirect via CDN
If the platform itself is unavailable or the rollback is too slow, your CDN proxy serves a maintenance page or routes to a static fallback. This requires architectural prep — the Worker must exist, the static fallback must be ready, the routing rules must be tested.
Most apps don't have this layer. Larger apps need it.
Communicate
Whatever the rollback layer, tell users. A short status-page post or in-app banner is enough. Silence during outages costs trust faster than the outage itself.
Common deployment mistakes
Skipping the snapshot because the change is "small." The change that didn't need a snapshot is the one that needed one.
Friday-afternoon deploys. Already covered.
Not running the second-account isolation test. Highest-severity bug class hides from solo testing.
Trusting "deploy complete" without smoke testing. The publish button is the start of the deploy, not the end.
No external smoke monitor. First signal of a bad deploy shouldn't be a customer email.
No documented rollback owner. When the on-call person isn't sure who can revert, the rollback takes hours instead of minutes.
Treating "the platform deployed" as "the change is live." Caches, partial deploys, and routing quirks can leave you in a half-deployed state.
Stale staging. A staging environment that diverges from production over time loses its value.
Pre-deploy checklist (printable)
- Code snapshot in version history
- Data snapshot for any schema change
- AI-agent regression check on critical paths
- Hostile second-account data isolation test
- Webhook signatures verified
- Security headers intact via proxy
- Core Web Vitals not regressed
- Top 5 user flows smoke tested
- Backend functions confirmed deployed
- Environment variables match target environment
- No upstream provider maintenance scheduled
- Rollback procedure rehearsed
- Team announcement posted
Post-deploy checklist (printable)
- New behavior visible in production (incognito)
- Synthetic monitor green on all critical endpoints
- No new error class in Sentry / log dashboard
- Credit-burn rate normal
- Webhook traffic at baseline
- No new customer-facing reports
- Deploy logged in changelog
Want us to set up your deployment process?
Our $497 audit reviews your current deployment hygiene, identifies gaps, and produces a written deploy/rollback procedure tailored to your app. For implementation (CI proxy, smoke monitors, snapshot infrastructure), we run a focused engagement after the audit. Order an audit or book a free 15-minute call.
Related reading
- Base44 Production Readiness Guide — the eight-pillar readiness picture, of which deployment is one pillar.
- Base44 Schema Migration Best Practices — the snapshot-and-rollback procedures referenced above.
- Base44 Performance Optimization Guide — the Core Web Vitals work that compounds with deployment hygiene.