Respect settings during an environment refresh (control what is overwritten)



Canvas environments beta and test are regularly overwritten with the content and configurations of the production environment. This causes issues where e.g. having a discovery page and navigating to the beta instance,, redirects you to the production discovery page after a environment refresh. Users are then unknowingly logged in to the production environment while thinking they are in beta. I would thereby like to propose an idea where an administrator have the ability to control what is overwritten during an environment refresh and ensure that configurations such as the Authentication are respected.


In a common system (development) life cycle model multiple environments are present to support taking a change from development to production. In this common practice, making changes or new development that is then tested before pushed to production ensures a safe and controlled deployment procedure.



In Canvas, we have a similar environment setup with beta and test (for some). However, the environment behavior in Canvas is quite different from what would be expected. For example, the beta environment is every week overwritten (“refreshed”) with the content and configuration of the production environment. The same apply for the test environment but with a longer frequency, every third week.

Issue description

The existing setup in Canvas where beta and test is overwritten with production content and configuration causes us issues in our development/change process. We constantly must reconfigure global settings and re-import our developer accounts after a environment refresh.

In our Canvas setup we have a discovery page for our production environment ( and a separate Discovery Page for our beta environment ( Users navigating to our production Canvas instance ( are redirected to our production discovery page, if not already authenticated, where they can choose authentication method.

Having a discovery page per environment allows us to perform changes and tests in a controlled fashion before they are pushed to production. A issue we are facing is when the beta or test environments are refreshed with production and our authentication settings are overwritten resulting in users navigating to being redirected to the production discovery page and then signed in to the production instance. The user, unaware they are in the production instance, can then unintentionally do changes on production content!

Another issue we face is with our developers, an external partner to us, who is building an integration engine for some data sources between Canvas and our ERP system. They are using our test environment for the development work and every third week, timely enough for the sprint UAT, they suddenly cannot access the test environment due to the refresh where the authentication settings have been overwritten and their user accounts been dropped.

Before refresh:



After refresh:



Idea suggestion

With the above issue description we would like to suggest an idea where an administrator can control what is pushed and overwritten from production to beta and test. For example we would via some configuration be able to define that e.g. Authentication settings shall be respected and not overwritten during a refresh. The same for accounts where it would be preferred to be able to decide if accounts are overwritten/dropped.

I also support this existing idea suggestion to have different icons for the different environments.


Instructure Alumni
Instructure Alumni
Status changed to: Open
Community Contributor

This is a great suggestion.  Many years ago, we had a major problem related to the propagation of the discovery URL to test and beta.  After that we created a scheduled job that updates specific settings on test and beta every minutes.  This has also allowed us to hook test and beta up to IU's test iDPs, which is standard procedure at Indiana University.

Community Explorer

@leward I could argue that we shouldn't have to create custom jobs/scripts for such things. 🙂 

Community Contributor

@MrAdam I totally agree.  Much of what my team develops is intended to make up for Canvas shortcomings.  When we first got started with Canvas, we had a major disaster due to the propagation of the discovery URL to Canvas Test and Beta that resulted in sending end users to the test instance of Canvas for about a week.  We felt we had no choice but to build something that would prevent this from happening again.

Community Explorer

@leward I see and thanks for sharing.

Chasing votes now, will have to create a marketing campaign to get more attention on this idea. 😀 😉

Status changed to: Archived
Comments from Instructure

As part of the new Ideas & Themes process, all ideas in Idea Conversations were reviewed by the Product Team. Any Idea that was associated with an identified theme was moved to the new Idea & Themes space. Any Idea that was not part of the move is being marked as Archived. This will preserve the history of the conversations while also letting Community members know that Instructure will not explore the request at this time.