The API is the control plane

One state, many callers

Tasmanian Cloud does not give the portal, CLI, and SDK separate deployment logic. They call the API. The API owns resource state, deployment intent, run progress, events, and verified outputs.

This matters when a workflow changes hands. A person can start with the portal, a release job can continue with the CLI, and an application can inspect the result through an SDK without creating a second version of the deployment.

REST for resources, GraphQL for connected state

The REST surface is useful when a workflow maps cleanly to resources and actions. It is easy to call from a shell, a small service, or a system that only needs one part of the state.

GraphQL is useful when a client needs related state in one query. A deployment view can bring together the resource, its run, dependencies, events, and outputs without making the client assemble a dashboard from unrelated requests.

The portal is a client

The portal is the visual client for people. It helps an operator inspect a resource, review a plan, watch a run, and read the resulting state. It is not a separate authority that can disagree with the API.

That boundary also keeps the product usable for teams that do not want a browser in their release process.

The CLI and SDK are clients

The CLI is for repeatable shell and release workflows. SDKs are for applications that own an infrastructure lifecycle. Both submit intent and read the same state that the portal displays.

The practical value is a smaller integration surface. You do not need one implementation for the portal, another for CI, and a third for an internal service.

x402 for machine-initiated access

Where an operation is enabled for x402, a machine can present a payment proof as part of the request path. The service verifies that the proof belongs to the requested resource and records the settlement through the same ledger boundary used for other payment sources.

This is useful for services that consume infrastructure or API capacity without a human checkout step. It does not replace normal authentication, authorisation, replay protection, or tenant accounting.

What this buys you

A stable API boundary lets the customer choose the interface without changing the platform model. The important object is not the button, command, or generated client. It is the resource state behind all of them.