Ability to create more environments

Currently ReTool has pre-defined “production” and “stage” environments.
It would be great to be able to create more custom environments.
If you consider this feature valuable in 2nd iteration it would be also great to be able to switch between them from the code/url param.
Our use case:
Currently we use a single on-premise ReTool instance in one of our clusters. We would like to expand it and make ReTool to be available on all clusters. One option would be to just run instance per cluster, enable read-only git sync and put additional load balancer in front of it. And we would like to avoid that.
Having such custom environments where every environment would correspond to specific cluster would solve our issue and make whole configuration and maintenance much easier.


Hello, what’s the status of this feature request?

Not quite sure what happened but while migrating to new forum engine some messages in this topic were gone. Luckily I’ve got a mail with the copy of it:

1 Like

Multiple environments would help for us as well. Our setup is much simpler than OP, we have prod, QA & dev environments. Additionally in dev, we would love to switch between different databases that different developers run.

1 Like

We have the same use case - developers wanting to test changes against local DBs/envs.

+1 This would be really awesome. It’s annoying to have backend features be on the staging environment to begin working on features. It makes developing full stack harder

1 Like

+1 We have 5 which would require 3 instances of each app to fully support.

Is there any prediction of when it will launch? Unfortunately, we cannot use retool in our company today because we have 3 envs (prod, stage, dev).

Sorry @gustavo.teodoro but not on the roadmap quite yet :frowning:

Hi, +1 for the more projects.
Does anyone have idea on how we can hack multiple environments in a single project?

UPD: Implemented a workaround for API resources:

  1. Create a select environment module, and inside:
    1.1. Create env_selector dropdown each value in it represent env “dev”, “staging”, “prod”, etc.
    1.2. Set dropdown’s initial value to localStorage.values.env
    1.3. Create a set_environment script which runs start and upon dropdown update with following content:
const urls = {
  dev: "https://staging.example.com",
  staging: "https://demo.example.com",
  prod: "https://example.com"
const env1 = env_selector.value // naming this variable "env" conflicts with subsequent name of the module
const url = urls[env1]


localStorage.setValue("env", env1) // make sure you do not save any keys to localstorage

1.4. Make sure temporary state state1 exists, it might be just state in this case rename it in script
1.5. Create a url output with value set to {{ state1.value }}
2. Create a base backend resource with no url
3. Add a select environment module to page and name it “env”
4. Use base backend resource with path {{ env.url }}/<your endpoint here>
Can also work with query library if url is passed as a variable.

Otherwise it would be super easy to implement if only global in-memory variables existed which resources could see.