Implications of setting AUTH0_ALLOW_DELETE to true in a0deploy tool

I would like to understand what kind of damage can be done by setting AUTH0_ALLOW_DELETE to true in the config.json file. I don’t see any real explanations in the docs of this parameter.

For context we are running branch-based deployments into 3 different Auth0 tenants for development, staging and production. By merging into the different branches, a build is kicked off that runs a0deploy with the correct config for that tenant/environment. All Auth0 tenant configuration is controlled from code i.e. no one makes any manual changes on the tenants.

At the moment I have set AUTH0_ALLOW_DELETE to true in development. I am now considering what this value should be for staging and (especially) production. I also see that most examples in the Auth0 docs have this value set to false (but with no explanation).

So my main question is: what can go wrong in production with this value set to true? e.g. losing our users would be the ultimate disaster scenario, but I don’t see how this could happen using this tool

1 Like

Welcome to Auth0 community @tyrone.erasmus Great to have you here and what a great first question to start your community contributions.

Can’t comment on what should be best practice here but IMO keeping it false seems safe as then you are not accidentally deleting something if you forgot to include in your config deployment. And you can absolutely destroy your users if you didn’t include your connection config. Because in that case the connection will be deleted and along with all the users that belong to that connection.

Thanks for the response @ashish!

It was a great insight for me that users belong to connections. I suppose I knew that but didn’t consider that they would be removed if the connection got deleted! :grimacing:

For anyone that is interested, this is now our setup.

Development
AUTH0_ALLOW_DELETE=true
Our workflow for enabling new features in Auth0 is to go into the console and enable the feature manually. Then we export tenant config and see what underlying config values have changed (this is because the config is not documented anywhere that I know of). We then do final tweaking on the config and commit it to development, which kicks off a build and then replaces the entire config again. This allows us to keep this tenant very clean and not littered with the various experiments that people have tried.

Staging
AUTH0_ALLOW_DELETE=false
Even though data loss in staging is not critical, we want to keep it as close to production as possible. No manual configuration is ever done here and so we shouldn’t have a bloated configuration (like we would in development if we set AUTH0_ALLOW_DELETE=false)

Production
AUTH0_ALLOW_DELETE=false
Highest stability considerations. Things would have worked in staging before being promoted here. We also do a backup (of tenant config and users) before applying new configuration here.

2 Likes

We are using the identical setup (branch/tenant based CI/CD). Have the same doubts about using AUTH0_ALLOW_DELETE=true in Production.

Off topic but, where do you keep the secrets?

We are aiming for the Jenkins secrets or pre-processing of files but it sure feels like we should get some proper secret management from Auth0.

We store our secrets in parameter store (because we use AWS CodeBuild for CI/CD). Same concept as Jenkins secrets though.

At build time we import these secrets as environment variables and then use the ##NAME## convention in the config that gets replaced with the secret (see https://auth0.com/docs/extensions/deploy-cli-tool/environment-variables-and-keyword-mappings)

Works pretty nicely for us.

2 Likes

Thanks for sharing it with the rest of community!

1 Like