Bdn Sealed Volumes Publish Once Mount Anywhere

BDN Sealed Volumes: publish once, mount anywhere Live webinar Oct 28: How to evaluate open models for your coding agents . Save your spot

Infrastructure

BDN Sealed Volumes: publish once, mount anywhere

BDN Sealed Volumes do for model data what container images do for code: publish once, get a digest, mount it anywhere. Mounts take seconds.

Authors

Stephen Day

Gregory Kofman

Yun Zou

Rajesh Malireddy

Published October 26, 2026

Share

Published October 26, 2026

TL;DR BDN is built to distribute any content (weights, container images, training checkpoints) across model serving infrastructure. Now, BDN Sealed Volumes let you publish any read-only data once and mount it in any deployment. Sealed Volumes are available today with the Baseten CLI 1.1.0 or newer.

When there’s no single source of truth for model files, data drifts from its source. Say you fine-tune a model, then save the checkpoint to cloud storage. Then someone downloads a copy to their laptop to test it, uploads it somewhere else so it can be served, and each deployment—e.g., staging, production, and testing—has its own config file pointing to the checkpoint. When one person pins another revision, nobody notices until the outputs differ. The same problem applies to LoRA adapters, vector indexes, tokenizers, embedding indexes, lookup tables, and any model or deployment artifact. Container images solved this problem for code a decade ago: you build once, get a digest, then run that digest anywhere. We’re releasing BDN Sealed Volumes to do the same for model data, and help our customers keep data consistent across iterations. What is a Sealed Volume? Sealed Volumes let you publish any read-only data once and mount it in any deployment. Push a directory, or sync a Hugging Face repo, a bucket, or a training checkpoint, and BDN seals the result as an immutable version with a digest. Reference that digest in your config.yaml , and every replica streams in identical data without needing to manually download anything. A volume specifically is a named, versioned set of files that the Baseten Delivery Network (BDN) delivers to your deployments. Volumes live in namespaces, such as weights , and hold a series of versions. When baseten volume push or baseten volume sync finishes, BDN commits the files as a new version and seals it. A sealed version never changes, and BDN identifies it by a digest of its contents: bdn:weights/qwen3-8b@b3:9f3c… You can use the --tag parameter when pushing to give a mutable name (the only mutable part) to a particular version. For instance, pushing with --tag prod points prod at the new version; so while bdn:weights/qwen3-8b:prod is a name people can read, the digest is what a deployment should pin. If you've used container registries, this is the same split between a tag and an image digest, and exists for the same reasons. Because your digest sits in your config files, mismatches between versions show up in a diff. ✕ One volume with three sealed versions. The “prod” tag points at version two, moved there by a push or a tag command, and both deployments pin its digest. Why Sealed Volumes? Sealing volumes is what keeps data consistent when you build on top of them. Because they’re sealed: Every replica serves the same bytes: A sealed version never changes, and every deployment that references it mounts the same files, read-only, so every replica streams the same bytes. Pinning the digest means later pushes can't change what this deployment mounts. To roll back, just point config.yaml at an earlier digest.

Updates upload only what changed: BDN splits files into chunks and stores each chunk once by its content hash, so a new checkpoint that shares most of its bytes with the previous one uploads only the chunks that changed. Files are keyed by hash, so BDN never transfers a file it already holds. This makes iterative uploads (like fine-tuning a base model) fast.

Deployments start without a download step: Because a sealed volume is mounted at the path you choose in config.yaml , the files are available as soon as the container starts. Bytes stream in from the BDN cache tiers as your model reads them. Startup time no longer depends on how big the volume is.

How to publish a Sealed Volume in two commands For a model on Hugging Face, the sync runs as a durable background job on Baseten; nothing downloads to your machine. This is the whole loop: baseten volume sync start \ -- source hf://Qwen/Qwen3-8B \ --dest bdn:weights/qwen3-8b:prod \ --include "*.safetensors" --include "*.json" \ -- wait When the job reports READY , it prints the sealed version's reference. Copy that into the deployment: model_name: qwen3-8b resources: accelerator: H100 bdn: mounts:

• source: bdn:weights/qwen3-8b@b3:

path: /mnt/weights/qwen3-8b Point your server at /mnt/weights/qwen3-8b and deploy with baseten model push . There’s no weights block to maintain, or credentials in the deployment. Subsequent deployments that reference already-mirrored content resolve in a metadata check, not a data transfer. sync works the same way for Hugging Face, S3, GCS, Azure Blob, Cloudflare R2, and CoreWeave buckets. Private sources take a Baseten secret, and for S3 and GCS you can skip stored credentials entirely and grant access with OIDC. To publish a local directory instead, use: baseten volume push ./dir bdn:weights/qwen3-8b --tag prod push uploads chunks in parallel, and skips any chunk BDN already holds. Updating versions and rolling back Pushing with --tag prod moves the tag to the new version, without publishing anything: baseten volume tag set --volume-ref bdn:weights/qwen3-8b@b3: --tag prod Deployments that pin a digest keep serving the old version until you change the source and redeploy. Moving the tag later doesn't change what running replicas serve, but new and scaled-up replicas mount the tag's new target. A deployment that mounts a tag can therefore serve two versions at once after a push. To roll back, pick the earlier digest from baseten volume versions , set it as source , and redeploy. A deleted version stays restorable for 7 days via baseten volume restore . BDN Sealed Volumes are for more than model weights Anything your model reads and doesn't write belongs in a volume. Common files a deployment reads at runtime that belong in volumes include: Adapters and sub-models. Deploy multiple LoRA adapters on a single base model and switch between them at inference time. Each adapter can be its...