The Bubble go-live checklist

Deploying a web app is not one button. It’s one button at the end of a list, and the list is what separates a live product from a prototype with a public URL: the domain, the API keys behind your address searches and emails, the favicon, the page titles, the security pass, the plan, the backup. None of it is hard; all of it is forgettable, which is exactly why it belongs on a checklist you run every time.

This is the checklist we teach, in the order we run it: add the domain name, configure the Google Maps API keys, configure SendGrid and its legacy template, add the favicon, review page naming and SEO fields, review security, back up the app, choose a paid plan, then deploy, and start measuring whether anyone actually uses the thing.

A go-live checklist is the ordered set of configuration, security and housekeeping tasks that turn a working test app into a legitimate live product: no loose wires hanging out of the wall, everything tidied, wrapped and ready for real users.

1. Add your custom domain

In Settings, open Domain and email and enter your domain name. Bubble responds with a set of A records (a type of DNS record) pointing to its IP addresses; add these at your DNS provider, then come back and hit “check my settings”.

A little mental model helps here. DNS is a giant phone book that maps meaningful names to the IP addresses of the servers handling the traffic. The entry without www is the naked domain, and providers write it differently: some want an @ symbol, others accept an empty host field. www is technically a subdomain and gets its own records pointing at the same app. If you’re deploying to a subdomain like app.yourdomain.com, you enter four records instead of eight. On GoDaddy specifically, delete the default CNAME records it pre-creates, or they’ll fight your new settings.

Then comes propagation: your records live at your provider and get copied out to DNS servers at ISPs all over the world. The first “check my settings” often reports bad DNS records, which is frustrating but normal; three or four minutes later it usually passes, and the domain itself may take a few more minutes to resolve. Changes made after that first success propagate more slowly, sometimes thirty minutes, an hour, or a day, because every server already holds a cached copy. The TTL (time to live) setting on your records controls how often those servers re-check, so a shorter TTL, say 600 seconds, makes changes land faster. When in doubt, mxtoolbox will show you how your DNS is propagating from anywhere in the world, and every DNS provider has a support chat that answers syntax questions quickly. You’re done when Bubble reports the domain is working and ready to go.

2. Add Google Maps API keys

In Settings, the general services API keys section wants a server key and a client key. These power every geocoded address search in your app, those dropdowns of matching addresses under a search box. Bubble covers a small free allowance during development but requires your own keys before you deploy live, reasonably enough, since it doesn’t want to pay for the world’s API calls.

Getting the keys means creating a Google Cloud account, adding payment details, and creating the keys in the API console; it’s a bit technical, and Bubble’s own video tutorial and documentation linked from that settings section are genuinely good, so follow them. If your app uses no geographic address fields at all, type placeholder text such as server and client into the two boxes to satisfy the issue checker; visible placeholders beat the old trick of entering a space, which left you unable to see anything was there at all.

3. Add your SendGrid API key

SendGrid is Bubble’s default email provider: the send email action, password resets and confirmation emails all go out through it. The free tier allows a low number of sends; the roughly USD 15/month plan sends plenty but caps you at about two users; the professional plan at around USD 100/month adds roughly a thousand users, higher volume and sub-accounts, which let an agency host several client apps under one account with billing and usage separated. (You can use another provider via a plugin or API call, but SendGrid is the paved path.)

In your SendGrid account, go to Settings, then API keys, and hit the create button. Name the key after your app, and look at the permissions options: SendGrid lets you scope exactly what the key can do, a welcome chance to apply the rule of least privilege in a world where most APIs just hand out full access. Create and view the key, copy it immediately, and paste it into the SendGrid box in Bubble’s domain and email settings. Note that this section only appears once your custom domain is working, which is why the domain is step one.

4. Configure a SendGrid legacy template

Without a template, Bubble’s system emails go out as plain text. Bubble still sends through SendGrid’s legacy templates, which are disabled by default and accept just one merge parameter, a body tag, rather than the handlebars-style fields of modern templates.

Enable them under Mail settings (the option sits right at the bottom), then open Legacy templates in the email templates menu and create one. The HTML editor works like any email builder, or paste your own HTML; the only requirement is that the body tags are present, since that’s where Bubble injects the content of each email. Add a header, a footer, contact details or social icons around it. Copy the template’s ID into the template ID field in Bubble, set the from address (which doubles as the app’s admin email, available in expressions as the app admin email) and the sender name, and every reset-password, confirm-email and send-email action now arrives dressed properly.

5. Add a favicon

The favicon is the little icon in the browser tab. It seems trivial, but it’s part of presenting a complete app. Upload it in Settings under the general tab. The format is a 64 by 64 pixel image, so keep the artwork radically simple: a letter or an app-icon-style square, working to the full margins rather than leaving white space around the edges. Look at the favicons in your own tab bar and match their simplicity; a complicated icon at that size just reads as noise.

6. Review page names and SEO settings

In Settings, the SEO and meta tags section sets app-wide defaults: title, site name, description and the thumbnail used for links. Fill in all four so no page ever falls back to Bubble boilerplate. The link thumbnail uses the Open Graph standard, and 1200 by 630 is the dimension that renders well when someone shares your URL in Slack or a social feed.

Then configure individual pages, because the defaults are a floor, not a finish. Every public or shareable page deserves its own title and description, and there’s a less obvious reason to care: the page title is what gets logged to Google Analytics, so vague names, or three different names for the same page because you kept changing your mind, will pollute your acquisition reports forever. Pick meaningful names once. For dynamic pages, such as a public product or blog article, put dynamic values into the title, description and even the image, so each record presents itself properly.

7. Review security

The full security discipline has its own module, but the pre-launch pass hits these points:

1. Set application rights to private app in the general tab. Anything looser exposes your editor, and with it your API keys and data, to the world; people genuinely do this by accident.
2. Change the test version’s username and password protection from the defaults to something real, with “do not apply password to live” ticked so only the test version is gated. Keep the inverse up your sleeve: applying that password to live (and deploying) is the fastest way to take your app offline in an emergency.
3. Walk the privacy rules tab systematically and confirm every rule looks the way you expect.
4. Check API workflows: are any set to public that don’t need to be? Check API settings: is the Data API enabled, and if so, are only the intended data types exposed?
5. Confirm every page sits behind a security container that shows content only to logged-in, adequately privileged users.
6. Review the page list and delete test pages (“test proof of concept”: delete), or put them behind security containers if they must stay.

8. Choose a plan

The free plan can’t deploy live and throttles anything at scale; it’s for having a play. The Starter plan suits low-usage apps: we run several sites and small internal tools on it, each seeing perhaps twenty to a hundred hits a day, and at around $32 a month it’s the right home for that traffic. The Growth plan is the serious step: ten development branches with full version control, more workload capacity, and the right starting point once you have a production app under continual change or multiple developers on different features.

Agencies should also know about the agency plan (about USD 85/month, signed up via Bubble’s agencies page). Agency apps get most Growth features but can’t deploy live; the model is build-and-hand-over. The quieter benefit is that agency-plan users don’t count toward a client app’s collaborator limit, so a client can stay on Starter with two or three of your developers attached, and the plan includes access to Bubble’s agency marketplace for proposals and listings.

9. Duplicate the app

Before deploying (and before any client handover), take a snapshot. Select the app on your Bubble homepage, click duplicate app, and say yes when it offers to copy the database: your test data and content data are what make the copy usable, and the process takes under a minute. The duplicate is a save point. Months later, when someone has reworked a workflow and you need to see how the old expression worked, you can open the snapshot and even copy workflows, UI and data back across between apps.

10. Deploy live

The moment itself is pleasingly small: click the branch button (main), hit deploy to live, and Bubble runs its checks and ships. Then immediately go and use the live version; a button offers to view it, or switch the editor to live and preview (removing debug_mode=true from the URL). This matters because live is a different environment: the new domain can break an external API connection, and anything hard-coded to a test URL now points at the wrong world. The vaccine, worth adopting app-wide, is the website home URL expression instead of hard-coded URLs, so the app always addresses itself correctly in both versions.

11. Measure user adoption

There is no point developing an app that no one uses, and finding out is a discipline, not a feeling. Pick your goals: customer discovery (what do these people actually want?), evaluating marketing, understanding engagement, and identifying usability issues. Discovery humbles everyone. We once built a health-sector reporting tool for about ten users; two or three adopted it, and the rest kept printing manual reports and transcribing them into A3 paper diaries. A client building a recruitment platform spent serious money on a talent-search feature before learning their key demographic just wanted to post jobs. Interviews and qualitative data before and after launch prevent expensive versions of those stories, provided you watch for confirmation bias and recency bias while listening.

The tool categories: digital analytics (Google Analytics, Amplitude) for traffic, acquisition, sessions and events; session replay (Hotjar) for heatmaps and recorded journeys; digital adoption platforms for user-level tracking plus in-app onboarding tours and chat widgets like Intercom’s; and customer data platforms (Segment) that capture user-level actions and pipe data onward. Start with Google Analytics: it’s free and gives you the baseline, though it’s deliberately de-identified, so you’ll never see what a specific user did. Create a property, grab the tag ID, and install a Google Analytics plugin in Bubble; we prefer the Copilot one because it tracks events, not just page views, so form submissions and key navigations become data. The strongest setup pairs GA with your own audit logging: analytics for the aggregate picture with nice charts, audit logs for the specific user trail you can export quarterly and analyse in a spreadsheet for yourself or your stakeholders.

This skill in the AI era

Launch discipline outlived the tool that taught it. Every AI-built site we ship runs the same gauntlet: DNS and TTLs, email deliverability, per-page metadata, a security pass, a backup, then analytics from day one; Claude Code can automate the configuration, but the checklist thinking has to come from a human who’s been burnt before. Domains, propagation and redirects are half of what makes website migrations succeed or fail, and it’s the same knowledge you’ve just read. For how the rest of the Bubble skill set translates, see from Bubble to AI coding.