Skip to main content

​
Install

​
Commands

The CLI’s default snapshot is alpine-3.23.0-256mb, which is smaller than the SDKs’ default (vsnap-base) and does not have Python preinstalled. Name vsnap-base if you want the two to match.
Starting a sandbox pulls the snapshot first if it is not cached, so pull is only needed when you want the download to happen at a different time from the run: in a Dockerfile layer, in a CI setup step, or before going offline.

​
vpod pull

A snapshot can be named three ways, and all three work anywhere a snapshot is accepted: Names are not unique. vsnap-base is published at three memory limits, and the bare name gives you the 256 MB one, so pin the id when the memory limit matters. Pulling something already cached is a no-op that prints where it is:

​
vpod list

Cached rows are the ones that start instantly. Remote rows are dimmed and download on first use.
list reports the catalogue your credentials reach, and the two catalogues replace each other. Without a key that is the public one; with a key it is your organisation’s instead, so the public snapshots are not in the list.

​
Options

​
--mount, -m

Create a link between your host and your sandbox by mounting a directory. You can configure read-only or read-write permissions for better access control.
Mounts are read-only by default. Append :rw to the sandbox path to allow writes back to the host.

​
--api-key

Reaches the private snapshots belonging to your organisation. See Private snapshots for how keys work.
Reads VPOD_API_KEY when the flag is absent, which is the better way to pass it: a flag ends up in your shell history.
The flag is global, so it goes before or after the subcommand either way.
The CLI takes secret keys (vpod_sk_) only. A publishable key (vpod_pk_) is refused: those are guarded by an allowlist of browser origins, and the CLI is not a browser, so the key would grant nothing.

​
Environment

​
Where snapshots are cached

Downloads land in the user cache directory, shared with the Python SDK and with the Node SDK: Files are named by snapshot id and verified against the digest in the catalogue, so a name that resolves differently under another key is re-downloaded rather than reused. Each file also records which registry and key fetched it, so clearing out snapshots the catalogue no longer lists never touches another organisation’s copies.