Skip to main content
Live with caveats. This area is real and usable, but the docs intentionally call out operational or UX limits that still matter.

Goal

Give implementers and early testers enough detail to model supported StackShift resources and action flows safely.

Prerequisites

  • The StackShift provider configured in Terraform
  • Existing resource IDs when importing

Workflow

1
Choose the resource that matches the StackShift object you want Terraform to own.
2
Use normal terraform apply for new resources.
3
Use terraform import for existing resources, matching the import ID format for each resource.
4
Run terraform plan immediately after import to reconcile missing config or server-computed fields.
5
Avoid mixing Terraform-managed env sets with manual edits in the dashboard.

Resource ownership

  • stackshift_project owns project-level declarative fields such as name, runtime, region, port, source details, and command settings.
  • stackshift_project_env owns the entire variable map for one project and environment.
  • stackshift_database owns database creation and deletion. Most shape changes replace the resource.
  • stackshift_bucket owns an S2 bucket, its initial access key state, and the choice to reject or allow destruction while non-empty.
  • stackshift_domain owns a project domain mapping.
  • stackshift_dns_record owns a DNS record on a registered StackShift-managed domain.
  • stackshift_build_action and stackshift_deployment_action own a single requested operation and its returned status.
  • stackshift_compute_instance owns VM/VPS provisioning. It is separate from normal StackShift-managed project placement.
  • stackshift_compute_action owns a single compute operation such as start, stop, restart, rebuild, or destroy.
  • stackshift_byoc_provider_connection owns one scoped or federated cloud identity and validates it during apply.
  • stackshift_byoc_node owns durable provider provisioning and provider-confirmed safe deletion.
  • stackshift_byoc_volume, stackshift_byoc_snapshot, and stackshift_byoc_static_ip own node-scoped provider add-ons.
  • stackshift_agency_client and stackshift_agency_resource_assignment own agency client records and assignments.
  • stackshift_runbook and stackshift_runbook_execution own runbook definitions and runbook execution requests.
  • stackshift_workload_external_dependency declares one exact external hostname, port, protocol, purpose, and TLS requirement.
  • stackshift_workload_egress_grant requests scoped, expiring access; it cannot approve its own request.

Hosted workload security resources

Use stackshift_workload_external_dependency to declare an exact non-web service before deployment. Use stackshift_workload_egress_grant to request the matching destination and expiry. An authorized StackShift operator still approves or rejects the request outside Terraform. These records are durable security evidence. Removing either resource from configuration removes it from Terraform state but does not revoke or delete the server-side declaration or request.

S2 bucket resources

Protect Terraform state because stackshift_bucket stores the one-time S3 secret returned during creation. Import by bucket UUID reads bucket configuration but cannot reconstruct a secret that S2 no longer returns.
  • Import a bucket with terraform import stackshift_bucket.uploads <bucket_id>.
  • Name, region, visibility, project, and initial key label changes replace the bucket.
  • Destroy rejects a non-empty bucket unless force_destroy is explicitly true.

BYOCloud resources

Hetzner and DigitalOcean connections accept only scoped tokens. AWS accepts role_arn and region and returns a server-generated external_id for the trust policy. Azure accepts tenant, subscription, and client IDs for workload federation; AWS access keys and Azure client secrets have no Terraform attributes. Protect Terraform state because provider token inputs are sensitive state values. Node and add-on resources derive idempotency keys from immutable resource identity, persist them, and wait for provider-confirmed terminal state. A structured deletion blocker stops terraform destroy instead of orphaning dependencies.
  • Import provider connections and nodes with their UUID.
  • Import volumes and snapshots with NODE_ID:RESOURCE_ID.
  • Import a stable IP resource with its node UUID.
  • Imported provider connections can be read without credentials, but credentials must be supplied before changing or revalidating them.
BYOCloud node and storage

Managed server projects

Projects deployed on StackShift managed servers do not need a node ID in Terraform. Use stackshift_project without node placement fields; StackShift keeps selecting the managed target on the server side. Only use explicit placement fields where a resource exposes them. For example, stackshift_database has optional target_node_id for explicit database placement, and leaving it unset keeps the managed/default path.

Import commands

Action resources

Action resources are intentionally explicit. Creating the resource requests the operation once and stores the returned action state. Deleting the Terraform resource only removes Terraform state for that action record.
Build and deployment actions
Runbook execution

Project source patterns

Projects can be created as empty projects, GitHub-backed projects, or image-backed projects. GitHub-backed projects need repository identity fields if you want StackShift to connect the source to an installed GitHub app.
GitHub-backed project
Docker image project

Domain and DNS examples

Project domain mapping
Registered-domain DNS record

Delete behavior

  • Deleting stackshift_project calls DELETE /projects/{projectID}.
  • Deleting stackshift_project_env writes an empty variable set for that project environment.
  • Deleting stackshift_database calls DELETE /projects/{projectID}/databases/{databaseID}.
  • Deleting stackshift_bucket calls DELETE /buckets/{bucketID}; force_destroy = true adds explicit recursive object deletion.
  • Deleting stackshift_domain removes the project domain mapping.
  • Deleting stackshift_dns_record removes the record from the registered domain DNS zone.

Expected result

The provider resources have clear ownership boundaries while registry publishing and full acceptance coverage are still pending.

Common failures

  • Importing stackshift_project_env without the environment suffix. Use <project_id>:<environment>.
  • Importing stackshift_domain with only the domain ID. Use <project_id>:<domain_id>.
  • Importing stackshift_dns_record with only the record ID. Use <domain_id>:<record_id>.
  • Treating action resources like reversible desired state. They trigger operations on create and do not roll those operations back on delete.
  • Importing stackshift_bucket and expecting Terraform to recover the existing secret access key. Issue a new key when imported infrastructure needs credentials.
  • Treating a workload dependency or egress request as self-approved network access. Security approval remains an operator action.
  • Removing a workload security resource from Terraform and expecting the durable request to be revoked. Delete removes Terraform state only.

Terraform and OpenTofu provider

Use the StackShift provider implementation to declare StackShift resources and run explicit StackShift actions from Terraform or OpenTofu.

DNS records and project connection

Manage DNS records and connect domains to projects or other runtime surfaces.

Credentials, pooling, and usage expectations

Use stable connection details, TLS, public-access policy, and pooler endpoints without relying on physical runtime addresses.