--- title: Manage an existing PingOne DaVinci environment description: The following guide walks you through the process of using the Ping CLI Terraformer plugin to: component: terraform page_id: terraform::products/pingone/tutorials/manage-existing-davinci-environment canonical_url: https://developer.pingidentity.com/terraform/products/pingone/tutorials/manage-existing-davinci-environment.html revdate: April 13, 2026 section_ids: prerequisites: Prerequisites set-up-authentication: Set up authentication export-terraform-configuration: Export Terraform configuration command-flags: Command flags review-and-apply-generated-configuration: Review and apply generated configuration configure-provider: Configure provider update-secret-values: Update secret values generate-a-plan: Generate a plan what-to-expect-in-the-plan: What to expect in the plan resources-to-be-imported: Resources to be imported configuration-updates: Configuration updates apply-the-configuration: Apply the configuration establish-continuous-development: Establish continuous development development-lifecycle: Development lifecycle initialize-version-control: Initialize version control commit-your-configuration: Commit your configuration next-steps: Next steps troubleshooting: Troubleshooting import-failures: Import failures secret-value-errors: Secret value errors plan-shows-unexpected-changes: Plan shows unexpected changes additional-resources: Additional resources --- # Manage an existing PingOne DaVinci environment The following guide walks you through the process of using the Ping CLI Terraformer plugin to: * Export and generate Terraform HCL configuration from an existing PingOne DaVinci environment. * Review and apply generated configuration. * Begin establishing a continuous configuration management workflow using version control. ## Prerequisites Before you begin, ensure you have: * An existing PingOne environment with the DaVinci service enabled and configuration applied. * A worker application with **at least** the **DaVinci Admin Read Only** role to read the live configuration. * The `pingcli-terraformer` command-line tool installed. Refer to the [Ping CLI Terraformer plugin repository](https://github.com/pingidentity/pingcli-plugin-terraformer) for installation instructions. * Terraform 1.5 or later installed. * Git for version control (optional, but recommended). | | | | - | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | | You will need a higher role, such as **DaVinci Admin** or a custom role with write access to the [flow export endpoint](https://developer.pingidentity.com/pingone-api/davinci/davinci-admin-apis/admin-flow-versions/export-flow-version.html), on the worker application to generate DaVinci Variable dependencies within DaVinci Flows. If the `pingcli-terraformer` tool can't access the endpoint, a warning will be returned and generation of the dependency will be skipped. | ## Set up authentication Configure your worker application credentials for use by the `pingcli-terraformer` tool: ```bash export PINGCLI_PINGONE_ENVIRONMENT_ID="" export PINGCLI_PINGONE_CLIENT_CREDENTIALS_CLIENT_ID="" export PINGCLI_PINGONE_CLIENT_CREDENTIALS_CLIENT_SECRET="" export PINGCLI_PINGONE_REGION_CODE="NA" # or EU, AP, CA, AU ``` ## Export Terraform configuration Use the `export` command to generate Terraform HCL from your live environment. The export: * Reads all Terraform-supported resources in the live environment. * Converts API responses to a reusable Terraform module. * Abstracts environment-specific values to variables. * Maps dependencies between resources for deployment ordering. For managing an existing environment, run the export with the `--include-imports` and `--include-values` flags: ```bash pingcli-terraformer export \ --include-imports \ --include-values ``` ### Command flags | Flag | Description | `--include-imports` | | ------------------------------------------------------------------------------------------------------------------------------ | ------------------ | ----------------------------------------------------------------------------------------- | | Generates import blocks for each identified resource, enabling you to bring existing infrastructure under Terraform management | `--include-values` | Produces a `terraform.tfvars` file populated with actual values from the live environment | The export creates a version-control-ready module that can be used standalone or composed into a larger root module. ## Review and apply generated configuration Next, you will review the generated configuration to prepare for what will occur in a subsequent apply. ### Configure provider The export generates a `versions.tf` file that specifies the expected PingOne Terraform provider version. You can add provider authentication directly to this file or supply credentials through environment variables. You can find details in the [Provider Authentication documentation](https://registry.terraform.io/providers/pingidentity/pingone/latest/docs#provider-authentication). Run `terraform init` to initialize the provider and download dependencies: ```bash terraform init ``` ### Update secret values PingOne DaVinci has secret attributes (such as client application secrets) that are **not readable using APIs**. You must update these manually before importing: 1. Open the generated `ping-export-terraform.auto.tfvars` file. 2. Locate and update all fields marked as `# Secret value - provide manually`. | | | | - | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | All of the variable values in the `ping-export-terraform.auto.tfvars` could be considered sensitive or environment specific. This file should not be committed to version control. For automated Terraform deployments, the values to these secrets should be managed through the deployment tool or secrets manager. | ### Generate a plan Output the plan to a file for review: ```bash terraform plan -no-color > tfplan-1.txt 2>&1 ``` ### What to expect in the plan The size of your Terraform plan will correspond to the size of your live infrastructure. The initial `terraform plan` and `terraform apply` process can produce the described actions. #### Resources to be imported The majority of the resources will show as items that will be brought under Terraform management without any interaction with the live infrastructure. This indicates that the defined HCL for the resource matches what would be stored in state exactly. For example, `module.ping-export.pingone_davinci_variable.pingcli__myVar_flowInstance will be imported`. The generated `ping-export-imports.tf` file includes an import block and a commented-out `terraform import` command for each discovered resource. The import commands can be run in a terminal prior to `terraform apply` to minimize the size of the Terraform plan and focus on items that can indicate live infrastructure interactions. For an environment with around 100 resources, this sequential import process takes approximately 5 minutes. #### Configuration updates Resources that show `will be updated in-place` typically indicate that there will be an API call made to the live infrastructure. Some updates might be considered non-functional changes, even though there's an API call made to the live infrastructure. There could be cases where functional and non-functional changes are identified on the same resource, so you should carefully review all planned changes before moving forward. Common planned changes include: * **Default values**: The Terraform provider includes default values for certain attributes to maintain consistency in continuous management. For example, the DaVinci Flow resource schema expects a `default_log_level` of `4`, so this value is injected in the generated HCL, even if it's not found on the API read. This change will run an API `PUT` to update the flow to bring the live infrastructure into alignment with the defined configuration. * **Deploy triggers**: If there is an update to a flow, the current version and published version will be out of sync, so the generated configuration will also look to `deploy` the flow for realignment. * **Computed values**: Changes marked with `~` and ending in `(known after apply)` represent computed attributes updating to their refreshed state. These are non-functional. A resource whose plan shows only computed updates will not appear as an item to change. * **Resources with secret values**: The PingOne API doesn't allow reading values of attributes that are considered secrets. For these values, the Terraform provider only looks for mismatches between what is stored in state and what is defined in configuration, rather than refreshing state against live infrastructure. If a `terraform import` command was run prior to this step, an obfuscated value will show in Terraform state. The identified change directs the Terraform provider to run an API `PUT` to bring the resource into alignment. This is a common case for Connector Instances that include client secrets as values. The `properties` attribute of a Connector Instance is considered sensitive, and child values are grouped together. You must be careful to ensure that your defined configuration on such resources is exact before running `terraform apply`. The following is an example of a `terraform plan` output after running `terraform import` commands: ```text # module.davinci.pingone_davinci_flow.my_flow will be updated in-place ~ resource "pingone_davinci_flow" "pingcli__OOTB-0020---0020-Account-0020-Recovery-0020-by-0020-Email" { ... ~ current_version = 1 -> (known after apply) ~ settings = { + log_level = 4 } # (4 unchanged attributes hidden) } # module.ping-export.pingone_davinci_flow_enable.pingcli__OOTB-0020---0020-Account-0020-Recovery-0020-by-0020-Email will be updated in-place ~ resource "pingone_davinci_flow_enable" "pingcli__OOTB-0020---0020-Account-0020-Recovery-0020-by-0020-Email" { ~ enabled = true -> (known after apply) id = "01af583c6b951086992eb3c37aed7af5" # (2 unchanged attributes hidden) } ``` ### Apply the configuration After you're satisfied with the plan: ```bash terraform apply ``` After approving the plan, your PingOne DaVinci environment is fully managed by Terraform. ## Establish continuous development With your existing environment under Terraform management, you can adopt a continuous configuration management workflow. ### Development lifecycle The typical development lifecycle: 1. Build features or changes in the PingOne UI. 2. Export those changes using `pingcli-terraformer export`. 3. View changes with your IDE or using `git diff --unified=0`. 4. Validate in Terraform. `terraform plan` should refresh state against the live environment and result in no changes required. 5. Commit to version control so changes can be picked up by automated pipelines. 6. Promote to higher environments through your CI/CD pipeline. ### Initialize version control If you haven't already, initialize a Git repository: ```bash git init ``` Create a `.gitignore` to exclude sensitive and generated files: ```none # Terraform .terraform/ .terraform.lock.hcl *.tfstate *.tfstate.* tfplan* # Sensitive or environment-specific .env .env.* *.tfvars *imports.tf ``` ### Commit your configuration ```bash git add . git commit -m "Initial Terraform configuration for DaVinci environment" ``` ### Next steps * Set up a CI/CD pipeline to automate `terraform apply` for higher environments * Establish branching strategies for development, staging, and production * Document your team's workflow and approval processes * Consider using Terraform workspaces or separate state files per environment ## Troubleshooting ### Import failures * Verify that your Terraform provider worker application has the correct **DaVinci Admin** role * Check that the resource IDs in the generated imports file are correct * Ensure Terraform 1.5 or later is installed ### Secret value errors * Confirm that all fields marked `# Secret value - provide manually` in the generated `terraform.tfvars` file have been updated * Verify that secret values are correctly formatted (no extra spaces or newlines) ### Plan shows unexpected changes * Review the diff carefully: some resources might receive default values on first apply * Check whether API responses have changed since the export was generated * Re-run the export if the environment was modified during the import process ## Additional resources * [Ping CLI Terraformer repository](https://github.com/pingidentity/pingcli-plugin-terraformer) * [Terraform import documentation](https://www.terraform.io/docs/cli/import/index.html) * [PingOne DaVinci documentation](https://docs.pingidentity.com/davinci)