Baseten Sealed Volumes pin model data by digest, with a warning about mutable tags

Baseten [released BDN Sealed Volumes on October 26](https://www.baseten.co/blog/bdn‑sealed‑volumes‑publish‑once‑mount‑anywhere/), giving teams a way to publish read‑only model data once and reference a specific version from deployments. The feature covers more than weights: the announcement names adapters, tokenizers, embedding indexes, lookup tables, compiled engines and reference data as possible contents. A volume is a named collection of files with a series of versions. Baseten says a completed push or synchronization seals a new version and gives it a content digest. A deployment can then name that digest and mount the files at a chosen path. This separates the identity of the model’s data from a copy stored on a developer’s laptop or an independently maintained path in each environment.

The [release’s important deployment warning](https://www.baseten.co/blog/bdn‑sealed‑volumes‑publish‑once‑mount‑anywhere/) concerns tags. A label such as `prod` can be moved to another sealed version; the digest identifying a version does not change. Deployments pinned to the old digest stay there until their source is changed and they are redeployed. A deployment that references the mutable tag has a different boundary: existing replicas keep serving their current version, while new or scaled‑up replicas mount the tag’s new target. Baseten explicitly warns that this can leave one deployment serving two versions at once. Moving a label therefore should not be described as an atomic update of every running replica. For rollback, the documented flow is to select an earlier digest, set it as the source and redeploy. The announcement also describes a seven‑day restoration window for a deleted version.

Baseten [documents two entry points](https://www.baseten.co/blog/bdn‑sealed‑volumes‑publish‑once‑mount‑anywhere/): `baseten volume push` for a local directory, and `baseten volume sync start` for an external source. The synchronization job runs on Baseten and reports a sealed reference when it reaches `READY`; that reference goes under `bdn.mounts` in the deployment configuration. Supported source types named in the release include Hugging Face, S3, GCS, Azure Blob, Cloudflare R2 and CoreWeave buckets. Private sources use a Baseten secret, with OIDC access described as an alternative for S3 and GCS. These are the service’s documented access options, not evidence that a particular account or bucket is already authorized.

The announced requirements are Baseten CLI 1.1.0 or newer, and Truss 0.18.30 or newer for Truss deployments. Volume mounts are not available on T4 or L4 instances as of the article’s last update. Mounts are read‑only; Baseten directs runtime writes to its separate b10cache facility.

Existing deployments using a weights block do not need an immediate configuration change, according to the release. Baseten describes an automatic migration as it rolls out, while encouraging direct volume use for new weights. That remains a migration statement, rather than proof that every existing deployment has already changed. The announcement does not specify complete plan, regional or pricing terms.

AI‑generated conceptual illustration by OpenTools Team: a sealed cartridge and movable tags represent fixed model‑data versions and mutable labels. This is illustrative artwork, not an actual product interface, company location, hardware device or tested result.