Notebook to service: the three files I add before deploying a model

Blake Price — Sun, 01 Nov 2026 15:03:23 +0000

Every model I've shipped started as a notebook, and every one of them needed the same three files before it could be a service.

config.py — one place for paths, model names, thresholds, and timeouts. The alternative is six constants copied into four notebooks, and then a month later nobody remembers which threshold is the real one.

serve.py — a thin FastAPI wrapper with a health endpoint and one predict endpoint. No business logic, no training code. Load the model once at startup, not per request.

test_smoke.py — two tests: the model loads, and a known input returns the expected shape. That's it. It catches 80% of the deploy failures I've caused.

The part I keep relearning: pin the versions. torch + numpy + your GPU driver are a triangle of pain, and "it worked in the notebook" means nothing when the container resolves different wheels.

What else do you add before calling a notebook production-ready?

The migration I would do differently next time

Blake Price — Thu, 29 Oct 2026 02:14:40 +0000

Moved a table with about twenty million rows last month and learned three things the hard way.

Do the double-write before the backfill, not after. We did it the other way and spent two evenings reconciling.

Measure replication lag before you start, not during. Ours spiked and we had no baseline.

Write the rollback plan first. We had one, sort of, in someone's head. That is not a plan.

DEV Community: Blake Price

Notebook to service: the three files I add before deploying a model

The migration I would do differently next time