"Run As →" feature needs to be completely revamped and is borderline illegal

Hello everyone,

We have an app built fully on Bubble + Google Cloud where our enterprise customers are set to process tens of millions of dollars worth of business activity through the app every month. I don’t think it’s secure or correct that we should have access to it or be able to run as anyone from their company.

Yes, I understand this is only accessible to users with database rights, but that’s not how traditionally made apps work. You need specifically implement this feature yourself if you want and if it’s legal in your use case it doesn’t exist by default.

This feature being on permanently makes your app much much harder to get SOC II certified and is also borderline illegal when you’re storing sensitive and personally identifiable user data.

There’s no way Bubble team plans to keep this on forever, it may have been ok in the early days of Bubble but not now or going forward. Here’s how I think this feature should be improved:

Option 1
[ Checkbox in settings ] Allow run as in live mode

Option 2
Off by Design
And users can give you explicit time bound access.

Any thoughts on this Bubble Wizards?


Completely agree. Also, there should be an ‘allow Bubble support access’ checkbox that allows/prevents Bubble employees from viewing the app contents/data.

The exact implementation if the solution is a bit awkward because obviously the app admin can just disable that 'disable run as → ’ checkbox and then run as… would be interested to hear solutions around that.


You mean people from Bubble Support can also run as any user of my app or view their data?? :skull:

1 Like

I can’t confirm that they can run as / view data but given that they help with debugging in many cases and don’t need explicit permission / action from me to do so strongly suggests that. Don’t see how they could debug without database access. I hope at the very least they’re limited to development mode…


Feel free to keep going here, of course (and you might know this already), but this topic has been done to death, and nothing that will be said in this thread will be new or is anything Bubble doesn’t already know. Anyway, carry on.


That’s ok. All we need is an ability to turn it off because then you can be held responsible for your actions and it just falls under secure development practices. It’s just like someone could build out run as feature in traditionally coded app but then they are responsible for it’s legality as they didn’t have to build it out.

If you want to upvote the idea on the ideaboard, here you go.

I must say that I am surprised it doesn’t have more votes.


Feel like our idea of what an average bubble user is doing on Bubble is completely off that’s why some forum-seemingly important features are at the bottom of the priority list from Bubble’s POV.


Well Bubble seems to be shifting more focus towards Enterprises over than individuals. Enterprise cares about this stuff more than individuals/hobbyists, but enterprise clients don’t make ideaboard suggestions :slight_smile:


There’s no way Bubble expects people to build serious apps without turning the feature off permanently with no way to turn it on. There’s no reason for it to exist in live at all (at least what I can think of)

Well, maybe I am doing it wrong, but I use it to troubleshoot in live quite often. I also use it to see the app through the lens of some of the admin-type users on my platform, and they all know and they don’t care at all. True, we aren’t doing anything close to what you described, @rohanjainneri, but I think the feature is invaluable in some ways. I do understand the need to disable it, though.


Well, I love it more than I hate it - it’s indeed invaluable!

Just that it makes a lot of use cases impossible. For example, if someone were in healthcare – HIPAA will get you thousands of dollars of fine per user with this type open access to data.

We’re still not in an extremly sensitive industry so I know the actual users won’t be too mad if we tell them that I have full access to all of their company data and financials but their auditors are for sure giving me a weird look when I tell them that run as exists but "only I can run as and do anything as anyone but I won’t, I promise"


Just don’t use Bubble for HIPAA compliant apps…


Well there are similar rules in a lot of cases

  1. Critical/Sensitive Industries
  2. Dealing with large scale enterprise customers
  3. #2 in #1

Anyway, you can always copy your database from LIVE to DEVELOPMENT and click to “Run as ->” an expecific user. This don’t change much.

And, in the majority of the cases, you don’t need to “Run as->” someone if you already have access to the database itself.

But I don’t see how this could change. Someone, somewhere, will always have the ability to see you database. If not you, someone in Bubble. It not them, someone in Amazon…

1 Like

Amazon CAN’T see your DBs on AWS.

1 Like

We now bring you to the encryption portion of the thread. I told ya, this discussion has been done to death. :slight_smile:


With respect, whether Bubble knows or not isn’t the point. Its customers may not know and even if they do, making enough noise about important security issues occasionally brings about results ala the massive public DB schema issue.

With respect, using upvotes to inform a product roadmap is fine for bells and whistles-type features but is a silly practice for basic infrastructure and security features as the overwhelming majority of Bubblers don’t understand basic DB schema and security.
Imagine if passwords weren’t encrypted and Bubble used the ideaboard to determine if it should encrypt its password—how many years would it take for that to be upvoted high enough?

1 Like

With respect, I knew someone would make the noise argument, and I actually thought it was going to be you, Jacob. :wink:

Bubble themselves want people to use the ideaboard, so silly or not, that’s how it works, friend.


Totally agree. And it gives no-code a bad name and a reputation as a destination for a quick MVP if you’re ok with a insecure and unstable platform while validating your value prop.