Move the notebook code into a small Python package, save the whole preprocessing and model pipeline, put it behind a FastAPI endpoint in a Docker container and deploy it. Then add what makes it production: tracked runs, a registry, a test in CI, prediction logging and a drift check. Start with batch predictions if you can.
What people tell me
I have trained several models in Jupyter, with decent accuracy, and put the notebooks on GitHub. Every tutorial on deployment seems to jump straight into Kubernetes or a cloud service I have never used, and I get lost. I want to be able to say my model is actually running somewhere and being used, but I do not know what the steps are or how far I need to go.
A composite of the messages behind this question, with personal details left out.
Key takeaways
- Deployment starts with refactoring: move notebook code into functions in a package and save the full pipeline.
- Decide batch or online first; batch predictions written to a table are a perfectly valid deployment.
- FastAPI plus Docker plus a managed container platform is enough for a first online deployment.
- Track runs, register the model and load it by alias so you can roll back.
- Log predictions and check drift, or you will not know when the model stops working.
Why notebook models feel impossible to deploy
Most deployment tutorials start at the end, with Kubernetes or a cloud ML platform, and skip the step that actually blocks you: notebook code is not something a server can run. Cells run out of order, preprocessing lives in five places and paths point at your laptop. Fix that first and deployment becomes a series of small, ordinary steps.
The steps, in order
- Refactor into a package. Move loading, feature building, training and prediction into functions under
src/your_package/, with dependencies inpyproject.tomland a lockfile. Keep the notebook for exploration and import from the package. - Save the whole pipeline. Save preprocessing and the model together as one artefact, so serving applies exactly the same transformations as training.
- Choose batch or online. If predictions can wait, such as scoring all customers every night, a scheduled job that writes predictions to a table is a real deployment and much simpler. If the input only exists at request time, you need an API.
- Build a small API. Use FastAPI with a Pydantic model for the request, load the model once at startup, return the prediction with the model version, and add a health endpoint.
- Containerise it. Write a Dockerfile, build the image and run it locally.
- Deploy it. Put the container on a managed platform that runs containers. You do not need Kubernetes for your first deployment.
- Make it production-shaped. Track your training runs in MLflow, register the model and load it by alias so you can roll back, add a GitHub Actions workflow that runs tests, log every prediction, and schedule a weekly drift report.
Steps 1 to 6 are a weekend or two. Step 7 is what turns a demo into something an employer recognises as MLOps.
A realistic first target
| Level | What you can say | Rough effort |
|---|---|---|
| Demo | My model answers requests at a public URL | 1 to 2 weekends |
| Solid | It is containerised, tested in CI and loaded from a registry | 2 to 4 more weekends |
| Production-shaped | Predictions are logged, drift is checked and I have rolled it back once | 4 to 6 more weekends |
Where to learn each part
The MLOps and LLMOps roadmap takes you through these steps as stages, with checks and projects for each, and the MLOps cheat sheet has the code patterns for the API, the Dockerfile, aliases and drift reports. For tracking and the registry, the MLflow cheat sheet goes deeper. Good free resources: the FastAPI tutorial for the API, Docker Get Started for containers, Made With ML for software engineering around models, and MLOps Zoomcamp for deployment and monitoring with homework.
Common mistakes
- Loading the model inside the request handler, which makes every call slow.
- Rebuilding preprocessing by hand in the API, so live features differ from training features.
- Deploying without logging predictions, so there is no way to know when the model gets worse.
- Starting with Kubernetes and spending a month on cluster setup instead of the model.
If you want a structured project to practise on, the demand forecasting service with drift monitoring covers the whole loop. More answers like this are on /questions/.
Create a free Sefism account to follow the roadmap with progress tracking, or book a session with me and we will pick the right first deployment for your project.
Was this answer helpful?
Your situation is not quite this one?
Members get written answers to their own questions, a roadmap built for them and feedback on their projects. Early access is open: sign up and your account is active shortly after. Prefer to talk? A free call works too.