Change "Default" Environment


I want to be able to change the default environment.

We have created a new Retool production environment (let's call it "production-new") that we would like to switch to (and get rid of the old one "production"). That is currently not possible.



Hey @david.m! This is on our roadmap, and I just added this thread to the internal ticket for tracking. I'll make sure to update this thread with any news :blush:

Thank you @victoria, I appreciate it. Do you have a rough ETA? :blush:

@david.m no ETA just yet, but I just asked the engineers working on this and will let you know if they have one!

Hi @victoria

We have checked that the new users that we create are getting default environment as Development, is there a way that we can have the users who get Production environment as default?

Hey @Salman! Oh, interesting :thinking: I believe the default environment is set by a cookie (so if you switch an app to Prod, close it, open another app, it'll be in the Prod environment as well). Not sure why all your new users are defaulting to the Dev environment (the environment default should be user/browser specific).

As a potential workaround, you could have your users start off in an app with the _environment URL param set to your Production environment as a way to set their default! Would something like that work for you?

Hey @victoria !

May I ask you if you have any updates on this subject ?

It would actually be really helpful to be able to change the default environment or at least to be able to change the default's environment name which can only be "production"...

Thank you for your precious help ! :smiley:

Hi @Gabriel_Ferrier!

I’m afraid I don’t have great news for you :pensive:

Currently, the team in charge of environments is choosing to prioritize their resources on improving our Source Control feature.

Would you mind sharing a bit more about your use case here/reason why this feature would be helpful so I can pass it along to the team?

Hey, thanks for your response !

Because the default Retool environment is "production" and can't be change, my problem is when I want to block some applications I have on staging for example, to connect and access to the production environment.

My concrete example is :

  • A toolbar menu with 4 applications
  • 4 of them needs to connect to staging
  • But only 2 needs to connect to production (I can easily hide and disable those application but with the url I can still access to the app on any environment and this represent a security alert)

A simple renaming would have worked ; or an action to block an entire app according to the environment.

Thanks for your help

Perfect, thank you so much for that context! Just passed it along. Will keep this thread up to date :slight_smile:

1 Like

Do you have any updates on this topic?

Yes! We do have a bit of an update: the team will be launching the ability to rename the production environment soon. Should be in the next Self-hosted stable release, and on Cloud within about a month. Stay tuned here - we'll confirm back on this topic when that's live. Hopefully that will help get closer toward some of the functionality mentioned in this topic.

Regarding being able to set a default environment for resources, or set a different default environment by app: Victoria's earlier post about the environment that is opened being controlled by a cookie still holds true in terms of current behavior

> the default environment is set by a cookie (so if you switch an app to Prod, close it, open another app, it'll be in the Prod environment as well).

@Savva to confirm my understanding of the functionality you're looking for, are you hoping to set a default environment at the app level, so that an app is always set to staging first when anyone opens the app? Something to keep in mind with this, that could complicate things with this use case, is that all resources in an app need to have access to the selected environment for the app to work. Based on the details of what you're looking for, I can make sure this topic is attached to the relevant internal feature requests and double check on their status.