From a Working Model to a Live Application: Lessons from an MLOps Workshop
A practical recap of how we took a customer-retention model from a local FastAPI application to a tested container, an automated CI pipeline, and a live cloud deployment.
A machine-learning model that works on one laptop is only the beginning. For other people and systems to use it reliably, the model needs an API, a reproducible runtime, automated tests, and a deployment process.
That was the focus of my recent Model to Production workshop. Using a customer-retention risk application, we followed one model through the practical steps required to turn it into a working web service.
Our starting point
The starter project contained a trained scikit-learn model, a FastAPI server, automated tests, and a browser interface. The model used deterministic synthetic data rather than real customer records. This kept the exercise reproducible and allowed us to concentrate on delivery instead of data access or privacy concerns.
We began by creating an independent repository from the public starter template. Participants cloned their own repositories, created Python virtual environments, installed the dependencies, and ran the preflight checks and test suite.
Before introducing another environment, we verified that the application worked locally. We opened the browser interface, submitted customer profiles, and inspected the API through FastAPI's interactive
/docs page. We also checked /health and /metadata to confirm that the application and model artifact loaded correctly.Packaging the application with Docker
The next question was simple: how can another computer reproduce the same runtime?
We answered it by writing the Dockerfile together. Instead of treating it as a block of configuration to copy, we discussed each instruction: choosing the Python base image, installing dependencies, copying the application and model artifact, running as a non-root user, and starting Uvicorn on the port provided by the hosting environment.
We then built the image, started a container, and called the health endpoint. This checkpoint demonstrated an important distinction: a Dockerfile is the recipe, an image is the packaged result, and a container is a running instance of that image.
Turning local checks into continuous integration
Once the container worked locally, we created a GitHub Actions workflow. We used the official Checkout and Setup Python actions from GitHub Marketplace, then wrote the project-specific steps ourselves.
The pipeline tested the application on both Ubuntu and Windows. Only after those tests passed did a second job build the Docker image, start a container, and call
/health. This smoke test checked more than whether the Dockerfile compiled. It verified that the packaged service could start and load its model.The most valuable lesson was that a failed pipeline is useful information. It identifies a broken assumption before that change reaches a live environment.
Deploying the passing commit
Finally, we described the hosted service in
render.yaml and deployed it through Render. The deployment used the same Dockerfile we had already tested locally and in GitHub Actions. Its health check called the same /health endpoint, and automatic deployment waited for the repository checks to pass.To prove the complete path, we changed the application version, ran the tests locally, committed the update, and followed that commit through GitHub Actions to the live application.
The main takeaway
MLOps is larger than a single workshop. Real production systems also need monitoring, security, drift detection, model governance, and a controlled retraining process. However, this exercise established an important foundation: the path from a saved model to an operable service should be reproducible and observable.
The specific hosting platform can change. The same principles apply when the container and deployment pipeline move to another cloud environment, including AWS:
- Verify the model and API locally.
- Package the complete runtime, not only the model file.
- Test every change before deployment.
- Expose health and version information.
- Make the deployment process repeatable.
By the end of the workshop, the model no longer worked only on its creator's laptop. It had become a tested, containerized application with a traceable path to production.
Here is the GitHub: https://github.com/cloudcorehub/customer-retention-app-practice
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article