Módulo 7: Alternative Platforms (Render, Railway, Fly.io)

1. Introducción: Alternative Platforms (Render, Railway, Fly.io)

Descripción

Esta es la primera cápsula del Módulo 7 de la Guía de Deployment & Cloud Infrastructure. Aquí vas a entender por qué AWS no es la única respuesta para desplegar sistemas AI — y por qué en muchos casos no es la mejor. Render, Railway y Fly.io representan una generación de plataformas que priorizan developer experience sobre control granular: deployment desde Git en minutos, pricing transparente, free tiers generosos, y cero necesidad de aprender IAM, VPCs o API Gateway.

Por qué importa: Si solo sabes desplegar en AWS, tienes un punto ciego. Un MVP que necesita estar online en 30 minutos no debería requerir configurar IAM roles, API Gateway y CloudWatch. Un proyecto personal no justifica una factura de $50/mes en servicios AWS que apenas usas. Estas plataformas alternativas existen porque hay una demanda real de simplificar deployment sin sacrificar calidad — y un AI Engineer con criterio sabe cuándo cada opción es la correcta.

Este módulo completa la decision matrix que empezaste en el Módulo 1. Allí evaluaste categorías (Local, Serverless, Managed, Self-hosted). Aquí evalúas plataformas concretas: AWS (que ya conoces de M3-M6) vs Render vs Railway vs Fly.io. No "eliges una" — entiendes cuándo cada una es la opción correcta.

¿Dónde Estamos en la Guía?

Contexto

Esta guía tiene 8 módulos organizados en 3 fases:

Phase 1: Deployment Strategies (Módulos 1-3)
├── Módulo 1: Understanding Deployment Options
├── Módulo 2: Local & Container Deployment
└── Módulo 3: Serverless & Lambda for AI

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

Phase 3: Alternatives & Production (Módulos 7-8)
├── Módulo 7: Alternative Platforms (Render, Railway, Fly.io)    ← ESTÁS AQUÍ
└── Módulo 8: Proyecto Integrador — Deployed AI System

Duración total estimada: 10-12 horas (self-paced).

¿Hacia dónde vamos?

Este módulo te da experiencia práctica con plataformas que priorizan developer experience. Con esa experiencia, el Módulo 8 te pide integrar todo: Docker (M2) + Lambda (M3) + LocalStack (M4) + AWS (M5) + Migration (M6) + la plataforma elegida aquí (M7) en un sistema AI desplegado en producción.

La progresión a este punto es:

Decidiste (M1) — framework de decisión con categorías
Implementaste local (M2) — Docker Compose multi-container
Implementaste serverless (M3) — Lambda para AI con cold starts
Desarrollaste sin coste (M4) — LocalStack para AWS local
Integraste AWS (M5) — S3, Lambda, SageMaker basics
Migraste (M6) — Patrones LocalStack → AWS
Evalúas alternativas (este módulo) — Render, Railway, Fly.io
Integras todo (M8) — Sistema AI desplegado en producción

El Landscape de Plataformas Managed

Por qué existen estas plataformas

AWS, GCP y Azure fueron diseñados para enterprises. Puedes hacer cualquier cosa con ellos — literalmente cualquier cosa. Pero "poder hacer cualquier cosa" tiene un coste: complejidad. Para deployar una FastAPI en AWS, necesitas Lambda o ECS + API Gateway + IAM roles + CloudWatch + VPC + Security Groups. O puedes conectar tu repositorio de Git a Render y tener la app corriendo en 3 minutos.

Las plataformas managed (Render, Railway, Fly.io) nacieron de una observación simple: para el 80% de los casos de uso, la complejidad de AWS es innecesaria. Su propuesta es:

AWS/GCP/Azure:  Control total → Complejidad alta → Tiempo de setup largo
                Perfecto para: Enterprise, compliance, escala masiva

Render/Railway/Fly.io:  Control suficiente → Complejidad baja → Deploy en minutos
                        Perfecto para: MVPs, startups, proyectos personales, prototipos

Las tres plataformas de este módulo

Plataforma	Filosofía	Diferenciador	Mejor para
Render	"Heroku moderno"	Simplicidad, pricing predecible	Web services, static sites, databases
Railway	"Deploy anything, fast"	Developer experience, add-ons integrados	Prototipos rápidos, apps full-stack
Fly.io	"Run at the edge"	Multi-region, edge computing	Apps que necesitan baja latencia global

Las tres comparten filosofía (deploy desde Git, pricing transparente), pero difieren en enfoque. Render apuesta por simplicidad. Railway por velocidad de iteración. Fly.io por distribución geográfica. Este módulo cubre las tres en comparativa y te guía en un deployment hands-on en la que elijas.

¿Qué pasa con Heroku?

Heroku fue la plataforma original de esta categoría. Render, Railway y Fly.io son su evolución. Heroku sigue existiendo, pero su free tier desapareció en 2022, su pricing es menos competitivo, y su innovación se estancó. Las tres plataformas de este módulo son las que un AI Engineer en 2026 debería conocer.

Objetivo del Módulo

Al terminar este módulo serás capaz de:

✅ Desplegar una app AI containerizada en al menos una plataforma alternativa (Render, Railway o Fly.io)
✅ Comparar las tres plataformas en dimensiones clave: deployment flow, pricing, free tier, databases, auto-scaling, request timeouts
✅ Identificar limitaciones específicas de cada plataforma para AI workloads: memory limits, cold starts, WebSocket support
✅ Integrar deployment en plataforma alternativa con CI/CD existente (GitHub Actions)
✅ Configurar environment variables, secrets y custom domains en la plataforma elegida
✅ Evaluar cuándo una plataforma alternativa es mejor que AWS — y cuándo no lo es
✅ Extender la decision matrix del Módulo 1 con criterios de plataforma para un framework de decisión completo
✅ Documentar trade-offs con datos reales: simplicidad vs control, pricing predecible vs pay-per-use, vendor lock-in

Objetivo profesional

Cuando alguien te diga "deployamos todo en AWS porque es lo que conocemos," vas a poder responder: "Para este MVP, Railway nos da deploy en 3 minutos y cuesta $5/mes. AWS nos da más control, pero necesitamos 2 días de configuración y $30/mes mínimo. ¿Cuál tiene más sentido para nuestro stage?" Y vas a tener datos para respaldar esa conversación.

Roadmap del Módulo

Mapa de cápsulas

#	Cápsula	Qué aprenderás	Tipo
01	Introducción (esta)	Phase 3, alternativas a AWS, objectives, roadmap	Intro
02	Render Deployment	Render: deploy desde Git, Dockerfile, databases, limitaciones AI	Técnica
03	Railway Deployment	Railway: DX, deploy flow, add-ons, pricing, limitaciones AI	Técnica
04	Fly.io Deployment	Fly.io: edge, multi-region, flyctl, volumes, limitaciones AI	Técnica
05	Comparativa de Plataformas	Side-by-side: pricing, features, límites, tablas con datos reales	Técnica
06	CI/CD Integration	GitHub Actions + Render/Railway/Fly.io, environment promotion	Técnica
07	Decision Matrix de Plataformas	Extender M1 matrix con criterios de plataforma, framework completo	Técnica
08	Proyecto: Deploy to Platform of Choice	Desplegar, documentar, comparar, extender decision matrix	Proyecto

Flujo de aprendizaje

Primero conocerás Render en profundidad con un deployment real (cápsula 02). Luego Railway con el mismo ejercicio para comparar experiencias (cápsula 03). Después Fly.io con su enfoque edge (cápsula 04). Con las tres plataformas probadas, harás una comparativa side-by-side con datos reales (cápsula 05). Integrarás CI/CD con GitHub Actions para las tres (cápsula 06). Construirás la decision matrix v2 con criterios de plataforma (cápsula 07). Y finalmente integrarás todo en un proyecto de deployment real (cápsula 08).

La progresión es: Render → Railway → Fly.io → Comparativa → CI/CD → Matrix → Proyecto.

Duración estimada del módulo: 1.25-1.5 horas.

Conexión con el Proyecto

Proyecto de este módulo: Deploy to Platform of Choice

El proyecto final del módulo tiene tres partes:

Deploy real: Tomas tu app AI (DocuSearch o la tuya propia) y la despliegas en la plataforma que elijas (Render, Railway o Fly.io)
Documentación comparativa: Documentas la experiencia y la comparas con deployment local (M2) y serverless (M3)
Decision matrix v2: Extiendes la matrix del M1 con los datos reales de esta experiencia

Input: App AI containerizada + experiencia M1-M6
  - Docker Compose funcional (de M2)
  - Dockerfile optimizado
  - CI/CD con GitHub Actions (de prerequisite #16)
  - Decision matrix v1 (de M1)

Output: App desplegada + decision matrix v2
  - URL pública de tu app AI
  - Documentación del proceso
  - Comparativa: local vs serverless vs plataforma
  - Decision matrix con criterios de plataforma

Conexión con el proyecto final: Deployed AI System

La plataforma que elijas en M7 puede ser la plataforma de producción en M8. Si tu decision matrix indica que Railway es mejor opción que AWS para tu caso, el M8 usa Railway. La experiencia de deployment aquí enriquece la documentación del M8.

Módulo 1: Decision Matrix v1 → framework para decidir (categorías)
    ↓
Módulo 7: Decision Matrix v2 → extendida con plataformas concretas
    ↓
Módulo 8: Decision Matrix aplicada → justifica el deployment final

Prerequisitos

Conocimientos necesarios

Docker: Dockerfile, docker build, docker run, Docker Compose (guía #15, M2 de esta guía)
CI/CD con GitHub Actions: Workflows básicos, triggers, secrets (guía #16)
AWS básico: Entiendes S3, Lambda, IAM (M3-M6 de esta guía)
FastAPI: Apps funcionales con endpoints REST
Git: Push, pull, branches, repositories en GitHub

Si no tienes estos prerequisitos

Te falta	Recurso recomendado
Docker	Docker Essentials Guide (#15) — NIEVA
CI/CD	CI/CD for AI Systems Guide (#16) — NIEVA
AWS	Módulos 3-6 de esta guía
FastAPI	Python REST APIs for AI Guide — NIEVA
Git	Cualquier tutorial de Git + GitHub

App AI de referencia

A lo largo de este módulo desplegarás una app AI. Puedes usar tu propia app o usar DocuSearch AI (el caso de estudio de M1). Lo importante es que tengas:

Un Dockerfile funcional
Al menos un endpoint que invoque un LLM (OpenAI, Anthropic, etc.)
Variables de entorno para API keys
Un repositorio en GitHub

Setup Técnico

Cuentas necesarias

Para este módulo necesitas cuentas (gratuitas) en las tres plataformas. Créalas antes de continuar:

# 1. Render — https://render.com
#    Sign up con GitHub (recomendado para deploy automático)

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

# 3. Fly.io — https://fly.io
#    Sign up (requiere tarjeta de crédito para verificación, no cobra)

CLIs necesarios

# Railway CLI
npm install -g @railway/cli
# O con brew:
brew install railway

# Verificar
railway --version

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

# Verificar
flyctl version

# Render no tiene CLI oficial — todo es via dashboard + Git
# Pero puedes usar su API:
# https://api.render.com/v1/

# Docker (ya lo tienes de módulos anteriores)
docker --version
docker compose version

# GitHub CLI (útil para CI/CD)
gh --version

Login en las plataformas

# Railway
railway login

# Fly.io
flyctl auth login

# Verificar conexiones
railway whoami
flyctl auth whoami

Estructura de archivos para el módulo

deployment-cloud-guide/
├── module-07/
│   ├── app/                        # Tu app AI (o DocuSearch)
│   │   ├── main.py
│   │   ├── requirements.txt
│   │   ├── Dockerfile
│   │   └── .env.example
│   ├── render/                     # Config específica de Render
│   │   └── render.yaml
│   ├── railway/                    # Config específica de Railway
│   │   └── railway.toml
│   ├── flyio/                      # Config específica de Fly.io
│   │   └── fly.toml
│   ├── .github/
│   │   └── workflows/
│   │       ├── deploy-render.yml
│   │       ├── deploy-railway.yml
│   │       └── deploy-flyio.yml
│   ├── decision-matrix-v2.md       # Tu matrix extendida
│   └── deployment-comparison.md    # Comparativa de experiencias
└── ...

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

App AI mínima para deployment

Si no tienes app propia, usa esta como 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": "Eres un asistente de documentación técnica."},
            {"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

Límites: Qué NO Cubre Este Módulo

❌ Tutorial exhaustivo de cada plataforma — Cubre lo necesario para desplegar una app AI y evaluar la plataforma, no toda la documentación
❌ Kubernetes o container orchestration — Estas plataformas abstraen la orquestación
❌ GPU deployment — Ninguna de las tres ofrece GPUs en sus tiers estándar; para GPU necesitas servicios especializados
❌ Plataformas adicionales (Vercel, Netlify, DigitalOcean App Platform) — Se mencionan en la comparativa pero no se despliega en ellas
❌ Self-hosted alternatives (Coolify, CapRover) — No son plataformas managed en el sentido de este módulo

Evidencia de Éxito

Al terminar este módulo, sabrás que tuviste éxito si:

✅ Tu app AI está desplegada y accesible públicamente en al menos una plataforma (Render, Railway o Fly.io)
✅ Puedes explicar las diferencias clave entre las tres plataformas con datos concretos
✅ Sabes configurar variables de entorno y secrets en cada plataforma
✅ Tienes un pipeline CI/CD que despliega automáticamente al hacer push
✅ Tu decision matrix tiene una nueva dimensión con criterios de plataforma
✅ Puedes argumentar cuándo elegir Render vs Railway vs Fly.io vs AWS para un caso dado

Test rápido de autoevaluación

Si puedes responder estas preguntas, vas por buen camino:

¿Cuál es el free tier de cada plataforma y cuándo se queda corto para AI?
¿Qué plataforma elegirías para un MVP con streaming y por qué?
¿Cuál tiene mejor soporte para deployment multi-region?
¿Cómo configuras deployment automático desde GitHub Actions en cada una?

Resumen

AWS no es la única opción — y para muchos casos (MVPs, proyectos personales, startups tempranas), no es la mejor.
Render, Railway y Fly.io representan deployment simplificado: Git push → app online en minutos.
Cada plataforma tiene un enfoque diferente: Render (simplicidad), Railway (DX), Fly.io (edge/multi-region).
Este módulo es comparativo: no evangeliza ninguna plataforma, te da datos para decidir.
La decision matrix del M1 se extiende con criterios de plataforma para producir un framework completo.
La plataforma elegida aquí puede ser tu plataforma de producción en el M8.
El objetivo es criterio, no lealtad a un vendor.

Recursos Adicionales

Render Documentation — Documentación oficial de Render
Railway Documentation — Documentación oficial de Railway
Fly.io Documentation — Documentación oficial de Fly.io
Render vs Railway vs Fly.io — Dev.to — Comparativas de la comunidad
The State of PaaS 2026 — ThoughtWorks Technology Radar
Platform Engineering — CNCF — White paper de CNCF sobre plataformas
Heroku Alternatives — GitHub — Lista curada de alternativas a Heroku

← Anterior8. Proyecto: Migration-Ready AI App Siguiente →2. Render: Deployment para AI Apps