Model files stop being copied between deployments: Baseten seals each version behind a content digest, and startup no longer waits for a full download
Synopsis
Baseten now lets read-only model data be published once as a sealed volume: a directory or checkpoint is committed as an immutable version addressed by a content digest that any deployment can mount. Previously the same checkpoint was downloaded and re-uploaded to several places, each deployment holding its own config pointing at a copy, so a mismatched revision surfaced only when outputs diverged. Volumes are chunked and keyed by content hash, so a push transfers only changed chunks, and a mount makes files available as the container starts, removing the pull phase from startup. Sealed Volumes ship with Baseten CLI 1.1.0 and newer.
Interpretation
Read-only files such as model weights, LoRA adapters and tokenizers now need to be published on Baseten only once, and any deployment mounts the same immutable data. Before this, a fine-tuned checkpoint was saved to cloud storage, someone downloaded a copy to a laptop to test it, someone else uploaded it so it could be served, and staging, production and testing each kept a config pointing at that checkpoint; when one person pinned another revision, it surfaced only once outputs differed. A sealed version is identified by a content digest, the digest sits in the config file, so a version mismatch appears in a diff, and rolling back means pointing the config at an earlier digest.
A deployment does not pull the whole model before it starts: the volume is mounted at the path named in the config, and bytes stream in from the cache tiers as the model reads them. Publishing runs through two commands, baseten volume push for a local directory and baseten volume sync for a Hugging Face repo or an S3, GCS and similar bucket, which commit the result as an immutable version; files are split into chunks keyed by content hash, so a new checkpoint uploads only the chunks that differ from the previous one. For a model on Hugging Face, the sync runs as a background job on Baseten with nothing downloaded to the machine and prints the sealed reference when ready, and bdn.mounts places it at the chosen path; the comparison given is that a weights block pulls every file before the container starts so startup time grows with model size, while a sealed volume mounts in seconds and is read at the same rate as a weights mount.
Perspective
Sealed Volumes ship with Baseten CLI 1.1.0 and newer, Truss deployments need 0.18.30 and newer, and volume mounts are not available on T4 or L4 instances. Existing deployments using a weights block need no config change, since the migration rolls out from the platform side; new weights can be synced into a volume and mounted by digest.
Mounts are read-only, so files a model writes at runtime go to b10cache; a deployment that mounts a tag can serve two versions at once after the tag moves, and the source recommends pinning the digest; a deleted version stays restorable for 7 days.