Auth0 Deploy CLI

The token_vault_privileged_access property allows you to harden a privileged Token Vault worker by restricting caller IPs, connections, and scopes.

Important: This field is Export-only.

While the Deploy CLI exports this property for visibility (showing ip_allowlist and grants), it will not deploy these settings. The property is stripped from all create/update payloads during deployment because the underlying Management API requires specific tenant-resident credential IDs that are not portable across tenants.

To manage token_vault_privileged_access, you must use the Auth0 Management API or the Auth0 Dashboard directly.

# Exported shape (visible in CLI export, but not deployable)
clients:
  - name: My Token Vault Privileged App
    app_type: non_interactive
    token_vault_privileged_access:
      ip_allowlist:
        - '192.168.1.0/24'
      grants:
        - connection: google-oauth2
          scopes:
            - 'https://www.googleapis.com/auth/calendar.readonly'

The prompts resource allows you to customize Universal Login pages. You can configure custom multilingual text, inject custom HTML via partials, and set specific rendering settings for prompt-screen combinations.

Custom Text

Translations follow a hierarchy: language code → prompt ID → screen ID → text ID.

Partials

Custom HTML injected at specific insertion points. In Directory Mode, you must provide a partials.json manifest that maps insertion points to .liquid files (paths relative to the prompts/ directory).

Screen Renderers

Used to configure rendering settings for specific prompt-screen combinations (e.g., setting rendering_mode to advanced or adding head_tags).

// Example partials.json manifest in Directory Mode
{
  "login": [
    {
      "login": [
        {
          "name": "form-content-start",
          "template": "partials/login/login/form-content-start.liquid"
        }
      ]
    }
  ]
}

The Auth0 Deploy CLI supports two configuration formats for expressing Auth0 resource state. You are prompted to choose between these formats when running the export command. While both formats achieve the same goal, they differ in structure and management style:

YAML

• Structure: Primarily a single, flat tenant.yaml file, supplemented by individual code files for specific resources like Actions or Email Templates.
• Best for: Version control tracking. A single file makes it easier to see changes over time in a git history and avoids ambiguity regarding directory/file naming conventions.

Directory (JSON)

• Structure: Separates resource types into distinct directories, where every individual resource is stored in its own dedicated .json file.
• Best for: Conceptual separation. This format mirrors the data shapes used in the Auth0 Management API, making it easier to map CLI configurations to API documentation.

Note: This choice is not permanent. You can switch between YAML and Directory formats using the import command.

The Deploy CLI supports dynamic keyword replacement to allow sharing the same resource configuration files across multiple tenants while injecting environment-specific values.

To enable this, define your mappings in the AUTH0_KEYWORD_REPLACE_MAPPINGS configuration property. You can then inject these values into your resource configuration files (YAML or JSON) using two different syntaxes depending on how you want the value to be treated:

• @@EXAMPLE_KEY@@: Performs a JSON.stringify on the value before replacement. Use this for strings (adds quotes), arrays, or objects (adds braces).
• ##EXAMPLE_KEY##: Performs a literal replacement without adding quotes or braces. Use this for raw text or when you need to manually control the formatting.

Environment variables are automatically added to the replacement mappings, so you can reference them using the same syntax.

{
  "AUTH0_KEYWORD_REPLACE_MAPPINGS": {
    "ENVIRONMENT": "dev",
    "ALLOWED_LOGOUT_URLS": ["https://dev-test-site.com/logout", "localhost:3000/logout"],
    "ALLOWED_ORIGINS": ["https://dev-test-site.com", "localhost:3000"]
  }
}

When managing Auth0 resources with the Deploy CLI, it is critical to distinguish between these three states:

1. Exclusion

Forcefully ignores configurations bi-directionally (both export and import) using properties like AUTH0_EXCLUDED. The CLI will not read from or write to these resources.

2. Omission

Resource configuration that is absent from your configuration files.

• Import: Omitted resources are skipped and will not be altered in the remote tenant.
• Export: All tenant configurations are written to files unless explicitly excluded.

3. Empty

Explicitly defining a resource as an empty set (e.g., [] or {}).

• Set-based resources (e.g., hooks, organizations, actions): Setting these to an empty set signals an intentional deletion of those resources (requires AUTH0_ALLOW_DELETE to be enabled).
• Non-set-based resources: Behavior depends on the resource. tenant, branding, attackProtection, and guardianPhoneFactorSelectedProvider cannot be deleted, while emailProvider can be deleted via an empty configuration.

# Omission: This resource is managed, but other missing keys are skipped
roles: 
  - name: Admin

# Empty: Signals intentional deletion (if AUTH0_ALLOW_DELETE is enabled)
connections: [] 

# Empty: Effectively a no-op for non-deletable resources
tenant: {}

# Empty: Will delete the email provider
emailProvider: {}

To deploy the same configuration across multiple environments (dev, staging, prod), use keyword mappings to inject environment-specific values like callback URLs or timeouts.

Values can be defined in your terminal environment variables or within config.json. Terminal variables take priority over config.json. You can disable this merging behavior using the --no-env flag.

There are two syntax types for injection in your configuration files:

1. @@key@@: Injects the full, literal value regardless of type (string, number, object, or array).
2. ##key##: Used for string interpolation.

Example Usage:

Client.json:

{
  "callbacks": [ "##ENVIRONMENT_URL##/auth/callback" ],
  "jwt_configuration": {
    "lifetime_in_seconds": @@JWT_TIMEOUT@@
  }
}

Dev Config.json:

{
  "AUTH0_KEYWORD_REPLACE_MAPPINGS": {
    "ENVIRONMENT_URL": "http://dev.fabrikam.com",
    "JWT_TIMEOUT": 120
  }
}