(Probably) Account-Breaking Experiment Desired - Help Wanted

[mathcatsand]

I wanted to experiment with moving repositories between personal and organization accounts. With the limitations of the GitHub API giving Streamlit Cloud access to everything I’ve been thinking it may be good practice to put all my Streamlit Cloud repositories in a dedicated organization so I can get the limited access that would be more in line with security best-practices.

However, I fully expect to break my account several times over with all the variations I want to test. I would like to write up a tutorial about how to migrate from personal to organization and also from organization to personal, without breaking anything, so I’d like to know the limitations there and basically try to break things a little bit on purpose…for educational reasons. (i.e. I am part engineer.)

I have concerns about possibly losing an app name in the process as well as maybe just catastrophically breaking the account. So…if a staff member knows the ins and outs related to such migration…or if a staff member would be interested in a collaboration/buddy-system and wouldn’t mind a day of constant “Please can you fix my account again? Thanks.” Let me know! I’m not quite adventurous enough to just do it since I have one app I’ve shared repeatedly already…

[andfanilo]

Hey @mathcatsand !

I don’t remember who exactly is maintaining Cloud, I’ll loop @Caroline in so she can bring the correct people if any of your older App URLs becomes inaccessible.

Though I’ve been deleting and recreating multiple apps in the past year, transferring an App URL from an older app to a newer one. While I didn’t move apps between organizations, I don’t think you’ll have one that demand an admin intervention if you delete an app, move your project in an org, and recreate the app from that org. (though I got a lot of emails about SSH Keys being recreated XD). Did you come accross problems when you tried on your side with a dumb empty project, like your App URL being not available for a few hours when recreated in the new org?

The only real bummer would be if someone steals your App URL during the few minutes in your migration process.

If you really worry about losing your App URL on the one you massively shared, you could also create a new App URL for the new app in your org, notify people about the new URL, put a deprecation message in your older app telling users to redirect to the new domain, and destroy the older one a month later, when you think everyone moved to the new URL.

Hope I understood your concerns correctly have a nice day breaking Streamlit Cloud

[mathcatsand]

I did figure the safest thing would be to delete all deployments, revoke the connection, then redeploy once everything was changed on the github side. It remains to be seen how easily app names can be grabbed again as they might remain “reserved” for a time even if their previous apps were deleted. I don’t have anyone in particular to notify, it’s just that I have dozens of links to pages on my example app all over this forum and just wanted to try and keep the existing app name for convenience. I don’t think it would get snatched away since it includes my username, but I don’t know how quickly Streamlit releases reservations and it’s done some very weird allowed/not-allowed indications when I tried name variations on an app…

I did not try anything with a junk app because there are so many examples on the forum of people not being able to get to their admin panel when Streamlit Cloud got confused about something on GitHub. I’m not even sure if trying to authorize an organization in addition to personal would cause such confusion.

[Caroline]

Hi @mathcatsand, if you delete the apps in Streamlit Community Cloud before deleting or renaming them in GitHub, you should be all set! Custom subdomains are a little more complicated – ideally, should be able to reclaim it after you’ve deleted the original app, but we’re still working on this system.