Deploy a blueprint

Every deployment follows the same lifecycle: plan, review, approve, apply. StackTakt renders the blueprint with OpenTofu, plans it against your account through the scoped deployment role, and shows you every resource before anything is created. The apply executes exactly the plan artifact the approver reviewed, never a fresh plan.

Create a deployment

1. Open Blueprints and select Deploy on a card. Each card shows the template version, its key controls, and how many framework requirements it maps.
2. Fill in the single-page form: a data classification (labels the resources this deployment creates; it does not change which requirements apply), the template’s parameters, and optionally a connection to another deployment (see below).
3. The right rail shows what the blueprint deploys, its control mappings under a framework lens, and its cost while running.
4. Select Create deployment plan. Deploying needs a healthy connection and operator access.

Review and approve

The deployment page shows the plan when it lands:

• Planned resources: every resource with its type and action (Create, Delete, and so on), plus the counts.
• OpenTofu logs: the full output, streamed live during runs.
• Control coverage: the control mapping this template version asserts, with an HIPAA or SOC 2 lens.

Select Approve & apply and confirm. The confirmation names the real consequence: how many resources, in which account, at what running cost. Approval and apply each write their own audit event (plan.approved, apply.started, apply.completed), and the whole thread shares one correlation ID you can follow in Activity.

Approval is a separate permission from requesting. Who can approve, and why a requester cannot approve their own deployment, is covered in Approvals and roles.

Statuses

Status	Meaning
Planned	Plan requested or ready for approval.
Approved	Approved, apply queued.
Applying	OpenTofu is running against the account.
Applied	Live. Evidence and control mapping available.
Failed	The last run failed; logs carry the error.
Destroyed	Tracked resources removed; the record remains.

Applies typically take 3 to 5 minutes and run server-side; you can leave the page and come back.

Connect deployments

Some blueprints link: an SFTP endpoint can back onto a Secure Bucket, and a Simple ETL pipeline wires a source bucket to a database. A wired link is real infrastructure (the platform injects the linked deployment’s outputs into the template). A recorded link documents an intended data flow only. Links are set at deploy time and shown on the deployment page.

Revise, retry, destroy

• Revise (SFTP endpoints only, once applied): add partners, CIDR blocks, or a destination bucket. Revising re-plans; you approve the new plan before anything changes. The endpoint name, VPC, and primary bucket never change.
• Failed runs: the logs carry the error, and partially created resources stay tracked in state. Retry the apply, or destroy to remove what the failed run created. Nothing is cleaned up silently.
• Destroy: available from Applied or Failed, behind its own confirmation. Backing buckets are deliberately never force-deleted, so destroying a deployment does not delete customer data.