Base44 gives you branches with their own preview, test data on the Builder plan and up, and one-click publishing of a previous version from Version History, but nothing runs your tests or blocks a bad publish — so pre-deploy verification is your discipline. The 20-step checklist: snapshot the codebase and entity data, run a smoke test on a branch preview or a fresh second account, verify Core Web Vitals haven't regressed (LCP, INP, CLS budgets), confirm no AI-agent regressions on critical paths like login and checkout, validate webhook signatures still work, check security headers are intact, run a hostile second-account data-isolation test, confirm backend functions are deployed, verify environment variables match the target environment, and have a documented rollback procedure rehearsed before deploy. Skipping any single step is what causes the "deployed Friday, paged Saturday" incidents.
Why this matters
The platform's "publish" button is one click. On Business and Enterprise, workspace admins can limit who may publish and approve publish requests, and the publish panel shows your security scan status, but nothing runs your tests or stops a regression from going to production. Defense is your discipline: a 15-minute pre-deploy checklist that catches the regression before your users do.
This article, written by the lead engineer at Base44Devs, is the checklist we run on every client deploy. It is not aspirational. It is the working list, 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. There is no uptime SLA below Enterprise, and support response times vary with ticket volume; 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, and note that once GitHub is connected, Version History can only restore versions that exist in the connected repository. Then open Compare with live code (the More actions menu at the top right of the editor), which lists every file that differs from your live app.
2. Data snapshot for any schema-touching change
If the deploy includes schema changes (added field, removed field, type change), make sure you can restore the affected entities first: Backup & Restore keeps point-in-time backups on Elite (7 days) and Business or Enterprise (30 days); below Elite, 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 and CSP (Base44 does not let you set those per app), and X-Frame-Options and Permissions-Policy set in Base44's Browser Security settings, 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. Base44's testing agent can run these flows as browser tests from the editor (all plans; a run uses about 1 to 4 credits). It signs in by itself and cannot yet test the login form, OTP codes or email-verification links, so do those by hand.
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. Know the split: redeploying a function updates the preview, while your live app keeps the version from your last publish, but automations and workflows run the redeployed version straight away.
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." Base44 keeps one set of secrets for main and every branch, so there is no separate test value for a branch preview.
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. This step is also where you catch editor-to-production parity failures — behavior that looked correct in the IDE but breaks once live.
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 Version History (the clock icon at the top of the AI chat), click the last good version to preview it, then choose Publish this version from its More actions menu: it goes live while your current draft stays open in the editor. Revert to this version replaces the draft instead, and you would then publish again. 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. On Elite, Business or Enterprise, Backup & Restore can put one table or every table back to a point in time, and a restore can be undone; restores run on production data only. Otherwise 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 branches. A branch that falls behind main tests the wrong app. Update it from main (the update card above the chat box) before you test and merge.
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 (proxy and Browser Security)
- 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.