blobhub blob limits

The limits in force for a blob, group by group, including the import allowlist

blob limits shows the limits in force for a blob: its platform.revisions_per_blob, and every limit of the blob’s own type — for a workflow blob, among them the workflow.code_imports allowlist that decides which third-party modules a revision’s code may import. Any key that can read the blob can read its limits. See Limits for what each limit means and how its value is chosen.

Synopsis

blobhub blob limits <org>/<blob> [--refresh]

Argument	Default	Description
blob	required	Blob as <org>/<name>, or a bare name with --org.

Flag	Default	Description
--refresh	off	Also refresh the compiler’s local allowlist cache.

What it does

One call, to the blob’s limits route. Unlike its two siblings it never fetches the blob record first — the limits route is the only request it makes.

Limits for acme/flow
  ID                             HELD     SOURCE   VALUE
Global (platform)
  platform.revisions_per_blob    1        default  2
Workflow (blobhub.compute.workflow)
  workflow.enabled                        default  true
  workflow.code_imports                   blob     ["numpy"]
  workflow.session_object_bytes           platform 5242880

The example is abridged: a workflow blob lists every workflow limit, and the ID column is as wide as the longest id served. The output is the platform’s catalog, printed as served:

• One block per group, in the platform’s order, headed by the group’s label and key: Global (platform) first, then the blob’s own type.
• One row per limit: its id; HELD where the platform reports a holding; the SOURCE of its value — default, user, org or blob for an override set at that level, platform for a fixed limit; and the VALUE.
• VALUE is printed as JSON, so a number, a flag, a module list and null all print as the platform sent them. It is the last column because a module list has no width bound.
• A limit the CLI has never seen prints like any other. Nothing about the catalog is built into this command.

Under --json the payload carries blob, groups — the platform’s response, verbatim — refreshed, and cache_path (null without --refresh).

Access

Limits are readable with any key that can read the blob, whatever its role. A 403 means what it means for blob show: the blob is absent, or this key cannot read it, and the platform answers the same for both. The command raises BLOB_NOT_ACCESSIBLE.

--refresh and the compiler’s allowlist cache

--refresh writes the modules in workflow.code_imports into the cache that build and diff read, under ~/.blobhub/cache/allowlist/, at mode 0600, alongside the fetch timestamp and the org and blob it came from. The entry "*" is left out: it tells the platform to import every listed module before the code runs, and is not a module itself. One more line follows the limits, naming the file it wrote:

Allowlist cache written to /Users/you/.blobhub/cache/allowlist/acme/dragon-ops.yaml

That same path is the --json payload’s cache_path.

workflow deploy reads the allowlist live and writes the same cache on every run but a --dry-run, which reads the cache instead. This flag is for a machine that builds without deploying: run it once there, and later builds read what it wrote. The cache is per-machine.

Before relying on it, know how the cache is keyed and when it goes stale.

The cache key is your reference as you typed it, lower-cased — org-qualified exactly when your reference is. build keys on the manifest’s blob: field the same way, as written. So a manifest saying blob: dragon-ops reads a different cache entry from the one blobhub blob limits acme/dragon-ops --refresh writes, and the refresh you just ran would change nothing:

# for a manifest whose blob: field is 'dragon-ops', refresh the bare name
blobhub --org acme blob limits dragon-ops --refresh

A cache entry goes stale after seven days. Past that, a build reading it raises ALLOWLIST_STALE and blobhub doctor’s allowlist row warns, naming the entry and its age. This command is how you clear that.

Errors

Code	When
BLOB_NOT_ACCESSIBLE	The limits read returned 403: the blob is absent, or this key cannot read it. The platform returns the same 403 for both. If the org segment isn’t a UUID, the message also notes that an org-scoped key must address the org by its id.
BLOB_REFERENCE_INVALID	The reference is empty, carries more than one /, has an empty org before the /, has no blob name, or is a bare name with no --org and no BLOBHUB_ORG.
MANIFEST_INVALID	--refresh only, and despite the name: the reference cannot be turned into a cache-file path. No empty, ., .., absolute, or backslash-bearing segments. The code is shared with the manifest loader, which is the other caller of the same normalizer.
CREDENTIALS_NOT_FOUND	No API key from flags, environment, or credentials file.
PROFILE_NOT_FOUND	BLOBHUB_PROFILE names a profile that is not stored.
INSECURE_CREDENTIALS_PERMISSIONS	credentials.yaml is readable by group or other.
API_RATE_LIMITED, API_TRANSIENT_ERROR, API_NETWORK_ERROR	The limits call failed after its retries.

See also

• blobhub blob show — the record, readable with the same key.
• blobhub blob revisions — every revision, as many as platform.revisions_per_blob allows.
• Concepts — the allowlist cache and the other platform behaviours that shape the binary.
• Error codes — LIMIT_EXCEEDED, the allowlist advisories, and the rest of the catalog.
• Get Blob Limits — the route behind this command.
• Limits — the model, the error and the full catalog.