Client libraries for interacting with the dstack guest agent from inside a TEE.

All SDKs communicate with the guest agent via HTTP over a Unix socket (/var/run/dstack.sock). See the HTTP API Reference for direct access using curl or any HTTP client.

The guest agent serves two surfaces on that socket, selected by URL path, and every SDK mirrors both:

The unsuffixed client is v1 in every SDK -- that is the recommended default. v1 is specified byte-for-byte in docs/guest-api-v1.md.

DstackClientV0 is legacy and explicitly named. That surface is closed: it gains no methods and changes no behaviour, so a v0.5.x program keeps working against a 0.6 agent unchanged.

The unsuffixed name flipped to v1 in 0.6.0. Code that used it for v0 calls fails loudly on upgrade -- the v1 method signatures differ and get_key requires algorithm explicitly -- rather than silently deriving different keys. To stay on the frozen surface, switch to DstackClientV0.

The clients are transport mirrors, not a compatibility layer: neither translates a call to the other, and each one's method set is exactly its surface's. v1 has no sign and no verify, because any caller that can reach the socket can ask get_key for the private key and do both locally.

Every field the v1 proto declares bytes is that language's byte type on the v1 clients -- Vec<u8>, bytes, []byte, Uint8Array -- with hex confined to serialization; there are no decode_* helpers. The v0 clients keep their hex strings and helpers, because that surface is frozen.

v1 keys are not v0 keys. Deriving under the same name through DstackClient returns different key material than DstackClientV0 does. This is deliberate -- the v0 KDF ignored the algorithm, so one secret served both curves -- and there is no compatibility mode. An application holding assets under a v0 key must migrate them with a transaction signed by the old key before cutting over.

The SDKs ship no verification helper. Verifying needs no client and no connection, and it is the relying party's job. docs/guest-api-v1.md specifies the rules normatively -- the claim encoding, the recovery step, and the trust anchor the chain has to terminate at. DstackClientV0.verify() remains for single signatures on the frozen surface, since that is what the v0 surface offers.

For local development without TDX hardware, use the simulator:

• Download releases
• Install as a systemd service
• Docker image