Stack moderno para PyMEs chilenas 2026 (Docker + Traefik)

Una PyME chilena que desarrolla software no tiene que elegir entre “shared hosting con cPanel” o “AWS con un sysadmin dedicado”. Hay un sweet spot moderno, controlable, barato y robusto que aGo usa para todos sus productos y casos. Este post lo describe.

Los principios

1. Local-first: lo que corre en producción debe correr igual en tu laptop.
2. Reproducible: cualquiera con git clone y docker compose up levanta el proyecto.
3. Versionado: infraestructura como código.
4. Automatizado: el deploy a producción es un git push.
5. Costo operacional bajo: la infraestructura compute pesa poco en el total del proyecto. Lo caro es el diseño, la implementación y la mantención.

El stack

Local (tu máquina)

• Docker Compose: define los servicios (app, BD, cache, etc.) en un docker-compose.yml.
• Traefik local con subdominios .localhost: cada proyecto en su URL (proyecto.localhost) sin tocar /etc/hosts.
• .env por proyecto: secrets y configuración fuera del repo.

Repositorio (GitHub)

• Repo privado por proyecto.
• .github/workflows/deploy.yml: pipeline de deploy.
• Secrets gestionados con gh secret set.

Producción (VPS Hetzner o Hostinger)

• VPS con Ubuntu 22.04 o 24.04.
• Docker + Traefik que enruta por subdominio.
• Let’s Encrypt para SSL automático.
• Cada proyecto en su docker-compose.yml con red Docker compartida con Traefik.
• Backups automatizados a S3-compatible (Cloudflare R2, Hetzner Object Storage).

El flujo de trabajo

Día 1, Setup local

mkdir mi-proyecto && cd mi-proyecto
git init
# crea docker-compose.yml, Dockerfile, .env.example, .gitignore
docker compose up
# abre http://mi-proyecto.localhost

Día 2, Push y deploy

git add . && git commit -m "feat: inicial"
gh repo create mi-proyecto --private --source=. --push
# configura GH Actions con secret del VPS
gh secret set VPS_SSH_KEY < ~/.ssh/id_rsa
git push origin main  # Actions hace el deploy

Día 3, Iteración

# trabajas local
git push origin main  # cada push despliega

Por qué Traefik y no nginx

• Configuración por labels en docker-compose.yml, no por archivos sueltos.
• Routing dinámico: levantas un servicio nuevo y aparece online sin reiniciar Traefik.
• Let’s Encrypt automático.
• Middleware útil (rate limiting, basic auth, redirect HTTPS) declarativo.

Cuándo VPS estándar y cuándo hyperscaler

En aGo trabajamos con varios proveedores cloud según el proyecto: Hetzner y Hostinger para VPS estándar, y AWS, Azure o Google Cloud cuando el proyecto lo requiere. La elección no es ideológica, es técnica.

VPS estándar (Hetzner, Hostinger) suele bastar cuando:

• Simplicidad operacional importa más que servicios gestionados. Una IP pública, un firewall, llaves SSH. La superficie de configuración cabe en una cabeza.
• Facturación predecible: tarifa fija mensual conocida de antemano. Sin sorpresas por egress, lambda invocations o NAT gateways.
• Tráfico razonable: hasta cientos de miles de requests al día sin esfuerzo arquitectónico.

Hyperscaler (AWS, Azure, Google Cloud) tiene sentido cuando:

• Escalado horizontal serio (más de 1M de requests al día sostenido).
• Servicios gestionados específicos (RDS Multi-AZ, BigQuery, Cloud Run autoscale, Cognitive Services).
• Alta disponibilidad multi-región.
• Compliance enterprise que exige certificaciones del proveedor.
• Integración profunda con productos del mismo proveedor (S3 + Lambda + EventBridge, BigQuery + Vertex AI, etc.).

Para PyMEs típicas, el VPS estándar gana en simplicidad y costo. Cuando el proyecto cruza el umbral de complejidad, hyperscaler vale el costo y la curva de aprendizaje.

GitHub Actions despliega con un workflow simple que hace ssh al VPS, git pull, docker compose up -d.

Errores comunes

1. Editar código en el VPS

Tentación: “es un fix chico, lo arreglo en el server”. Resultado: el VPS y el repo divergen. La próxima vez que se despliegue, se pisa el fix. Regla aGo: NUNCA arreglar código en el VPS. Solo .env, infraestructura, backups. Código se arregla en local, push, GitHub Actions despliega.

2. Secrets en el repo

Aunque sea repo privado, los secrets viven en .env (local) o en GitHub Secrets / Doppler / Vault (producción). Nunca en archivos versionados.

3. Sin backups

Backup automático diario a R2 o S3 compatible. Sin esto, una restauración accidental + un bug = pérdida total.

4. Sobreingeniería desde el día 1

Kubernetes para un sitio que sirve 100 req/min es exceso. Empieza con Docker Compose simple, escala cuando duela.

Stack concreto recomendado para 90% de los casos

# docker-compose.yml
services:
  app:
    image: tu-imagen:latest
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.app.rule=Host(`tuproyecto.cl`)"
      - "traefik.http.routers.app.tls.certresolver=letsencrypt"
    networks:
      - traefik-net
      - internal

  db:
    image: postgres:16
    volumes:
      - db_data:/var/lib/postgresql/data
    networks:
      - internal

  redis:
    image: redis:7
    networks:
      - internal

volumes:
  db_data:

networks:
  traefik-net:
    external: true
  internal:

GitHub Actions despliega con un workflow simple que hace ssh al VPS, git pull, docker compose up -d.

Casos reales

aGo usa este stack para:

• hub.nubiq.ai (SaaS multi-tenant chatbot)
• sign.datanubi.com (firma electrónica)
• finanzas.datanubi.com (análisis IPSA con ML)
• quelicitar.cl (B2B licitaciones)
• linki.cl (acortador + eventos QR)

Todos corren bajo el mismo patrón con variaciones por stack interno (Django, Next.js, Go).

Conclusión

Docker Compose + Traefik + GitHub Actions + un VPS bien dimensionado cubre el 90% de las necesidades técnicas de una PyME chilena que desarrolla software. Sin lock-in, controlable, productivo desde el día 1, con un costo operacional predecible. El valor está en cómo se diseña, se documenta y se opera el sistema, no en la receta de proveedores.

Es el stack que aGo usa internamente y adapta para cada cliente según su carga, su equipo y su nivel de tolerancia al riesgo operacional.

¿Quieres que armemos tu setup o auditemos el actual? Conversemos.