# From Local Model to Deployable API: A Docker Journey How containerization bridges the gap between development and production ML models - **Source:** [Towards Data Science](https://towardsdatascience.com) - **Published:** 2026-09-13 - **Topic:** [Data & AI](https://brifing.si/c/data-ai) - **Original article:** - **On Brifing:** https://brifing.si/s/05158997-2a08-41a8-8570-56c05cc418b5 ## The Deployment Reality Check The author initially believed their churn prediction model was complete after local testing, only to realize it was essentially useless outside their personal laptop environment. This highlights a common pitfall in machine learning projects where models never transition from development to production. The article documents the practical steps needed to make an ML model truly accessible and usable by others through proper deployment techniques. ## Understanding the Deployment Challenge The core problem identified was environmental dependency - the model required specific Python versions, package dependencies, and file paths that wouldn't exist on other machines or cloud servers. This reproducibility crisis is a fundamental challenge in ML operations that containerization aims to solve. The author's FastAPI application for churn prediction served as the test case for learning proper deployment practices. ## Docker as the Solution Containerization with Docker emerged as the solution to the deployment problem. Instead of delivering just code with installation instructions, Docker packages the application with its complete environment into a self-sufficient image. This includes the specific Python version, all required libraries, and the correct folder structure - eliminating the 'it works on my machine' problem that plagues software development. ## Preparing for Containerization Before writing the Dockerfile, the author meticulously documented their local environment using pip freeze to capture exact package versions. This attention to detail is crucial for ensuring the containerized environment matches the development environment where the model was trained and tested. The list included critical packages like FastAPI 0.141.1, scikit-learn 1.9.0, and Python 3.14.6. ## Crafting the Dockerfile The Dockerfile configuration specified Python 3.14-slim as the base image to match the local environment. It followed standard practices: setting a working directory, copying requirements, installing dependencies, and copying application code. The configuration exposed port 8000 and set the command to run the FastAPI app using Uvicorn. The initial build took 166 seconds due to some packages needing compilation for Python 3.14. ## Unexpected Module Error The first runtime error revealed a path resolution issue - Python couldn't find the schemas module. This occurred because the working directory in the container differed from local development. The error highlights how subtle differences in execution context can break applications during deployment, even when the build process completes successfully. ## Fixing Path Resolution The solution involved modifying the Uvicorn command to explicitly use the app folder as the root directory, mimicking the local development setup. This adjustment maintained the same module resolution behavior as during development. After rebuilding the image with this change, the container ran successfully, demonstrating identical behavior to the local environment. ## Validation Testing The author sent test requests to verify the containerized model produced identical outputs to the local version. This validation step confirmed the container hadn't altered the application's behavior - returning the same churn probabilities, predictions, and risk levels. Such testing is crucial when moving models between environments to ensure consistent performance. ## AWS EC2 Deployment For cloud deployment, the author chose an AWS t3.micro EC2 instance running Ubuntu, which is free-tier eligible and suitable for lightweight API deployments. The setup involved configuring security groups with appropriate inbound rules and establishing SSH access. This choice maintained architectural consistency with previous projects while keeping costs minimal for this learning exercise. ## The Deployment Mindset This journey underscores that an ML model isn't truly complete until it's deployable and usable by others. The article demonstrates how containerization bridges the gap between development and production, solving critical issues of reproducibility and accessibility. These deployment skills are as essential as model-building expertise in real-world data science applications. ## Sources covering this story - https://towardsdatascience.com/your-model-isnt-done-until-someone-else-can-call-it/ — --- _Summary written by Brifing from the original reporting. Copyright in the original article belongs to its publisher; read the full piece at the link above._