How It Works
From supported scenario to manifest to standard OpenTofu.
OPSd is a workflow, not a one-shot generator. It starts from a supported scenario, moves through a manifest-driven model, and renders standard OpenTofu that stays under the team's control.
The workflow in one clear sequence
OPSd narrows and structures the path up to rendered IaC. The aim is not to replace OpenTofu, but to make the path into OpenTofu more deliberate and repeatable.
1. Choose a supported scenario
Start from a blueprint and variant that match the current stage of the environment instead of assembling raw infrastructure primitives from zero.
2. Initialize and review the manifest
OPSd turns that starting point into a manifest that becomes the control layer for supported environment changes.
3. Validate before rendering
The manifest is checked before infrastructure code is produced, which keeps the workflow narrower and more predictable.
4. Render standard OpenTofu
The result stays reviewable and operable through the normal `tofu` workflow your team already understands.
5. Review and apply through OpenTofu
Once the rendered stack looks correct, the team continues with normal `tofu plan` and `tofu apply` steps to execute the infrastructure change.
Canonical flow
opsd config set provider digitalocean
opsd list blueprints
opsd init blueprint backend-api backend-api-vm.environment.yaml --variant vm
opsd validate manifest backend-api-vm.environment.yaml
opsd render manifest backend-api-vm.environment.yaml --output rendered/backend-api-vm
cd rendered/backend-api-vm
tofu init -backend=false -input=false
tofu plan
tofu applyThe critical point is that OpenTofu remains normal infrastructure output. OPSd narrows the path into it; it does not replace the execution layer.
What changes after the first deployment
OPSd should remain useful after bootstrap. In practice that means changing the manifest, re-rendering, and letting the supported scenario evolve with the environment instead of freezing everything at the first `tofu plan`.
The manifest stays active
After the first render, the workflow continues through the manifest. The point is to make supported changes there instead of treating the generated stack as a one-off scaffold.
Growth uses explicit change commands
The CLI already models changes such as adding load balancers, caches, databases, CDN endpoints, nodes, and resizing existing resources before rendering again.
The rendered scenario can change
As the manifest changes, the rendered source scenario can change too. A simpler starting point can move into a more advanced supported operating shape over time.
Typical growth loop
opsd add load-balancer backend-api-vm.environment.yaml --id web-public --visibility public --port 80 --target-port 8080
opsd scale compute-group backend-api-vm.environment.yaml primary --replicas 3
opsd validate manifest backend-api-vm.environment.yaml
opsd render manifest backend-api-vm.environment.yaml --output rendered/backend-api-vm
cd rendered/backend-api-vm
tofu plan
tofu applyThe important detail is that OPSd applies supported change to the manifest first, then re-renders the infrastructure output. It does not directly apply infrastructure changes on your behalf.
Ownership and boundary stay explicit
The operating model only works if the line between OPSd, provider modules, and the team's own infrastructure responsibility stays clear.
- OPSd owns scenario discovery, manifest initialization, validation, and rendering.
- Provider modules own the reusable implementation pieces behind supported scenarios.
- OpenTofu remains the execution layer for init, plan, apply, state, and long-term operations.
- The team keeps the manifest, lock file, and rendered output under its own control.
- If you want the OPSd workflow to remain reliable, make supported changes through the manifest and re-rendering rather than hand-editing generated output.