Caddy na VPS: um jeito simples de publicar aplicações PHP com HTTPS automático

Quando pensamos em publicar uma aplicação web em uma VPS, normalmente três nomes aparecem rapidamente: Apache, Nginx e, mais recentemente, Caddy.

Apache e Nginx são escolhas extremamente consolidadas. O Caddy, por outro lado, ganhou espaço principalmente entre desenvolvedores que querem reduzir a quantidade de configuração necessária para colocar uma aplicação no ar, especialmente quando HTTPS, reverse proxy e múltiplos domínios fazem parte do cenário.

Mas o Caddy é realmente melhor?

A resposta depende do problema que você está tentando resolver.

Neste artigo vamos entender o que é o Caddy, como utilizá-lo em uma VPS, quais são suas vantagens e diferenças em relação ao Apache e ao Nginx e, principalmente, quando essa escolha faz sentido.

O que é o Caddy?

O Caddy é um servidor web e reverse proxy escrito em Go.

Ele pode servir arquivos estáticos, atuar como reverse proxy para aplicações HTTP, encaminhar requisições para PHP-FPM e gerenciar automaticamente certificados TLS para domínios públicos.

Uma das características mais conhecidas do Caddy é o HTTPS automático.

Quando configuramos um domínio no Caddy, ele pode solicitar automaticamente um certificado de uma autoridade ACME, configurar HTTPS e cuidar da renovação do certificado. O redirecionamento de HTTP para HTTPS também é feito automaticamente.

Isso elimina uma quantidade considerável de configuração que normalmente precisamos fazer manualmente em outros servidores web.

Por exemplo, uma configuração muito simples pode ser:

example.com {
    reverse_proxy localhost:3000
}

Com essa configuração, o Caddy recebe as requisições para example.com e encaminha para uma aplicação rodando localmente na porta 3000.

O mesmo conceito pode ser utilizado com APIs, aplicações Node.js, Python, Go, Java e praticamente qualquer aplicação que exponha HTTP.

Caddy não substitui PHP-FPM

Para quem trabalha com PHP, existe uma distinção importante.

O Caddy é o servidor web.

Ele não é o interpretador PHP.

Em uma aplicação PHP tradicional, podemos ter uma arquitetura como:

text

Internet
   │
   ▼
 Caddy
   │
   ▼
 PHP-FPM
   │
   ▼
Aplicação PHP
   │
   ▼
 MySQL / PostgreSQL

O Caddy recebe a requisição HTTP, identifica que ela deve ser processada pelo PHP e encaminha a execução para o PHP-FPM usando FastCGI.

O próprio Caddy possui a diretiva php_fastcgi, criada especificamente para esse cenário. Ela encapsula boa parte da configuração necessária para trabalhar com PHP-FPM e aplicações cujo index.php funciona como ponto de entrada.

Um exemplo poderia ser:

example.com {
    root * /var/www/example/public

    php_fastcgi unix//run/php/php-fpm.sock

    file_server
}

O caminho exato do socket depende da distribuição e da versão do PHP instalada.

Em uma aplicação Symfony, por exemplo, o diretório público normalmente seria:

text

/var/www/example/public

Isso é importante porque arquivos internos da aplicação, como .env, src/, config/ e vendor/, não devem ser expostos diretamente pela internet.

Como ficaria um deploy simples em uma VPS?

Uma estrutura básica poderia ser:

text

VPS
├── Caddy
├── PHP-FPM
├── Aplicação Symfony
├── MySQL
└── Redis

O Caddy ficaria responsável pela camada HTTP.

O PHP-FPM executaria o PHP.

O banco de dados armazenaria os dados da aplicação.

O Redis poderia cuidar de cache, sessões ou filas, dependendo da arquitetura.

Uma configuração simples de Caddy para uma aplicação PHP poderia ser:

app.example.com {
    root * /var/www/app/public

    encode gzip zstd

    php_fastcgi unix//run/php/php-fpm.sock

    file_server
}

A partir disso, a aplicação pode ser acessada pelo domínio configurado.

A instalação oficial do Caddy em distribuições como Debian e Ubuntu também fornece integração com systemd, permitindo que o serviço seja iniciado automaticamente após o boot e tenha seu gerenciamento integrado ao sistema operacional.

E onde entra o reverse proxy?

O Caddy não precisa necessariamente estar servindo PHP diretamente.

Esse é um dos cenários em que ele fica particularmente interessante.

Imagine uma VPS rodando:

text

Caddy :443
   │
   ├── app.example.com → localhost:3000
   ├── api.example.com → localhost:8080
   └── admin.example.com → localhost:9000

Cada aplicação continua rodando internamente em sua própria porta.

O Caddy centraliza:

HTTPS
certificados
domínios
roteamento
reverse proxy
headers
compressão
regras HTTP

A diretiva reverse_proxy suporta múltiplos backends, balanceamento de carga e verificações de saúde, entre outros recursos.

Isso significa que podemos ter uma VPS executando várias aplicações sem precisar expor diretamente as portas delas na internet.

Caddy vs Apache

Apache continua sendo uma excelente escolha, principalmente em ambientes que já dependem fortemente de sua arquitetura.

Uma diferença importante está na forma como as configurações costumam ser organizadas.

Em um ambiente Apache tradicional, é comum trabalharmos com:

text

/etc/apache2/sites-available/
/etc/apache2/sites-enabled/

Além disso, muitos projetos PHP antigos utilizam .htaccess.

No Caddy, a configuração costuma ficar muito mais centralizada no Caddyfile.

Por exemplo:

example.com {
    root * /var/www/example/public

    php_fastcgi unix//run/php/php-fpm.sock

    file_server
}

Essa simplicidade pode ser muito interessante para uma VPS pequena administrada diretamente pelo desenvolvedor.

Uma diferença importante: `.htaccess`

Aplicações antigas podem depender fortemente de regras em .htaccess.

Nesse cenário, migrar para Caddy não significa simplesmente copiar o arquivo.

As regras precisam ser convertidas para a configuração do Caddy.

Por isso, uma aplicação antiga com dezenas de regras específicas de Apache pode tornar uma migração para Caddy mais trabalhosa do que parece.

Para uma aplicação moderna e controlada pelo próprio desenvolvedor, isso tende a ser menos problemático.

Caddy vs Nginx

Nginx também é extremamente comum em ambientes de produção.

A arquitetura clássica é bastante parecida:

text

Internet
   │
   ▼
Nginx
   │
   ├── PHP-FPM
   ├── Node.js
   └── API

A grande diferença não está necessariamente no que os dois conseguem fazer, mas principalmente em como a configuração e a operação são realizadas.

Uma configuração Nginx para PHP normalmente envolve conceitos como:

nginx

server {
    listen 443 ssl;
    server_name example.com;

    root /var/www/example/public;

    location / {
        try_files $uri /index.php?$query_string;
    }

    location ~ \.php$ {
        fastcgi_pass unix:/run/php/php-fpm.sock;
        include fastcgi_params;
    }
}

Enquanto no Caddy podemos ter uma configuração equivalente muito mais compacta:

example.com {
    root * /var/www/example/public

    php_fastcgi unix//run/php/php-fpm.sock

    file_server
}

O Caddy foi desenhado para oferecer uma experiência de configuração mais simples, enquanto Nginx oferece uma configuração muito ampla e extremamente madura.

Não existe uma regra dizendo que uma aplicação com Caddy será automaticamente mais rápida ou melhor que a mesma aplicação com Nginx.

Na maioria dos projetos PHP, o desempenho final também dependerá da aplicação, PHP-FPM, banco de dados, cache, queries, infraestrutura e volume de tráfego.

A escolha do servidor web deve considerar principalmente as necessidades operacionais e arquiteturais do projeto.

Uma das maiores vantagens: HTTPS automático

Esse é provavelmente o recurso que mais chama atenção em um deploy simples.

Com Caddy:

example.com {
    reverse_proxy localhost:3000
}

Já estamos declarando o domínio que deverá ser atendido.

Quando o domínio está corretamente apontado para a máquina e as portas necessárias estão acessíveis, o Caddy pode obter e renovar automaticamente o certificado TLS.

Isso reduz bastante o número de tarefas manuais.

Em uma configuração tradicional, precisamos pensar em:

text

Certificado
    ↓
Chave privada
    ↓
Virtual Host
    ↓
HTTPS
    ↓
Redirect HTTP → HTTPS
    ↓
Renovação

Com Caddy, grande parte desse processo fica integrada ao servidor.

Isso não significa que o administrador possa ignorar DNS, firewall ou a própria infraestrutura.

Por exemplo, uma instalação pública precisa continuar corretamente configurada para receber tráfego nas portas HTTP e HTTPS.

Onde o Caddy é mais usado?

O Caddy pode aparecer em vários tipos de infraestrutura.

VPS de pequenos e médios projetos

Esse é um dos cenários mais interessantes.

Imagine uma VPS com:

text

Ubuntu
Caddy
PHP 8.x
PHP-FPM
Symfony
MySQL
Redis

Para um desenvolvedor responsável pela própria infraestrutura, a configuração pode ser bastante direta.

Reverse proxy

Outro cenário muito comum é usar o Caddy apenas como entrada da infraestrutura:

text

Internet
   │
   ▼
 Caddy
   │
   ├── Symfony
   ├── Node.js
   ├── API
   └── Frontend

Nesse modelo, cada aplicação pode permanecer isolada internamente.

Docker

O Caddy também pode trabalhar como reverse proxy diante de containers.

Por exemplo:

text

Internet
   │
   ▼
 Caddy
   │
   ├── frontend-container
   ├── backend-container
   └── api-container

Isso é especialmente interessante quando queremos que apenas o Caddy publique portas para a internet enquanto os demais serviços permanecem acessíveis apenas na rede interna.

Homelab

Caddy também é uma opção interessante para laboratórios pessoais.

Podemos ter:

text

grafana.example.internal
git.example.internal
api.example.internal
home.example.internal

e centralizar o acesso HTTP em um único servidor.

Além disso, o Caddy possui suporte a certificados locais para ambientes internos, além do fluxo tradicional de certificados públicos para domínios acessíveis externamente.

Onde o Caddy não é a escolha mais natural?

Apesar das vantagens, Caddy não deve ser escolhido simplesmente porque sua configuração é menor.

Existem cenários onde Apache ou Nginx podem ser mais adequados.

Aplicações muito dependentes de Apache

Se uma aplicação utiliza extensivamente:

text

.htaccess
mod_rewrite
módulos específicos
configurações Apache

a migração pode exigir trabalho adicional.

Nesse cenário, continuar utilizando Apache pode reduzir o risco operacional.

Infraestrutura padronizada em Nginx

Em empresas onde toda a infraestrutura já utiliza Nginx, métricas, templates, documentação, automações e procedimentos operacionais podem estar totalmente construídos em torno dele.

Introduzir outro servidor web apenas por preferência técnica pode não trazer benefício suficiente para justificar a mudança.

Ambientes altamente especializados

Existem infraestruturas com requisitos específicos de:

módulos;
observabilidade;
integração;
políticas internas;
automação;
suporte operacional;
ferramentas já existentes.

Nesses casos, a decisão deve considerar o ecossistema completo e não apenas a configuração do servidor web.

Quem precisa conhecer o ecossistema Apache/Nginx

Também existe um fator profissional.

Apache e Nginx possuem uma presença enorme no mercado.

Mesmo que você escolha Caddy para seus projetos pessoais, vale a pena conhecer os dois.

Aprender Caddy não deveria significar abandonar Apache e Nginx.

O ideal é entender os conceitos que são transferíveis entre eles:

text

HTTP
TLS
DNS
Reverse Proxy
FastCGI
PHP-FPM
Headers
Cache
Compression
Load Balancing
Logs
Firewall

Esses conceitos continuam existindo independentemente do servidor escolhido.

Caddy torna o deploy mais fácil?

Em muitos projetos pequenos e médios, sim.

Mas é importante separar deploy de servidor web.

O Caddy pode simplificar:

text

HTTPS
Reverse Proxy
Roteamento
Serviço HTTP

Mas ele não resolve sozinho:

text

Git
Composer
Banco de dados
Migrations
Workers
Cron
Filas
Backup
Monitoramento
Logs da aplicação
Secrets
Firewall
Atualizações do sistema

Um deploy completo de uma aplicação Symfony, por exemplo, ainda pode envolver:

bash

git pull
composer install --no-dev --optimize-autoloader
php bin/console doctrine:migrations:migrate
php bin/console cache:clear

e eventualmente reiniciar workers, atualizar assets ou executar outras tarefas específicas da aplicação.

O Caddy resolve uma parte da infraestrutura.

Ele não substitui uma estratégia de deployment.

Uma VPS simples com Caddy

Para um projeto pessoal, um cenário bastante interessante seria:

text

                    INTERNET
                       │
                       ▼
                 ┌───────────┐
                 │   Caddy   │
                 │    :443   │
                 └─────┬─────┘
                       │
              ┌────────┴────────┐
              │                 │
              ▼                 ▼
          PHP-FPM             API
              │                 │
              ▼                 ▼
          Symfony            Serviço
              │
              ▼
          PostgreSQL

A configuração do Caddy poderia permanecer relativamente pequena:

example.com {
    root * /var/www/example/public

    encode gzip zstd

    php_fastcgi unix//run/php/php-fpm.sock

    file_server
}

E uma API separada:

api.example.com {
    reverse_proxy 127.0.0.1:3000
}

O Caddy passa a funcionar como a porta de entrada da infraestrutura.

Caddy ou Apache ou Nginx?

Talvez essa seja a pergunta errada.

Em vez de perguntar:

Qual servidor web é melhor?

Eu prefiro perguntar:

Qual servidor web reduz a complexidade do meu ambiente sem criar novas limitações importantes?

Para uma VPS nova, uma aplicação moderna e uma infraestrutura administrada pelo próprio desenvolvedor, Caddy pode ser extremamente interessante.

Para aplicações legadas fortemente dependentes de Apache, manter Apache pode ser mais simples.

Para ambientes já padronizados em Nginx, continuar utilizando Nginx pode fazer mais sentido operacionalmente.

E para infraestruturas maiores, a decisão deve considerar observabilidade, automação, equipe, padrões internos e requisitos específicos.

Conclusão

O grande diferencial do Caddy não é simplesmente ser outro servidor web.

A proposta mais interessante está na combinação de:

text

Configuração simples
        +
Reverse Proxy
        +
HTTPS automático
        +
Integração com PHP-FPM
        +
Boa experiência operacional

Para quem administra uma VPS sozinho, essa combinação pode reduzir bastante o trabalho necessário para publicar uma aplicação.

Para um desenvolvedor PHP, isso permite montar uma infraestrutura relativamente enxuta:

text

Caddy
  ↓
PHP-FPM
  ↓
Symfony / Laravel / PHP
  ↓
PostgreSQL / MySQL

Mas simplicidade de configuração não deve ser confundida com superioridade absoluta.

Apache continua sendo relevante.

Nginx continua sendo relevante.

E Caddy é mais uma ferramenta que vale a pena conhecer.

A melhor escolha é aquela que se encaixa na aplicação, na infraestrutura e na forma como você pretende operar o ambiente.

No final, o objetivo não é escolher o servidor web mais popular.

É escolher aquele que resolve o problema com a menor complexidade operacional possível.

Referências

Documentação oficial do Caddy — instalação e execução como serviço.
Documentação oficial do Caddy — HTTPS automático.
Documentação oficial do Caddy — php_fastcgi.
Documentação oficial do Caddy — reverse_proxy.

O que é o Caddy?

Caddy não substitui PHP-FPM

Como ficaria um deploy simples em uma VPS?

E onde entra o reverse proxy?

Caddy vs Apache

Uma diferença importante: .htaccess

Caddy vs Nginx

Uma das maiores vantagens: HTTPS automático

Onde o Caddy é mais usado?

VPS de pequenos e médios projetos

Reverse proxy

Docker

Homelab

Onde o Caddy não é a escolha mais natural?

Aplicações muito dependentes de Apache

Infraestrutura padronizada em Nginx

Ambientes altamente especializados

Quem precisa conhecer o ecossistema Apache/Nginx

Caddy torna o deploy mais fácil?

Uma VPS simples com Caddy

Caddy ou Apache ou Nginx?

Conclusão

É escolher aquele que resolve o problema com a menor complexidade operacional possível.

Referências

Uma diferença importante: `.htaccess`