From Model to Container:
Deploying a Titanic Survival API on Docker Hub

Problem

A machine learning model that runs only on the developer's machine is not deployable. It depends on a specific Python version, a specific set of installed libraries, and a specific directory structure — none of which another person, server, or cloud environment is guaranteed to have. The traditional answer is documentation and hope: "install these packages, make sure your numpy matches, good luck." Docker eliminates that entirely. The challenge in this project was learning how to package not just a trained model but an entire ML inference stack — training environment, model artifacts, and FastAPI service — into reproducible containers that anyone can pull and run with a single command, anywhere.

Solution

This project trained a Random Forest classifier on the Titanic dataset inside a Jupyter Docker container, resolved a numpy/pandas binary incompatibility that crashed the serving layer, and packaged the FastAPI prediction API into a Docker image published to Docker Hub. The result is a fully containerized, publicly pullable ML service: docker pull thetechlearner/titanic-survival-api:v1.0 runs a production-ready API that accepts passenger features and returns survival probabilities with structured confidence levels — no local Python environment required.

Skills Acquired

• Docker — the core tool of the project. Used to containerize both the training environment (Jupyter + scikit-learn) and the serving environment (FastAPI + model artifacts). Every artifact produced in this project is reproducible via Docker commands.
• Docker Hub — the public container registry where the final image was pushed and tagged as both v1.0 and latest. Anyone can pull thetechlearner/titanic-survival-api and run it locally without a Python environment.
• FastAPI — the serving framework wrapping the trained model. Exposes four endpoints with auto-generated Swagger documentation at /docs.
• scikit-learn — used to train the Random Forest classifier on the Titanic dataset. Feature engineering (age groups, fare levels, family size) was applied at both training and inference time to ensure consistent representations.
• Dependency management — diagnosed and resolved a numpy/pandas binary incompatibility ("numpy.dtype size changed, may indicate binary incompatibility") by pinning numpy==1.24.3 alongside pandas==2.0.3 in requirements.txt.
• Docker image tagging — learned the distinction between tagging with a username (thetechlearner/) versus a local alias, and how registry authorization works when pushing to Docker Hub.
• MLOps workflow — experienced the full containerization pipeline: train → serialize → serve → containerize → push → document.

Deep Dive

There is a well-known gap between "it works on my machine" and "it works in production." Docker exists to close that gap. Before this project, I understood containerization conceptually — after it, I had shipped a containerized ML service to a public registry that anyone in the world can pull and run.

This project built a two-container ML system: one container for training (Jupyter + scikit-learn on the Titanic dataset), and a second, leaner container for serving predictions via FastAPI. The serving container was pushed to Docker Hub as thetechlearner/titanic-survival-api:v1.0 — a publicly verifiable, reviewer-approved deployment artifact.

Why This Project?

This was the Docker and Containerization sprint of my TripleTen AI and Machine Learning Bootcamp. The assignment: train a model from scratch inside a Docker container, build a serving API, containerize it, and publish the image to Docker Hub for others to pull and run. The Titanic survival dataset was the chosen domain — a classic binary classification problem that put the focus on the containerization workflow rather than model complexity.

I treated every step as a real MLOps exercise — not just making things run but making them reproducible. The numpy/pandas incompatibility that crashed the first serving attempt was a real production-class dependency management problem, not a notebook error.

What You'll Learn from This

• Why Docker containers solve the "works on my machine" problem for ML systems — and what "reproducible environment" actually means in practice
• How to structure a two-container ML project: training environment separate from serving environment
• Why pinning numpy alongside pandas matters — and how binary incompatibilities between compiled packages manifest at runtime
• The correct workflow for tagging and pushing Docker images to Docker Hub, including why the username prefix must match your registry account
• How FastAPI's auto-generated Swagger UI gives you a live, testable API explorer with zero additional documentation work
• What a reviewer looks for when validating a containerized ML deployment — from image pullability to endpoint contract compliance

The Service

The API predicts Titanic passenger survival from 7 features: passenger class, sex, age, siblings/spouses aboard, parents/children aboard, fare, and embarkation port. The trained Random Forest model applies feature engineering at inference time — computing age group, fare level, family size, and travel-alone status — before making a prediction.

The prediction response includes not just survived and survival_probability but also a prediction_confidence label (High / Medium / Low) and a full passenger_profile object — showing the feature-engineered representation the model actually used.

# Live test result — Class 1 adult female
curl -X POST "http://localhost:8000/predict" \
  -H "Content-Type: application/json" \
  -d '{"Pclass": 1, "Sex": "female", "Age": 30.0,
      "SibSp": 0, "Parch": 0, "Fare": 50.0, "Embarked": "S"}'

# Response
{
  "survived": 1,
  "survival_probability": 0.9152319739084446,
  "prediction_confidence": "High",
  "passenger_profile": {
    "class": "Class 1",
    "gender": "female",
    "age_group": "Adult",
    "family_size": 1,
    "traveling_alone": true,
    "fare_level": "High",
    "embarkation_port": "Southampton"
  }
}

How I Built It

ValueError: numpy.dtype size changed, may indicate binary incompatibility.
Expected 96 from C header, got 88 from PyObject

# requirements.txt — before (missing numpy pin)
fastapi==0.104.1
uvicorn==0.24.0
pandas==2.0.3
scikit-learn==1.3.0
joblib==1.3.1
python-multipart==0.0.6

# requirements.txt — after (numpy pinned to compatible version)
fastapi==0.104.1
uvicorn==0.24.0
numpy==1.24.3
pandas==2.0.3
scikit-learn==1.3.0
joblib==1.3.1
python-multipart==0.0.6

# Retag with correct Docker Hub username
docker tag titanic-survival-api thetechlearner/titanic-survival-api:v1.0
docker tag titanic-survival-api thetechlearner/titanic-survival-api:latest

# Push both tags
docker push thetechlearner/titanic-survival-api:v1.0
docker push thetechlearner/titanic-survival-api:latest

# Anyone can now pull and run the API
docker pull thetechlearner/titanic-survival-api:v1.0
docker run -p 8000:8000 thetechlearner/titanic-survival-api:v1.0

Model Performance

The Random Forest (100 estimators, max_depth=10) was trained on 712 samples and evaluated on 179 held-out samples using a stratified 80/20 split.

Top 10 feature importances from the trained model:

Reviewer Approval

The project received full approval from TripleTen reviewer Victor Camargo. Every checkpoint was verified against the official evaluation criteria.

Key Takeaways

• Two-container architecture — training and serving are separate concerns, each with their own Dockerfile and dependencies
• Dependency pinning is non-negotiable — missing a numpy pin caused a binary incompatibility that would fail silently in a notebook but crashes a container immediately
• Registry account must match image tag — vietnguyen/ and thetechlearner/ are different namespaces; the image tag must match the Docker Hub account you're authenticated to
• Create the Docker Hub repo before pushing — the registry won't auto-create a repository on push; it must exist first
• Feature engineering at inference time — all 5 engineered features (FamilySize, IsAlone, Title, AgeGroup, FareGroup) are computed inside the container, ensuring consistency with training regardless of caller inputs
• Full reviewer validation — all 10 checkpoints approved by TripleTen reviewer, confirming the deployment artifact meets production standards

Conclusion & Reflections

The most durable lesson from this sprint: containerization is not a deployment detail — it is a reproducibility guarantee. Every time someone runs docker pull thetechlearner/titanic-survival-api:v1.0, they get the exact same Python version, the exact same library versions, and the exact same model weights that the reviewer validated. No setup instructions. No "works on my machine."

That guarantee is what makes containers the standard unit of deployment for ML systems in production. It is also what makes a containerized portfolio project more credible than a GitHub notebook: the artifact is verifiable, pullable, and runnable by anyone with Docker installed — including a technical interviewer.