Templates that describe a running system

A template is more than an image

A useful deployment definition describes the system that must exist. That may include a virtual machine, containers, Docker Compose services, attached storage, network rules, and the configuration work that connects them.

The definition can also name Ansible tasks and Terraform or OpenTofu resources. That keeps provider-specific work inside an explicit system description instead of hiding it in a release script.

State has an order

A database must exist before an application can configure its connection. A private network must exist before a service can attach to it. A secret reference must resolve before a task can use it.

Saga turns those dependencies into an ordered run. The record contains the step, input, result, retry decision, and compensation path. A customer can inspect where a run stopped and what was already applied.

VMs, containers, and Compose can share one intent

A workload often spans more than one substrate. A VM may hold a private service, containers may provide the application tier, and Compose may describe the local group of services that must move together.

Saga keeps that shape visible. The customer can update the system as a system instead of maintaining separate, manually coordinated definitions for every piece.

Ansible and OpenTofu are operations, not decoration

Ansible is useful when the operation is configuration on a host. Terraform or OpenTofu is useful when the operation is a provider resource graph. The template records which tool owns which part of the change.

The runner boundary keeps each operation inspectable. The workflow can render inputs, execute the right runner, capture outputs, and decide whether the next phase can start.

Failure is part of the design

A failed apply is not the same as a failed request. A plan may succeed while an apply fails. A partial apply may need a compensation step. A provider may return a transient error that is safe to retry.

Saga treats those cases as state transitions. It does not pretend that a single HTTP response is a complete deployment record.

The value is a repeatable change

The same template can describe an initial deployment, a reconfigure, a replacement, or a recovery attempt. That gives the customer one place to review what the system should be and one run history to explain how the platform tried to make it true.