Instalar WordPress com Dokploy em uma VPS é uma forma de reunir domínio próprio, HTTPS e controle da infraestrutura em um ambiente administrado por containers. O painel simplifica o deploy, mas uma instalação confiável também precisa de persistência, isolamento, backup e manutenção.
Neste guia, vamos criar um WordPress com MariaDB usando Docker Compose, configurar o acesso pelo domínio e verificar os pontos que costumam causar problemas. O objetivo é chegar a uma base operacional que você consiga entender e manter.
Escopo: instalação nova, em uma única VPS, com Docker Compose e Traefik do Dokploy. Este procedimento não migra um site existente e não cria alta disponibilidade. Os nomes dos campos podem variar conforme a versão do painel.
Arquitetura que vamos utilizar
WordPress, banco de dados e proxy reverso
O WordPress roda na imagem Apache, que já reúne o servidor HTTP e o PHP. O MariaDB guarda posts, usuários e configurações. O Traefik recebe as conexões externas e encaminha as requisições para o WordPress. O Dokploy administra o ciclo de deploy.
- WordPress: atende internamente na porta 80.
- MariaDB: atende na porta 3306, sem publicá-la no host.
- Traefik: recebe HTTP e HTTPS nas portas 80 e 443 da VPS.
- Volumes: preservam os arquivos do site e os dados do banco.
O HTTPS termina no proxy. Isso significa que o navegador conversa com o Traefik por uma conexão criptografada, enquanto o encaminhamento para o WordPress ocorre pela rede de containers.
Para entender o papel do painel na infraestrutura, leia também Deploy de aplicações com Dokploy em uma VPS: do zero à produção.
Preparando a VPS
Recursos e acesso administrativo
A documentação do Dokploy indica pelo menos 2 GB de RAM e 30 GB de disco. Para este cenário, minha sugestão inicial é reservar 4 GB de RAM, 2 vCPUs e espaço adicional para uploads e backups temporários. Essa sugestão é um ponto de partida: tráfego, plugins e outras aplicações mudam o consumo real.
Utilize uma distribuição Linux suportada e mantida, acesso SSH por chave e um domínio sob seu controle. Antes de instalar, verifique se outro serviço já ocupa as portas do proxy:
sudo ss -lntp
free -h
df -hSe já houver sites nessa máquina, planeje a integração antes de alterar serviços. Em uma VPS nova, a instalação é mais previsível.
Instalando o Dokploy
Se o painel já está instalado, pule esta etapa. Para uma instalação nova, a documentação disponibiliza o instalador oficial. Uma forma de executá-lo com oportunidade de inspeção é baixar o script antes:
curl -fsSL https://dokploy.com/install.sh -o /tmp/dokploy-install.sh
less /tmp/dokploy-install.sh
sudo sh /tmp/dokploy-install.shO instalador pode instalar o Docker quando necessário. Após concluir, acesse http://IP_DA_VPS:3000, crie imediatamente a conta administrativa e configure um domínio com HTTPS para o painel.
Permita o acesso necessário a HTTP e HTTPS. Restrinja SSH e o painel administrativo aos acessos autorizados. Depois de validar o domínio do painel, feche o acesso público desnecessário à porta 3000. Não abra a porta do banco de dados.
Configurando DNS e domínio
Neste exemplo, o site ficará em blog.seudominio.com.br. No provedor de DNS, crie um registro A para blog apontando para o IPv4 público da VPS. Use AAAA apenas se o IPv6 estiver corretamente configurado e acessível.
dig +short A blog.seudominio.com.br
dig +short AAAA blog.seudominio.com.brSe estiver usando Cloudflare, começar com o registro em modo somente DNS facilita verificar o caminho direto até o servidor. Quando ativar o proxy, utilize criptografia Full (strict) com certificado válido na origem. Evite Flexible em um site que já exige HTTPS.
Criando o projeto no Dokploy
Escolhendo Docker Compose
Crie um projeto e um serviço Compose. Selecione o tipo Docker Compose, não Docker Stack. Use o editor de Compose do painel ou um repositório Git que contenha a configuração. O exemplo a seguir foi escrito para Compose.
O Dokploy também oferece um template de WordPress. Aqui utilizaremos uma configuração explícita para tornar visíveis as variáveis, os volumes e a dependência do banco. Não crie as duas opções para o mesmo site.
Variáveis de ambiente
Na área de variáveis do serviço Compose, cadastre os valores abaixo. Substitua todos os marcadores antes do deploy:
WORDPRESS_IMAGE=wordpress:apache
MARIADB_IMAGE=mariadb:11.4
DB_NAME=wordpress
DB_USER=wordpress
DB_PASSWORD=SUBSTITUA_POR_UMA_SENHA_FORTE
DB_ROOT_PASSWORD=SUBSTITUA_POR_OUTRA_SENHA_FORTEGere cada senha separadamente. Por exemplo, openssl rand -hex 32 produz um valor sem caracteres que costumam complicar a interpretação do arquivo de ambiente. Guarde as credenciais no seu gerenciador de senhas.
As tags acima são referências para o exemplo. wordpress:apache acompanha atualizações e mariadb:11.4 acompanha sua série. Antes de operar em produção, selecione versões compatíveis, teste-as e fixe tags completas ou digests. Não coloque credenciais em um repositório público.
Compose para WordPress e MariaDB
services:
wordpress:
image: ${WORDPRESS_IMAGE:?Defina WORDPRESS_IMAGE}
restart: unless-stopped
environment:
WORDPRESS_DB_HOST: db:3306
WORDPRESS_DB_NAME: ${DB_NAME:?Defina DB_NAME}
WORDPRESS_DB_USER: ${DB_USER:?Defina DB_USER}
WORDPRESS_DB_PASSWORD: ${DB_PASSWORD:?Defina DB_PASSWORD}
WORDPRESS_CONFIG_EXTRA: |
define('DISALLOW_FILE_EDIT', true);
volumes:
- wordpress_data:/var/www/html
expose:
- "80"
depends_on:
db:
condition: service_healthy
db:
image: ${MARIADB_IMAGE:?Defina MARIADB_IMAGE}
restart: unless-stopped
environment:
MARIADB_DATABASE: ${DB_NAME:?Defina DB_NAME}
MARIADB_USER: ${DB_USER:?Defina DB_USER}
MARIADB_PASSWORD: ${DB_PASSWORD:?Defina DB_PASSWORD}
MARIADB_ROOT_PASSWORD: ${DB_ROOT_PASSWORD:?Defina DB_ROOT_PASSWORD}
volumes:
- mariadb_data:/var/lib/mysql
healthcheck:
test: ["CMD", "healthcheck.sh", "--connect", "--innodb_initialized"]
interval: 10s
timeout: 5s
retries: 12
start_period: 30s
volumes:
wordpress_data:
mariadb_data:O host do banco é db, o nome do serviço no Compose. localhost apontaria para o próprio container do WordPress. O usuário da aplicação é separado do administrador root do MariaDB.
O healthcheck verifica a disponibilidade do banco, e service_healthy faz o Compose aguardar essa condição antes de iniciar o WordPress. Isso ajuda no primeiro boot, mas não substitui monitoramento nem garante recuperação de todos os incidentes.
Não há publicação de portas por ports. O acesso web será configurado no Dokploy. A diretiva expose informa a porta interna; ela não é um firewall.
As variáveis de inicialização do MariaDB criam banco e usuário quando o volume está vazio. Em um banco existente, trocar a senha no painel não altera automaticamente a conta SQL. Faça a rotação no banco e na aplicação de forma coordenada.
Rede e isolamento
Para acompanhar este guia, habilite Isolated Deployments. O Dokploy cria uma rede para o projeto, conecta os serviços e permite que o Traefik alcance a aplicação. Assim, não é necessário declarar dokploy-network neste Compose.
Confira o resultado em Preview Compose antes de implantar. WordPress e banco precisam compartilhar uma rede, e o proxy precisa alcançar o WordPress. Se optar por redes manuais, adapte a configuração: não presuma que desabilitar o isolamento preserve o mesmo funcionamento.
Configurando domínio e HTTPS
Na aba Domains do serviço Compose, adicione o domínio do site. Use estes valores como referência:
- Host:
blog.seudominio.com.br, sem protocolo. - Serviço:
wordpress. - Porta do container:
80. - Caminho:
/. - HTTPS: habilitado, com emissão de certificado por Let’s Encrypt conforme as opções do painel.
Salve e execute o deploy. Em Docker Compose, alterações de domínio exigem um novo deploy para aplicar as labels de roteamento. Verifique os logs se o certificado não for emitido: DNS, portas acessíveis e desafios de validação precisam estar corretos.
WordPress atrás do proxy
A imagem oficial do WordPress inclui tratamento de X-Forwarded-Proto em sua configuração Docker. O proxy precisa enviar esse cabeçalho corretamente para que o site reconheça HTTPS. Evite adicionar vários trechos de configuração antes de verificar o comportamento existente.
Abra o instalador diretamente pelo domínio HTTPS. Se o navegador entrar em loop de redirecionamento, confira o modo SSL do CDN, as URLs do WordPress e os cabeçalhos do proxy.
Concluindo a instalação do WordPress
- Acesse
https://blog.seudominio.com.br. - Defina o nome do site, um usuário administrativo próprio, senha forte e e-mail válido.
- Conclua a instalação e entre no painel.
- Em Configurações → Geral, confira as URLs com HTTPS.
- Em Configurações → Links permanentes, escolha a estrutura desejada.
- Configure o fuso horário e revise a visibilidade para mecanismos de busca.
Escolha a estrutura de permalinks antes de publicar. Alterá-la depois pode exigir redirecionamentos para preservar os endereços antigos.
Crie um post de teste, envie uma imagem e abra ambos em uma janela anônima. Verifique o login, os links, o carregamento de CSS e o certificado. Configure também o envio de e-mails e teste uma recuperação de senha; não presuma que o servidor já entrega mensagens.
Persistência de dados e volumes
O que fica salvo
O volume wordpress_data preserva /var/www/html, incluindo uploads, temas, plugins e configuração. O volume mariadb_data preserva os dados do banco em /var/lib/mysql. Recriar um container com os mesmos volumes permite reutilizar esses dados.
O nome real do volume pode incluir um prefixo do projeto. Registre os nomes utilizados e evite mudar a identidade do projeto sem planejar a migração. Um volume novo pode fazer uma instalação antiga parecer vazia.
O que um volume não resolve
Persistência não é backup: exclusão de conteúdo, corrupção e perda da VPS também afetam os volumes. Evite comandos como docker compose down -v e limpeza indiscriminada de volumes no ambiente do site.
Como este exemplo persiste todo o diretório do WordPress, acompanhe também a versão do core pelo painel. Trocar a imagem do container não deve ser tratado como garantia de atualização dos arquivos já presentes no volume.
Segurança pós-instalação
- Mantenha WordPress, temas, plugins, Dokploy e sistema operacional atualizados.
- Use autenticação de dois fatores nas contas administrativas quando disponível.
- Remova extensões e usuários que não são necessários.
- Restrinja acesso ao painel da infraestrutura e use SSH por chave.
- Não exponha MariaDB nem ferramentas de administração do banco na internet.
- Use um tema filho para personalizações e mantenha uma cópia do código.
- Revise permissões sem recorrer a
chmod 777.
A constante DISALLOW_FILE_EDIT do exemplo desabilita a edição de arquivos pelo painel do WordPress. Ela reduz um caminho de alteração, mas não impede instalação de plugins nem substitui proteção de credenciais.
Para uma rotina mais abrangente, consulte WordPress em VPS: checklist de desempenho, segurança e manutenção.
Backup e restauração
Banco, arquivos e configuração
Monte um conjunto de backup com exportação consistente do banco, arquivos do WordPress e configuração do deploy. Inclua Compose, relação das versões e variáveis necessárias; proteja credenciais com criptografia e controle de acesso.
Para o banco, prefira um dump consistente ou uma ferramenta de backup apropriada ao MariaDB. Copiar os arquivos de /var/lib/mysql enquanto o banco está escrevendo não garante uma restauração válida.
O Dokploy disponibiliza backups de volumes. Verifique o suporte e a configuração na sua instalação e envie cópias para armazenamento externo. O backup do painel Dokploy também não deve ser presumido como backup completo das aplicações.
Uma política inicial de backup
Como ponto de partida editorial, sugiro backups diários, retenção de sete cópias diárias e quatro semanais, além de uma cópia anterior a mudanças importantes. Ajuste frequência e retenção à quantidade de conteúdo que você aceita perder e ao tempo disponível para recuperação.
Em lojas ou sites com cadastros frequentes, um backup diário pode ser insuficiente. Coordene os arquivos e o banco para representar um estado compatível.
Teste a recuperação
- Crie um ambiente separado, com novos volumes e acesso restrito.
- Restaure os arquivos e importe o dump do banco.
- Ajuste o endereço do site com uma ferramenta que respeite dados serializados.
- Confira posts, mídias, usuários, plugins e login.
- Registre o procedimento e o tempo de recuperação.
Desabilite envio de e-mails, pagamentos e integrações externas no ambiente restaurado. Um backup só vira um plano de recuperação quando você confirma que consegue utilizá-lo.
Problemas comuns e como diagnosticar
Erro ao estabelecer conexão com o banco
Confira o estado do MariaDB, o host db:3306, a rede compartilhada e as credenciais. Se o volume já estava inicializado, investigue as contas existentes: as variáveis do primeiro boot não recriam usuários a cada deploy.
Erro 502 ou 504
Verifique se o WordPress está em execução e se o domínio aponta para o serviço correto, na porta 80. Depois confira a rede entre proxy e aplicação. Não tente corrigir esse erro publicando a porta do banco.
Site abrindo em HTTP ou redirecionando sem parar
Revise a URL configurada no WordPress, o encaminhamento de HTTPS e a configuração do CDN. Também procure URLs antigas em temas e plugins. Faça backup antes de substituições no banco.
Uploads desaparecendo depois de um deploy
Confira se o volume continua montado em /var/www/html e se o nome do projeto permaneceu igual. Um container com volume diferente pode abrir uma instalação nova sem que o volume anterior tenha sido apagado.
Site lento ou VPS sem espaço
Observe CPU, RAM, disco e crescimento de logs e backups. Corrija primeiro o gargalo identificado. Cache de páginas pode ajudar páginas públicas, mas áreas autenticadas, carrinho e checkout exigem regras específicas.
Comece pelos logs do painel. Se precisar investigar no host, descubra os containers e volumes antes de executar qualquer comando:
docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}"
docker volume ls
docker stats --no-streamEsses comandos ajudam a localizar o ambiente. Não remova recursos apenas porque o nome parece antigo: identifique primeiro a aplicação que os utiliza.
Checklist antes de colocar o site em produção
- Domínio resolvendo para a infraestrutura correta.
- HTTPS válido, sem conteúdo misto ou loops.
- WordPress e MariaDB executando com volumes persistentes.
- Banco sem porta publicada no host.
- Login, upload, links permanentes e e-mails testados.
- Versões registradas e estratégia de atualização definida.
- Backup externo configurado e restauração testada.
- Monitoramento de disponibilidade e recursos ativo.
Manutenção depois do primeiro deploy
Reserve uma rotina para revisar atualizações, capacidade, logs e execução dos backups. Antes de atualizar componentes importantes, gere uma cópia recuperável e teste a mudança em um ambiente separado.
Uma única VPS continua sendo um ponto de falha. Se o projeto passar a exigir maior disponibilidade, você precisará rever armazenamento, banco, recuperação e distribuição dos serviços. O painel facilita a operação, mas não elimina essa decisão de arquitetura.
Conclusão
Com WordPress, MariaDB, domínio HTTPS e volumes configurados, você já tem os componentes centrais do site. O próximo passo é transformar a instalação em uma operação previsível: saber o que atualizar, onde os dados estão e como recuperá-los.
A vantagem de usar Dokploy é concentrar boa parte dessa administração em um painel mantendo a configuração do deploy visível. Comece com uma stack simples, valide cada etapa e acrescente complexidade quando houver uma necessidade concreta.
Referências técnicas
- Dokploy: instalação e requisitos
- Dokploy: domínios em Docker Compose
- Dokploy: isolamento de deployments
- Dokploy: backups de volumes
- Imagem oficial do WordPress
- Imagem oficial do MariaDB
- Docker Compose: ordem de inicialização
- WordPress: backup de arquivos e banco
