Incorporate into Multi-environment Workflows
The Deploy CLI supports working within a multi-tenant, multi-environment context. When integrated into your CI/CD development workflows, can be used to propagate Auth0 changes from feature development all the way through production.
In general, the advised workflow is as follows:
- Create a separate Auth0 tenant for each environment (development, staging, production).
- Create a single repository of resource configuration files for all environments.
- Add a step in your CI/CD pipeline when deploying to environments that applies the Auth0 resource configurations to the appropriate Auth0 tenant.
Tenant to environment
It is recommended to have a separate Auth0 tenant/account for each environment you have. For example:| Environment | Tenant |
|---|---|
| Development | travel0-dev |
| Testing | travel0-uat |
| Staging | travel0-stage |
| Production | travel0-prod |
Resource configuration repository
When exported, your Auth0 tenant state will be represented as a set of resource configuration files, either in a YAML or directory format. In a multi-environment context it is expected to have a single repository of resource configurations that is applied to all environments. In practice, this may exist as a directory in your project’s codebase or in a separate codebase altogether. You should have at least one branch for each tenant in your repository, which allows you to make changes without deploying them. This way, changes will only deploy when you merge the working branch into the primary branch (such asmain or master). With this setup, you can have a continuous integration task for each environment that automatically deploys changes to the targeted environment whenever the primary branch receives updates.
Your workflow could potentially look something like this:
- Make changes to development.
- Merge changes to testing (or uat).
- Test changes to uat. When ready, move and merge the changes to staging.
- Test staging. When ready, move and merge the changes to production.
Unidirectional flow
The multi-environment workflow works best when changes are propagated “up” in a single direction. Changes to the resource configuration files should first be applied to the lowest level environment (such as development) and then incrementally applied up through all other environments until applied to production. This unidirectional practice ensures sufficient testing and approval for changes to your tenant. Once set, it is recommended to not apply configurations directly to production through other means such as the or unless those changes are captured by a subsequent Deploy CLI export. Otherwise, those changes are subject to overwrite.Environment-specific values
While it is expected that all environments will share the same set of resource configuration files, environment-specific values can be expressed through separate tool configuration files and dynamic Keyword Replacement.Separate configuration files
Specifying a separate tool configuration file per environment can be used to keep the resource configuration files agnostic of the environment, but still support the needs of each environment. At a minimum, you will need to provide separate credentials for each environment, but it is also possible to exclude certain resources, enable deletion, and perform dynamic keyword replacement on a per-environment basis.Example file structure
Dynamic values with keyword replacement
Once separate configuration files are adopted for each environment, keyword replacement through theAUTH0_KEYWORD_REPLACE_MAPPINGS configuration property can be used to express the dynamic replacement values depending on the environment. For example, you may find it necessary to have a separate set of allowed origins for your clients. To learn more, read Keyword Replacement.