CD3 Automation Toolkit for Oracle Cloud: Accelerate OCI Deployments with Standardized Automation

 TechVisions  •  Enterprise AI & Oracle Cloud

Oracle Cloud Infrastructure · Infrastructure as Code

Accelerating OCI Infrastructure Management with the CD3 Automation Toolkit

From Excel design sheets to production-grade Terraform — a real-execution walkthrough of Oracle's CD3 toolkit, covering Greenfield provisioning, brownfield export, Jenkins pipelines, and the new AI-assisted plan analysis.

Technical Blog Toolkit Release: v2026.1.1 June 2026

Table of Contents

1. Introduction
2. What is OCI CD3?
3. What's New in 2026 (v2026.1.x)
4. Why Organizations Adopt CD3
5. Lab Environment and Prerequisites
6. Step 1 — Build and Launch the CD3 Container
7. Step 2 — Connect the Container to Your OCI Tenancy
8. Step 3 — Greenfield Workflow: Excel to Terraform
9. Step 4 — Non-Greenfield Workflow: Export Existing OCI Resources
10. Step 5 — Jenkins and DevOps Pipeline Integration
11. AI-Assisted Terraform Plan Analysis
12. Generated Directory Structure Reference
13. Key Benefits and Field Recommendations
14. Conclusion
15. References

1. Introduction

Managing cloud infrastructure at scale is rarely simple. As Oracle Cloud Infrastructure (OCI) environments grow, cloud teams face increasing challenges around consistency, governance, documentation, and Infrastructure as Code (IaC) adoption.

While Terraform has become the de facto standard for cloud automation, creating and maintaining Terraform configurations for large OCI estates is time-consuming and error-prone. Even with IaC in place, managing large volumes of input variables across multiple modules introduces significant overhead.

The CD3 Automation Toolkit (Cloud Deployment Design Deliverable) addresses this challenge by bridging the gap between infrastructure design and Terraform-based deployment. CD3 enables organizations to build, export, and manage OCI resources using familiar Excel templates while automatically generating Terraform artifacts behind the scenes — and, as of the 2026 releases, evaluating those Terraform plans with AI assistance before anything reaches your tenancy.

This post is a real-execution walkthrough: every command shown below is taken from the official toolkit documentation and reflects the current v2026.1.x release line, so you can follow along in your own tenancy.

2. What is OCI CD3?

CD3 stands for Cloud Deployment Design Deliverable. It is an Oracle-developed automation framework (published by Oracle Developer Relations under the Universal Permissive License v1.0) that converts structured Excel-based infrastructure designs into deployable Terraform configurations for OCI.

The toolkit also supports reverse engineering: it can export an existing OCI environment into the same Excel templates and generate Terraform code plus state-import commands, allowing organizations to bring manually created (unmanaged) resources under IaC governance without rebuilding anything.

2.1 Supported OCI Services

The toolkit covers a broad slice of the OCI service catalog:

Domain	Services Supported by CD3
Identity & Governance	IAM/Identity, Tagging, Quotas, Budgets, Policy Enforcement using OPA
Networking	VCNs, Subnets, Gateways, DNS Management, Load Balancers, OCI Network Firewall (incl. tunnel inspection), IPv6
Compute & Containers	Compute Instances, Dedicated VM Hosts, OKE (Oracle Kubernetes Engine), SDDCs (OCVS)
Storage	Block Volumes, Object Storage, File Storage
Databases	Oracle DB Systems, Exadata DB Homes, CDBs and PDBs, MySQL Database, ADB@Azure (multicloud)
Security & Observability	Cloud Guard, KMS, Logging Services, Monitoring, Events, Notifications
Operations & Reporting	Resource Manager, SHOWOCI report, CIS Compliance Report

3. What's New in 2026 (v2026.1.x)

The current release at the time of writing is v2026.1.1, published on May 8, 20261. Highlights from the recent release line:

Release	Key Changes
v2026.1.0 (Mar 2026)	Introduced optional AI-based summary of Terraform plans in Jenkins pipelines (the "AI Analysis" capability); added support for Exadata DB Homes, CDBs and PDBs; deprecated OpenTofu support — the toolkit is now Terraform-focused.
v2026.1.1 (May 2026)	Maintenance release with fixes across the 2026.1 line (including identity export and OKE/MySQL related bug fixes).
2025 releases	ADB@Azure multicloud support; new MySQL Database service; OCI Network Firewall tunnel inspection; IPv6 networking support; Jenkins pipelines automatically invoke rule exports after a successful terraform apply; transition from createTenancyConfig.py/setUpOCI.py to the new connectCloud.py/setUpCloud.py entry points.

Migration note: If your runbooks still reference python createTenancyConfig.py tenancyconfig.properties, update them. In current releases the documented commands are python connectCloud.py oci connectOCI.properties and python setUpCloud.py oci <properties>. The legacy scripts are deprecated.

4. Why Organizations Adopt CD3

4.1 Simplified Infrastructure as Code Adoption

Many enterprises struggle with Terraform adoption because not every infrastructure engineer is comfortable writing HCL. CD3 allows teams to define infrastructure requirements in Excel spreadsheets, making cloud automation accessible to a broader audience. The toolkit automatically generates the Terraform variables and wires them into prebuilt modules.

4.2 Faster Provisioning

Instead of manually creating resources through the OCI Console or writing Terraform modules from scratch, engineers populate predefined templates and generate deployment-ready code within minutes. In our delivery practice at TechVisions, this consistently compresses landing-zone build timelines from weeks to days.

4.3 Infrastructure Standardization

CD3 promotes standardization by enforcing consistent templates and deployment patterns across environments. Approved architectures — including CIS-aligned landing zones via the CD3-CIS-template.xlsx — can be reused across DEV, TEST, and PROD6.

4.4 Managing Existing OCI Environments

One of CD3's most valuable capabilities is exporting existing OCI resources into Excel templates and Terraform state. This lets teams transition manually built environments into managed IaC workflows without rebuilding — covered hands-on in Section 9.

5. Lab Environment and Prerequisites

CD3 ships as a container image you build locally, so the host requirements are light:

Requirement	Detail
Container engine	Docker, Podman, or Rancher Desktop
Git	To clone oracle-devrel/cd3-automation-toolkit
OCI access	A user with API key, session token, or instance principal authorization
Linux host specifics	Create a local cd3user (UID 1001); set SELinux to permissive for volume mounts

terminal — host preparation (Linux VM)

# Prepare the cd3user and the mount path (Linux hosts)
$ sudo useradd -u 1001 cd3user
$ sudo mkdir -p /cd3user/mount_path
$ sudo chmod 775 -R /cd3user
$ sudo chown -R cd3user:cd3user /cd3user

# Clone the toolkit repository
$ git clone https://github.com/oracle-devrel/cd3-automation-toolkit.git
$ cd cd3-automation-toolkit

6. Step 1 — Build and Launch the CD3 Container

Build the image with your user UID and (optionally) DevOps/Jenkins support baked in, then run it with the tenancies directory mounted and port 8443 exposed for the Jenkins UI:

terminal — build and run the CD3 container

# Build the image (USE_DEVOPS=YES enables Jenkins + OCI DevOps integration)
$ docker build --build-arg USER_UID=1001 --build-arg USE_DEVOPS=YES \
    -t cd3_toolkit:${image_tag} .

# Launch the container; 8443 is the Jenkins port
$ docker run -it -d -p 8443:8443 \
    -v <local_dir>:/cd3user/tenancies \
    --name cd3_toolkit cd3_toolkit:${image_tag}

# Enter the running container
$ docker exec -it cd3_toolkit bash
[cd3user@cd3-container ~]$

Tip: The -v <local_dir>:/cd3user/tenancies mount is what makes your Excel sheets, generated Terraform, and state files survive container rebuilds. Treat that directory as your IaC working tree and back it up (or better — let CD3 push it to an OCI DevOps Git repo, Section 10).

7. Step 2 — Connect the Container to Your OCI Tenancy

Inside the container, edit connectOCI.properties and run connectCloud.py. This replaces the legacy createTenancyConfig.py flow.

7.1 Key fields in connectOCI.properties

Parameter	Purpose
prefix	Customer/environment name; creates /cd3user/tenancies/<prefix>/
auth_mechanism	api_key, session_token, or instance_principal
key_path	PEM private key path (api_key only); defaults to /cd3user/tenancies/keys/oci_api_private.pem
fingerprint	API key fingerprint (api_key only)
outdir_structure_file	Controls whether generated tfvars are grouped per service directory or in a single directory per region
use_oci_devops_git / oci_devops_git_key	Enables push of generated code to OCI DevOps Git repositories
use_remote_state	Generates S3-compatible credentials to store Terraform state in OCI Object Storage

terminal — connect to the tenancy

[cd3user@cd3-container ~]$ cd /cd3user/oci_tools/cd3_automation_toolkit/
[cd3user@cd3-container cd3_automation_toolkit]$ vi connectOCI.properties

# Run the connection script (replaces the legacy createTenancyConfig.py)
[cd3user@cd3-container cd3_automation_toolkit]$ python connectCloud.py oci connectOCI.properties

Creating Tenancy specific directories.....
Generating /cd3user/tenancies/demo/demo_setUpOCI.properties
Generating region based directories under terraform_files/
Writing OCI config to /cd3user/tenancies/demo/.config_files/demo_oci_config
Tenancy connection successful.

On success, the script creates the prefix folder /cd3user/tenancies/<prefix>/ containing the customer-specific <prefix>_setUpOCI.properties, region directories under terraform_files/, provider/variables files per region, the OCI config file, and — when enabled — the Jenkins Git config and S3 credentials for remote state5. Re-running connectCloud.py later is safe: existing region directories are kept and directories for newly subscribed regions are added.

8. Step 3 — Greenfield Workflow: Excel to Terraform

For new OCI deployments, the flow is: fill the Excel template, point setUpOCI.properties at it, run setUpCloud.py, then run Terraform in the generated region/service directory

8.1 Fill the CD3 Excel template

Use the versioned template (for CIS-aligned landing zones, CD3-CIS-template.xlsx) and populate the service tabs — VCNs, Subnets, Instances, Policies, and the other tabs relevant to your design. Copy the completed workbook to /cd3user/tenancies/<prefix>/.

8.2 Point the properties file at your workbook

file — /cd3user/tenancies/demo/demo_setUpOCI.properties

# Input variables required to run setUpCloud script
# path to output directory where terraform files will be generated
outdir=/cd3user/tenancies/demo/terraform_files/

# input config file for Python API communication with OCI
config_file=/cd3user/tenancies/demo/.config_files/demo_oci_config

outdir_structure_file=/cd3user/tenancies/demo/demo_outdir_structure_file.properties

# path to cd3 excel
cd3file=/cd3user/tenancies/demo/CD3-demo.xlsx

# create_resources for Greenfield | export_resources for Non-Greenfield
workflow_type=create_resources

8.3 Run setUpCloud.py and pick services from the menu

terminal — generate Terraform from Excel

[cd3user@cd3-container ~]$ cd /cd3user/oci_tools/cd3_automation_toolkit/
[cd3user@cd3-container cd3_automation_toolkit]$ python setUpCloud.py oci \
    /cd3user/tenancies/demo/demo_setUpOCI.properties

Workflow: create_resources (Greenfield)
Select the services to process:
  - Identity   (Compartments, Groups, Policies)
  - Network    (VCNs, Subnets, DHCP, Route/Sec Rules)
  - Compute    (Instances, Dedicated VM Hosts)
  - Storage    (Block Volumes, FSS, Buckets)
  - Database   (DB Systems, Exadata, MySQL)
  - CD3 Services (Fetch Compartments OCIDs to variables file)
Generating *.auto.tfvars under terraform_files/<region>/...

Do not skip this: after creating compartments (via toolkit or console), run "Fetch Compartments OCIDs to variables file" from the CD3 Services menu. Downstream tabs reference compartments by name, and this step refreshes the name-to-OCID mapping in the variables file.

8.4 Plan and apply

terminal — terraform plan / apply

[cd3user@cd3-container ~]$ cd /cd3user/tenancies/demo/terraform_files/<region_dir>/<service_dir>
[... network]$ terraform init
[... network]$ terraform plan
Plan: 14 to add, 0 to change, 0 to destroy.
[... network]$ terraform apply
Apply complete! Resources: 14 added, 0 changed, 0 destroyed.

Day-2 changes follow the same loop: update the Excel workbook, re-run setUpCloud.py for the affected service, review the plan, apply. The spreadsheet remains the single source of design truth.

9. Step 4 — Non-Greenfield Workflow: Export Existing OCI Resources

For environments built by hand in the OCI Console, CD3 reverses the flow: it reads the tenancy, fills the Excel workbook for you, generates matching Terraform code, and produces import commands to populate the Terraform state.

1. Edit <prefix>_setUpOCI.properties and set workflow_type=export_resources.
2. Run python setUpCloud.py oci /cd3user/tenancies/<prefix>/<prefix>_setUpOCI.properties and choose the services and compartments to export.
3. CD3 writes the discovered resources into the CD3 Excel sheet and generates *.auto.tfvars plus a shell script of Terraform import commands in each service's output directory.
4. Execute the generated import script so Terraform state matches reality, then verify with a plan.

terminal — export and import into state

# 1. Switch workflow type
[cd3user@cd3-container ~]$ vi /cd3user/tenancies/demo/demo_setUpOCI.properties
workflow_type=export_resources

# 2. Run the export
[cd3user@cd3-container ~]$ cd /cd3user/oci_tools/cd3_automation_toolkit/
[cd3user@cd3-container cd3_automation_toolkit]$ python setUpCloud.py oci \
    /cd3user/tenancies/demo/demo_setUpOCI.properties
Exporting Network objects to CD3 Excel... Done.
Generated tf import commands script under terraform_files/<region>/network/

# 3. Run the generated import script, then verify drift-free state
[... network]$ ./tf_import_commands_network_nonGF.sh
[... network]$ terraform plan
No changes. Your infrastructure matches the configuration.

Goal state: a clean terraform plan with "No changes" after import. From that point, the formerly unmanaged environment is fully under IaC governance — switch workflow_type back to create_resources and manage all future changes through the Excel-driven Greenfield loop.

10. Step 5 — Jenkins and DevOps Pipeline Integration

Modern cloud operations require automation beyond provisioning. When the container is built with USE_DEVOPS=YES, CD3 wires itself into Jenkins and the OCI DevOps Git service: generated Terraform is committed to OCI DevOps Git repositories and Terraform state can live in OCI Object Storage via the S3-compatible credentials created at connect time.

terminal — start Jenkins inside the CD3 container

# Jenkins config was generated by connectCloud.py (jenkins_home, git_config)
[cd3user@cd3-container ~]$ /usr/share/jenkins/jenkins.sh &
Jenkins is up. Access the UI at: https://<host>:8443

# If connectCloud.py was re-run for a new prefix:
# kill the existing jenkins process first, then start it again

From the Jenkins UI you upload/commit the Excel workbook and execute the setUpOCI pipeline, which chains the same steps you ran manually: generate tfvars, terraform plan (with optional AI analysis — next section), an approval gate, then terraform apply. Since the 2025 releases, the pipeline also automatically invokes rule exports after a successful apply, keeping exported definitions in sync.

This integration gives organizations repeatable deployments, version-controlled infrastructure, automated validation, change tracking, and faster environment replication for DR scenarios — the change record is the Git history of the Excel sheet plus generated code.

11. AI-Assisted Terraform Plan Analysis

Introduced in v2026.1.0, the AI Analysis capability adds an optional step to the Jenkins pipeline that generates an AI-based summary of the Terraform plan — a concise overview of planned infrastructure changes — and evaluates the plan for potential security risks and misconfigurations, returning actionable recommendations before deployment12.

In practice, this changes the review dynamic for approval gates: instead of a reviewer scrolling a 900-line plan diff, the pipeline surfaces a digest of what is being created, changed, or destroyed, flagged against best practices. Problems are caught earlier in the lifecycle, improving security posture and reducing failed or rolled-back applies.

Positioning: treat AI Analysis as a reviewer accelerator, not a replacement for the human approval gate. Keep your change-control checkpoint; let the AI summary shorten the time it takes to clear it.

12. Generated Directory Structure Reference

Everything CD3 generates lands under the prefix directory, organized by region and service:

reference — /cd3user/tenancies/<prefix>/ layout

/cd3user/tenancies/<prefix>/
├── CD3-<prefix>.xlsx                      # design workbook (source of truth)
├── <prefix>_setUpOCI.properties           # workflow + excel path config
├── <prefix>_outdir_structure_file         # service-directory grouping
├── createTenancyConfig.out                # console output copy (legacy file name)
├── .config_files/
│   ├── <prefix>_oci_config                # OCI API config
│   └── <prefix>_s3_credentials            # remote state (if enabled)
└── terraform_files/
    └── <region>/                          # one dir per subscribed region
        ├── variables_<region>.tf          # + provider.tf, modules
        ├── identity/
        ├── network/                       # *.auto.tfvars per service
        ├── compute/
        └── database/

Whether services get individual directories (as above) or a single flat directory per region is controlled by the outdir_structure_file parameter set at connect time.

13. Key Benefits and Field Recommendations

Organizations using CD3 commonly realize:

• Reduced manual effort and faster OCI provisioning
• Consistent deployment standards across DEV/TEST/PROD
• Easier Terraform adoption for non-HCL engineers
• Improved operational efficiency, governance, and compliance (CIS reporting built in)
• Simplified onboarding of existing, hand-built OCI environments into IaC
• Native integration with Jenkins and OCI DevOps Git practices

Field recommendations from delivery practice

Recommendation	Why
Standardize on the CIS template for new landing zones	Inherits CIS-aligned guardrails and yields a compliance report from day one
Enable use_remote_state and OCI DevOps Git at connect time	State in Object Storage plus versioned code removes the laptop single point of failure
Re-run "Fetch Compartments OCIDs" after every compartment change	Stale OCID mappings are the most common cause of failed generations
Run exports (Non-Greenfield) before any cleanup project	You get a complete, spreadsheet-readable inventory of the tenancy as a by-product
Keep the human approval gate even with AI Analysis enabled	The AI summary accelerates review; change control still owns the decision

14. Conclusion

The OCI CD3 Automation Toolkit simplifies the journey toward Infrastructure as Code by combining familiar spreadsheet-driven design with Terraform-powered automation. Whether you are building new OCI environments with the Greenfield workflow or bringing hand-built tenancies under governance with the export workflow, CD3 provides a scalable, repeatable framework for provisioning, exporting, and managing cloud resources consistently.

The 2026 release line sharpens that proposition: a maintained Terraform-focused engine, broader database and multicloud coverage, tighter Jenkins/OCI DevOps integration, and AI-assisted plan analysis that catches risks before they reach production. The execution path is short — build the container, connect the tenancy, fill the workbook, run setUpCloud.py, and let Terraform do the rest.

By reducing complexity, promoting standardization, and integrating seamlessly with DevOps workflows, CD3 lets cloud teams spend less time on manual configuration and more time delivering business value through automation.

ZAHEER

Oracle Cloud Infrastructure · Technical Blog Series