Recurring outages are hurting our businesses — please allow self-hosting

Need help
1

I love Bubble and have been building on it for years, but I have to say what many of us are thinking.

It feels like every week there’s another infrastructure issue. Load balancers, connectivity problems, editor issues… and every outage impacts our customers, our businesses, and our reputation.

We’re the ones who have to explain to clients why their applications are down, even though we have no control over the infrastructure.

Please give us the option to self-host Bubble.

Let those of us who want to run Bubble on our own infrastructure (AWS, Azure, Hetzner, GCP, etc.) take responsibility for uptime and scaling.

Many of us would gladly pay for a self-hosted or enterprise-managed license if it meant having control over our production environments.

Bubble is an amazing development platform, but reliability has become one of its biggest weaknesses. Giving developers the choice to self-host would solve a huge concern for many businesses that depend on Bubble every day.

Is this something the Bubble team is actively considering?

2

The reality is that for most apps and users, self hosting is a worse option… if your app goes down, and you’re a small team of <5 people… good luck…

Dedicated servers aren’t down and you can get your own dedicated server with Bubble. The cost is still much less than hiring a SRE to maintain your ‘self hosted Bubble’ instance.

Yes, I (and everyone) would agree that Bubble should minimise downtime where possible, but Bubble’s more likely to recover downtime quickly than most individuals would.

3

I understand your point, but I think things have changed significantly over the last few years.

Today, running infrastructure is far more accessible than it used to be. Between Docker, Kubernetes, Terraform, managed databases, AI tools like Claude Code and Codex, and cloud providers like AWS, Azure, GCP, and Hetzner, many small teams are perfectly capable of operating production infrastructure.

I’m not saying Bubble should stop offering managed hosting. Plenty of developers will continue to choose it, and that’s great.

What I’m asking for is choice.

I’d rather be responsible for my own uptime than have every Bubble customer affected by the same infrastructure incident because we all depend on the same platform. If my server goes down, that’s on me. If Bubble’s infrastructure goes down, everyone goes down together.

Bubble has built an incredible platform, but an affordable self-hosting option would give developers and businesses the freedom to choose the level of control that’s right for them instead of forcing everyone into the same infrastructure model.

4

I honestly doubt that will ever happen. The number of support tickets generated by issues caused by environments outside of Bubble’s control would be enormous. That would inevitably increase response times for other support requests and ultimately hurt Bubble’s own reputation.

I agree with @georgecollier here. Bubble’s focus should be on hosting the platform themselves and committing to an industry-standard SLA with 99.99% uptime. That’s where their efforts should be directed.

Allowing self-hosting would be like opening the gates of hell.

The only reason you’re asking for this is because of the lack of confidence in Bubble itself. If these outages weren’t an issue, we wouldn’t even be having this discussion on the forum.

We need to address the root cause of the problem, not come up with ways to live with it.

5

and any effort that’s directed to self hosting is effort that’s not being spent on reliability in general

6

Never going to happen unless Bubble goes out of business, in which case it will 100% happen. So you can either bet against Bubble and wait until that happens, which would be paradoxical, or you can just switch off and see if the grass is truly greener.

7

How much are you paying now and how much would you pay for a self hosted option?

8

Above is more true than the below. I am of the opinion that it is more a logistical issue than a technical one:

  • How would self hosting look like?
  • What part of a Bubble app is being self hosted?
  • Where does Bubble’s responsibility start and end?

What Bubble needs is a good middle ground between shared clusters and dedicated.

For example, the option to pay for duplicated instance of an app in different clusters.

I would expect by now that Bubble has good instance sharding in place.

9

(Genuine question, not intended to sound argumentative)

How often would a non-bubble hosted app “go down” and for what reasons? The last handful of major outages seem to have always come after some sort of architectural change that the bubble team pushed during business hours. If reliability is essential for an application, can’t a developer at least mitigate impact by pushing these sorts of changes only when they’re available to recover an outage? In my case, for instance, I never push changes to production until after 9p Pacific to ensure that I can test in prod and mitigate any impact if there are flaws. I know there are probably outages that can be caused by things like overloaded servers / scaling issues, but again, a diligent developer could prepare for those possibilities.

Half the issue I’ve had with the bubble outages is the poor timing. For instance, if I’m self-hosting and about to give a demo to a really important potential enterprise customer, I wouldn’t push changes in the middle of the meeting that crashes the service - if this sounds specific, its because that exact issue happened to me during one of the major spring 2025 outages :')

Again, asking this all to better understand the tradeoffs - I would love to not feel like I need to migrate off of bubble, but the timing and severity of the outages may be becoming too large of a risk for my business. Every discussion I see of “why you shouldn’t leave bubble” touts the argument that you get devOps “handled” for us by the bubble team, but painful outages during critical times doesn’t feel exactly like they’re being handled? More like they’re just doing a great job at recovering after they break something…

Please educate me on why I’m wrong / under-appreciating the reliability bubble delivers so I don’t waste time migrating and end up worse off :slight_smile:

10

These issues are common to apps in the shared clusters. If stability and uptime is extremely critical and you want to stick to Bubble, then better to fork out money for dedicated.

Shared cluster prices are a steal already. What you pay for with code may be cheaper (for now), but you will probably end up with a distributed system with multiple services to monitor and working to maintain the fabric that ties them all together.

People tend to ignore the complexities that Bubble takes away that AI cannot takeover.

Our startup has a second major project where the codebase is completely managed by AI. The senior engineer overseeing it basically doesn’t look at the code. He has a pretty impressive harness set up to monitor, review and code. It runs pretty much autonomously.

Yet it is very frustrating to me to see how it has reached the point where you lose touch with the codebase and become reliant on the AI…so much so that a simple UI fix is like a gamble. You might end up with a fix or/and some other bug.

11

I understand that every platform can experience an outage, but I think some people here are normalizing a level of instability that should not be considered acceptable.

Before Bubble, I deployed and managed an application entirely in-house for approximately eight years. During the first two months after launch, we experienced a few periods of downtime while stabilizing the system. After that, the application operated for nearly eight years without any meaningful outages. At most, we experienced a couple of brief slowdowns lasting only a few minutes.

That experience is why I do not accept the argument that frequent outages are simply an unavoidable part of running an application. Good architecture, monitoring, controlled deployments, backups, and responsible release timing can mitigate most of these risks. Of course, nothing guarantees 100% uptime, but there is a major difference between a rare incident and repeated platform-wide outages caused by changes outside the application owner’s control.

I also understand that Bubble removes infrastructure and development complexity. That convenience is valuable, and I am not claiming that AI magically eliminates DevOps or software engineering. However, if a shared Bubble cluster cannot provide reasonable reliability for a production business, telling customers to pay substantially more for a dedicated instance is not a convincing defense. Stability should not be treated as a premium luxury.

With a self-hosted application, I can decide when changes are deployed, monitor the system, roll back a bad release, and avoid pushing architectural changes during an important demo or during my customers’ busiest hours. With Bubble, I carry the business consequences of an outage while having no control over when the underlying changes happen or how quickly they are reversed.

That loss of control is the real issue. Bubble handles DevOps for us, but if the result includes repeated outages at critical times, then DevOps is not truly being handled at the level a serious production application requires.

12

I understand that shared infrastructure has limitations, but I disagree with normalizing repeated outages as something customers should simply accept unless they pay for a dedicated instance.

Before Bubble, I deployed and managed an application in-house for approximately eight years. We experienced some downtime during the first two months while stabilizing the initial launch. After that, we went nearly eight years without any meaningful outages—at most, a couple of brief slowdowns lasting a few minutes.

No system guarantees 100% uptime, but there is a major difference between an isolated incident and recurring platform-wide outages that customers cannot prevent, schedule, or roll back.

Bubble’s value is that it supposedly handles infrastructure complexity. If dependable production uptime requires paying substantially more for a dedicated instance, then stability is effectively being sold as a premium feature. I do not think that should be considered normal or acceptable for businesses already paying to run production applications.

The discussion about AI-managed code is also a separate issue. AI does not eliminate the need for engineering discipline, testing, monitoring, or human oversight. But concerns about AI-generated code do not excuse recurring outages in infrastructure that Bubble itself controls.

13

I would agree with you if the price of an app plan in the shared clusters weren’t already extremely cheap. Since you are already in software development, then you should understand better the work and manpower required to maintain your own infra and why Bubble should charge premium for a dedicated instance.

It’s like paying for a cheap car but expecting it to run as fast as a Ferrari.

I am not excusing Bubble because it really sucks when outages happen during times when my users are most active. I do agree that outages with this level of frequency are bad, but overall Bubble has been improving. The trend for outage frequencies like these usually:

  • always happen in the shared clusters
  • occur when Bubble goes into a season of pushing updates that eventually add bigger features, add general performance optimizations to Bubble apps etc

At the end of the day, you have to make an architectural and/or cost decision to stay in a shared cluster or move to dedicated. You cannot expect to stay in shared, hence paying less, and want the stability of a dedicated plan. Same arguments apply when you decide on a VPS/on-prem hardware, or some random cloud service versus established ones.

14

That is exactly why I am gradually moving my projects away from Bubble and rebuilding them as native applications.

I fully understand the work required to maintain infrastructure—I already did it for approximately eight years. That system was far more stable than what I am experiencing on Bubble’s shared infrastructure. So this is not a hypothetical comparison for me.

The Ferrari analogy also misses the point. I am not expecting dedicated resources or unlimited performance at a shared-plan price. I am expecting a production platform to remain reasonably available. Reliability and premium performance are not the same thing. Recurring outages should not become acceptable simply because the plan is shared.

Saying that outages “always happen in shared clusters” and during periods when Bubble pushes updates does not defend Bubble—it confirms the exact problem. Bubble controls those updates, their timing, testing, deployment strategy, and rollback process. Customers absorb the business consequences without having any control.

So yes, ultimately it is an architectural and cost decision—and I am making mine. Instead of continuing to pay for a platform where basic reliability apparently requires an expensive dedicated instance, I am progressively converting my applications to native code, where I can control the infrastructure, deployments, costs, and recovery process myself.

15

Hey no one’s stopping you. You know what’s best for your project. I usually reply to posts like these to give another perspective for readers.

So how would you structure a deployment pipeline to an infra supporting Bubble’s shared clusters?

16

I get the frustration @dcitellytraining , I’ve been building on Bubble for 4+ years and outages hurt agencies like mine too. We’re the ones on client calls explaining downtime we didn’t cause. I do agree with others’ point of view here.

I don’t think self-hosting is the answer, and I say this as someone who self-hosts n8n on a VPS for automation work. Self-hosting works for tools like n8n because they’re open source, the runtime is a single container, and updates are your problem by design. Bubble is completely different. The editor, runtime, database layer, and deployment pipeline are one tightly coupled system that Bubble ships updates to constantly. If they let us self-host, they’d have to either freeze versions (so you’d miss features and security patches) or build an entire on-prem update and support operation. That’s a massive product in itself, and the customers asking for it are a tiny slice of their base.

There’s also the reality most of us don’t want to admit: the majority of people asking for self-hosting would not actually run production infrastructure better than Bubble does. Managing Postgres, scaling, backups, TLS, monitoring… that’s a full time job. The first time a self-hosted app goes down at 3am, the client blames you, not AWS.

What I’d actually push Bubble for instead:

  1. A real SLA on Dedicated and enterprise tiers with credits when it’s breached
  2. Better incident transparency, like proper post-mortems instead of vague status updates
  3. Regional hosting options so we can pick where our apps live
  4. Editor and runtime isolation, so an editor outage never takes down live apps

Those solve the actual problem (reliability and accountability) without asking Bubble to become a different company.