Formato: plano de execução com tarefas verificáveis, checklists, dependências, evidências e gates de aprovação.
Versão do documento: 1.0 · Revisado em: 11/10/2026
Projeto:dnb-postiz-infra· Stack: Postiz + PostgreSQL + Redis + Temporal + PostgreSQL Temporal + Elasticsearch
Ambiente: Easypanel com serviço Docker Compose conectado a um repositório privado no GitHub.
Estado inicial: todas as tarefas pendentes até serem executadas e verificadas no ambiente real.
Objetivo: implantar e manter o Postiz atualizado, com propostas de atualização automáticas, aprovação humana, credenciais fora do Git e restauração comprovadamente possível.
| Item | Decisão |
|---|---|
| Fonte canônica da configuração | Repositório GitHub privado, independente, dnb-postiz-infra |
| Implantação | Easypanel → Compose → origem Git |
| Credenciais | Easypanel → Environment → Create .env file; nunca no Git |
| Atualizações de imagens | Renovate cria PRs; sem automerge |
| Atualizações de infraestrutura | Comparação manual com o Compose oficial do Postiz |
| Entrada em produção | Backup validado → revisão → aprovação → deploy manual → smoke tests |
| Auto-deploy ao fazer merge | Desativado até existir homologação e rollback testado |
| Imagens de produção | Versões explícitas, sem latest |
| Temporal | Manter sob revisão especial: o Compose de referência utiliza temporalio/auto-setup, marcado como descontinuado |
| Banco e volumes | Nunca remover com docker compose down -v; upgrades de versões principais exigem plano próprio |
Importante: o Renovate acompanha versões de imagens referenciadas no Compose, mas não sincroniza automaticamente as mudanças estruturais do repositório oficial. E um PR aprovado no GitHub não equivale a um deploy: o Easypanel só muda os contêineres quando um deployment é disparado.
Pré-requisito documental: este plano acompanha o guia anterior guia-postiz-easypanel.md e o pacote postiz-easypanel-kit.zip. Os comandos abaixo consideram o Compose daquele pacote, no qual a imagem Postiz originalmente usa ${POSTIZ_IMAGE_TAG}.
| Fase | Bloco de trabalho | Prioridade | Depende de | Gate para concluir |
|---|---|---|---|---|
| 0 | Segurança e levantamento | P0 | — | Riscos e estado atual documentados |
| 1 | Preparar Git privado | P0 | 0 | Repo sem credenciais; Compose versionado |
| 2 | Tornar tags detectáveis | P0 | 1 | Imagem Postiz com tag literal no YAML |
| 3 | Instalar/configurar Renovate | P0 | 2 | Dashboard/PR do Renovate confirmados |
| 4 | Acompanhar upstream | P1 | 1 | Processo de comparação manual operacional |
| 5 | Integridade do Easypanel | P0 | 1–3 | Stack saudável, domínio e testes passam |
| 6 | Ciclo de atualização | P0, recorrente | 3, 5 | Release aprovada e testada, sem perda de dados |
| 7 | Backups e recuperação | P0, recorrente | 5 | Restauração testada e documentada |
| 8 | Revisão mensal | P1, recorrente | 3–7 | Pendências, riscos e versões revisados |
| 9 | Aceite e documentação | P0 | Todas aplicáveis | Evidências e runbook atualizados |
Legenda: P0 = obrigatório para produção; P1 = importante para operação contínua.
Regra dos gates: não marcar uma fase como concluída por ter apenas criado arquivos; concluída significa executada e validada.
Objetivo: identificar o que existe, evitar perda de contas/postagens e decidir com segurança se haverá migração ou instalação nova.
Tarefas
Comandos úteis na VPS:
uname -m
free -h
df -h
docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}'
Gate F0 — Pode avançar se:
Objetivo: guardar configuração e histórico sem versionar credenciais.
Tarefas
Estrutura esperada:
dnb-postiz-infra/
├── docker-compose.yaml
├── dynamicconfig/
│ └── production-sql.yaml
├── .env.example
├── .gitignore
├── renovate.json # criado na Fase 3
├── README.md
└── docs/
└── PLANO-POSTIZ-EASYPANEL-ATUALIZACOES.md
.gitignore mínimo:
.env
.env.*
!.env.example
*.pem
*.key
*.dump
*.sql.gz
backups/
Auditoria rápida antes do push:
git status --short
git ls-files | grep -E '(^|/)(\.env$|.*\.pem$|.*\.key$|.*\.dump$)' || true
A auditoria por extensão não detecta segredos escritos diretamente em YAML/README. Revisar o diff e, idealmente, executar também um scanner de secrets antes do push. Não cole outputs completos de
docker compose configem issues ou chats, pois podem conter senhas expandidas.
Gate F1 — Pode avançar se:
Objetivo: permitir que o Renovate detecte a versão da imagem, sem tocar nas secrets.
O pacote inicial possui:
services:
postiz:
image: ghcr.io/gitroomhq/postiz-app:${POSTIZ_IMAGE_TAG:?Defina_POSTIZ_IMAGE_TAG}
Alterar para uma tag explícita já validada e instalada (o valor abaixo é a tag de referência do kit, não uma afirmação de que seja a versão mais recente):
services:
postiz:
image: ghcr.io/gitroomhq/postiz-app:v2.25.0
A configuração ${POSTIZ_IMAGE_TAG} depende do ambiente para determinar a versão. O gerenciador Docker Compose do Renovate identifica imagens com tags no YAML, mas não deve ser usado como se atualizasse automaticamente a versão que está somente no .env do Easypanel.
Tarefas
Comandos (na cópia local do repositório):
git checkout -b chore/renovate-versionamento
git diff -- docker-compose.yaml .env.example
# Depois de editar e revisar:
git add docker-compose.yaml .env.example
git commit -m "chore: fixa imagem do Postiz no compose para Renovate"
git push -u origin chore/renovate-versionamento
Abra um PR, revise e faça merge. Se a stack já está em produção, trate qualquer deploy subsequente com a mesma cautela da Fase 6, ainda que a imagem de fato não tenha mudado.
Gate F2 — Pode avançar se:
Objetivo: receber sugestões de upgrade sem aplicar mudanças diretamente em produção.
Na raiz do repositório, criar renovate.json:
{
"$schema": "https://docs.renovatebot.com/renovate-schema.json",
"extends": ["config:recommended"],
"enabledManagers": ["docker-compose"],
"dependencyDashboard": true,
"automerge": false,
"prConcurrentLimit": 5,
"labels": ["dependencies", "review-required"]
}
Esse arquivo instrui o Renovate a procurar tags de imagens Docker em arquivos Compose, abrir PRs e não mesclar automaticamente. PR criado não é garantia de compatibilidade, principalmente em atualizações de banco e Temporal.
Abrir: https://github.com/apps/renovate
Tarefas
Gate F3 — Pode avançar se:
Objetivo: acompanhar mudanças estruturais que o Renovate não cobre, como novas variáveis, serviços e migrações.
Fonte: https://github.com/gitroomhq/postiz-docker-compose
Como o repositório dnb-postiz-infra nasceu independente do oficial, os históricos são diferentes. Não faça git merge upstream/main automaticamente: isso pode reintroduzir portas públicas, senhas de exemplo, container_name e configurações incompatíveis com Easypanel.
Preparação (uma vez, na cópia local):
git clone git@github.com:SEU_USUARIO/dnb-postiz-infra.git
cd dnb-postiz-infra
git remote add upstream https://github.com/gitroomhq/postiz-docker-compose.git
git fetch upstream
Se
upstreamjá existir, não executeremote addnovamente; use apenasgit fetch upstream.
Comparação na revisão mensal:
git fetch upstream
git log --oneline -n 12 upstream/main
git show upstream/main:docker-compose.yaml > /tmp/postiz-upstream-compose.yaml
git diff --no-index -- docker-compose.yaml /tmp/postiz-upstream-compose.yaml || true
A comparação mostra várias diferenças intencionais do seu Compose. O objetivo é identificar novos requisitos, não deixar os arquivos idênticos.
git diff --no-indexretorna status1quando encontra diferenças; isso é esperado.
Tarefas
Gate F4 — Pode avançar se:
Objetivo: garantir que a base está saudável antes de aceitar PRs de atualização.
Tarefas
Verificação resumida na VPS:
docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}'
Gate F5 — Base pronta se:
Não basta clicar em Merge. Cada versão pode modificar banco, workflows e integrações.
docker compose down -v e não recrie bancos às cegas.Objetivo: não depender de rollback de imagem quando banco/workflows são alterados.
Tarefas
Atenção: volume persistente não é backup. Snapshot de contêiner não substitui dump/backup consistente de banco. Backup apenas do PostgreSQL do Postiz não recupera necessariamente Temporal, mídia e tarefas.
Gate F7 — Backup aceito:
| Campo | Valor a registrar |
|---|---|
| Data/hora da manutenção | AAAA-MM-DD HH:MM (America/Sao_Paulo) |
| Executor | ... |
| Pull Request | URL do PR |
| Commit aprovado | SHA |
| Imagem / versão anterior | ... |
| Imagem / nova versão | ... |
| Backups | local/destino externo + evidência de integridade |
| Migração de banco | não / sim: detalhes |
| Testes pós-deploy | login, API, uploads, agenda, publicação, logs |
| Resultado | SUCESSO / ROLLBACK / PENDENTE |
| Bloqueios/riscos | ... |
| Próxima ação | ... |
O processo está pronto quando o GitHub detecta propostas de atualização, nenhuma atualização entra automaticamente em produção, o Easypanel executa somente versões aprovadas, os serviços passam nos testes funcionais, os dados são preservados e existe um caminho testado para recuperá-los.
Postiz / dependência publica nova imagem
↓
Renovate identifica nova versão
↓
PR criado no GitHub privado
↓
Revisão de release notes, compatibilidade, migrações e segurança
↓
Backup off-server + validação de recuperação
↓
Aprovação humana + merge do PR
↓
Deploy MANUAL no Easypanel
↓
Healthchecks + login + uploads + teste real de agendamento
↓
Registrar evidências e encerrar
Observação de escopo: este plano é um procedimento documentado; não há confirmação de que o GitHub, o Renovate ou o Easypanel do usuário tenham sido configurados, nem de que o deploy e os backups tenham sido executados. Cada checkbox deve ser marcado com base em evidência real.