Ability to create more environments

Feature Requests
1

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.

12 Likes
2

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:

image
image1316×1414 231 KB

1 Like
3

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
4

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

1 Like
5

+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
6

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

7

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).

8

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

9

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]

state1.setValue(url)

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.

2 Likes
10

I agree with @frakti . Running multiple retool has been a difficult experience keeping them in sync even with the git workflow (you have to sync all at once or none at all - rather than saying just sync these apps specifically). This causes a lot of things to go stale or out of date for us.

I would go farther and say not only should there be multiple configurable environments but they should be permissions on them as well. For instance you may want some users to only see some environments: end users only see prod - so they cannot accidentally toggle on staging which has happened before, and new hires start with just qa and dev.

That unlocks a lot of developer productivity in having apps in one place, safety of development, and makes keeping apps up to date quite a bit easier. Here's a mockup (you could imagine environments you don't have access to are disabled):

Screen Shot 2021-05-03 at 2.20.58 PM

11

Also in need of this, specifically a "development" one. I wonder how challenging would be to build it considering that there's already a system in place for staging, if it were just production it would make more sense that this is setting here for over 1,5 years already.

12

This is a major hurdle for us as well at the moment - we have Production, Staging and Sandbox environments, so using all 3 means having to swap out the environment config temporarily.

13

It's crazy to me that this has been an issue since 2019. I understand that it might not be dead simple to implement, but surely it shouldn't take over a year to add more environments.

This is a major annoyance for us, and definitely will give us pause when deciding if we want to go the retool route in the future.

Ideally, we could have any number of environments, so we can hook up ngrok, so we can develop locally. I understand that may be complicated, but 3: dev, staging, and prod should be doable. It's a very common workflow for tons of companies.

14

+1 would also really love to have Dev, Staging and Prod

15

Hi all!

I'm an engineer at Retool and we've kicked off work on adding the ability to create more environments. We're targeting releasing it sometime in Q4 -- thanks for your patience!

Best,
Moksh

3 Likes
16

Thanks for the update. Looking forward to this feature.

17

Hi Moksh. Is there any update on when this feature may be available?

18

Hey @ttg it'll be ready in a few weeks! We are just doing some final polish an QA -- thanks for your patience so far!

2 Likes
19

Any progress on this?

20

It's almost ready! It's still being tested internally now, but just a few more weeks until it's released to Cloud users. I'll keep you updated in this thread once it's live! :pray:

2 Likes