Modern stack for Chilean SMBs 2026 (Docker + Traefik)

A Chilean SMB that develops software does not have to choose between “shared hosting with cPanel” or “AWS with a dedicated sysadmin”. There is a modern, controllable, cheap and robust sweet spot that aGo uses for all of its products and client work. This post describes it.

The principles

1. Local-first: what runs in production must run the same on your laptop.
2. Reproducible: anyone with git clone and docker compose up brings the project online.
3. Versioned: infrastructure as code.
4. Automated: deploy to production is a git push.
5. Low operational cost: compute infrastructure is a small line in the total project. The expensive part is design, implementation and maintenance.

The stack

Local (your machine)

• Docker Compose: defines services (app, DB, cache, etc.) in a docker-compose.yml.
• Local Traefik with .localhost subdomains: each project at its URL (project.localhost) without touching /etc/hosts.
• .env per project: secrets and configuration outside the repo.

Repository (GitHub)

• Private repo per project.
• .github/workflows/deploy.yml: deploy pipeline.
• Secrets managed with gh secret set.

Production (Hetzner or Hostinger VPS)

• VPS with Ubuntu 22.04 or 24.04.
• Docker + Traefik routing by subdomain.
• Let’s Encrypt for automatic SSL.
• Each project in its docker-compose.yml on a Docker network shared with Traefik.
• Automated backups to S3-compatible storage (Cloudflare R2, Hetzner Object Storage).

The workflow

Day 1, Local setup

mkdir my-project && cd my-project
git init
# create docker-compose.yml, Dockerfile, .env.example, .gitignore
docker compose up
# open http://my-project.localhost

Day 2, Push and deploy

git add . && git commit -m "feat: initial"
gh repo create my-project --private --source=. --push
# configure GH Actions with VPS secret
gh secret set VPS_SSH_KEY < ~/.ssh/id_rsa
git push origin main  # Actions runs the deploy

Day 3, Iteration

# you work locally
git push origin main  # every push deploys

Why Traefik and not nginx

• Configuration by labels in docker-compose.yml, not by loose files.
• Dynamic routing: bring up a new service and it appears online without restarting Traefik.
• Automatic Let’s Encrypt.
• Useful middleware (rate limiting, basic auth, HTTPS redirect) declarative.

When standard VPS and when hyperscaler

At aGo we work with several cloud providers depending on the project: Hetzner and Hostinger for standard VPS, and AWS, Azure or Google Cloud when the project requires it. The choice is not ideological, it is technical.

Standard VPS (Hetzner, Hostinger) usually suffices when:

• Operational simplicity matters more than managed services. One public IP, one firewall, SSH keys. The whole configuration surface fits in one head.
• Predictable billing: fixed monthly fee known in advance. No surprises from egress, lambda invocations or NAT gateways.
• Reasonable traffic: up to hundreds of thousands of requests per day without architectural effort.

Hyperscaler (AWS, Azure, Google Cloud) makes sense when:

• Serious horizontal scaling (more than 1M sustained requests per day).
• Specific managed services (RDS Multi-AZ, BigQuery, Cloud Run autoscale, Cognitive Services).
• Multi-region high availability.
• Enterprise compliance requiring provider certifications.
• Deep integration with same-provider products (S3 + Lambda + EventBridge, BigQuery + Vertex AI, etc.).

For typical SMBs, standard VPS wins on simplicity and cost. When the project crosses the complexity threshold, hyperscaler is worth the cost and learning curve.

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

Common mistakes

1. Editing code on the VPS

Temptation: “it’s a small fix, I’ll fix it on the server”. Result: VPS and repo diverge. Next deploy overwrites the fix. aGo rule: NEVER fix code on the VPS. Only .env, infrastructure, backups. Code is fixed locally, pushed, GitHub Actions deploys.

2. Secrets in the repo

Even if the repo is private, secrets live in .env (local) or in GitHub Secrets / Doppler / Vault (production). Never in versioned files.

3. No backups

Daily automated backup to R2 or S3-compatible. Without it, an accidental restore plus a bug equals total loss.

4. Over-engineering from day 1

Kubernetes for a site serving 100 req/min is overkill. Start with simple Docker Compose, scale when it hurts.

Concrete stack recommended for 90% of cases

# docker-compose.yml
services:
  app:
    image: your-image:latest
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.app.rule=Host(`yourproject.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 deploys with a simple workflow that sshs into the VPS, git pull, docker compose up -d.

Real cases

aGo uses this stack for:

• hub.nubiq.ai (multi-tenant chatbot SaaS)
• sign.datanubi.com (electronic signature)
• finanzas.datanubi.com (IPSA analysis with ML)
• quelicitar.cl (B2B public procurement)
• linki.cl (URL shortener + event QR)

All run under the same pattern with variations on the internal stack (Django, Next.js, Go).

Conclusion

Docker Compose + Traefik + GitHub Actions + a properly sized VPS covers 90% of the technical needs of a Chilean SMB that develops software. No lock-in, controllable, productive from day 1, with predictable operational cost. The value is in how the system is designed, documented and operated, not in the specific list of providers.

It is the stack aGo uses internally and adapts for each client according to load, team and tolerance to operational risk.

Want us to assemble your setup or audit your current one? Let’s talk.