Module 7: Alternative Platforms (Render, Railway, Fly.io)

1. Introduction: Alternative Platforms (Render, Railway, Fly.io)

Description

This is the first capsule of Module 7 of the Deployment & Cloud Infrastructure Guide. Here you'll understand why AWS is not the only answer for deploying AI systems — and why in many cases it isn't the best. Render, Railway and Fly.io represent a generation of platforms that prioritize developer experience over granular control: deployment from Git in minutes, transparent pricing, generous free tiers, and zero need to learn IAM, VPCs or API Gateway.

Why it matters: If you only know how to deploy on AWS, you have a blind spot. An MVP that needs to be online in 30 minutes shouldn't require configuring IAM roles, API Gateway and CloudWatch. A personal project doesn't justify a $50/month bill for AWS services you barely use. These alternative platforms exist because there's real demand to simplify deployment without sacrificing quality — and an AI Engineer with good judgment knows when each option is the right one.

This module completes the decision matrix you started in Module 1. There you evaluated categories (Local, Serverless, Managed, Self-hosted). Here you evaluate concrete platforms: AWS (which you already know from M3-M6) vs Render vs Railway vs Fly.io. You don't "pick one" — you understand when each is the right option.

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
├── 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)    ← YOU ARE HERE
└── Module 8: Integrative Project — Deployed AI System

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

Where are we headed?

This module gives you hands-on experience with platforms that prioritize developer experience. With that experience, Module 8 asks you to integrate everything: Docker (M2) + Lambda (M3) + LocalStack (M4) + AWS (M5) + Migration (M6) + the platform chosen here (M7) into an AI system deployed in production.

The progression up to this point is:

You decided (M1) — decision framework with categories
You implemented local (M2) — multi-container Docker Compose
You implemented serverless (M3) — Lambda for AI with cold starts
You developed cost-free (M4) — LocalStack for local AWS
You integrated AWS (M5) — S3, Lambda, SageMaker basics
You migrated (M6) — LocalStack → AWS patterns
You evaluate alternatives (this module) — Render, Railway, Fly.io
You integrate everything (M8) — AI system deployed in production

The Managed Platform Landscape

Why these platforms exist

AWS, GCP and Azure were designed for enterprises. You can do anything with them — literally anything. But "being able to do anything" has a cost: complexity. To deploy a FastAPI app on AWS, you need Lambda or ECS + API Gateway + IAM roles + CloudWatch + VPC + Security Groups. Or you can connect your Git repository to Render and have the app running in 3 minutes.

Managed platforms (Render, Railway, Fly.io) were born from a simple observation: for 80% of use cases, AWS's complexity is unnecessary. Their pitch is:

AWS/GCP/Azure:  Full control → High complexity → Long setup time
                Perfect for: Enterprise, compliance, massive scale

Render/Railway/Fly.io:  Sufficient control → Low complexity → Deploy in minutes
                        Perfect for: MVPs, startups, personal projects, prototypes

The three platforms in this module

Platform	Philosophy	Differentiator	Best for
Render	"Modern Heroku"	Simplicity, predictable pricing	Web services, static sites, databases
Railway	"Deploy anything, fast"	Developer experience, integrated add-ons	Fast prototypes, full-stack apps
Fly.io	"Run at the edge"	Multi-region, edge computing	Apps that need low global latency

The three share a philosophy (deploy from Git, transparent pricing), but differ in approach. Render bets on simplicity. Railway on iteration speed. Fly.io on geographic distribution. This module covers all three side by side and guides you through a hands-on deployment on the one you choose.

What about Heroku?

Heroku was the original platform of this category. Render, Railway and Fly.io are its evolution. Heroku still exists, but its free tier disappeared in 2022, its pricing is less competitive, and its innovation stalled. The three platforms in this module are the ones an AI Engineer in 2026 should know.

Module Goal

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

✅ Deploy a containerized AI app on at least one alternative platform (Render, Railway or Fly.io)
✅ Compare the three platforms across key dimensions: deployment flow, pricing, free tier, databases, auto-scaling, request timeouts
✅ Identify platform-specific limitations for AI workloads: memory limits, cold starts, WebSocket support
✅ Integrate deployment on an alternative platform with existing CI/CD (GitHub Actions)
✅ Configure environment variables, secrets and custom domains on the chosen platform
✅ Evaluate when an alternative platform is better than AWS — and when it isn't
✅ Extend the Module 1 decision matrix with platform criteria for a complete decision framework
✅ Document trade-offs with real data: simplicity vs control, predictable pricing vs pay-per-use, vendor lock-in

Professional goal

When someone tells you "we deploy everything on AWS because it's what we know," you'll be able to answer: "For this MVP, Railway gives us deploy in 3 minutes and costs $5/month. AWS gives us more control, but we need 2 days of configuration and $30/month minimum. Which one makes more sense for our stage?" And you'll have data to back up that conversation.

Module Roadmap

Capsule map

#	Capsule	What you'll learn	Type
01	Introduction (this one)	Phase 3, alternatives to AWS, objectives, roadmap	Intro
02	Render Deployment	Render: deploy from Git, Dockerfile, databases, AI limitations	Technical
03	Railway Deployment	Railway: DX, deploy flow, add-ons, pricing, AI limitations	Technical
04	Fly.io Deployment	Fly.io: edge, multi-region, flyctl, volumes, AI limitations	Technical
05	Platform Comparison	Side-by-side: pricing, features, limits, tables with real data	Technical
06	CI/CD Integration	GitHub Actions + Render/Railway/Fly.io, environment promotion	Technical
07	Platform Decision Matrix	Extend the M1 matrix with platform criteria, complete framework	Technical
08	Project: Deploy to Platform of Choice	Deploy, document, compare, extend the decision matrix	Project

Learning flow

First you'll get to know Render in depth with a real deployment (capsule 02). Then Railway with the same exercise to compare experiences (capsule 03). Next Fly.io with its edge approach (capsule 04). With all three platforms tested, you'll do a side-by-side comparison with real data (capsule 05). You'll integrate CI/CD with GitHub Actions for all three (capsule 06). You'll build the decision matrix v2 with platform criteria (capsule 07). And finally you'll integrate everything into a real deployment project (capsule 08).

The progression is: Render → Railway → Fly.io → Comparison → CI/CD → Matrix → Project.

Estimated module duration: 1.25-1.5 hours.

Connection with the Project

This module's project: Deploy to Platform of Choice

The module's final project has three parts:

Real deploy: You take your AI app (DocuSearch or your own) and deploy it on the platform you choose (Render, Railway or Fly.io)
Comparative documentation: You document the experience and compare it with local deployment (M2) and serverless (M3)
Decision matrix v2: You extend the M1 matrix with real data from this experience

Input: Containerized AI app + M1-M6 experience
  - Working Docker Compose (from M2)
  - Optimized Dockerfile
  - CI/CD with GitHub Actions (from prerequisite #16)
  - Decision matrix v1 (from M1)

Output: Deployed app + decision matrix v2
  - Public URL of your AI app
  - Process documentation
  - Comparison: local vs serverless vs platform
  - Decision matrix with platform criteria

Connection with the final project: Deployed AI System

The platform you choose in M7 can be the production platform in M8. If your decision matrix indicates that Railway is a better option than AWS for your case, M8 uses Railway. The deployment experience here enriches the M8 documentation.

Module 1: Decision Matrix v1 → framework to decide (categories)
    ↓
Module 7: Decision Matrix v2 → extended with concrete platforms
    ↓
Module 8: Decision Matrix applied → justifies the final deployment

Prerequisites

Required knowledge

Docker: Dockerfile, docker build, docker run, Docker Compose (guide #15, M2 of this guide)
CI/CD with GitHub Actions: Basic workflows, triggers, secrets (guide #16)
Basic AWS: You understand S3, Lambda, IAM (M3-M6 of this guide)
FastAPI: Working apps with REST endpoints
Git: Push, pull, branches, repositories on GitHub

If you don't have these prerequisites

What you're missing	Recommended resource
Docker	Docker Essentials Guide (#15) — NIEVA
CI/CD	CI/CD for AI Systems Guide (#16) — NIEVA
AWS	Modules 3-6 of this guide
FastAPI	Python REST APIs for AI Guide — NIEVA
Git	Any Git + GitHub tutorial

Reference AI app

Throughout this module you'll deploy an AI app. You can use your own app or use DocuSearch AI (the M1 case study). What matters is that you have:

A working Dockerfile
At least one endpoint that invokes an LLM (OpenAI, Anthropic, etc.)
Environment variables for API keys
A repository on GitHub

Technical Setup

Required accounts

For this module you need (free) accounts on all three platforms. Create them before continuing:

# 1. Render — https://render.com
#    Sign up with GitHub (recommended for automatic deploy)

# 2. Railway — https://railway.app
#    Sign up with GitHub

# 3. Fly.io — https://fly.io
#    Sign up (requires a credit card for verification, no charge)

Required CLIs

# Railway CLI
npm install -g @railway/cli
# Or with brew:
brew install railway

# Verify
railway --version

# Fly.io CLI
brew install flyctl
# Or with curl:
curl -L https://fly.io/install.sh | sh

# Verify
flyctl version

# Render has no official CLI — everything is via dashboard + Git
# But you can use its API:
# https://api.render.com/v1/

# Docker (you already have it from previous modules)
docker --version
docker compose version

# GitHub CLI (useful for CI/CD)
gh --version

Logging in to the platforms

# Railway
railway login

# Fly.io
flyctl auth login

# Verify connections
railway whoami
flyctl auth whoami

File structure for the module

deployment-cloud-guide/
├── module-07/
│   ├── app/                        # Your AI app (or DocuSearch)
│   │   ├── main.py
│   │   ├── requirements.txt
│   │   ├── Dockerfile
│   │   └── .env.example
│   ├── render/                     # Render-specific config
│   │   └── render.yaml
│   ├── railway/                    # Railway-specific config
│   │   └── railway.toml
│   ├── flyio/                      # Fly.io-specific config
│   │   └── fly.toml
│   ├── .github/
│   │   └── workflows/
│   │       ├── deploy-render.yml
│   │       ├── deploy-railway.yml
│   │       └── deploy-flyio.yml
│   ├── decision-matrix-v2.md       # Your extended matrix
│   └── deployment-comparison.md    # Experience comparison
└── ...

mkdir -p deployment-cloud-guide/module-07/{app,render,railway,flyio,.github/workflows}
cd deployment-cloud-guide/module-07

Minimal AI app for deployment

If you don't have your own app, use this as a base:

# app/main.py
import os
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel

app = FastAPI(title="DocuSearch AI", version="1.0.0")


class Query(BaseModel):
    question: str
    max_tokens: int = 500


class Answer(BaseModel):
    answer: str
    model: str
    tokens_used: int


@app.get("/health")
def health_check():
    return {
        "status": "healthy",
        "version": "1.0.0",
        "platform": os.environ.get("PLATFORM", "local"),
    }


@app.post("/ask", response_model=Answer)
async def ask_question(query: Query):
    api_key = os.environ.get("OPENAI_API_KEY")
    if not api_key:
        raise HTTPException(status_code=500, detail="OPENAI_API_KEY not configured")

    import openai

    client = openai.OpenAI(api_key=api_key)

    response = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[
            {"role": "system", "content": "You are a technical documentation assistant."},
            {"role": "user", "content": query.question},
        ],
        max_tokens=query.max_tokens,
    )

    return Answer(
        answer=response.choices[0].message.content,
        model="gpt-4o-mini",
        tokens_used=response.usage.total_tokens,
    )

# app/Dockerfile
FROM python:3.11-slim

WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

EXPOSE 8000

CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

# app/requirements.txt
fastapi==0.115.0
uvicorn[standard]==0.30.0
openai==1.50.0
pydantic==2.9.0

Limits: What This Module Does NOT Cover

❌ Exhaustive tutorial of each platform — Covers what's needed to deploy an AI app and evaluate the platform, not all of the documentation
❌ Kubernetes or container orchestration — These platforms abstract orchestration away
❌ GPU deployment — None of the three offer GPUs in their standard tiers; for GPU you need specialized services
❌ Additional platforms (Vercel, Netlify, DigitalOcean App Platform) — They're mentioned in the comparison but you don't deploy on them
❌ Self-hosted alternatives (Coolify, CapRover) — They're not managed platforms in the sense of this module

Evidence of Success

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

✅ Your AI app is deployed and publicly accessible on at least one platform (Render, Railway or Fly.io)
✅ You can explain the key differences between the three platforms with concrete data
✅ You know how to configure environment variables and secrets on each platform
✅ You have a CI/CD pipeline that deploys automatically on push
✅ Your decision matrix has a new dimension with platform criteria
✅ You can argue when to choose Render vs Railway vs Fly.io vs AWS for a given case

Quick self-assessment test

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

What is each platform's free tier and when does it fall short for AI?
Which platform would you choose for an MVP with streaming and why?
Which one has the best support for multi-region deployment?
How do you configure automatic deployment from GitHub Actions on each one?

Summary

AWS is not the only option — and for many cases (MVPs, personal projects, early-stage startups), it isn't the best.
Render, Railway and Fly.io represent simplified deployment: Git push → app online in minutes.
Each platform has a different approach: Render (simplicity), Railway (DX), Fly.io (edge/multi-region).
This module is comparative: it doesn't evangelize any platform, it gives you data to decide.
The M1 decision matrix is extended with platform criteria to produce a complete framework.
The platform chosen here can be your production platform in M8.
The goal is judgment, not loyalty to a vendor.

Additional Resources

Render Documentation — Render's official documentation
Railway Documentation — Railway's official documentation
Fly.io Documentation — Fly.io's official documentation
Render vs Railway vs Fly.io — Dev.to — Community comparisons
The State of PaaS 2026 — ThoughtWorks Technology Radar
Platform Engineering — CNCF — CNCF white paper on platforms
Heroku Alternatives — GitHub — Curated list of Heroku alternatives

← Previous8. Project: Migration-Ready AI App Next →2. Render: Deployment for AI Apps