How to Quickly Create and Run a Bubble.io Subdomain: Ultimate Guide 2025

Meta Description: Learn how to quickly create and run a Bubble.io subdomain for your app in this step-by-step guide. We cover domain setup, DNS configuration, SSL, and troubleshooting to get your Bubble.io app running on a custom subdomain fast and securely.

Outline:

Introduction – Overview of running a Bubble.io app on a subdomain and why it matters.

What is a Bubble.io Subdomain? – Definition of subdomains and how Bubble uses them.

Why Use a Subdomain for Your Bubble App – Benefits of using a custom subdomain (branding, separation, SEO considerations).

Prerequisites and Requirements – What you need before starting (domain name, Bubble plan, DNS access, etc.).

Preparing Your Domain and Subdomain – Choosing a subdomain name and setting it up in your domain registrar’s DNS settings.

Step 1: Add Your Subdomain in Bubble.io Settings – Entering the subdomain in Bubble app settings and enabling SSL.

Step 2: Configure DNS Records for the Subdomain – Adding A records (or CNAME) in your DNS provider to point the subdomain to Bubble.

Step 3: SSL and Security on Bubble – Ensuring SSL encryption is enabled for HTTPS on your subdomain.

Step 4: Deploying Your Bubble App Live – Pushing your Bubble app to the live version so it runs on the custom subdomain.

Step 5: Testing the Subdomain – Verifying that your Bubble app loads correctly on the new subdomain (and using /version-test for development mode).

DNS Propagation and Wait Time – Understanding DNS propagation delays (usually within minutes to hours, up to 24 hours).

Troubleshooting Common Issues – Solving problems like “Bad DNS” errors, propagation issues, or SSL certificate problems.

Tips for a Quick and Smooth Setup – Best practices (e.g. using a CNAME shortcut, double-checking entries) to speed up the process.

SEO Considerations for Subdomains – How using a subdomain might affect SEO and tips to maintain good SEO.

Maintaining Your Subdomain and App – Ongoing management, making further changes, or adding more subdomains via Bubble’s sub-app feature.

Frequently Asked Questions (FAQs) – Answers to common questions about Bubble.io subdomains (paid plans, multiple subdomains, etc.).

Conclusion – Final thoughts on creating and running a Bubble.io subdomain, emphasizing ease and benefits.

Introduction

Launching your Bubble.io application on a custom subdomain is an excellent way to present a professional image and integrate your app with your brand. Bubble.io, a popular no-code web application builder, allows you to use a custom domain or subdomain for your app instead of the default Bubble domain. In this guide, we’ll walk through how to quickly create and run a Bubble.io subdomain for your app. We’ll cover everything from prerequisites to step-by-step setup, including domain configuration and troubleshooting. By the end, you’ll see that deploying a Bubble app on a subdomain is straightforward and achievable, even if you’re not a DNS expert. Moreover, this approach lets you keep your main website and your app under the same overall domain, giving users a seamless experience while helping you organize different sections or functionalities of your website or app.

Bubble.io provides a default domain for every app (usually something like yourapp.bubbleapps.io), but using a custom subdomain like app.yourdomain.com can make your app look more polished and trustworthy to your audience. For example, if your main website is on yourdomain.com, you might run your Bubble app on app.yourdomain.com or portal.yourdomain.com. This keeps your branding consistent and avoids confusing users with a strange URL. In a nutshell, our goal is to connect your Bubble application to a subdomain you own, so that when users visit that subdomain, they see your Bubble app running smoothly. We will use an optimistic, step-by-step approach – it’s not rocket science, and with the right guidance, you’ll have your Bubble.io subdomain up and running in no time.

Before diving into the steps, we will clarify what subdomains are and why they are useful for Bubble apps. Then we’ll list what you need (don’t worry, it’s not much) to get started. With preparations in place, we’ll proceed through 5 simple steps to create and run your Bubble.io subdomain. We’ll also discuss some tips, cover potential pitfalls, and answer frequently asked questions. Let’s get started on bringing your Bubble app to a custom subdomain quickly and effortlessly!

What is a Bubble.io Subdomain?

A subdomain is essentially an extension or subdivision of your main domain name. In the Domain Name System (DNS) hierarchy, any domain that is part of a larger domain is called a subdomain. For example, if you own example.com as your main domain, you could create subdomains like app.example.com, blog.example.com, or portal.example.com for different purposes. In our context, a Bubble.io subdomain refers to using a subdomain of your own domain to host your Bubble application. Instead of using Bubble’s default domain (yourapp.bubbleapps.io), you map your app to something like yourapp.yourdomain.com.

Bubble.io fully supports running your app on a custom subdomain as long as your plan allows custom domains. Each Bubble app can be connected to one custom domain (which can be a root domain or a subdomain) at a time. This means if you want one Bubble app on example.com and another on app.example.com, you would typically set those up as two separate apps in Bubble (or use Bubble’s sub-app feature for multiple subdomains). The key point is that Bubble treats subdomains just like any other custom domain – the platform doesn’t differentiate much whether your custom URL is the main domain or a subdomain. It will serve your app on whatever domain you configure, after you prove ownership via DNS settings.

From a technical standpoint, a subdomain functions by having a DNS record (usually an A record or CNAME record) that directs that subdomain to the server where your site/app is hosted. In our case, Bubble is the host, so we’ll set DNS records to point the subdomain to Bubble’s servers. Bubble then knows which app to load based on the domain name requested. Simply put, app.yourdomain.com will become an alias for Bubble’s servers to load your specific application. Files uploaded to your Bubble app are stored on external services such as S3 or AppForest, not directly on your domain.

One advantage of using a subdomain for your Bubble app is that it allows you to separate concerns. Your main website (which might be built with another platform like WordPress, Webflow, or anything else) can stay on the primary domain (www.yourdomain.com or yourdomain.com), while your Bubble app runs on a subdomain. Users visiting the subdomain will directly interact with your Bubble application, and they might not even realize it’s hosted on Bubble – it’s completely under your domain name’s umbrella. This creates a cohesive user experience where everything appears to be part of the same overall website, even if under the hood the subdomain is served by Bubble’s infrastructure.

In summary, a Bubble.io subdomain is just your Bubble application accessible via a custom subdomain URL that you choose. It leverages the concept of subdomains in DNS to route traffic to Bubble’s platform. Next, we’ll discuss why you might want to do this and how it benefits you and your users.

Why Use a Subdomain for Your Bubble App

You might be wondering why go through the trouble of setting up a subdomain for your Bubble app when Bubble already gives you a free bubbleapps.io address. There are several compelling reasons to use a custom subdomain:

• Branding and Professionalism: Using your own domain (or subdomain) makes your app look professional. Users seeing app.yourdomain.com will trust it more than a generic Bubble URL. It reinforces your brand identity and shows that your app is an integrated part of your online presence. This is especially important if you already have an established website – the subdomain feels like a natural extension of it, whereas a completely different domain might confuse users.

• Separation of Concerns: If you have a marketing site or main website on your root domain (for example, a marketing homepage on yourdomain.com), you can host that separately (maybe using WordPress or another no-code tool), and run your actual web app on a subdomain like app.yourdomain.com. This separation means you can use the best platform for each purpose – perhaps a traditional site for content and SEO, and Bubble for the web application functionality – without interfering with each other’s setup. In fact, it’s common practice to put apps or client portals on a subdomain while keeping the main site on the primary domain.
• Avoiding Conflicts with Existing Sites: Many users already have a website running on their main domain. By choosing a subdomain for Bubble, you won’t disturb the existing site. The Bubble forum has examples of people doing exactly this – they keep their primary site intact and simply add a subdomain for the Bubble app. Since DNS allows different subdomains to point to different servers, you can run Bubble on a subdomain while another host/server runs the main site. This way, you add new functionality without rebuilding your whole website.
• SSL and Security: Bubble provides SSL encryption for custom domains (including subdomains) at no additional cost. This means when you set up your subdomain with Bubble, it can automatically get an HTTPS certificate. Your subdomain will be secure (https://subdomain.yourdomain.com) which is crucial for protecting user data and gaining user trust. Customers and users benefit from secure (TLS/SSL) access when using your app on the subdomain, ensuring their information is protected. Using a subdomain ensures you can have SSL on both your main site and your Bubble app independently.
• Organizational Clarity: If your project would benefit from being segmented, subdomains help a lot. For instance, you might have dashboard.yourdomain.com for an internal app or clients.yourdomain.com for a client portal. Bubble on a subdomain lets you roll out these sections without confusing them with the content on the main domain. It keeps your URLs organized and meaningful.
• SEO Considerations: There’s an ongoing discussion about subdomains vs. subfolders for SEO. Some SEO experts argue that content on a subdomain might not directly benefit the main domain’s SEO as much as content in a subfolder would. (Moz and other credible sources have noted that subfolders can sometimes carry more SEO weight for the root domain than subdomains.) However, using a subdomain for a web app is often fine because the app usually serves a different function (like user dashboards, interactive tools, etc.) rather than content meant to rank on search engines. What’s important is that you interlink your main site and subdomain where appropriate and provide a good user experience. At the end of the day, a subdomain can rank in search engines as well – many big companies use subdomains for specific purposes (e.g., support.google.com, translate.google.com for Google’s services). So, the impact on SEO will depend on your use case. For marketing content like blogs, some prefer subfolders; but for apps or distinct services, a subdomain is a clean solution. We’ll touch on SEO best practices later in this article as well.

In short, using a subdomain for your Bubble app offers the best of both worlds – you get to leverage Bubble’s powerful no-code capabilities for your application while still presenting it under your own domain name. It keeps your infrastructure flexible and your branding strong. With these benefits in mind, let’s move on to what you need to get started.

Prerequisites and Requirements

Before you begin setting up a Bubble.io subdomain, make sure you have the following prerequisites in place:

• A Registered Domain Name: You need to own the domain under which the subdomain will be created. For example, if you plan to use app.mywebsite.com, you should own mywebsite.com. If you don’t have a domain yet, you’ll need to purchase one from a domain registrar (like GoDaddy, Namecheap, Google Domains, etc.). It is not necessary to register a completely new domain for your Bubble app if you already have one – creating a subdomain on an existing domain is sufficient. Ensure you have access to manage this domain’s DNS settings (usually through the registrar’s control panel or wherever your DNS is hosted).
• A Bubble.io Paid Plan: Bubble requires a paid subscription to use custom domains (including subdomains) for your app. On the free (hobby) plan, your app can only run on Bubble’s default domain. To connect yourdomain.com or any subdomain of it, you must upgrade to a plan that supports custom domains. According to Bubble experts, custom domains are not available on the free plan – you need at least the Starter (Personal) plan or higher to add a domain. Check Bubble’s pricing page to confirm which plan you need; as of 2025, the lowest paid tier is typically enough for one custom domain. Make sure your Bubble app is on the appropriate plan before attempting to configure a custom domain, or you won’t see the domain settings option.
• Bubble Application Ready to Deploy: You should have a Bubble app created and ready (or at least a basic version of it). It doesn’t have to be 100% finished, but you will be pointing the subdomain to this app’s live version. If you haven’t built anything yet, consider having a simple page set up so you can verify the subdomain works once connected. Remember that Bubble maintains a Development and Live version of your app. Only the Live version is served to your custom domain (by default, the development version remains on the Bubble preview domain unless you specifically access it with a special URL). We’ll talk about deploying to live in the steps.
• Access to DNS Management: You need the ability to add DNS records for your domain. This usually means access to your domain registrar’s DNS control panel or your hosting provider’s DNS settings. Common providers include GoDaddy, Namecheap, Cloudflare, Hostinger, etc. If your domain’s nameservers are pointing to a web host (for example, if you use Hostinger’s hosting, your DNS might be managed in their panel), you may need to create the subdomain through that interface. Essentially, wherever your DNS is controlled, you must be able to add an A record or CNAME record. As part of the setup process, you will be configuring your DNS records to point your subdomain to Bubble's public server IP address. We’ll cover exactly what to add in the forthcoming steps.
• Subdomain Name Chosen: Decide on the subdomain you want to use for your Bubble app. It could be “app”, “dashboard”, “portal”, “beta”, or any term that fits your use case. Keep it short and relevant. For instance, if your site is mycompany.com and you are building an app for clients, portal.mycompany.com might be intuitive. If it’s an internal tool, maybe internal.mycompany.com. You can be creative, but avoid using a subdomain that’s too long or confusing. Also, make sure the subdomain isn’t already in use for something else on your domain. (If you’ve never set it up before, it likely isn’t.) You generally don’t “register” a subdomain the way you register a domain – you simply create DNS records for it. So as long as it’s not defined yet, you can use it.
• A bit of Patience: While the process is quick, DNS changes can require some waiting. Typically, after you set up everything, it might take some time (minutes or hours) for the subdomain to start working globally due to DNS propagation. Be prepared to wait up to 24 hours in worst-case scenarios, though often it will be much faster (sometimes within 15-30 minutes, depending on your DNS host). We mention patience because it’s a common pitfall to think something’s wrong, while it’s simply a matter of waiting for DNS records to update across the internet.

Once you have these prerequisites ready – a domain, a Bubble paid plan, and access to DNS – you’re all set to proceed. Double-check that you can log into Bubble and your domain registrar side by side, as you’ll be switching between them. In the next section, we’ll start preparing the domain for the subdomain and then move on to configuring Bubble and the DNS records.

Preparing Your Domain and Subdomain

Now that you know what you need, let’s prepare the domain for the subdomain setup. This section is about getting things ready on the domain side before we touch the Bubble settings. Don’t worry, you don’t need to do much, and if you prefer, you can even do the Bubble part first. But it helps to understand the domain side clearly:

1. Choose Your Subdomain Name: We touched on this in prerequisites, but now finalize the subdomain you’ll use. For example, let's say we decided on app.example.com (where example.com is your primary domain). There’s no need to inform anyone or reserve it – you simply will create DNS records for “app”. Keep this name noted.

2. Log in to Your DNS Management Console: This could be at your domain registrar or another service if you use third-party DNS (like Cloudflare). Once logged in, find the section for managing DNS or “DNS Zone” for your domain. Typically, you will see existing records like A, CNAME, MX, etc., perhaps entries for the root (@) or www already there (especially if you have a website running).

3. (Optional) Create the Subdomain Entry: In some hosting providers (like certain cPanel hosts or Hostinger), there’s an option to “create subdomain” which automatically sets up some DNS records for you. For instance, Hostinger’s panel lets you add a subdomain and it creates a folder on your hosting and an A record automatically. However, if your main site is not on that same host or you don’t have such an interface, you can skip any automated subdomain creation wizard. We will add the DNS records manually ourselves in the next steps. The key point is: creating a subdomain is essentially done by adding DNS records – there isn’t a separate purchase or registration needed.

4. No Impact on Main Domain: Rest assured, adding a new subdomain will not break your main website. As long as you only add records for the specific subdomain (e.g., app), you won’t be altering how www.example.com or example.com behave. Many forum users have expressed concern about “messing up the already running website”, but if you carefully add just the new records, your existing site remains untouched. We are simply telling the DNS, “If someone goes to app.example.com, send them to Bubble’s servers; for all other subdomains and the root domain, keep them as is.”

5. Backup Current DNS Settings: As a precaution, it’s wise to note down or screenshot your current DNS records before making changes. In case something doesn’t work, you have a reference to restore to. However, since we are only adding new entries (not deleting existing ones, except perhaps conflicting ones if any), the risk is minimal.

At this stage, we haven’t changed anything yet (unless you used a host’s interface to create a subdomain automatically, which might have added a record). We’ve simply logged in and are ready. The real action happens when we tell Bubble about the subdomain and then add the records it requires. Let’s move on to the actual step-by-step process of linking the subdomain with your Bubble app.

Step 1: Add Your Subdomain in Bubble.io Settings

The first major step in linking your Bubble app to a subdomain is to configure the domain within Bubble itself. This effectively tells Bubble “Hey, I want my app to answer to this custom URL.” Here’s how to do it:

Open Your Bubble App’s Editor: Log in to your Bubble.io account and open the editor for the app you want to configure. You should have Owner/Editor access to the app.

Navigate to Settings > Domain/Email: In the Bubble editor interface, look at the left sidebar for the Settings tab (the gear icon). Click it, and then across the top of the Settings page, find the section labeled Domain / Email. This is where you manage domains and some email settings for your app.

Enter the Subdomain: You’ll see an input field for your domain. Click into it and type your chosen subdomain. Important: enter it without http:// or https:// – just the bare subdomain + domain. For our example, you’d enter app.example.com. Make sure there’s no trailing slash or anything extra. It should just be the hostname. Bubble will accept a root domain here as well, but since we’re using a subdomain, include the subdomain part. (If you accidentally just put “example.com” when you intended “app.example.com”, you can change it, but do it now before proceeding.)

Save or Set up the Domain: Bubble’s interface might have a button that says “Set up this domain” or simply a save icon once you enter the domain name. Click that. What Bubble does now is attempt to register that domain for your app. At this point, Bubble will generate the DNS records you need to add on your side (domain registrar). Typically, after clicking save, Bubble will show a message or a list of records like:In older Bubble documentation, they mention that after you enter the domain, Bubble provides a list of DNS settings to use. For a subdomain, this often includes a set of A records with specific IP addresses that Bubble uses for hosting. For example, Bubble might list four A records with different IPs (these are likely Cloudflare IPs or Bubble’s server IPs) and instruct that those should be set for your domain. They might list them twice (one set for the root and one for www) if you were doing a root domain, but for a subdomain it might specifically mention the subdomain.

• Type: A, Name: app, Value: <IP address> (and possibly multiple IP addresses),
  or sometimes CNAME instructions if applicable.
• Example (illustration only): Bubble might say: “Create A records for app.yourdomain.com pointing to 104.16.36.105, 104.16.42.105, 104.19.240.93, 104.19.241.93” (these IPs are just an example from Bubble’s docs – use whatever IPs Bubble actually provides for your app). Each IP would be one A record. These multiple IPs provide redundancy and load balancing for your app, which is why there can be several.
• In some cases, Bubble might also suggest a CNAME record if relevant. Particularly if you entered a subdomain, Bubble may alternatively allow a CNAME like app -> app.bubble.io. The interface changes over time, but the key is Bubble will tell you exactly which DNS records to create. Make sure you copy this information or keep the Bubble editor open on this screen.

Enable SSL (HTTPS): On the same Domain settings page in Bubble, there is usually a checkbox or toggle for SSL encryption for your domain. Ensure this is enabled/checked. Bubble provides free SSL certificates (likely via Let’s Encrypt) for your custom domain, but it needs to know to do so. By checking the SSL option, you ensure that when your app is accessed at https://app.example.com, it will be secure. Bubble’s forum advice for subdomains specifically reminds us to check that SSL box. If you forget this, your app might initially load on HTTP which is not ideal (or modern browsers might even block it). Fortunately, Bubble by default usually forces SSL if you set it up, but double-check. After enabling, Bubble might indicate it will provision an SSL certificate once the domain is verified.

Verify Plan & Payment Settings: Just as a sanity check, if you haven’t already, confirm that your app is on a paid plan. If not, Bubble will usually not let you save a custom domain or it will throw a notice. Upgrading the plan at this point (if you forgot earlier) will be necessary to proceed.

At this point, you have informed Bubble about the domain app.example.com. Bubble is now expecting you to add the DNS records on your side to confirm ownership. It might show a status like “Pending configuration” or “Waiting for DNS records” with maybe a red or yellow indicator in the editor until it detects the correct DNS setup. That’s normal – we haven’t done the DNS part yet. The next step is to switch over to your domain’s DNS settings and add the records that Bubble provided. Don’t worry if you closed the list; you can always revisit the Bubble settings and it will show the needed records (or you can remove and re-add the domain to see them again).

By completing Step 1, you’ve essentially done the Bubble-side configuration. That was pretty quick, right? Now let’s handle the domain side of things where we point that subdomain to Bubble’s servers.

Step 2: Configure DNS Records for the Subdomain

This is the most crucial step: updating your domain’s DNS records so that your chosen subdomain directs traffic to Bubble.io. It may sound technical, but we’ll break it down. Essentially, you’ll create entries in your DNS that match what Bubble told you to add.

Follow these instructions to configure the DNS records:

Go to Your Domain’s DNS Management Page: As prepared earlier, have your DNS control panel open for example.com. We will add new records here.

Add A Records (or CNAME) for the Subdomain: Based on the information Bubble provided in Step 1, add the DNS records one by one. There are two common scenarios:

• Bubble Provided IP Addresses (A Records): This is the typical case. For each IP address given by Bubble, create an A record. The “Host” or “Name” field of the record should be the subdomain part (for example, just put app if the interface asks for the host name, since the DNS zone is already for example.com). Some DNS providers might have you enter the full app.example.com as the host, but most will just take app and assume .example.com is appended. For the “Value” or “Points to” field, enter the IP address provided (e.g., 104.16.36.105). Repeat this for each IP address Bubble gave you. When done, you might have, say, 2-4 A records all for host app pointing to different IPs. Ensure you typed everything correctly – a single typo in an IP can cause issues.
• Bubble Provided a CNAME Option: In some setups, especially if you only want to use a subdomain and prefer not to manage multiple IPs, you can use a CNAME record. A CNAME basically says “this name is an alias for another name.” Bubble’s forum experts have noted that you can create one CNAME record from your subdomain pointing to app.bubble.io as a shortcut. In practice, if you go this route, you’d add a CNAME record with Host app and Value app.bubble.io. This way, whenever someone goes to app.example.com, the DNS will redirect it to Bubble’s universal domain, and Bubble then serves your app. This approach can simplify setup since you manage just one record. However, not all providers allow a CNAME on a subdomain that already might have other records, and generally, if Bubble gave you specific A records, the official method is to use those. A CNAME is an alternative that some users report working. If you use a CNAME, you typically should not duplicate with A records – choose one method or the other to avoid confusion. For clarity, you can stick to Bubble’s official instructions (A records) unless you’re comfortable with DNS. Both achieve the same end result.

Add Any Additional Records (if specified): Bubble might have provided an A record for the root or www as well, but since we’re focusing on a subdomain, you usually don’t need to touch your root domain’s records for this. Be careful not to delete or overwrite existing records for your main domain or other services (like email MX records, etc.). We are only adding new records for the app subdomain. If by chance your subdomain name was already used for something (say you had a previous app or verification using that name), remove or update those old records to avoid conflict. For example, if app.example.com had an old A record pointing somewhere else, you should delete that in favor of the new ones pointing to Bubble.

Save Changes: DNS panels often require you to save or confirm after adding records. Click “Save”, “Update”, or the equivalent action in your DNS management interface to ensure the new records are published.

DNS Propagation Begins: Once saved, your DNS changes will start propagating. This means it may take a bit of time for the entire internet’s DNS servers to know that app.example.com now points to Bubble. In many cases, within a few minutes you can start seeing the effect, but it might take longer depending on TTL (Time To Live) settings and your DNS provider’s efficiency. By default, many DNS records have a TTL of 300 seconds (5 minutes) or something similar, but it can vary. Some interfaces let you set the TTL when adding a record – if so, you can choose a low value like 5 minutes for faster propagation. If not, just sit tight; it can take up to 24 hours in rare cases for global propagation, though that’s not common for new records.

Here’s a quick example recap in context: Suppose Bubble gave you two IP addresses: 123.45.67.89 and 98.76.54.32 (these are hypothetical). In your DNS panel for example.com, you add:

• A record | Host: app | Points to: 123.45.67.89
• A record | Host: app | Points to: 98.76.54.32

If you opted for the CNAME method instead, you’d add:

• CNAME record | Host: app | Points to: app.bubble.io

And that’s it. You have now configured your subdomain’s DNS to direct to Bubble’s servers.

Double-check everything: It’s easy to accidentally put the wrong host or value. For instance, some people accidentally include the whole domain in the host field (like app.example.com as host when the system expects just app), resulting in a record for app.example.com.example.com – which is incorrect. Namecheap’s guide points out that with their system, you typically just enter the prefix (e.g., “blog” for blog.domain.com). Different providers vary slightly: GoDaddy might have you fill two fields (one for subdomain, one that auto-completes the domain), Cloudflare has you enter the full name but warns if you repeat the domain, etc. If uncertain, your provider’s help guide can clarify.

After adding records, there’s nothing more to do on the DNS side for now. The heavy lifting is done! The next steps will involve waiting a bit and then testing to ensure everything works. Let’s move on to enabling SSL if it’s not already handled and then deploying and testing the application.

Step 3: SSL and Security on Bubble

Securing your subdomain with SSL (HTTPS) is a must nowadays. Fortunately, Bubble.io makes SSL very easy – it will automatically issue an SSL certificate for your custom domain (through Let’s Encrypt) once your domain is properly pointed and verified. We already checked the SSL option back in Step 1, but let’s elaborate on this aspect and ensure your subdomain will be secure:

• SSL in Bubble: In the Bubble Settings under Domain, the checkbox “SSL Encryption” should be checked. Bubble’s documentation and forum advice clearly say to do this when setting up a domain on Bubble. What this does is tell Bubble to provision an HTTPS certificate for the domain (app.example.com in our case) and to serve your app exclusively over HTTPS. Bubble uses Cloudflare under the hood for domain hosting, which handles the SSL certificate issuance seamlessly once your DNS is correct. You typically do not need to purchase any SSL certificate yourself – it’s provided for free.
• “Not Secure” Issue: If you skip enabling SSL, your subdomain might load over http:// which will trigger “Not Secure” warnings in browsers. Always make sure SSL is on. Bubble will redirect HTTP to HTTPS by default for the primary domain, especially if you have the SSL box checked (Bubble’s platform forces all traffic through HTTPS for custom domains after setup, which is good security practice).
• Propagation and Certificate Generation: The SSL certificate might not be issued until the DNS is fully propagated and Bubble can verify the domain. When you first set up, Bubble might show a status like “DNS records not found” or “Checking for DNS changes…”. Once those records propagate and Bubble detects them, it will proceed to get an SSL certificate. This might take a little time after the DNS is recognized. So don’t panic if your subdomain doesn’t show the lock icon immediately. Give it a bit of time. Typically, after Bubble sees the domain (which you can observe in the Bubble editor domain section – it might turn green or say something like “Domain is live” when ready), the SSL will be active.
• Verify HTTPS: After everything is configured and propagated (we’ll test in the next step), ensure that when you type https://app.example.com in your browser, you see the secure lock icon. That indicates the SSL certificate is working. If you accidentally go to http://app.example.com, it should automatically redirect to the https version (most likely). If it doesn’t, you can enforce it via Bubble’s settings or domain config, but usually it’s automatic when using Bubble’s provided SSL.
• No Extra Cost: Just a reassurance – enabling SSL on Bubble doesn’t cost extra. It’s included in the custom domain feature you get with the paid plan. This is great because you maintain user trust (users expect the “https” and lock these days for any site, especially an app where they might log in or enter data).
• Subdomain and Main Domain SSL are separate: If your main domain (e.g., www.example.com) is hosted elsewhere and has its own SSL certificate, that’s completely fine. Having an SSL certificate for app.example.com via Bubble won’t interfere with example.com or other subdomains. Each subdomain can have its own certificate. Bubble’s provisioning for your subdomain is isolated to that subdomain.

By taking care of SSL, you ensure that your Bubble app subdomain will be accessed securely. Security is an integral part of trustworthiness (part of that E-E-A-T: Experience, Expertise, Authority, Trustworthiness), so we don’t want to overlook this. The good news is Bubble handles the hard parts here.

As one forum user quipped when helping someone set up a subdomain, “Bubble comes with https certificate so you should be fine with SSL” – meaning once you set it up, Bubble will take care of the SSL for you, making the process quite painless. So, at this step, just double-check that you did enable SSL in settings, and now you’re ready to deploy and test the app on the new subdomain.

Step 4: Deploying Your Bubble App Live

With your domain configured and DNS records propagating, you need to make sure your Bubble app is deployed to the Live environment for it to be visible on the subdomain. In Bubble, development and live are separate versions. The custom domain will serve the Live version of your app by default. If you haven’t deployed your app yet, now is the time to do it:

• Deploy to Live: In the Bubble editor, you’ll find a Deploy button (usually at the top right, looks like an upward arrow icon). Click “Deploy Development to Live”. Bubble will run through saving the current state of your development version as the live version. If you haven’t done this before, it might ask for a deployment note (you can just write “initial launch” or something). Deployment typically takes a few seconds to a minute depending on the size of your app.
• Live vs. Development: After deploying, your app now has a Live version identical to what you had in development at that moment. When people go to your subdomain (e.g., app.example.com), Bubble will serve the Live version. If you continue editing in Bubble after that, those changes won’t appear on the subdomain until you deploy again. This is important to understand – if you set everything up correctly and go to the subdomain but see a Bubble placeholder or an older version of your app, you might need to deploy. Also, Bubble might not show anything useful if you have never deployed (I recall it might show a generic “Coming soon” or just an empty page if the live version is empty). So definitely deploy at least once.
• Ensure Content is There: Make sure that on your index page (home page of your Bubble app) you have something for users to see, even if it’s just a “Hello, world” text for now. That way, when testing, you can confirm the app loaded. If the index is blank, it might be hard to tell if it loaded successfully or not.
• Development Mode Access: A quick tip – if you want to test your development version on the custom domain, Bubble allows that by adding version-test in the URL. For instance, once your domain is working, https://app.example.com/version-test/page-name would show the development version of that page on the domain (assuming you are logged in as an admin or if the app is not restricted). This isn’t commonly needed for end-users, but it’s useful for you to verify things on the custom domain without deploying each time. However, initially just focus on getting the live version working.
• No need for separate hosting: Remember, deploying in Bubble’s context doesn’t mean you need to set up any servers – Bubble’s cloud handles hosting. You don’t need a separate hosting plan for the subdomain on your web host. Some people ask if they need to buy hosting for a subdomain; the answer is no, Bubble is hosting the app as part of your Bubble plan. We’re simply pointing a subdomain to Bubble. So once deployed, Bubble’s servers do the work of serving the content.

Now that your app is deployed and everything is configured, it’s time for the moment of truth – testing whether the subdomain is up and running with your Bubble app. We’ll cover that next, as well as what to do if it doesn’t work immediately.

Step 5: Testing the Subdomain

Testing your new subdomain is an exciting step – this is when you get to see your Bubble app live on your own URL. Here’s how to thoroughly test and ensure everything is in order:

Access the Subdomain in a Browser: Open your web browser (Chrome, Firefox, Safari, etc.) and type your full subdomain URL: for example, https://app.example.com. Include the https:// to be sure you’re trying the secure version. Hit Enter and see what happens.

• Success Scenario: Ideally, you should see your Bubble app’s front page loading. This confirms that the DNS has propagated and Bubble is serving your app on that domain. Check for the lock icon in the address bar, verifying the SSL certificate is active (no warnings).
• Potential Delay: If it doesn’t load yet, you might see a Bubble error or a generic page. Commonly, Bubble might show a message like “Testing your domain’s DNS...” or it might not resolve at all (browser says domain not found). If you get a Bubble-specific message, it suggests Bubble knows about your domain but DNS might not be fully ready or the certificate isn’t issued yet. If you get a not found error, likely DNS isn’t propagated to your local network yet. Wait a bit and try again.

Clear DNS Cache or Try Different Network: If you suspect DNS propagation is the issue (e.g., some online tool says the domain resolves but your computer doesn’t, or vice versa), you can try clearing your DNS cache. On Windows, open Command Prompt and type ipconfig /flushdns. On Mac, you might use dscacheutil -flushcache in Terminal. Alternatively, try using a mobile network or a VPN to see if others can reach it. Often, DNS propagation is spotty for a short while – some ISPs update fast, others slower.

Use DNS Lookup Tools: There are free tools online like whatsmydns.net or DNSMap to check if your subdomain’s A records have propagated globally. You can input app.example.com and it will show which IP it resolves to in various regions. If you see mostly the Bubble IPs you set, that’s good. If many are still “not found”, just give it more time.

Check Bubble Editor Status: In Bubble’s editor, under Settings -> Domain, you may see a status indicator. If everything is correct, Bubble might show a green light or a “Domain is set up correctly” message. If something’s off, it might show an error like “We found bad DNS records” with a list of what it found. For instance, a forum user reported Bubble giving a message "We found bad DNS" listing the records they entered when they had an issue – typically this means either the records weren’t entered as expected or hadn’t propagated when Bubble checked. If you see such a message, re-verify the DNS entries in your registrar to ensure they match exactly what Bubble wants. Sometimes just waiting solves it if the entries were correct.

Test Functionality: If the page loads, navigate through your app briefly. Click a few buttons or log in if that’s applicable (assuming you have user accounts). Ensure that the app is functioning normally on this domain. It should – because it’s essentially the same app, just being accessed via a different URL. You might notice you need to log in again on the new domain (users sessions won’t carry over from the bubbleapps.io domain to your custom domain due to it being seen as a different site – that’s normal).

Development Version Testing: As mentioned, you can test the development version by appending /version-test to the URL. For example, https://app.example.com/version-test should load the development version of your index page (you might need to add /version-test/index explicitly or any specific page name). This is a quick way to see if the dev version works on custom domain if needed. Keep in mind, you likely have to be logged in as an admin or have the app set to allow public viewing of dev version to see it. This is optional, but useful for future changes – you can test on the live domain in dev mode before deploying updates.

Email and Other Integrations: If your app sends emails or calls API endpoints, do a quick check that those still work with the new domain (for example, if you had any hardcoded URLs in APIs or redirects, update them to the new subdomain). If you integrated a service like a social login or Stripe, you might need to add the new domain to allowed redirect URLs in those services since the domain changed from the bubbleapps.io one. This goes beyond basic setup, but it’s something to remember post-launch.

If everything loads correctly, congratulations – you have successfully created and run your Bubble.io app on a custom subdomain! This is a big step in making your app production-ready and branded. Seeing your app on your own domain is often a rewarding moment for founders and developers, as it solidifies the app as “yours.”

In case things aren’t perfect, don’t worry. In the next section, we’ll address common issues and how to troubleshoot them. But if you’ve made it this far with the app showing up, the hardest part is over. Now let’s ensure any hiccups can be smoothed out quickly.

DNS Propagation and Wait Time

It’s worth emphasizing the aspect of DNS propagation, as it’s a source of confusion for many. After adding or changing DNS records, it can take some time for those changes to be recognized everywhere. Here’s what you need to know about propagation in the context of your Bubble subdomain:

• What is DNS Propagation? When you update your DNS records (like adding the A records for your subdomain), those updates need to be distributed across DNS servers around the world. Your ISP (internet service provider) likely caches DNS results to speed up browsing. So do many other DNS resolvers. Propagation is the process where all those caches expire and fetch the new info, meaning eventually everyone gets directed to the new IP for your subdomain. The time this takes can vary.
• Typical Time Frame: Often, propagation happens quickly (within minutes to an hour) for new records, especially if the DNS zone had no prior record for that name. Many modern DNS providers push updates in near real-time. However, as a safe rule, expect it could take up to 24 hours to fully propagate. Several factors influence DNS propagation time, including the TTL (Time to Live) settings of your DNS records, the efficiency of your DNS provider in updating records, and how long various DNS resolvers and ISPs cache old information. If after a few hours you still can’t resolve the subdomain, double-check for any mistakes, but also keep patience.
• TTL (Time to Live): Each DNS record has a TTL value which is essentially an indicator of how long a DNS server should cache that entry before checking again. If the TTL was high (like 86400 seconds, which is 24 hours), changes can take longer to be seen if something was cached. If it was low (like 300 seconds), it updates faster. When adding a brand new subdomain record, caching is less of a problem since it likely wasn’t cached anywhere before. But if you changed an existing one, TTL matters. Some providers default new records to a certain TTL (some use 1 hour or 30 min, etc.). Without getting too technical, just be aware that this is why sometimes one location sees the update and another doesn’t yet.
• Checking Propagation: As mentioned earlier, you can use online tools to check propagation. For example, searching for “DNS propagation checker” will lead you to services where you input app.example.com and it shows IPs resolved in multiple cities worldwide. If most locations show Bubble’s IP addresses and perhaps one or two don’t, you’re almost there – just wait a bit more. If none show and it’s been a long time, suspect an error in configuration.
• Common Propagation Misunderstanding: A lot of new domain owners get tripped up thinking something is wrong with their website setup when it’s actually just propagation delay. It’s a classic case of “worked for me, not for my friend 500 miles away, until an hour later.” So if you can access the app on your phone’s cellular network but not on your home Wi-Fi, that’s likely propagation (or your router’s DNS cache) at play. Give it time, or try restarting the router, etc.
• Hostinger/GoDaddy Specifics: In the earlier forum example with Hostinger, the user mentioned having to wait 24 hours. Hostinger’s own documentation notes the same propagation window. GoDaddy typically says changes might take up to 48 hours, though rarely it’s that long. The key is: do not repeatedly change the DNS records during this period thinking you did something wrong, as that can actually prolong the process or introduce new errors. Set it correctly once, then wait.

In summary, be patient and use the waiting time productively – maybe work on other aspects of your app or prepare content. If you’ve followed the steps correctly, the subdomain will almost certainly come online once propagation is done. Meanwhile, Bubble is checking periodically too; the Bubble editor will update the domain status once it detects the DNS records.

Next, we’ll cover troubleshooting common issues, some of which might be related to DNS or other configuration mistakes.

Troubleshooting Common Issues

Even with a careful setup, you might run into some bumps when connecting a subdomain to Bubble. Let’s address a few common issues and how to solve them:

1. “Bad DNS” or Verification Failed in Bubble: If Bubble’s settings page shows an error like “We found bad DNS records” or “Your domain is not pointed to Bubble”, it means Bubble isn’t seeing the expected records. Possible causes:

• The DNS records were entered incorrectly (e.g., wrong IP, or the host was set incorrectly).
• The records haven’t propagated yet to whatever server Bubble is checking from.
• There are extra conflicting records. For instance, if you accidentally created a duplicate CNAME or the subdomain was also set up as a separate site on your host, those could conflict.
• Solution: Double-check the records exactly against Bubble’s instructions. If it lists what it found, compare those to what you intended. Fix any typos or misconfigurations. If all looks right, give it more time. You can also remove and re-add the domain in Bubble to prompt it to recheck (though usually it checks continuously). Another trick is to use a third-party DNS lookup (like nslookup or online tools) to see what the authoritative servers are saying your subdomain’s IP is – that will tell you if your update is live.

2. Subdomain Not Resolving at All: If after a long while, going to app.example.com still says “server not found”, it means DNS isn’t directing to Bubble at all. Maybe the records never got properly added.

• In your DNS manager, ensure the records are actually present and not showing errors. Sometimes, domain registrars have weird UI where you add a record but if you didn’t hit save correctly it doesn’t stick.
• Make sure you didn’t include the domain twice. E.g., for Namecheap you should put host as “app” not “app.example.com”, because Namecheap’s system appends the domain automatically. If you accidentally put the full domain, you might have created a record for app.example.com.example.com, which of course won’t work. This kind of mistake is surprisingly common.
• If using Cloudflare or another DNS service, check that your DNS is not proxying incorrectly. With Cloudflare, if you have proxy (orange cloud icon) on, it still should work with Bubble, but ideally for custom domain you might have it just DNS only (depending on Bubble’s latest guidance – historically, Cloudflare proxy could interfere with the SSL since Bubble already has Cloudflare integration).
• Try to ping or use dig command for the subdomain to see if it returns an IP. If not, DNS isn’t set up right.

3. SSL Issues (Not Secure Warning): If the site loads but not under HTTPS (or you get a certificate error):

• Check that SSL was enabled in Bubble settings (we did that in Step 1, but just in case).
• It might be that the certificate hasn’t been issued yet. Usually, if DNS is fine, Bubble will get the cert within a few minutes. Until then, you might get a security error or a redirect to HTTP. Don’t panic; wait and try again. If it persists, reach out to Bubble support – but that’s rare.
• Make sure you’re not accessing by IP or some wrong domain spelling that would cause a certificate name mismatch.
• Sometimes, clearing browser cache or trying incognito helps if an old redirect is cached.

4. Main Site Broke After Adding Subdomain: In theory, adding a subdomain’s records shouldn’t affect your main site at all. However, if you mistakenly changed something for the root or www records, that could disrupt your main site.

• If that happened, quickly revert those changes. For example, if you pointed the root domain’s A record to Bubble by mistake, your main site might now be going to Bubble (which is not what you want if your main site is elsewhere). The solution is to change the root record back to the IP of your web host.
• Always keep records of what the original values were (hence our suggestion to backup DNS settings before). If you have that, restoring is easy. If not, you might need to contact your hosting provider to get the correct DNS values for your main site and re-enter them.
• In any case, properly adding just the subdomain should not cause any downtime for the main site. Many have done it successfully, so any issue is likely a minor misstep in configuration.

5. Email or Other Services Affected: Adding an A or CNAME for a new subdomain typically won’t affect email (which uses MX records) or other subdomains. However, be careful not to delete any MX or TXT records during cleanup. Some people might accidentally remove a necessary verification or mail record thinking it’s unrelated. Always only modify what you need to. If you suspect email issues after the change, verify that your MX records for your domain are intact and unchanged.

6. Bubble App Not Working Properly on Subdomain: If the app loads but some features don’t work:

• Check if you have any API calls or redirects that use the old domain (yourapp.bubbleapps.io). You might need to update them to the new domain.
• If you use any plugins or scripts that rely on the domain (for example, OAuth redirect URIs from Google or Facebook logins), you’ll need to add the new subdomain URL in those external settings, otherwise logins might fail. This is not a “setup” issue per se, but part of launching on a new domain.
• Ensure your app’s domain-level settings (like cookies, local storage, etc.) aren’t being blocked. For instance, sometimes when switching domain, you might need to update cookie settings if you had any domain-specific logic. This is advanced, though; most Bubble apps will just work.

7. Need to Use Multiple Subdomains: A question that might arise is, “I got app.example.com working. Can I also have another subdomain or the root domain for the same app?” By default, Bubble apps are one domain each. So you cannot have the same Bubble app on both example.com and app.example.com simultaneously through the standard settings. If you need multiple, Bubble offers a “sub-apps” feature (essentially separate apps that can share a database). But that’s a more advanced scenario beyond this tutorial. If you simply changed your mind and want to use a different subdomain, you can do so by changing the domain in settings – but you can only have one active at a time per app (excluding the bubbleapps.io one which is always there for development access).

• If you tried to add a second domain in Bubble without the sub-app approach, it won’t allow it (only one custom domain input). So avoid attempting to hack multiple domains onto one app; it requires an architectural approach with separate Bubble apps if needed.

In general, troubleshooting is about carefully reviewing each step and piece of data you entered. Most issues boil down to a typo, a missed step, or a bit more waiting needed. The Bubble forum is a great resource if you run into obscure issues – chances are someone faced a similar problem. For example, one person was struggling until they realized they needed to be on a paid plan, another until they found out they should use a CNAME instead of trying multiple A records on a tricky DNS provider. There’s almost always a solution discovered by the community.

Now that we’ve tackled the problems, let’s discuss some extra tips to make the setup quicker and smoother, as well as touch on SEO and maintenance considerations.

Tips for a Quick and Smooth Setup

To ensure you can quickly create and run your Bubble.io subdomain without hiccups, consider these additional tips and best practices:

• Use a CNAME for Simplicity (Optional): As mentioned, you can often use a single CNAME record pointing your subdomain to Bubble, which can simplify setup. This way, you don’t have to input multiple IP addresses. It’s a handy shortcut particularly if your DNS provider’s interface is confusing or if you worry about copying multiple numbers correctly. For instance, instead of four A records for “app”, one CNAME app -> app.bubble.io can do the job. Many users have reported success with this method, and it has the added benefit that if Bubble’s IP addresses ever change, you wouldn’t need to update them because the CNAME always points to the current address behind app.bubble.io. However, remember not all providers support CNAME flattening on root domains (but on a subdomain it’s fine). Also, do this or A records, not both simultaneously, to avoid conflicts.
• Plan Domain Move Timing: If you’re transitioning an app from Bubble’s test domain to your custom subdomain, plan to do it during a low-traffic period. While the change is propagating, some users might still hit the old domain (which will still show the app, but if you intend to move completely, you might want to put a notice or redirect eventually). Bubble doesn’t auto-redirect your bubbleapps.io domain to your custom domain; they’ll both work. So consider communicating the new URL to your users if relevant, or setting up a redirect page on the old domain if needed (though not strictly necessary).
• Leverage Host Support and Docs: If you’re unsure about the DNS steps on your particular provider, don’t hesitate to look up their help articles or contact support. For example, Hostinger’s help center provides a guide on adding subdomains in their panel and Namecheap’s knowledgebase shows step-by-step how to add A or CNAME records for subdomains. Using these resources can save you time and prevent mistakes. As one community member said, “I’m sure your hosting support will help you too” – they can often guide you if something isn’t clear.
• Use Short TTL for Testing: When adding DNS records, if you have the option, set a low TTL (like 300 seconds) initially. This can help the changes propagate faster. After everything is working, you can leave it or increase it. Short TTL is useful if you might need to tweak things and want updates to reflect quickly. Some providers default to 1 hour which is okay, but 5 minutes is even better for quick changes.
• Avoid Forwarding/Redirect Methods: Some might be tempted by options like “URL forwarding” or other shortcuts offered in DNS managers. For example, GoDaddy or Namecheap might have a feature to forward a subdomain to a URL. Do not use URL forwarding for this purpose – it’s not what we want. We need actual DNS A/CNAME records (the forwarding option would just send a HTTP redirect which is not suitable for running the app). Stick to the method of pointing via A/CNAME as described.
• Keep Track of Changes: Document what you changed and when. If something doesn’t work, it’s easier to backtrack. Also, DNS propagation might make it tricky to tell which change had an effect. If you change something, note the time. This way, if 30 minutes later it works, you know which configuration likely was the right one.
• Use an Incognito Window for Testing: Sometimes your browser might cache a redirect or an error page. By using an incognito/private window when testing the new domain, you ensure you’re seeing a fresh result. Also test on multiple devices if possible (like your phone on cellular data) to confirm it’s not just working on your machine due to cache.
• Community Plugins for Domain (if any): Generally not needed, but if you had a scenario of dynamic domains or multi-tenant setups where each user gets their own subdomain, that’s beyond the default Bubble capability. There are solutions and plugins (like the CoAlias service or others) for such advanced needs. But for one-off subdomains like we’re doing, you won’t need those. Still, it’s good to know that if your project scales to needing many subdomains (like user1.yourdomain.com, user2.yourdomain.com etc.), you’d have to explore Bubble’s sub-apps or third-party solutions. This is out of scope for now, but keep it in mind if your strategy changes.
• SEO Tip – Set Preferred Domain: If your app’s content needs to be indexed by search engines, make sure you submit the subdomain in Google Search Console as a property (if it’s a public site). Also, if you have both the root and subdomain in play, consider linking them clearly. While Google is generally okay with subdomains, ensuring your main site links to the subdomain (and vice versa where it makes sense) will help search engines connect the dots that it’s part of the same brand. As referenced, subdomains vs subdirectories is an SEO debate, but since you likely chose subdomain for structural reasons (an app is separate from main site content), just focus on providing a good user experience. You could also add a sitemap for the subdomain if SEO indexing is desired.
• Monitor Uptime: Once running, you might want to monitor your site’s uptime on the new domain using a service or plugin. This isn’t specific to subdomains – but after any change, it’s good to keep an eye. Bubble is quite stable, but if something were misconfigured with the domain, an uptime monitor would alert you if the site goes down.

By following these tips, you’ll smooth out the process and get your Bubble.io subdomain up quickly and painlessly. The key theme is attention to detail in DNS entries and utilizing resources at your disposal.

Next, let’s briefly discuss SEO considerations specifically, as some readers might be concerned about how having the app on a subdomain interacts with their overall web presence.

SEO Considerations for Subdomains

Using a subdomain for your Bubble app can raise some questions about search engine optimization (SEO). While this article is primarily about the technical steps, it’s worth addressing SEO for completeness, since many site owners care about maintaining their Google rankings and domain authority across all parts of their site. Here are some points to consider:

• Content vs. App: First, determine if your Bubble app even needs to be indexed by search engines. Many web apps (dashboards, portals, internal systems) don’t contain content meant for public search indexing (they might require login, or the content is user-specific). If that’s the case, SEO might not be a big factor – you may even have nofollow or noindex on those pages. If, however, your Bubble app has public-facing pages (like user-generated content, profiles, or a directory) that you do want indexed, then SEO matters more.
• Subdomain treated separately: Historically, Google has treated subdomains as somewhat separate sites, though in recent years they’ve gotten better at understanding they can be part of the same entity. For example, blog.yourdomain.com and www.yourdomain.com might be seen as related if properly interlinked, but they don’t automatically share “SEO juice.” As one forum user pointed out, credible sources suggest subfolders (like yourdomain.com/app) might pass SEO value more directly than subdomains. However, since Bubble cannot be hosted as a subfolder of another site (without complex reverse proxy setups which are advanced), using a subdomain is the straightforward way.
• Interlink Your Sites: To help search engines understand that your subdomain is part of your main site’s brand, provide links between them. For example, on your main site (www.yourdomain.com), have a clear link in the navigation or footer to the app (app.yourdomain.com) like “Login” or “Dashboard”. Conversely, from the app (if it has a header or footer for logged-out state or such), link back to the main site (like “Home” or “About Us” linking to www). This cross-linking signals relationship. Also, keep consistent branding (logos, design cues) so it’s obvious to users and Google that it’s the same company.
• Analytics and Search Console: Treat the subdomain as its own property in tools. For Google Analytics or other analytics, ensure you set them to track across subdomains if needed (there are settings for that if using GA, so that a user moving from www to app is seen as same session). For Google Search Console (formerly Webmaster Tools), you’ll likely add a new property for app.yourdomain.com if you care about its indexing status. That way you can monitor if Google can crawl it. If the content is not meant for crawling (e.g., behind login), you might not add it at all.
• Sitemap: If your Bubble app has public content that should be indexed, create a sitemap for it. Bubble can generate a sitemap.xml for your app (check Bubble settings SEO/metatags section). Make sure it’s accessible at app.yourdomain.com/sitemap.xml. You can then submit that in Search Console for the subdomain property.
• Avoid Duplicate Content: Ensure you’re not duplicating content between your main site and subdomain in a way that could confuse search engines. Usually not an issue (your main site might be marketing, your subdomain is an app or different content). Just something to be mindful of.
• Page Titles and Metadata: Just because it’s on a subdomain doesn’t mean you shouldn’t optimize your Bubble app pages for SEO (if they are indexable). Use Bubble’s page title and description settings to give meaningful titles. For example, if you have user profile pages on the app, the title could include the user’s name – this helps if those pages ever get indexed.
• Loading Speed: Bubble apps on custom domains often benefit from Cloudflare’s CDN (since Bubble partners with Cloudflare). This can help with speed, which is a factor for SEO. Ensure your pages are loading reasonably fast (Bubble is decent, though very heavy pages might need optimization). A fast, mobile-friendly app is good for SEO in general.
• Mobile Optimization: Check that your Bubble app on the subdomain is mobile-responsive. Google’s indexing is mobile-first, and if your app has any publicly accessible pages, they should be usable on mobile. Bubble allows responsive design; make sure you’ve tested it.

In summary, using a subdomain for your Bubble app is fine for SEO as long as you follow general best practices. The main sacrifice is that any SEO value built by your main domain’s content doesn’t automatically transfer to the subdomain – you have to treat the subdomain as its own entity content-wise. But user-wise, if it’s mostly an app behind login, SEO impact might be minimal anyway. Don’t let SEO worries discourage you from using a subdomain; many businesses run their apps on subdomains successfully. Just implement the tips above to tie things together.

Now, after covering all these angles, let’s discuss maintaining your subdomain and some closing thoughts.

Maintaining Your Subdomain and App

Once everything is set up and running, ongoing maintenance for the subdomain is fairly light, but here are a few things to keep in mind for the future:

• Domain Renewals: This might sound obvious, but ensure you keep your primary domain registration active. If example.com expires, naturally app.example.com will go down too. Set your domain to auto-renew or keep track of renewal dates to avoid any downtime due to expiration.
• SSL Renewal: Bubble (through Let’s Encrypt) will automatically renew your SSL certificate for the subdomain. Typically, Let’s Encrypt certs renew every 90 days. You usually don’t have to do anything as long as your domain is still correctly pointing and your Bubble app is active. It should happen behind the scenes. If for some reason your domain verification breaks (say you changed something in DNS without updating Bubble), then a renewal could fail – but you would likely notice the site failing before that. In general, Bubble handles SSL renewals, so just monitor it casually.
• Changing Subdomain or Domain: If you ever rebrand or want to move to a different domain, you’d repeat a similar process: update Bubble’s settings with the new domain, then add DNS records for the new domain. Bubble will then issue a new SSL for that. You should also remove or update the old domain’s records if you retire it. It’s not something you do often, but just know the process can be repeated anytime (just remember one app = one domain at a time).
• Multiple Apps, One Domain: If down the line you create another Bubble app and want it on another subdomain of the same domain, you can absolutely do that. For example, you have app1 on portal.example.com and app2 on blog.example.com (though blog might be better as a WordPress site, just an example). Each Bubble app will have its own settings entry for its respective domain. There’s no conflict as long as they are different subdomains. Just be cautious not to overlap – e.g., don’t try to put two apps on the exact same subdomain or one on the root and one on www; that wouldn’t work without sub-apps. But distinct subdomains per app is fine.
• Sub-app Feature: If you are scaling and need many subdomains (like a subdomain per customer scenario), Bubble’s sub-app or wildcard domain features might come into play. That involves programmatically creating apps or using an external service like the CoAlias (which allows dynamic subdomains mapping to content). This is advanced and not needed for most cases, but it’s available if your project grows in complexity.
• Monitoring and Analytics: Continue to monitor your app’s performance on the subdomain. Use analytics to see if users reach it fine, bounce rates, etc. From an infrastructure side, you normally don’t have to worry about server maintenance – Bubble takes care of uptime, scaling, etc., which is a big relief. Your focus remains on the app’s functionality and user experience.
• Keep DNS Records Minimal: Over time, you might accumulate DNS records, especially if you try things. It’s good to tidy up any unnecessary or old records. For instance, if you had earlier tried a different subdomain or had some experimental record, remove those to avoid confusion. Keep your DNS zone lean: just the records you need for current services (your main site, your bubble subdomain, email records, verifications, etc.). This prevents accidentally conflicting settings.
• Test After DNS Changes: If you change something related to your domain (like moving your main site hosting, or adding Cloudflare, etc.), always test that your Bubble subdomain still works after. For example, if you switch nameservers to a different provider, you need to re-add the Bubble DNS records in the new place. It’s easy to forget that when migrating DNS, so keep Bubble in mind during any domain changes.

Maintaining the setup largely means ensuring the domain remains correctly configured and up-to-date. The Bubble app itself will be maintained through Bubble’s versioning and your own development cycle, which is beyond the domain setup.

We have now covered all aspects: the how-to, the why, troubleshooting, tips, and aftercare. It’s been a detailed journey, but hopefully you feel equipped with Experience and Expertise to confidently set up a Bubble.io subdomain, see the Authority in the references and steps provided, and trust that this approach is reliable for your project.

Let’s move on to some frequently asked questions to clarify any remaining points, and then conclude the guide.

Frequently Asked Questions (FAQs)

Q: Do I need a paid Bubble plan to use a custom subdomain?
A: Yes. Bubble only allows adding custom domains (including subdomains) on paid plans. The free Hobby plan is limited to the Bubble subdomain (yourapp.bubbleapps.io). Upgrade to at least the Starter (Personal) plan or higher to use your own domain. Once on a paid plan, the Domain settings tab will let you input your subdomain.

Q: How long does it take for my Bubble app subdomain to start working?
A: It can be very quick – often within a few minutes – but it might take up to 24 hours for DNS propagation worldwide. In many cases, you’ll see it working in 10-15 minutes. If it’s not working immediately, don’t worry; give it some time and double-check your DNS settings for any mistakes.

Q: My main website is on the root domain. Will adding a Bubble subdomain affect my main site?
A: No, not if done correctly. Adding a subdomain (e.g., app.yourdomain.com) via DNS will not interfere with your root domain (yourdomain.com or www.yourdomain.com) as long as you don’t change the existing records for the root or www. You’re simply creating a new branch of the domain. Your main site will continue to run as is, and your Bubble app will run on the subdomain independently. Many people use this setup to keep their marketing site and web app separate but under one branding.

Q: Can I have multiple subdomains (or domain and subdomain) pointing to the same Bubble app?
A: Not simultaneously on one Bubble app. Each Bubble application can be linked to one custom domain or subdomain at a time. If you need the same app accessible via different URLs, Bubble doesn’t support that out of the box except through the sub-apps feature (which essentially clones apps for each domain). However, you can build multiple Bubble apps and assign each its own domain/subdomain if that fits your architecture. For most cases, pick one domain or subdomain for your app to use.

Q: What if I don’t have a domain at all? Can I still run my Bubble app?
A: Yes, if you don’t have a custom domain, you can continue to use Bubble’s free subdomain (yourapp.bubbleapps.io). That’s fine for testing, development, or even early-stage launches. The guide above is for using your own domain’s subdomain, which gives a more professional touch. If you decide to get a domain later, you can always set it up then. Domains are relatively inexpensive and add credibility, so when you’re serious about your app, it’s a good idea to invest in one.

Q: Do I need web hosting for the subdomain in addition to Bubble?
A: No. Bubble acts as the web host for your app. You do not need to purchase separate hosting for the subdomain. The DNS records you add will point to Bubble’s servers, which serve your app. Some registrars or hosts might mention “create a subdomain in hosting”, but that typically applies if you were hosting something on their servers. In our case, Bubble is the host, so no extra hosting plan is required (beyond your Bubble subscription).

Q: Is using a subdomain bad for SEO?
A: Not necessarily. While some SEO professionals prefer subdirectories for content, using a subdomain for a web app is a common practice and generally acceptable. Search engines will treat app.yourdomain.com as part of the same overall domain family. Just make sure to interlink your main site and subdomain logically, maintain good content, and, if the subdomain has indexable pages, use standard SEO techniques on them. Many successful sites use subdomains for various functions without issue. As long as your main site and subdomain serve different purposes (e.g., marketing site vs. app), you’re fine.

Q: Bubble gave me several IP addresses for A records – do I need to add all of them?
A: Yes, if Bubble provides multiple IPs, add each one as a separate A record for the subdomain (with the same host). These multiple records are for redundancy and load balancing. By adding all, you ensure your app remains accessible even if one IP has an issue. If you use the CNAME method (pointing to app.bubble.io), that effectively covers all IPs under the hood, which is why it’s a convenient alternative. But if sticking to A records, include every IP Bubble listed.

Q: Can I still access my app via the old bubbleapps.io URL after setting up the subdomain?
A: Yes, your Bubble app’s preview URLs (on bubbleapps.io) will continue to work for development and testing. The custom domain displays the Live version (and version-test for development as needed). It’s actually useful to have both: you might use the Bubble URL for quick testing or if you encounter any domain issues, but your users will use the friendly custom subdomain. There’s no harm in the Bubble domain remaining active; you just might not publicize it. If you prefer, you can put up a redirect on the index of the Bubbleapps domain to the new domain (Bubble doesn’t do this automatically).

Q: I followed the steps but it’s still not working – what should I do?
A: If you’ve waited for propagation and double-checked everything yet it’s not working, here’s a quick checklist:

• Verify that your Bubble app is on a paid plan and the domain is correctly entered in Bubble settings.
• Check your DNS records using an external lookup to see if they match what Bubble expects (correct subdomain and IPs).
• Look at Bubble’s error message (if any) in the Domain tab – it often hints at what’s wrong (like which record is missing or mismatched).
• Ensure no typo in domain name (it happens – e.g., app.mydomain.co vs app.mydomain.com).
• Reach out on the Bubble forum or Bubble support with details; the community and support team can often identify the issue if it’s a tricky one. There may be platform-specific quirks (e.g., certain registrars might require a dot at end of domain in DNS entries or something unusual).
• Remember, almost every issue has a solution discovered by someone. Stay calm and systematically troubleshoot – you’ll get it resolved!

With these FAQs addressed, we’ve covered most of the concerns that come up during the process. If you have other questions, Bubble’s documentation and user community are excellent additional resources.

Conclusion

Setting up a custom subdomain for your Bubble.io app might initially seem daunting, especially if you’re not familiar with domains and DNS. However, as we’ve shown in this comprehensive guide, the process can be broken down into a series of clear, manageable steps. By preparing your domain, configuring Bubble’s settings, updating DNS records, and verifying everything carefully, you can quickly create and run a Bubble.io subdomain for your application without a hitch. This integration allows you to deliver a seamless and branded experience to your users – your app becomes an integral part of your online presence, accessible at a glance-worthy URL.

Throughout this journey, we adhered to best practices ensuring you benefit from our experience and expertise. We emphasized the importance of a paid Bubble plan for custom domains, guiding you through the exact records to add and even alternative methods like using a CNAME for simplicity. We addressed common pitfalls (like DNS propagation delays or misconfigured records) and provided solutions backed by community advice and official documentation. By following these steps, you’ve essentially applied the same techniques that countless Bubble developers have used to go live on their own domains – and you’ve done so with an eye on security (SSL encryption), performance, and SEO considerations.

One of the great things about Bubble is that it empowers creators to build complex web applications without coding, and extending that no-code philosophy to domain setup means you don’t have to tinker with servers or complex hosting setups. A few DNS entries and toggles, and Bubble takes care of the heavy lifting behind the scenes. You can run your app with confidence on Bubble’s robust infrastructure, all while presenting it under your own subdomain.

In an optimistic light, this step of putting your app on a custom subdomain is often the moment your project “graduates” from experiment to real-world application. It signals that you’re ready for real users, real traffic, and to integrate with the broader web ecosystem. It’s a milestone worth celebrating. And it’s not just about vanity or looks – having your app on a subdomain can improve user trust (users see a familiar domain) and even internal organization (you know exactly where your app lives and how it interfaces with your main site or other services).

As you move forward, remember to maintain the domain as part of your project’s routine (renew the domain, keep an eye on Bubble plan usage, etc.). But you can largely focus on developing your app’s features and serving your users – the domain setup typically needs very little ongoing attention.

We hope this guide has been informative and that it has given you not only the “how” but also the understanding of “why” each step is done, following the principles of experience, expertise, authority, and trustworthiness. With your Bubble app running on your own subdomain, you’re now presenting a polished, professional face to the world.

Happy Bubbling, and enjoy your new subdomain! Your app is live at a place you can call its true home. Now it’s time to continue building and maybe even scaling up further. If you’d like to keep reading and learn more about the benefits of using a subdomain for your app, be sure to explore our related content.

Next Steps:

Translate this article – Need this guide in another language? Consider translating it to share with non-English speaking team members or the community, ensuring the knowledge is accessible to a broader audience. This can help others learn how to quickly create and run a Bubble.io subdomain in their native language.

Generate blog-ready images – Enhance this article or your own documentation by creating visuals. For example, you might generate diagrams of DNS settings or screenshots of the Bubble configuration steps. Blog-ready images (like infographics or step-by-step screenshots) can make the process even easier to follow and are great for SEO and reader engagement.

Start a new article – Now that you’ve mastered Bubble subdomains, you might want to document another aspect of Bubble or no-code development. Consider writing a new comprehensive guide on a related topic, such as integrating APIs in Bubble, optimizing Bubble app performance, or a case study of launching a Bubble app. Sharing knowledge not only helps others but also reinforces your own learning. Happy writing!