someones.computer_terraform

The Terraform (and OpenTofu) provider for someones.computer. It manages the platform's declarative nouns — applications, their configuration variables, managed services and the bindings between them — over the same stateless bearer /cli/* contract the sc CLI drives, through the shared scclient module. One wire contract, no forks between consumers — the same reason sc and sc-tray share that module.

What it manages

Resource	Lifecycle	Notes
someonescomputer_application	create · read · replace · destroy	The platform has no update verb, so slug/name/organization/isolation_level force replacement. force_destroy proceeds while a database is still bound.
someonescomputer_variable	create · read · update · destroy	One name × scope. value is write-only — the platform never returns it, so drift on the value cannot be detected. sensitive/scope force replacement.
someonescomputer_service	create · read · destroy	A managed database/bucket. engine defaults to the catalogue default; a deprecated engine is created and surfaced as a warning. force_destroy retires it while bound.
someonescomputer_service_binding	create · read · destroy	Grants an application the use of a service. Both ends force replacement.

Data source	Answers
someonescomputer_application	one application by slug, with its deployments
someonescomputer_organizations	the caller's organizations and roles
someonescomputer_service_engines	the managed-service engine catalogue
someonescomputer_me	who the token belongs to

Deployments are deliberately not a resource: a deployment is an immutable revision produced by pushing code (sc deploy), not declarative state. Reference them read-only through the someonescomputer_application data source.

Configuring the provider

terraform {
  required_providers {
    someonescomputer = {
      source = "grey.ooo/grey/someonescomputer"
    }
  }
}

provider "someonescomputer" {
  # endpoint = "https://someones.computer"   # or $SC_ENDPOINT (default: hosted)
  # token    = "…"                           # or $SC_TOKEN, or `sc login`'s store
  # organization = "acme"                     # default org for resources that omit one
}

Credentials resolve explicit attribute → environment → the credential file sc login writes ($SC_CONFIG_HOME/$XDG_CONFIG_HOME/sc), so a machine that has already run sc login needs no token in the configuration. Mint a token at /settings/api-tokens. Never commit a token; prefer SC_TOKEN or the sc store.

Installing it (until it is published to a registry)

The provider is not yet in a public registry, so point Terraform/OpenTofu at a locally built binary with a dev_overrides block in ~/.terraformrc:

provider_installation {
  dev_overrides {
    "grey.ooo/grey/someonescomputer" = "/path/to/gobin"  # dir holding terraform-provider-someonescomputer
  }
  direct {}
}

go build -o "$(go env GOBIN)/terraform-provider-someonescomputer" .

With a dev_overrides in effect, skip terraform init — plan/apply pick the override up directly.

Development

Inside the platform repo's go.work checkout this module resolves scclient by path, so a contract change is seen without a publish. Standalone (this repo's own CI) it resolves scclient as a private module and vendors it — the same flow sc uses (GOPRIVATE=git.grey.ooo, then go mod vendor).

Task	Command
Build	go build ./...
Unit tests	go test ./...
Acceptance tests (drive a real tofu/terraform)	make testacc
Static analysis (pinned golangci-lint)	hack/lint.sh
Coverage ratchet	hack/coverage.sh (runs acceptance tests; needs tofu/terraform)

Acceptance tests are gated behind TF_ACC and run the provider against an in-memory stub of the /cli surface — they need a tofu or terraform binary on PATH.