Client SDKs for the Docker Sandboxes API, in Go, TypeScript and Python. One
contract, served by local sandboxd and by the cloud sandbox API, so the same
code runs against either backend by changing the endpoint.
go get github.com/docker/sandboxes-api
npm install @docker/sbx-api @connectrpc/connect
pip install docker-sbx-apiA client is constructed from an endpoint. Management services live in
docker.sbx.v1. Process and file services live in docker.sbx.process.v1 and
docker.sbx.files.v1, and are reached through a running sandbox's own endpoint
rather than the management endpoint.
Backends do not serve identical surfaces. Ask CapabilityService.GetCapabilities
what the backend in front of you supports, and treat UNIMPLEMENTED at a call
site as "not on this backend" rather than as a failure. That is also what a
version skew looks like, where an older server meets a newer SDK.
The generated facade bundles the management clients for one endpoint: sbx.New
in Go, connect in TypeScript, sbx_facade.connect in Python.
Go and TypeScript speak Connect. Python speaks Connect too, through connectrpc,
because the cloud endpoint sits behind a load balancer that answers
application/grpc with HTTP 464 and a native gRPC client never reaches it.
The Python package contributes docker.sbx as a namespace subpackage and ships
no docker/__init__.py, so it installs alongside the Docker Engine SDK in either
order.
This repository publishes released SDKs. They are generated from a protobuf contract that is developed elsewhere, and they arrive here on a version tag, so the tree holds no hand-written source and takes no pull requests.
Report a problem by opening an issue. Security reports go to
security@docker.com instead, as described in SECURITY.md.