Skip to main content

Support

Get help without giving up ownership.

OPSd is built to work self-serve first. Support is available when you want help choosing a path, reviewing the first workflow, or getting the first deployment over the line with less risk.

Adopt independently or with a more guided model

The point of support is not to stand between the team and the product. It is there for teams that want a shorter, safer path into the workflow.

Self-serve first

OPSd is designed so teams can install it, follow the docs, run the quickstart, and understand the workflow without turning support into a requirement.

Guided when you want it

Some teams prefer to shorten the first learning loop with help choosing the right path, reviewing the first manifest, or shaping the first rollout.

Ownership still stays with you

Even when support is hands-on, the goal is still a workflow and output your team can keep, understand, and operate independently later.

Where support helps most

The highest-value moments are usually early: choosing the right path, validating the first workflow, and getting the first deployment shape right without overcomplicating it.

Path and scenario choice

Get help deciding which supported path fits the current stage of the product and which operating model makes sense today.

First manifest and workflow review

Use support to review the first manifest, validate the workflow choices, and avoid early mistakes before the first serious rollout.

First deployment and team enablement

Work through the first deployment, training, and adoption steps with help, while still keeping the resulting model understandable for the team.

Support should make future handoff easier

The best support model is one that helps the current team move faster without making the future team inherit a black box.

  • Support is there to reduce time and risk, not to become a permanent dependency.
  • The manifest, lock file, and rendered OpenTofu remain with the team.
  • A future team should be able to take over the resulting workflow without reverse-engineering a proprietary control plane.

How support is priced

Support stays straightforward: work is billed hourly, and the total effort depends on the kind of help your team actually needs.

Pricing model

EUR 100 / hour

Minimum booking: 2 hours

Most engagements start with a short scoping conversation and continue hourly.

Typical effort by scenario

First implementation

8-16 hours

For teams that want the first supported path implemented with help instead of building the initial rollout on their own.

Implementation review

3-6 hours

For teams that are doing the work themselves but want a second set of eyes on the path choice, manifest, render, and rollout plan.

Transition support

12-24 hours

For teams moving from one operating model to another and wanting help reducing downtime risk and keeping the transition controlled.

CI/CD integration

6-12 hours

For teams that want the OPSd workflow integrated into their delivery pipeline, including validation, render flow, review checkpoints, and safer plan or apply handoffs.

Next step

Reach out in the way that fits how you work

If you want to scope support seriously, start with a short call. If you still want to validate the product flow on your own first, the docs and quickstart remain the right place to start.