OCI Resource Manager Explained

Running Terraform yourself means operating the machinery around it: storing state safely, locking it during changes, providing somewhere to run the plans and applies, and securing the credentials the automation uses. The OCI Resource Manager takes that machinery off your hands by running Terraform as a managed service inside OCI, and for many teams it is the simplest way to adopt infrastructure as code without first building the plumbing to run it. This guide explains what the Resource Manager is, how it works, and when it is the right choice.

It is part of our DevOps and automation on OCI cluster, and it builds directly on our Terraform on OCI getting started guide, which covers the Terraform fundamentals this service is built around.

What the Resource Manager is

The Resource Manager is OCI's managed service for running Terraform. Instead of installing Terraform, configuring where state lives, and running plans and applies from your own machine or pipeline, you give the Resource Manager your Terraform configuration and it runs the whole cycle for you inside OCI. It stores the state, locks it during operations, runs the plan and apply, and keeps a record of what happened, all as a managed service that you do not have to operate.

The unit of work in the Resource Manager is a stack, which is a Terraform configuration plus the variables and state that go with it. Against a stack you run jobs: a plan job to preview changes, an apply job to make them, and a destroy job to tear the resources down. This maps cleanly onto the Terraform cycle covered in our Terraform guide, with the difference that the Resource Manager runs the cycle as a service rather than leaving you to run it.

What it takes off your hands

The main value of the Resource Manager is the operational burden it removes. State management, which is the part of self managed Terraform most likely to cause trouble, is handled entirely by the service, with state stored safely and locked automatically so two jobs cannot collide. The execution environment is provided, so there is no need to maintain a machine or a runner to run Terraform on. And the service integrates with OCI identity, so the automation can run with controlled permissions rather than carrying credentials around.

For a team early in its infrastructure as code journey, this removal of burden is significant, because the plumbing around Terraform is exactly the part that is fiddly to get right and easy to get wrong. The Resource Manager lets a team focus on writing good Terraform definitions while the service handles the operating machinery, which lowers the barrier to adopting infrastructure as code properly.

How a stack flows

Working with the Resource Manager follows a clear cycle. You create a stack from your Terraform configuration, providing it as uploaded files, from a source control repository, or from a template. You set the variables the configuration needs. You run a plan job and read the result to see exactly what the apply would change, the same crucial review step as in self managed Terraform. Then you run an apply job, which makes the changes and updates the state, and the service records what was done.

When resources are no longer needed, a destroy job tears down everything the stack created, which is a clean way to retire an environment without leaving stray resources behind to bill quietly. This destroy capability is one reason the Resource Manager pairs well with disposable environments such as test clones, because the whole lifecycle, create, change, and tear down, is managed in one place with the state kept consistent throughout.

When to use it and when not to

The Resource Manager is a strong default for teams that want infrastructure as code without operating the machinery, for environments where keeping state and execution inside OCI is an advantage, and for self contained stacks that map neatly onto the service's model. It is especially good for getting started, because it removes the setup that often delays or derails a first adoption of Terraform.

It is less suited to teams that have already built a sophisticated external pipeline they want to keep, or to complex multi stack arrangements that need orchestration the service does not provide, or to workflows that depend on tooling around Terraform that runs better in an external CI and CD system. In those cases, running Terraform within an existing pipeline, covered in our OCI DevOps service pipelines guide, may fit better. The choice is not about which is better in the abstract but about which matches how the team already works and where it wants to go.

It still needs discipline

A managed service removes operational burden but not the need for discipline, and the same habits that make self managed Terraform safe apply to the Resource Manager. Changes should still go through the service rather than being made by hand in the console, because drift undermines the Resource Manager's state just as it does any Terraform state. Plans should still be read before applies are run, because the service previews changes for exactly that reason. And the configurations should still be structured well, using the patterns covered in our infrastructure as code patterns on OCI guide, because the Resource Manager runs whatever you give it and gives back tangled results if you give it tangled definitions.

The Resource Manager is best thought of as a way to run good Terraform more easily, not as a substitute for understanding Terraform. A team that uses it with the right discipline gets the benefit of infrastructure as code with much less plumbing to maintain, which is a genuinely good trade for many estates. When we set up infrastructure as code for clients, the Resource Manager is often part of the picture, and choosing where it fits is part of the work in our DevOps and IaC solution. Used well, it is one of the quickest routes to running an OCI estate as code.