A ideia é ter:

• containers gerenciáveis via Portainer
• stack versionável via Docker Compose
• Evolution API pronta para uso em produção

Pré-requisitos que evitam dor de cabeça

1. Servidor limpo (zerado)
   O SetupOrion verifica se já existe painel/stack instalada e vai falhar se o servidor não estiver “limpo”.
2. Domínio e DNS
   A recomendação do guia é criar um subdomínio base (ex.: vps.seudominio.com) apontando para o IP do servidor e, a partir dele, criar CNAMEs para as apps (portainer, api etc.).

Passo a passo: instalar Docker + Traefik + Portainer + Evolution API via SetupOrion

1) Prepare o DNS (antes de rodar o instalador)

Crie o registro base:

• A: vps.seudominio.com → IP do seu servidor (proxy desligado, se usar Cloudflare)

Depois, crie os CNAMEs que você vai usar:

• CNAME: portainer → vps.seudominio.com (proxy desligado)
• CNAME: api → vps.seudominio.com (proxy desligado)

Se você não quiser usar vps.seudominio.com, pode apontar o CNAME direto para o IP, mas o modelo do “vps base” facilita troca de IP depois.

2) Conecte via SSH

Exemplo:

ssh root@SEU-IP

(ou ssh root@vps.seudominio.com)

3) Rode o SetupOrion (um comando)

bash <(curl -sSL setup.oriondesign.art.br)

Isso abre o menu do SetupOrion.

4) Instale Traefik + Portainer (primeiro)

No menu, a recomendação é começar pela opção de base Traefik + Portainer (no guia aparece como a “primeira instalação obrigatória”).

Durante o processo ele vai pedir:

• hostname do Portainer (ex.: portainer.seudominio.com)
• usuário e senha (o guia menciona evitar caracteres problemáticos e usar credenciais seguras)
• e-mail (usado para SSL/certificados)

Ao final, você acessa o Portainer em:

• https://portainer.seudominio.com

5) Instale a Evolution API pelo próprio menu do SetupOrion

Com o SetupOrion aberto, selecione a Evolution API.

• “03 – Evolution API” → digite 03

Depois ele vai pedir o domínio da Evolution API:

• informe: api.seudominio.com (garanta que o CNAME api já existe)

Ao final ele exibe algo como:

• Server URL: https://api.seudominio.com
• Global API Key: ... (salve isso)

6) Acesse o “manager” da Evolution API (Orion/gerenciador)

A URL indicada no guia:

• https://api.seudominio.com/manager

Você entra com:

• Server URL = https://api.seudominio.com
• Global API Key = a chave exibida ao final da instalação

7) Verifique no Portainer se está tudo rodando

No Portainer:

• Stacks → encontre a stack da Evolution API → status “Running”

O que esse método te entrega (sem gambiarra)

• Docker instalado automaticamente
• Traefik pronto (rotas + SSL)
• Portainer pronto (gestão)
• Evolution API instalada e acessível por domínio
  Tudo via menu, no padrão do SetupOrion.

The post Como instalar Docker, Portainer e Evolution API appeared first on Leonardo Nascimento | Engenheiro de Software.

CI/CD não é sobre velocidade. É sobre previsibilidade, repetibilidade e segurança no processo de entrega.

O que CI/CD realmente resolve em projetos Laravel

Em aplicações Laravel, o pipeline de deploy resolve três problemas clássicos:

1. Ambiente inconsistente
   O código roda local, mas quebra em produção porque algo foi esquecido ou executado fora de ordem.
2. Deploys inseguros
   Código sobe sem testes, sem validação, sem rollback fácil.
3. Processo dependente de pessoas
   “Só fulano sabe fazer deploy”. Quando ele não está, ninguém sobe nada.

CI/CD elimina esses pontos ao transformar deploy em processo automatizado, não em ritual manual.

Conceito básico do pipeline (independente da ferramenta)

Antes de falar de GitHub Actions ou GitLab CI, é importante entender o fluxo lógico. Um pipeline de Laravel bem definido costuma ter estas etapas:

1. Checkout do código
2. Instalação de dependências
3. Execução de testes
4. Build (quando aplicável)
5. Deploy
6. Pós-deploy (migrations, cache, filas)

Se qualquer etapa falhar, o deploy não acontece. Isso é uma proteção, não um obstáculo.

Estrutura mínima de um deploy Laravel saudável

Independente de cloud ou CI, alguns princípios não mudam:

• composer install sempre em modo produção
• .env nunca versionado
• APP_ENV e APP_DEBUG corretos
• migrations rodando de forma controlada
• cache/config/views limpos e recompilados
• workers reiniciados corretamente

Se isso não estiver automatizado, o risco é constante.

Exemplo de pipeline com GitHub Actions

Um pipeline simples, mas funcional, usando GitHub Actions:

name: Deploy Laravel

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: '8.2'
          extensions: mbstring, pdo, pdo_mysql

      - name: Install dependencies
        run: composer install --no-dev --optimize-autoloader

      - name: Run tests
        run: php artisan test

      - name: Deploy via SSH
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SERVER_SSH_KEY }}
          script: |
            cd /var/www/app
            git pull origin main
            composer install --no-dev --optimize-autoloader
            php artisan migrate --force
            php artisan optimize
            php artisan queue:restart

Onde muita gente erra no deploy de Laravel

Rodar migration sem pensar em impacto

Migration em produção pode travar tabela, gerar lentidão ou indisponibilidade. CI/CD não elimina isso. Ele apenas automatiza. Migration precisa ser escrita com consciência de produção.

Cache mal tratado

Não limpar/recriar cache de config e routes gera bugs difíceis de explicar. Cache antigo em produção é clássico.

Workers esquecidos

Deploy sobe código novo, mas workers continuam rodando código antigo. Resultado: comportamento inconsistente.

Falta de rollback

CI/CD sem rollback é metade da solução. Mesmo que seja manual, precisa existir um caminho claro para voltar.

Estratégia simples de rollback

Mesmo sem blue/green ou canary, dá para ter rollback básico:

• manter tags ou releases
• usar git checkout para versão anterior
• rodar php artisan migrate:rollback quando aplicável
• reiniciar workers

O importante é ter plano. Não improvisar sob pressão.

CI/CD não substitui observabilidade

Deploy automatizado reduz erro humano, mas não impede bugs. Por isso, CI/CD precisa andar junto com:

• monitoramento de erros
• alertas pós-deploy
• logs estruturados
• métricas de saúde

Deploy sem visibilidade é só um erro mais rápido.

CI/CD em projetos Laravel não é luxo nem modinha. É uma camada básica de segurança operacional. Ele garante que o código passe sempre pelo mesmo caminho, reduz risco humano e cria previsibilidade no processo de entrega.

Quando o deploy deixa de ser um evento tenso e vira algo rotineiro, o time ganha confiança para evoluir o sistema. E isso, no fim, é o que permite crescer sem quebrar tudo a cada release.

The post Deployment de Laravel no Cloud com CI/CD (GitHub Actions e GitLab CI) appeared first on Leonardo Nascimento | Engenheiro de Software.