The one-click publish flow
Inside the Base44 builder, the Publish button is the whole story for the first deploy. Base44 builds your app, uploads the artifact to its edge network, and returns a Base44 subdomain URL — something like your-app.base44.app — that you can share immediately. The first build typically takes 30 to 90 seconds; subsequent redeploys after prompt edits are noticeably faster because dependency layers are cached. There is no separate build config file to manage; the generation pipeline knows how to build the app it just generated, which is one of the compounding advantages of the AI-first approach.
Connecting a custom domain
Go to Project Settings → Domains and paste the root domain you want to use — for example your-app.com. Base44 will then show you the DNS records to create at your registrar. In almost every case this is an A record for the root ('@') pointing at Base44's edge, a CNAME for 'www' pointing at the same target, and a TXT record for ownership verification. If your registrar uses ALIAS or ANAME records for the apex, use one of those instead of the A record — the effect is identical but the record type is registrar-specific.
DNS propagation
Once you add the records, verification usually completes within a few minutes but can take up to 24 hours to propagate worldwide. Use a tool like dnschecker.org to confirm the records are visible from multiple geographies. Do not delete the old records for your previous host before the new ones fully propagate or you will see an outage in the gap. TLS is provisioned automatically as soon as the ownership TXT record is visible — you do not need to upload a certificate.
Environment secrets
Runtime secrets — API keys, third-party tokens, webhook signing secrets — are stored per project in the secrets panel and injected at request time. Never paste a secret directly into a prompt, because the prompt becomes part of the generated code and would end up committed to your project's source. If a secret does leak into a prompt, rotate it at the upstream provider and remove the reference from the generated code before the next deploy. Base44 will not leak secrets to third parties, but source code you generate is yours to review.
Rollback
Base44 retains recent deploy artifacts, and you can redeploy an earlier version from Project Settings → Deploys. This is the fastest way to recover from a bad prompt that made it into production. Because each deploy is an immutable artifact rather than a re-run of the build, a rollback is effectively instantaneous — no rebuild, no DNS change, no waiting.
Environments and preview deploys
Each project has a production URL and a preview URL. The preview URL always serves the latest build from the builder, so you can iterate against it in real time. The production URL is stable and only updates when you explicitly Publish. Treat the preview like a staging environment: point analytics and error monitoring at it separately if you want clean production dashboards.
Custom-domain gotchas
Three things go wrong most often. First, forgetting the TXT verification record — the domain will appear connected in your registrar but Base44 will not issue TLS until it sees the TXT. Second, keeping stale records from a previous host — mixed A records return random hosts and users see intermittent errors. Third, using Cloudflare's proxy in front of Base44 without setting SSL/TLS to Full — the double-TLS combination causes redirect loops. Turning the Cloudflare proxy off (grey cloud) is the safe default while you verify the setup.
Monitoring the live deploy
Once your app is live, watch two things. The upstream — status.base44.com — for platform-level incidents that would affect your deploy. And your own error monitoring — Sentry, LogRocket, or the browser console during smoke tests — for issues in the generated code itself. base44.health mirrors the official status page and cross-references sister platforms so you can tell at a glance whether an outage is Base44's, your LLM provider's, or your own.