ajeetraina777/sbx-kits-cloudsmith repository overview

⁠sbx kit for Cloudsmith

A Docker Sandboxes⁠ mixin that gives any sandboxed agent the ability to publish and manage packages on Cloudsmith⁠, the cloud-native artifact management platform across 30+ formats (Docker, npm, PyPI, Maven, Debian, RPM, Helm, Cargo, Go, NuGet, and more).

⁠Architecture

The mixin composes the sandbox's isolation + egress control with Cloudsmith's artifact API (diagram above):

1. Install time: the cloudsmith CLI is pulled from PyPI, which the kit allowlists.
2. In the sandbox: the agent runs the CLI directly. CLOUDSMITH_API_KEY is the literal proxy-managed; the real key is never present.
3. At the sbx proxy: outbound calls to api.cloudsmith.io are checked against the network allow-list, and the proxy-managed sentinel is swapped for your real key, injected as Authorization: token <key>.
4. Cloudsmith serves the request — publishing, listing, or fetching packages across 30+ formats via the API and the dl/docker/npm registry hosts.

⁠What the kit does

1. Installs the official cloudsmith CLI⁠ (cloudsmith-cli==1.26.0) into the sandbox.
2. Declares a cloudsmith credential. The sbx proxy injects your API key as Authorization: token <key> on requests to api.cloudsmith.io.
3. Sets CLOUDSMITH_API_KEY=proxy-managed in the container as a sentinel — the real key never touches the sandbox; the proxy swaps it in on egress.
4. Restricts network egress to only the Cloudsmith and package-index domains the CLI needs (api.cloudsmith.io, dl.cloudsmith.io, docker.cloudsmith.io, npm.cloudsmith.io, plus PyPI to install the CLI).

⁠Prerequisites

Store your Cloudsmith API key (found under User Settings → API in the Cloudsmith web app) once, out of the container image:

sbx secret set cloudsmith

Service secrets are global by default, so every sandbox can reuse it. The kit ships no key; it only declares where the proxy should inject the one you stored.

⁠Launch

Pick whichever agent you want (claude, codex, gemini, …) and one of the three --kit forms:

# Published OCI artifact (primary — available the moment this repo publishes)
sbx run --kit docker.io/ajeetraina777/sbx-kits-cloudsmith:latest claude

# Straight from git
sbx run --kit "git+https://github.com/ajeetraina/cloudsmith.git" claude

# Local checkout
sbx run --kit ./cloudsmith/ claude

⁠Confirm the kit installed correctly

Inside the sandbox:

# i. CLI is present and on the expected version
cloudsmith --version              # -> 1.26.0

# ii. The credential env var is the sentinel, not a real key
echo "$CLOUDSMITH_API_KEY"        # -> proxy-managed

# iii. End-to-end: the proxy injects the real key on egress
cloudsmith whoami                 # -> your Cloudsmith username

If whoami returns your username, the proxy is injecting the stored key correctly.

⁠Using Cloudsmith from the agent

The agent can drive the CLI directly — the API key is handled by the proxy:

cloudsmith list packages OWNER/REPO            # what's already there
cloudsmith push python OWNER/REPO dist/*.whl   # publish a Python wheel
cloudsmith push docker OWNER/REPO image.tar    # publish a Docker image tarball
cloudsmith status OWNER/REPO/<slug>            # check sync status

OWNER is your workspace (organization) slug, REPO the repository slug. Run cloudsmith push --help for the full format matrix.

⁠Troubleshooting

• 401 Unauthorized / whoami fails — the key wasn't stored, or was stored under a different service name. Re-run sbx secret set cloudsmith and check sbx secret ls.
• 403 / connection blocked — a required domain isn't allowed. Under a managed org policy, ask an admin to allow the Cloudsmith domains (see the governance note above). Check what the proxy blocked with sbx policy log <sandbox>.
• Home-directory mount policy error on launch — your sbx config forbids mounting the agent home; recreate the sandbox without the conflicting mount, or adjust the policy.

⁠License

MIT⁠