Scenario-driven infrastructure bootstrap
Install OPSd, pick a supported path, and render the first environment.
OPSd helps you create a profile, choose a supported blueprint and variant, validate a manifest, and render standard OpenTofu that stays in your control.
What OPSd helps you do first
OPSd is useful when you want a supported starting point, a clear provider choice, and a narrow path from bootstrap to rendered infrastructure.
You need a repeatable starting point
OPSd gives you a supported scenario and a seeded manifest instead of asking you to rebuild the same baseline from zero for every environment.
You still need a chosen provider and path
The first step is to pick a profile and provider, then choose a blueprint and variant that match the operating model you want to own.
The workflow has to end in something useful
The workflow should reach a validated manifest and rendered OpenTofu that your team can continue with through the normal `tofu` flow.
How the workflow stays controlled
OPSd keeps the workflow narrow: choose a profile, inspect a blueprint, seed a manifest, validate it, and render standard OpenTofu.
1. Install OPSd and create a profile
Install the CLI, create a profile, and choose the provider you want to work with.
2. Inspect the supported blueprints
List the available blueprints and inspect the one that matches the scenario you want to bootstrap.
3. Seed the manifest from a blueprint
Initialize a manifest from the chosen blueprint and variant so the environment starts from a known-good shape.
4. Validate and render OpenTofu
Validate the manifest, render the output, and continue with the standard `tofu` workflow your team already understands.
Canonical flow
opsd config profile create work
opsd config profile use work
opsd list blueprints
opsd describe blueprint backend-api-db
opsd init blueprint backend-api-db backend-api-db-vm.environment.yaml --variant vm
opsd validate manifest backend-api-db-vm.environment.yaml
opsd render manifest backend-api-db-vm.environment.yaml --output rendered/backend-api-db-vm
cd rendered/backend-api-db-vm
tofu init
tofu planOPSd narrows the path up to rendered OpenTofu. After that, the team continues with the normal IaC review, plan, and operations work.
When OPSd is a fit
OPSd does not try to solve every infrastructure problem in one layer. It is a fit when you want repeatable starting points, a clear provider path, and a controlled route from bootstrap to rendered infrastructure.
This model makes sense when
- you want repeatable starting points for similar environments
- you want to avoid common baseline mistakes, such as exposing too much infrastructure directly to the public internet
- you want a foundation the team can keep extending after bootstrap
- you want room to grow from simpler scenarios into more advanced ones over time
This model is not the right fit when
- you expect a complete answer to every DevOps or platform concern
- you want the product to model every topology from day one
- you do not want responsibility for reviewing or owning the generated infrastructure
- you want convenience even when it depends on weak or unsafe defaults
Support if you want a more guided model
OPSd is designed to be adopted self-serve first. If you do not want to carry the whole rollout alone, or you prefer a model where we help with training, review, and adoption, support is available.
Self-serve first
OPSd is designed so teams can install it, understand the workflow, and reach the first useful result without turning support into a requirement.
Guided adoption if you want it
If you prefer a model where we help with rollout, training, review, or adapting the workflow to your needs, support is available.
Ownership still stays with you
Even when support is hands-on, the goal is still a working model your team can keep, understand, and carry forward independently.
The exit path stays clear
OPSd should make adoption easier, not exit harder. From day one, the model should stay understandable and transferable so another team can take over without reverse-engineering a proprietary system.
- The manifest stays in your repository as the main control surface for the environment.
- The lock file captures the resolved render inputs for deterministic future renders.
- The rendered OpenTofu remains inspectable and operable without a hosted OPSd control plane.