Module 1: Understanding Deployment Options

1. Introduction: Understanding Deployment Options

Next →

Overview

This is the first capsule of Module 1 of the Deployment & Cloud Infrastructure Guide. Here you'll understand the full landscape of deployment options for AI systems: Local, Serverless, Managed, and Self-hosted. Before you touch a single line of configuration, you need a mental framework to decide where and how to deploy your application.

Why it matters: Most AI Engineers build their app, containerize it with Docker, set up CI/CD, and then freeze: "Where do I deploy it? AWS? Render? My own server?" This module answers that question with a decision framework, not an opinion. Without this framework, the later modules (Docker Compose, Lambda, LocalStack, AWS, alternatives) would be loose techniques with no criteria for when to use each one.

This module isn't theory for theory's sake. Every concept connects to the Deployment Decision Workshop you'll build at the end: a decision matrix that evaluates your real use case and produces a documented recommendation. That matrix extends in Module 7 (platforms) and gets applied in Module 8 (capstone project). It's piece one of a decision system that matures throughout the whole guide.

Where Are We in the Guide?

Context

This guide has 8 modules organized into 3 phases:

Phase 1: Deployment Strategies (Modules 1-3)
├── Module 1: Understanding Deployment Options    ← YOU ARE HERE
├── Module 2: Local & Container Deployment
└── Module 3: Serverless & Lambda for AI

Phase 2: Cloud Infrastructure & Migration (Modules 4-6)
├── Module 4: LocalStack — AWS Local Development
├── Module 5: AWS Services for AI (S3, Lambda, SageMaker Basics)
└── Module 6: Cloud Migration Patterns

Phase 3: Alternatives & Production (Modules 7-8)
├── Module 7: Alternative Platforms (Render, Railway, Fly.io)
└── Module 8: Capstone Project — Deployed AI System

Total estimated duration: 10-12 hours (self-paced).

Where Are We Headed?

This module gives you the complete decision framework. With that base, Module 2 goes deep on local multi-container deployment with Docker Compose, and Module 3 on serverless with AWS Lambda for AI.

The progression is deliberate:

  1. First you decide (this module) — without criteria, every tool looks like "the right one"
  2. Then you implement locally (module 2) — Docker Compose multi-container, production-like
  3. Then serverless (module 3) — Lambda for AI with cold starts, timeouts
  4. You develop at zero cost (module 4) — LocalStack for AWS locally
  5. You integrate AWS (module 5) — S3, Lambda, SageMaker basics
  6. You migrate (module 6) — LocalStack → AWS patterns
  7. You evaluate alternatives (module 7) — Render, Railway, Fly.io
  8. You integrate everything (module 8) — AI system deployed in production

The Four Deployment Categories

Quick Overview

Before going deep in the following modules, you need to know the four big categories. Each has a distinct profile of cost, complexity, scalability, and control:

CategoryWhat it isExampleWhen
LocalYou run the app on your own machine or server with containersDocker Compose on your laptop or a VPSDevelopment, staging, low-traffic MVPs
ServerlessThe cloud provider manages the infrastructure, you just upload codeAWS Lambda + API GatewayEvent-driven APIs, variable traffic, pay-per-use
ManagedPlatforms that abstract infrastructure with deploy-from-GitRender, Railway, Fly.io, HerokuStartups, MVPs that need to be online fast
Self-hostedYou manage your own servers (physical or cloud VMs)EC2, DigitalOcean Droplets, bare metalFull control, compliance, predictable workloads

The transportation analogy

Think of deployment like choosing transportation for a trip:

  • Local = Your own car. Full control, you know exactly how it works, but you maintain it, you pay for gas, and if it breaks down on the road, you're the one who fixes it.
  • Serverless = Uber/taxi. You only pay per ride, you don't worry about vehicle maintenance, but you don't control the route or the car.
  • Managed = Express bus. Predefined route, fixed price, you get there fast without managing anything, but you can't take a detour.
  • Self-hosted = Buying and operating your own truck fleet. Maximum control, you can optimize every aspect, but you need mechanics, drivers, and a garage.

No option is "better." It depends on your destination (requirements), budget, team, and urgency.

Each Category in an AI Context

Let's look at how each category plays out in practice for an AI Engineer. These are quick snapshots — capsule 02 goes deep on each one.

Local — Your AI app in containers you manage:

# What a typical local deployment for AI runs:
# docker-compose.yml orchestrates 3 containers:
#   - FastAPI API (your app, receives prompts, returns responses)
#   - ChromaDB (vector store for RAG, ~2GB in memory)
#   - Redis (response cache to reduce API costs)
# Total: 1 command (docker compose up) → full AI system running

Your RAG app with FastAPI + ChromaDB + Redis runs on Docker Compose on a $24/month VPS. Your embeddings are in memory, Redis caches responses, and you control everything. If the VPS goes down at 3am, you're the one who fixes it.

Serverless — Functions that run on demand:

# What serverless for AI runs:
# - 1 Lambda function (receives prompt, calls LLM, returns response)
# - API Gateway as the HTTP trigger
# - No permanent containers, no VPS
# You pay: ~$0.000017 per invocation × number of requests

Your Lambda function receives a prompt, calls GPT-4o-mini, and returns the response. The first request of the day takes 3 seconds (cold start) while Lambda imports the OpenAI SDK. The following ones are fast.

Managed — Deploy from Git, the platform does the rest:

# What you do in a managed deployment:
git push origin main
# Railway detects the change, builds your container, deploys
# https://your-app.railway.app is live in 2 minutes with SSL included

You connect your GitHub repo to Railway, push, and in 2 minutes you have a public URL with SSL. Railway manages the container for you. If you need Redis, you add an add-on with one click.

Self-hosted — Full control, full responsibility:

# What you manage in self-hosted for AI:
# - 3 EC2 instances (app servers with a load balancer)
# - 1 GPU instance p3.2xlarge (local model inference)
# - Prometheus + Grafana (monitoring)
# - Nginx (reverse proxy + SSL)
# - Your ops team maintains everything 24/7

You have EC2 instances with a load balancer, a GPU to run Llama 3 locally, Prometheus for monitoring, and a dedicated team maintaining the infra. Maximum control, maximum overhead.

Module Objective

By the end of this module you'll be able to:

  • ✅ Differentiate the four deployment categories (Local, Serverless, Managed, Self-hosted) with concrete examples for AI systems
  • ✅ Evaluate trade-offs across five dimensions: cost, operational complexity, scalability, control, and time-to-deploy
  • ✅ Build a functional decision matrix that maps a real project's requirements to the optimal strategy
  • ✅ Identify how the project stage (MVP, growth, scale) changes the recommended strategy
  • ✅ Explain basic cost modeling: fixed vs variable costs per strategy
  • ✅ Document decision criteria in a way that lets another engineer understand and question your choice

Professional objective

When someone asks you "where should we deploy our AI app?", you won't answer "AWS because that's what everyone uses." You'll answer: "It depends. What's your budget? How much traffic do you expect? Do you have an ops team? What latency do you need for inference?" And you'll have a framework to turn those answers into a documented recommendation.

Module Roadmap

Capsule map

#CapsuleWhat you'll learnType
01Introduction (this one)The deployment landscape, why decide before implementingIntro
02Landscape of Deployment OptionsThe 4 categories in depth with AI-specific examplesTechnical
03Trade-offs by StrategyEvaluation across 5 dimensions, detailed comparisonTechnical
04Serverless vs Containers for AIDeep comparison of the two most common optionsTechnical
05Cost Modeling for AI DeploymentFixed vs variable costs, real estimates, calculatorsTechnical
06Decision Matrix FrameworkHow to build and use a decision matrixTechnical
07Project Stage and DeploymentMVP vs Growth vs Scale, how the strategy changesTechnical
08Project: Deployment Decision WorkshopBuild your decision matrix for a real caseProject

Learning flow

First you'll understand the four categories in depth with AI-specific context (capsule 02). Then you'll evaluate trade-offs across 5 dimensions for each strategy (capsule 03). Next you'll compare in detail serverless vs containers — the two most common options (capsule 04). You'll learn to estimate real costs for AI workloads (capsule 05). You'll build a decision matrix framework to systematize the choice (capsule 06). You'll understand how the project stage changes the equation (capsule 07). And finally you'll integrate everything in a workshop where you produce your real decision matrix (capsule 08).

The progression is: categories → trade-offs → comparison → costs → framework → context → project.

Estimated module duration: 1.0-1.25 hours.

Connection to the Project

This module's project: Deployment Decision Workshop

The Deployment Decision Workshop is a structured exercise where you take a real use case (your own AI app or one provided) and produce:

  • A decision matrix that evaluates each strategy against your requirements
  • A decision document with the recommended strategy and justification
  • Documented criteria that another engineer can review and question
Input: Your AI app's requirements
  - Expected traffic: ~5K requests/day
  - Budget: <$50/month
  - Team: 1-2 developers
  - Latency: <3s for inference
  - Stage: MVP

Output: Decision Matrix + Recommendation
  - Recommended strategy: Managed (Railway)
  - Justification: Limited budget, small team,
    simplicity > control, free tier covers the MVP
  - Alternative if it scales: Serverless (Lambda)
  - Review at: 3 months or when reaching 50K requests/day

Connection to the final project: Deployed AI System

The Module 1 decision matrix is the seed of Module 8. In the capstone project, your AI system deployed in production includes documentation of why you chose that strategy and that platform — with the matrix as evidence.

Module 1: Decision Matrix → framework to decide
    ↓
Module 7: Decision Matrix v2 → extended with platform criteria
    ↓
Module 8: Decision Matrix applied → justifies the final deployment

Prerequisites

Required knowledge

  • Basic Docker: You know what a container, image, and Dockerfile are (guide #15)
  • Basic CI/CD: You understand deployment pipelines, GitHub Actions (guide #16)
  • Intermediate Python: FastAPI, Pydantic, async/await
  • AI experience: You've built at least one working AI app (RAG, chatbot, agent)
  • REST APIs: You understand HTTP, requests, responses, endpoints

If you don't have these prerequisites

What you're missingRecommended resource
DockerDocker Essentials Guide (#15) — NIEVA
CI/CDCI/CD for AI Systems Guide (#16) — NIEVA
Python + FastAPIPython REST APIs for AI Guide — NIEVA
AI appsAI Engineering Bootcamp — NIEVA
REST APIsBackend Python Developer Bootcamp — NIEVA

Technical Setup

Required tools

For this module you don't need to install new tools — it's strategic and conceptual. But verify that you have what you'll need in later modules:

# Docker (prerequisite from guide #15)
docker --version
# Docker version 24.0+ expected

# Docker Compose
docker compose version
# Docker Compose version v2.20+ expected

# Python
python --version
# Python 3.10+ expected

# Git
git --version

For this module specifically

You only need a text editor to create your decision matrix. You can use:

  • A Markdown file (recommended — versionable with Git)
  • A spreadsheet (Google Sheets, Excel)
  • Notion, Obsidian, or any documentation tool
# Create a directory for your work
mkdir -p deployment-cloud-guide/module-01
cd deployment-cloud-guide/module-01

# Create a file for your decision matrix
touch decision-matrix.md

Technologies you'll use in this module

Although this module is strategic, you'll use concrete tools to document and calculate your decisions:

ToolFor whatWhere you use it
Python 3.10+Cost calculators, evaluation scriptsCapsules 05 and 06
MarkdownDocument your decision matrix and recommendationFinal project (capsule 08)
GitVersion your decision documentThe whole module
Text editorCreate and edit Markdown filesThe whole module
# Verify that you can run Python (you need it for the calculators)
python3 -c "print('Python OK — ready for cost calculators')"

Work environment for the scripts

Capsules 05 and 06 include cost calculators in Python. To be able to run them:

# Create a virtual environment for this module
python3 -m venv .venv
source .venv/bin/activate  # macOS/Linux

# You don't need external libraries for this module
# The scripts use only Python's standard library
python3 -c "import json, hashlib; print('Standard library OK')"

If you want to go further and build an interactive calculator, you can install rich for formatted tables in the terminal — but it's totally optional:

# Optional: for pretty tables in the terminal
pip install rich

Recommended file structure

deployment-cloud-guide/
├── .env                         # API keys (later modules)
├── module-01/
│   └── decision-matrix.md       # Your decision matrix (project)
├── module-02/                   # Docker Compose (next module)
├── module-03/                   # Lambda (following)
└── ...

Limits: What This Module Does NOT Cover

  • ❌ Implementation of any strategy — This module is decision, not execution. Implementation comes in Modules 2-7.
  • ❌ Kubernetes — Not covered in the whole guide. It's an orchestration tool that goes beyond the scope.
  • ❌ Advanced DevOps — We don't go deep on Terraform, Ansible, or Infrastructure as Code tools.
  • ❌ Cloud provider comparison (AWS vs GCP vs Azure) — The focus is on deployment categories, not specific vendors.
  • ❌ Advanced networking — VPCs, subnets, load balancers are mentioned but we don't teach how to configure them.

Signs of Success

By the end of this module, you'll know you succeeded if:

  • ✅ You can explain the 4 deployment categories with an AI-specific example of each
  • ✅ Given a use case ("I have a RAG app with 10K users/month"), you identify the right strategy with justification
  • ✅ Your decision matrix has at least 5 criteria evaluated numerically for each strategy
  • ✅ You can estimate the monthly cost of an AI app on Lambda vs a VPS vs Railway
  • ✅ Your decision document is clear enough for another engineer to review it
  • ✅ You can argue when your recommendation would stop being valid (change of stage, traffic, budget)

Quick self-assessment

If you can answer these questions, you're on the right track:

  1. What are the 4 deployment categories and an example of each?
  2. What 5 dimensions do you use to evaluate trade-offs?
  3. Why can Lambda be expensive for high-volume AI workloads?
  4. What changes in your strategy when you go from MVP to scale?

Quick calibration exercise

Before moving to the next capsule, try this mental exercise. Given this scenario:

AI app: support chatbot for e-commerce

  • 500 users/day
  • Response streaming (token-by-token)
  • Budget: $30/month
  • Team: 1 developer
  • Stage: MVP

Which category would you choose? Write your answer before seeing the solution.

See answer

Managed (Railway/Render) or Local (Docker Compose on a VPS).

  • Serverless is ruled out: streaming isn't native on Lambda.
  • Self-hosted is overkill for 1 developer and $30/month.
  • Managed is the fastest option if Railway supports WebSockets (it does).
  • Local (VPS) works if you prefer more control for the same price (~$24/month).

If you answered something similar with justification, you're doing well. If you chose "AWS because that's what companies use," this module is exactly what you need.

Signs you need this module

If you identify with any of these scenarios, this module will change the way you make decisions:

  • "I always use Heroku/Vercel/AWS without evaluating alternatives"
  • "I don't know how much my infra should cost per month"
  • "I containerize everything but then I don't know where to deploy it"
  • "I pick the technology that shows up first in the YouTube tutorial"
  • "I can't explain to my team why I chose this platform"

If none apply and you already make deployment decisions with documented criteria — this module will give you a more rigorous, reusable framework to do it.

Summary

  • Deployment decisions should be made with criteria, not by inertia ("we use AWS because we always use AWS").
  • The 4 categories (Local, Serverless, Managed, Self-hosted) cover the full landscape of options.
  • Each category has trade-offs in cost, complexity, scalability, control, and time-to-deploy.
  • There's no universal "correct" deployment — there's a correct deployment for YOUR case, YOUR constraints, YOUR stage.
  • The decision matrix is the tool that systematizes this choice.
  • This module is strategic: decide before implementing.
  • The module's project is a Deployment Decision Workshop with a real decision matrix.

Additional Resources

  1. AWS Well-Architected Framework — Operational Excellence — AWS framework for architecture decisions
  2. The Twelve-Factor App — Principles for cloud-native apps that inform deployment decisions
  3. CNCF Cloud Native Landscape — Visual map of the cloud native ecosystem
  4. Serverless vs Containers — AWS — Official AWS decision guide
  5. Render vs Railway vs Fly.io — Comparison — Comparison of managed platforms
  6. Lambda Power Tuning — Tool to optimize Lambda costs
  7. Cloud Cost Handbook — Reference of cloud costs by service
Next →2. Landscape of Deployment Options