Yeah, we wanted to use the Wasabi plugin as well, but the cold start takes way too long
Another prime example of the issues we open ourselves up to with vendor lock-in. These kinds of decisions are prime āweāre a platformā behavior that serious cloud services providers wouldnāt dream of ever pushing out into production.
Optimistic that this will be resolved, though. Thanks for the prompt response @nick.carroll!
7 Likes
Thatās the ācostā of the keeping the credentials hidden from the browser.
2 Likes
Iām an agency, and I canāt expose the name āBubbleā to my customers and my competitors. Thatās a no-go. I pay for the Whitelabel, it doesnāt make sense. I do have a critical product that relies on the files, and thatās not good.
2 Likes
Hi, @nick.carroll thanks for looking into this. Iām attaching the files as URL into an ERP system and my customers will not like seeing the bubble.io cdn information in their files. Canāt you leave only my app name in the file prefix? That would be the perfect world: https://[my_app_name]/[aws_s3]/[file_name]
2 Likes
If you view your page source thereās bubble written all over it.
Your stylesheet also has the appname by default so we have to be careful with the app names 
JW
1 Like
@nick.carroll Or let us put in our own S3 compatible storage API keys and itās no longer any Bubble engineersā problem (to a certain degree) 
1 Like
Yea any Bubble app is covered with hints that itās on Bubble
BuiltWith Technology Profiler chrome extension:
F12 Console:
1 Like
once you open the dev tools you always find a clue on how the app is made. There is also plenty of bots scanning your domain to see what tech is powering your servers. You can even have X-Powered-By headers.
Most of your user will never check that.
But some users are still checking the url of a file 
Edit: I do agree with you that if you want the tech stack of your app to be hidden (if thatās possible at all) you probably want to go full-code instead of using nocode platforms. I can also understand the value of pretty urls for files. I think we should be warned about this kind of changes so that we can act accordingly to our particular needs.
3 Likes
Tell me about it - Iāve been trying to remove those headers but to no avail. Bubble told me it canāt be done 
well, you can actually use cloudflare workers as a reverse proxy and modify any request served from bubble, including headers.
I do use a worker to allow iframe embedding only on a specific domain, leaving the bubble settings untouched.
This is off topic here, but I wonder what was the setup that didnāt work for you.
1 Like
Thank you for flagging this - weāre actively working on addressing this concern. In the meantime, I want to add a bit of context for why this change has been implemented. The previous URL format posed a significant risk as a single point of failure to our users, due to the potential for a few bad actors to take down all user-uploaded files by getting the URL format flagged by common anti-virus software, mainly Microsoft Smartscreen. This update was implemented to mitigate these issues and improve the overall reliability of delivering files to every app.
The URL we changed it to is appname.cdn.bubble.io which should be simpler and more unique to your app, and also should improve the reliability of delivering files to every app. This has the downside of exposing the app name you created originally, which I can 100% understand might not be something you ever expected to see again. I also recognize that you may have concerns about brand management and control, especially if you have a custom domain and app title.
Iām working with our team to explore alternative solutions that would allow us to serve Bubble files without issue while still enabling you to manage your appās brand. Unfortunately, due to the security and reliability implications of this, we had to roll out this update directly. Thank you for the feedback as well as for your patience as we determine the best path forward.
13 Likes
Why not? Your users dont care at all. Your competitors probably wish they can build as quickly as you. You shouldnāt even be concerned about investors. Investors will find out your tech stack before they make a deal either way.
1 Like
You can whitelist your domain in the builtwith website, so no scan on your app. It will not return anything.
Also, most of the ācuesā arenāt referring to ābubble.ioā itself, bubble can be a function (bubble method, for example).
This change has completely broken several pieces of my app as backend workflows, external workflows etc. was setup with the old naming system. I even experience errors when downloading files (that should be public) with something like node-fetch. Jesus what a clusterfuck to not tell us about these changes in advance!
3 Likes
The console mentions are so frustrating. really puts competitors on the front foot. If youāre disrupting an industry with established competitors, itās definitely not ideal to give away how youāre doing it. Having the jump on established competitors is key. Really wish there was a way to hide the console mentions.
1 Like
hi hi! any update here?
@gbenchanoch Just created a new file today, appears now it is
https://[unique id].cdn.bubble.io/f[unique id]/[filename.ext]
I guess half way there not having the app name anymore, but still has the bubble.io domainā¦
2 Likes
Hi all,
Weāve updated this so the hostnames will now read as a [random hexadecimal].cdn.bubble.io. Your appās end users will no longer see your original appname in the URL string, so if youāre using old branding or a deprecated name, you should be all set. I do want to be transparent that we did not change that bubble.io is in the hostname. I understand that this isnāt going to be satisfactory to all customers but that this is the best solution for now that meets our scaling and security needs.
10 Likes
Just posted! Thanks for your patience.
1 Like