For most production services, bake an approved model into an image or a versioned volume and run with no outbound access to a model hub. Download at startup only when images would be unmanageably large, and then pin a full commit hash and verify hashes before the service takes traffic.
The two approaches
Baked in: the model files are copied into the image at build time. The image digest then identifies the code and the model together.
Downloaded at startup: the container pulls the model from a hub or bucket when it starts. The image stays small and the model can change independently.
Comparison
| Concern | Baked into image | Download at startup |
|---|---|---|
| Reproducibility | One digest names code and model | Depends on what the source returns today |
| Network at runtime | None needed | Outbound access to the source required |
| Image size and pull time | Large | Small image, slow first start |
| Rollback | Redeploy the previous digest | Need to restore the previous model too |
| Scanning | The image can be scanned as one unit | Model files are outside the image scan |
| Source outage or move | No effect on running pods | Startup can fail |
| Update model without rebuild | No | Yes |
Why the network row matters most
Startup download means every new pod depends on an external source being up, unchanged and trustworthy at that moment. If the repo moves or is made private, new pods fail while old ones keep running, which is a confusing outage. See what happens to your build when a model repo moves.
Allowing outbound access at startup also gives any code that runs there a path out. A baked in design lets you run the container with no egress, which limits damage if a model file misbehaves.
When download at startup is reasonable
Very large models, many model variants per deployment, or frequent model swaps can make baked in images impractical. In those cases:
- Download from your own artifact store, not a public hub.
- Pin a full commit hash or content digest in configuration.
- Verify file hashes against a manifest before loading.
- Make the download step an init container, and block the main container until it passes.
- Mount the model volume read only into the serving container.
Middle path
Build the model into a separate data image or volume, versioned and scanned on its own, and mount it into the serving container. You keep a small serving image and a digest for the model.
Try it yourself
Click through it at your own pace, or open it full screen. See what an image scan reports, then think about what it cannot see if the model arrives later.
Safeguard's dependency scanning and policy gates cover the packages and base images in the container. A free scan is a way to start.
Quick check
Does baking the model into the image make it safe?
No. It makes the version fixed and removes a runtime dependency. You still need to vet the model before baking it in.
Can I run the serving container with no network?
Yes, if the model is already in the image or on a mounted volume. That limits what a bad file can reach.
Last reviewed: 19 October 2026.
