🖥️ Servidor e Docker

Para um stack Postiz + Postgres + Redis + Nginx, o piso confortável é 2 vCPU / 4 GB RAM / 40 GB SSD. Abaixo disso, o build do Next e as filas do BullMQ derrubam o servidor sob carga moderada. A escolha campeã em custo-benefício é a Hetzner Cloud CX22 (Frankfurt/Helsinki) por ~€4/mês — rede de 1 Gbps, snapshots baratos, painel limpo.

Alternativas válidas: Contabo VPS S (mais RAM por euro, mas IO de disco oscila), OVH VPS Starter (DC em Beauharnois/Gravelines, bom para Brasil/Europa) e DigitalOcean Basic (mais caro, mas ecossistema maduro). Evite "VPS de R$ 9/mês" — overcommit cruel.

# Comparativo rápido (Mai/2026, valores aproximados)
# Provider     | CPU  | RAM  | Disco  | Tráfego | Preço/mês
# -------------|------|------|--------|---------|----------
# Hetzner CX22 | 2vC  | 4GB  | 40GB   | 20TB    | €4,15
# Contabo VPS S| 4vC  | 8GB  | 100GB  | 32TB    | €5,99
# OVH Starter  | 2vC  | 4GB  | 80GB   | ilim.   | €6,00
# DO Basic     | 2vC  | 4GB  | 80GB   | 4TB     | $24,00

# Antes de comprar, teste latência do seu lugar:
ping -c 5 nbg1-speed.hetzner.com   # Nuremberg
ping -c 5 ash-speed.contabo.com    # Ashburn
mtr --report --report-cycles 10 fra1-speed.hetzner.com

Conceitos-chave

Servidor recém-criado é uma porta aberta. Antes de instalar qualquer coisa, faça os cinco hardenings básicos: usuário não-root, chave SSH (senha desligada), firewall ufw, fail2ban contra brute force, e unattended-upgrades para patches automáticos de segurança.

# 1. Criar usuário deploy não-root
adduser deploy
usermod -aG sudo deploy

# 2. Copiar chave SSH do root para deploy
rsync --archive --chown=deploy:deploy ~/.ssh /home/deploy

# 3. No SEU laptop, gerar chave e adicionar (se ainda não tem)
ssh-keygen -t ed25519 -C "deploy@mkblogs"
ssh-copy-id deploy@SEU.IP.DO.SERVIDOR

# 4. Desligar senha SSH e login root em /etc/ssh/sshd_config
sudo sed -i 's/^#\?PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
sudo sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo systemctl reload ssh

Com SSH endurecido, levante o firewall e os daemons de proteção. A ordem importa: libere SSH antes de habilitar UFW, senão você se tranca para fora.

# 5. Firewall: SSH + HTTP + HTTPS
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp     # SSH (ANTES de enable!)
sudo ufw allow 80/tcp     # HTTP (certbot ACME)
sudo ufw allow 443/tcp    # HTTPS
sudo ufw --force enable
sudo ufw status verbose

# 6. fail2ban contra brute force
sudo apt install -y fail2ban
sudo tee /etc/fail2ban/jail.local > /dev/null <<EOF
[sshd]
enabled = true
port    = 22
maxretry = 3
bantime  = 1h
findtime = 10m
EOF
sudo systemctl enable --now fail2ban

# 7. Patches automáticos de segurança
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

Conceitos-chave

O docker.io do apt do Ubuntu vem velho e sem o plugin Compose v2. Use o script oficial de get.docker.com, que adiciona o repositório certo da Docker Inc. e instala Engine + Compose v2 em uma tacada.

# 1. Baixar e rodar script oficial
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh

# 2. Adicionar usuário deploy ao grupo docker (sem sudo)
sudo usermod -aG docker deploy

# 3. Logout + login para o grupo aplicar (ou: newgrp docker)
exit
ssh deploy@SEU.IP.DO.SERVIDOR

# 4. Verificar instalação
docker --version
# Docker version 27.3.1, build ce12230

docker compose version
# Docker Compose version v2.29.7

# 5. Smoke test
docker run --rm hello-world
# Hello from Docker! ...

# 6. Habilitar auto-start no boot
sudo systemctl enable docker

Conceitos-chave

O Compose de produção difere do de dev em quatro pontos críticos: sem portas de DB expostas no host, restart: always, redes internas isoladas e limites de recursos. O Postiz fala com o Postgres apenas pela network interna; quem expõe ao mundo é o reverse proxy (próximo módulo).

# /home/deploy/postiz/docker-compose.prod.yml
services:
  postiz:
    image: ghcr.io/gitroomhq/postiz-app:latest
    container_name: postiz
    restart: always
    env_file: .env.prod
    expose:
      - "5000"            # interno, NÃO ports:
    volumes:
      - postiz-uploads:/uploads
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_healthy
    networks: [postiz-net]
    deploy:
      resources:
        limits: { cpus: '1.5', memory: 2G }

  postgres:
    image: postgres:16-alpine
    container_name: postiz-postgres
    restart: always
    environment:
      POSTGRES_USER: postiz
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: postiz
    volumes:
      - postgres-data:/var/lib/postgresql/data
    # Sem ports: — Postgres só acessível via postiz-net
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postiz -d postiz"]
      interval: 10s
      timeout: 5s
      retries: 5
    networks: [postiz-net]

  redis:
    image: redis:7-alpine
    container_name: postiz-redis
    restart: always
    command: ["redis-server", "--appendonly", "yes"]
    volumes:
      - redis-data:/data
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      retries: 5
    networks: [postiz-net]

volumes:
  postgres-data:
  postiz-uploads:
  redis-data:

networks:
  postiz-net:
    driver: bridge
    internal: false   # postiz precisa de internet p/ APIs

Conceitos-chave

Container é efêmero — se você der docker compose down, tudo que estava no FS do container some. Volumes ficam fora desse ciclo: vivem em /var/lib/docker/volumes/ e sobrevivem a destruir e recriar containers.

Há duas opções: named volumes (gerenciados pelo Docker, escolha padrão) e bind mounts (mapeiam um caminho do host). Para dados de DB sempre use named volume — bind mounts dão dor de cabeça com UID/permissão.

# Listar volumes do projeto
docker volume ls --filter "name=postiz"

# Inspecionar um volume (onde mora no host)
docker volume inspect postiz_postgres-data | grep Mountpoint
# "Mountpoint": "/var/lib/docker/volumes/postiz_postgres-data/_data"

# Backup ad-hoc de um volume (tar comprimido com data)
docker run --rm \
  -v postiz_postgres-data:/source:ro \
  -v $(pwd)/backups:/backup \
  alpine tar czf /backup/pg-$(date +%F).tar.gz -C /source .

# Restore (CUIDADO: destrói o destino)
docker run --rm \
  -v postiz_postgres-data:/target \
  -v $(pwd)/backups:/backup \
  alpine sh -c "cd /target && tar xzf /backup/pg-2026-05-24.tar.gz"

# Paths críticos para backup em prod
# /var/lib/docker/volumes/postiz_postgres-data    -> banco
# /var/lib/docker/volumes/postiz_postiz-uploads   -> mídia dos posts
# /var/lib/docker/volumes/postiz_redis-data       -> filas pendentes
# /home/deploy/postiz/.env.prod                   -> secrets

Conceitos-chave

Em produção, dois mecanismos garantem que o stack se recupera sozinho: restart policy (Docker reinicia o container se ele cair) e healthcheck (Docker sabe se o processo dentro está realmente respondendo, não só "rodando").

Use restart: unless-stopped em quase tudo: reinicia em crash e no boot, mas respeita um stop manual seu. restart: always é mais agressivo (ignora stop manual após reboot) e útil só em componentes críticos como o reverse proxy.

# Healthcheck no Postiz com curl interno
services:
  postiz:
    image: ghcr.io/gitroomhq/postiz-app:latest
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:5000/api/health"]
      interval: 30s        # frequência
      timeout: 10s         # cada check tem 10s p/ responder
      retries: 3           # 3 falhas seguidas = unhealthy
      start_period: 60s    # graça inicial: ignora falhas no boot
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_healthy

O par depends_on + condition: service_healthy é o segredo de um boot determinístico: o Postiz só inicia depois que pg_isready e redis-cli ping respondem OK. Sem isso, no primeiro up a app crasha tentando rodar migrations em um Postgres que ainda está fazendo initdb.

# Inspecionar saúde de cada serviço
docker compose ps
# NAME              STATUS                   PORTS
# postiz            Up 2h (healthy)          5000/tcp
# postiz-postgres   Up 2h (healthy)
# postiz-redis      Up 2h (healthy)

# Ver últimos resultados do healthcheck (JSON)
docker inspect postiz --format '{{json .State.Health}}' | jq

# Forçar reinício de um serviço
docker compose restart postiz

# Acompanhar reinícios automáticos (quantas vezes caiu)
docker inspect postiz --format '{{.RestartCount}}'

Conceitos-chave