CLI

The Takosumi CLI is an automation helper for actions you can also do in the dashboard. The normal product flow is the dashboard /install?git=... / /new path: choose a service, choose the provider connection it should use, then plan / apply. The CLI can target any Takosumi endpoint.

export TAKOSUMI_DEPLOY_CONTROL_URL=https://takosumi.example.com
export TAKOSUMI_DEPLOY_CONTROL_TOKEN=<bearer>

open "$TAKOSUMI_DEPLOY_CONTROL_URL/install?git=https://git.example.com/example/photo-blog.git&path=deploy/opentofu&ref=v1.0.0"

takosumi status <run-id>
takosumi logs   <run-id>

When using Takosumi Cloud, the hosted endpoint is https://app.takosumi.com.

The CLI does not run OpenTofu directly. The normal creation flow is dashboard Git URL install, which creates Source / Capsule / Run records and pins the Git commit / ref / path as the Run source identity. Execution happens in the runner sandbox, and credentials are injected at run time from ProviderConnections and CredentialRecipes. Source authoring is Git-only; immutable source archives are internal runner transport and are not accepted as a CLI creation input. The local-upload path for takosumi deploy / takosumi plan is retired.

Issuing tokens

The TAKOSUMI_DEPLOY_CONTROL_TOKEN other pages tell you to use is created here.

takosumi accounts tokens create \
  --name my-cli \
  --scope write \
  --accounts-url "$TAKOSUMI_ACCOUNTS_URL" \
  --token "$TAKOSUMI_ACCOUNTS_SESSION_BEARER"

Option	Meaning
--name	a name to tell tokens apart
--scope	read / write / admin
--expires-at	expiry (ISO 8601)
--accounts-url	the Accounts URL; env TAKOSUMI_ACCOUNTS_URL
--token	the Accounts session bearer (sess_...)
--json	output as JSON

The accounts commands take the Accounts session bearer as --token, not an issued token. Only this family of commands differs.

The issued token string is returned only once. Listings show metadata (name, prefix, scope, created at) only. If you lose it, create a new one and revoke the old.

takosumi accounts tokens list   --accounts-url "$TAKOSUMI_ACCOUNTS_URL" --token "$SESSION"
takosumi accounts tokens revoke pat_example --accounts-url "$TAKOSUMI_ACCOUNTS_URL" --token "$SESSION"

admin cannot be self-assigned; only an operator can issue it.

Self-host setup

Commands for running Accounts in your own environment. Skip them if you only use an existing endpoint.

Apply the schema

With PostgreSQL:

takosumi accounts migrate --database-url "$TAKOSUMI_ACCOUNTS_DATABASE_URL"

--dry-run shows what would run without applying. The connection is also read from TAKOSUMI_ACCOUNTS_DATABASE_URL.

With Cloudflare D1 the command differs: for each pending migration it calls bunx wrangler d1 execute and records the applied version in takosumi_accounts_schema_migrations.

takosumi accounts migrate-d1 --database-id takosumi-accounts --remote

Option	Meaning
--database-id	the D1 database or binding name
--wrangler-config	wrangler config when run from another checkout
--account-id	the Cloudflare account id (when not the default)
--remote / --local	remote D1 or local miniflare. Defaults to --remote
--env	the --env profile passed to wrangler

Use --local to check behavior before the first deploy.

Seed initial data

takosumi accounts seed \
  --issuer https://accounts.example.com \
  --subject tsub_example \
  --client-id example-client \
  --redirect-uri https://app.example.com/callback

Serve

takosumi accounts serve \
  --issuer https://accounts.example.com \
  --hostname 0.0.0.0 --port 8080 \
  --database-url "$TAKOSUMI_ACCOUNTS_DATABASE_URL"

For upstream identity providers or passkeys, add --upstream-providers (JSON array), --passkey-rp-id, --passkey-rp-name, --passkey-origin, and so on. For a single local session use --dev-session-id sess_.... Never in production.

Platform Readiness Contributions

takosumi launch-readiness template generates the baseline shared by OSS and Operator. When a hosted service or another edition requires additional operational evidence, the owner maintains a versioned PlatformReadinessContribution JSON and selects it at template-generation time with --contribution-file <path>.

takosumi launch-readiness template \
  --contribution-file <owner-controlled-contribution.json> \
  > readiness.private.json

takosumi launch-readiness validate --file readiness.private.json

The generated takosumi.platform-readiness@v2 document embeds the contribution's id, version, and capability plus its additional requirement/evidence schema. That lets validate and the public summary verify fail-closed from the document alone, without provider-specific code or an external registry lookup. A different contribution version is never implicitly treated as the same readiness profile. validate never double-interprets a legacy baseline ID; an explicit launch-readiness migrate-final-model updates it exactly once.

There is no ad hoc collector DSL. When a contribution assists collection planning, it may only assign its own evidence types to the existing fixed classes (browser-user-e2e, external-provider, operator-review, live-probe-sync, operation-drill, release-provenance) through collectionClassHints. Extension evidence that omits a hint remains valid for validation but is uncategorized for collection planning. The takosumi.platform-readiness-report@v2 validation result also returns the composed definition's requiredDomainIds and requiredRehearsalStepIds. Progress consumers use those arrays instead of OSS-only fixed IDs, so totals and completed counts remain exact when Operator or Cloud contributions are present.

Connections

Provider credential values are read from files and are never printed.

takosumi connections create \
  --provider registry.opentofu.org/example/example \
  --recipe generic-env \
  --auth-mode env \
  --secret-partition provider-credentials \
  --values-file <path-to-credential-env-json>

takosumi connections list
takosumi connections test conn_...
takosumi connections revoke conn_...

Compatibility APIs are explicit operator-installed extension capabilities. The Provider Connection CLI never infers a specific gateway or provider family.

Deployment secrets

The selected runtime adapter and operator vault own deployment-secret storage and application. The Takosumi CLI does not treat Wrangler, one Worker runtime, or a fixed secret-name manifest as canonical. Register provider credentials as Provider Connections through connections; generate and store platform-service signing keys and internal bearers outside the repository, then apply them with the chosen deployment adapter's native secret command.