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
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.
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!
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.
Hello @tyrone.erasmus. Thanks for sharing your experiences.
I have two questions about your integration, hope you don’t mind me reaching you out directly.
How do you deploy your rules to staging and prod if AUTH0_ALLOW_DELETE=false?
You also mentioned you backup the users before deploying? How do you do that?
Thank you.
Kind regards
Really good questions, unfortunately I don’t have elegant answers to either of them.
Deleting rules is a tricky one with AUTH0_ALLOW_DELETE=false. If we do major refactoring or end up wanting to delete a rule, we first disable the old rule and push that. Then periodically we delete the old rules from the repo and push again. Because of this flag being set, the rule is not actually deleted in Auth0 staging and prod, but once the config has been pushed successfully to these environments they are just deleted manually from the web interface. Not elegant, but it works.
As for backing up users, there is a bit more to the story. Turns out its not really possible to backup all users properly See Full backup of Auth0 users
@tyrone.erasmus thank you for your reply. Really appreciated.
For some reason, I can’t now toggle the enable flag in the rule. If I set to false and run the import, it gets deleted - which is fine. However when I switch it back on, and run the import, it doesn’t recreate the rule. Both of these tried with the AUTH0_ALLOW_DELETE=true.
I’m not getting the real point of this deploy CLI tool.
If there is a risk in deleting the databases with production users, one of things I was considering, not sure you tried before, is to unit test the yaml file. For example fail the build if certain configuration e.g. database connection isn’t present. Assume if there was a configuration change to database connection, it would not delete the database in order to apply what changed(?).
See