Install BentoML 1.4.39 for ML Model Serving

End state first: BentoML 1.4.39 in a clean venv, a tiny service answering on http://localhost:3000, and a Docker image path that doesn’t blow up on uv or CUDA base selection. Commands below match that release (May 2026).

BentoML wraps inference code as an HTTP service. One service class, one CLI serve – you get REST endpoints and an interactive UI. I burned time on containerize failures while pinning 1.4.39; those are called out before the happy-path Docker steps so you don’t repeat them.

Most “pip install and go” write-ups stop at the demo greeter. Fine for screenshots. Useless when bentoml containerize dies half an hour later on a path that only exists inside the generated build context. Why do so many guides treat the image build as a footnote?

System requirements for BentoML 1.4.39

From PyPI and the project’s pyproject.toml (as of 1.4.39):

GPU images need a matching CUDA stack. 1.4.38 fixed debian NVIDIA base selection and set DEFAULT_CUDA_VERSION=12.8.1 – if you’re on anything older in the 1.4 line, wrong bases show up quietly.

Official sources only

• PyPI package: pip install bentoml (1.4.39 as of the May 2026 tag)
• Code: github.com/bentoml/BentoML
• Docs: docs.bentoml.com – hello-world serve behavior lives here
• Site: bentoml.com

Skip random mirrors. Dev install from git works (pip install git+https://github.com/bentoml/BentoML) – not what you want in prod.

Install 1.4.39

Clean venv. This sequence worked on fresh Ubuntu and macOS:

# 1. venv (3.11 preferred)
python3.11 -m venv .venv-bentoml
source .venv-bentoml/bin/activate # Windows: .venv-bentomlScriptsactivate

# 2. pip, then BentoML
pip install -U pip
pip install -U bentoml

# Optional extras - only what you need
# pip install "bentoml[all]"
# pip install "bentoml[grpc,io-image]"

Need a lock later? pip install bentoml==1.4.39.

Minimum service (verify the install, not the model)

import bentoml

@bentoml.service
class HelloServe:
 @bentoml.api
 def greet(self, name: str = "world") -> str:
 return f"BentoML 1.4.39 is serving, {name}!"

No weights. Cold start stays tiny so a failure is the install, not CUDA download theater. Swap in torch/transformers later via the docs’ image=bentoml.images.Image(...).python_packages(...) pattern when the greeter already returns 200s.

Day-one env vars:

• BENTOML_HOME – default ~/bentoml (bentos + models). Example: export BENTOML_HOME=/data/bentoml
• BENTOML_CONFIG – custom YAML for workers, timeouts, traffic settings

Think of BENTOML_HOME like a junk drawer next to the workbench: every build and model save drops another thing in. Nothing in the product enforces a quota. Ignore it for a week of experiments and the disk alarm is what tells you.

Verify

bentoml --version
# bentoml, version 1.4.39

python -c "import bentoml; print(bentoml.__version__)"

bentoml serve service.py:HelloServe
# listening on http://localhost:3000

Open http://localhost:3000. Hit /greet in the UI, or:

curl -X POST http://localhost:3000/greet 
 -H "Content-Type: application/json" 
 -d '{"name": "deploy"}'

You want that string back. Install works.

Port busy? Kill the old process or bentoml serve --port 3001.

Common install and containerize failures

The catch is almost never pip install. It’s the image build.

1. containerize + uv: “No such file or directory” on requirements.txt
Showed up on 1.4.31-class builds with Python 3.13 – generated Dockerfiles running uv --directory ./src pip install -r ... against a path that wasn’t there. Reporters unblocked by pinning a known-good older 1.4.x, moving off 3.13 for the build host, or jumping forward once uv/build path fixes landed. 1.4.39’s notes call out containerize/uv-related fixes (symlink following, BuildKit cache, FileSchema UTF-8). Prefer 3.11/3.12 on the machine that runs containerize.

2. ValueError: Accessing file outside of current working directory
Custom dockerfile_template in bentofile.yaml. Tighter path checks (mid-1.4.x) extract under /tmp, then reject template paths that resolve outside the expected CWD. Keep templates inside the project tree. If you’re mid-regression between the secure-path change and the follow-up fix, skip custom templates until you confirm your exact patch level.

3. Wrong CUDA base on debian
Pre-1.4.38 templates could pick bases that didn’t match older CUDA (≤12.1) naming. 1.4.38+ fixes get_cuda_base_image behavior and defaults to 12.8.1. GPU Bento pulls something odd? Force cuda_version in the image config, or upgrade past 1.4.38.

4. Import errors at local serve
Local serve uses this venv. The Bento image freezes its own deps. So yes – you still pip install torch transformers (or whatever) locally even though the image will install them again later. Different environments on purpose.

Package only after serve works

bentoml build
bentoml containerize hello_serve:latest # tag: check bentoml list
docker run --rm -p 3000:3000 hello_serve:latest

Docker daemon has to be up. Tag names follow what bentoml list prints – don’t guess.

Upgrade, uninstall, disk cleanup

pip install -U bentoml
# or
pip install bentoml==1.4.39

Simple services usually move across 1.4.x without code edits. Custom Dockerfiles and uv-based installs are where changelogs matter.

pip uninstall bentoml -y
rm -rf "${BENTOML_HOME:-$HOME/bentoml}"
# leftover images: docker images | grep -i bento

Deleting the venv removes the package only. BENTOML_HOME is separate and can hold multiple GB of bentos/models with no built-in GC – as of current docs there’s still no official RAM/disk minimum and no quota. bentoml list / bentoml models list, then bentoml delete / bentoml models delete on old tags.

FAQ

Does BentoML 1.4.39 support Python 3.13?

No – not in the published classifiers (3.9-3.12). Use 3.11 or 3.12.

I only need a local API – do I have to containerize?

No. bentoml serve is enough for dev and plenty of internal tools. Example: one model, one team, VPN-only access – stop at serve. Build + containerize when you need a repeatable artifact for Kubernetes, ECS, or a bare-metal host. Managed BentoCloud is the route if you don’t want to own Docker at all.

Where did the disk space go?

Almost always ~/bentoml or whatever you set as BENTOML_HOME. Each bentoml build and model save accumulates. List, delete old tags, re-check disk. If you already wiped the venv and space didn’t return, you only removed the package – the home directory is still there. That’s the whole cleanup story; don’t expect automatic garbage collection.

Copy the venv + service.py block. Run bentoml serve. When /greet is healthy, replace the method body with your real load path. Then bentoml build && bentoml containerize and push the image where ML model serving actually has to run.