How to work with Environments

We just switched from the Free plan to Team, and now have two environments, staging and production (default). I am struggling to fully understand how things work, and would really appreciate some hints, and please correct me if my statements are incorrect..

I think before having the two environments I was expecting to switch to an environment and see everything in that environment, be able to publish from Staging to Production. It seems to be more that you need to configure every app, resource, etc. separately, for how they behave
in each environment.

Questions

  • Is it right that production is the default environment?
    (It doesn't feel intuitive yet, for apps/resources to be created in production before they are created/tested in staging).
  • Is there a way as an admin to see what someone with viewer rights sees?
    (I'm wondering as every app that we had created in our test environment is now in production. I don't understand if there is a need to "remove" these apps)

Hi @jonj

This community post is very helpful! I recommend reading the linked blog post

I think it's true to say production is the default environment because staging isn't required. That said, the environment applies to the resources, rather than the app itself. Switching between staging & production changes the underlying resource to use staging or production credentials. The app UI is typically the same in both environments, unless you're specifically using the retoolContext.environment in your component configs. The release management feature is separate from environments, and it helps with creating different versions of your app to test, build, and release changes without disruption to end users.

On the team plan, everyone that isn't an admin has the same access to view & edit apps & resources. If you upgrade to Enterprise or the Business plan on Cloud, you can create permission groups that only have access to certain apps or resources (they'd have access to both staging & production).

Hi @Tess,

Thank you, that's very helpful, that linked article, definitely helps clarify some really useful information.

I think I'm still not 100% clear on the second part of my post. Some specific questions....

  • When we upgraded, the single environment became production.
    • Does this mean that every app is visible in production? (I think not)
    • Or do apps only become visible when we publish them? (I think yes)
    • If all apps are visible now (or if in the future we want to archive something), how can we "hide" or depublish apps?
  • Is there a way to see an overview of what has been published (including if we are at a higher tier where we can assign custom permissions), without looking at each app?
    • As an admin, I want to be able to review what is visible to our users.

Thanks,
Jon.

Hi Jon,

Apps are always visible in production on every plan. Environments have no impact on app visibility. If you don't enable other environments, your apps will only use production data. If you choose to enable another environment in addition to production, which is always available by default, it only means that you could use the same app with different resource data.

Apps are immediately "published," unless you choose to implement release management. If you use release management you could choose which version is published. In either case, if an app has been created, it is visible to all users that have access to it.

I'm not sure what you mean by depublish an app. You could delete it if you no longer need it, or you could upgrade to the Business plan and control who is able to see it. As soon as you start creating an app on the canvas, it means you have the edit version of the app and the preview/end user version of the app. You don't actively publish or depublish it.

On the Team plan level, all users can see & edit all apps. If you upgrade to Business, you could see a view like this and decide which permission groups can see or edit which apps & resources.

To summarize, on your plan level, if you create an app, it's visible to any user in your org. They can edit it or view it.

The only caveat would be if you share an app publicly. If you are on the Business plan or higher, you can choose to share your apps publicly to anyone with the link. We don't have a dashboard where you can see how many apps have this setting enabled, but you could click Share->Public on each one & enable or disable the setting. Since public apps have no authentication and can be accessed by anyone, they tend to have limited use cases.

Hope this helps, but please let me know!

Hi Tess,

Thank you so much for such a thorough reply. I now definitely have a much clear idea of how environments work in Retool. It also makes the article you originally linked to much clearer. I've done some experimentation this morning too, and that's been really helpful to put things into context.

My questions around depublishing, was mainly thinking that at the Team tier level development would be very public. As you mentioned, using release management will definitely help, as we can make a placeholder draft version the production view until we are ready. I guess it's also thinking about the 50+ experiments we converted with, and the ones we will make in the future. Some of those would be good to have in staging, but not in production. I'm sure I'll find a solution for that.

Thanks again. :blush:
Jon.