How to Build a CMDB for OCI
Every cloud team eventually needs a configuration management database. For Oracle Cloud Infrastructure, that means knowing what compute instances, VCNs, databases, and IAM policies exist across every region, compartment, and tenancy you manage. Without a CMDB, inventory lives in spreadsheets, audit preparation takes days, and nobody can answer basic questions about your OCI estate with confidence.
This guide walks through the practical steps to build a CMDB for OCI - whether you start with manual exports, custom automation, or a purpose-built platform like our Oracle Cloud CMDB.
Define what belongs in your OCI CMDB
A CMDB is only useful if you agree on what counts as a configuration item. For OCI, start with the resource domains that matter most to your team: compute (instances, images, shapes), networking (VCNs, subnets, security lists, load balancers), storage (block volumes, object storage buckets), databases (DB systems, Autonomous Databases), and IAM (users, groups, policies, dynamic groups).
MSPs managing multiple customer tenancies should also decide how to scope workspaces. Each customer estate may need its own isolated CMDB view with separate credentials and scan schedules. Enterprise teams with a single large tenancy should map compartments to business units so the CMDB reflects organisational structure, not just OCI's default hierarchy.
Choose your data collection approach
There are three common paths to populating an OCI CMDB, each with trade-offs.
Manual exports and spreadsheets are where most teams start. You copy resource lists from the OCI Console or run occasional OCI CLI queries, then paste results into shared spreadsheets. This works for a single small tenancy but breaks quickly: data goes stale within days, merging exports across regions is error-prone, and there is no searchable catalog.
Custom scripts and automation use the OCI SDK or CLI to query APIs on a schedule and write results to a database or data lake. This gives you control but requires ongoing maintenance as OCI adds services, API shapes change, and your team must build search, reporting, and multi-tenancy themselves.
Purpose-built OCI inventory tools handle discovery, normalisation, and presentation out of the box. An OCI resource inventory tool like OCI Vision scans 12+ resource domains on demand, stores results in a searchable CI catalog, and supports multi-tenancy workspaces for MSP customer estates - without you maintaining custom collectors.
Structure your configuration items
Raw API responses are not a CMDB. You need consistent attributes for every configuration item: resource OCID, display name, compartment, region, lifecycle state, tags, and relationships to parent resources (for example, which subnet an instance sits in, or which VCN a subnet belongs to).
Relationships are what turn an inventory list into a CMDB. When an auditor asks "which databases are exposed to the public internet?" or an engineer needs to assess blast radius before a VCN change, relationship data answers the question. Map parent-child links during discovery rather than trying to reconstruct them later from flat exports.
Tagging strategy matters too. OCI freeform and defined tags should flow into your CMDB so teams can filter by environment, cost centre, or owner. If tagging is inconsistent today, use the CMDB build as a forcing function to standardise across compartments.
Plan for refresh cadence and drift
A CMDB that reflects last month's estate is a liability. Define how often inventory refreshes: on-demand before audits, scheduled nightly for operational teams, or triggered after change windows for MSPs managing customer environments.
Drift detection - comparing current scans to previous baselines - helps governance teams spot unauthorised resources, orphaned volumes, or IAM policy changes. This is where a live CMDB pays off over static spreadsheets. Teams preparing for OCI compliance reviews benefit especially from repeatable scan-and-compare cycles rather than rebuilding evidence from scratch each quarter.
Connect the CMDB to governance and audit workflows
The CMDB should feed compliance, audit, and operational workflows - not sit in isolation. Inventory PDF exports give auditors formatted evidence. IAM domain data supports access reviews. Cost domain data alongside compute and storage helps finance teams reconcile cloud spend with deployed resources.
For MSPs, the CMDB becomes the foundation for customer onboarding: scan a new tenancy, review the CI catalog, and establish a governance baseline before handing over day-two operations. For enterprise teams, it supports change management by showing exactly what exists before and after infrastructure updates.
When to use a purpose-built platform
Building a CMDB from scratch makes sense when you have dedicated platform engineering capacity and unique integration requirements. For most MSPs and cloud teams, the maintenance cost of custom collectors, search UI, multi-tenancy isolation, and audit reporting outweighs the benefit - especially when OCI adds new services regularly.
OCI Vision provides a live Oracle Cloud CMDB with on-demand scanning, organisation-scoped workspaces, encrypted credentials, and audit-ready PDF exports from Reporting Studio. You get a searchable CI catalog across compute, network, IAM, storage, databases, and cost without building and maintaining custom discovery pipelines.