# Desenvolver PHP localmente: Docker, DDEV e afins

> Desenvolver PHP localmente com servidor integrado, Docker ou DDEV: pontos fortes, limites, exemplos e o mesmo nível de patches que em produção.

Fonte: https://phpsos.de/pt/php/php-lokal-entwickeln/  
Atualizado em: 25/10/2026  
Prestador: PHP SOS, Assistência de emergência PHP e segurança de servidores. Ajuda imediata por WhatsApp: https://wa.me/491736494914?text=Ol%C3%A1%2C%20PHP%20SOS%2C%20precisamos%20de%20ajuda%20com%20o%20nosso%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6

**Em resumo:** Para desenvolver PHP localmente, há três caminhos habituais: o servidor web integrado (`php -S`) para experiências rápidas, as imagens Docker oficiais do PHP para ambientes reproduzíveis e ferramentas como o DDEV, que criam ambientes de projeto prontos para WordPress, TYPO3, Shopware ou Laravel. Decisiva é menos a ferramenta do que a concordância: localmente deve correr a mesma versão do PHP, com as mesmas extensões, que em produção. Para a segurança, porém, conta sempre, no fim, o ambiente de execução no servidor.

## Porquê um ambiente de desenvolvimento próprio?

Fazer alterações diretamente no servidor em produção é arriscado: cada gralha é logo visível para os clientes, e os ficheiros de teste ficam facilmente esquecidos. Um ambiente local separa a experimentação da operação. É também o lugar onde as novas versões do PHP e as atualizações de segurança são testadas primeiro.

Para a gestão e a direção de TI, a pergunta não é, por isso, se existe um ambiente de desenvolvimento, mas se corresponde ao sistema em produção. Um ambiente local com PHP 8.4, enquanto em produção ainda corre o 8.1, esconde problemas em vez de os mostrar. O mesmo vale para a versão da base de dados, o servidor web e extensões como `intl`, `gd` ou `pdo_mysql`: basta uma extensão em falta para que um erro só se note em produção.

## As opções em resumo

| Opção | Adequada para | Pontos fortes | Limites |
|---|---|---|---|
| Servidor integrado `php -S` | experiências curtas, scripts pequenos | sem instalar mais software | não substitui o Nginx nem o Apache, não serve para redes públicas |
| Imagem Docker oficial | equipas, ambientes reproduzíveis | versão fixável por tag, próximo da operação em contentores | configuração e interação de vários contentores por conta própria |
| DDEV | projetos de CMS e frameworks | tipos de projeto prontos, base de dados e servidor web incluídos | pressupõe Docker, convenções próprias |
| PHP instalado localmente | programadores individuais | rápido, direto | difícil manter em paralelo as versões de vários projetos |

## O servidor web integrado

Desde o PHP 5.4, a linha de comandos inclui um pequeno servidor web. Arranca no diretório atual ou, com `-t`, noutro diretório de documentos:

```bash
php -S localhost:8000 -t public/
```

Opcionalmente, passa-se um script de router, que corre primeiro em cada pedido. O manual é claro na classificação: o servidor destina-se a apoiar o desenvolvimento, não é um servidor web completo e não deve ser usado numa rede pública. Ligue-o por isso a `localhost`, e não a `0.0.0.0`, caso contrário pode ficar acessível na rede Wi-Fi da empresa ou de um hotel. Mais sobre a linha de comandos em [PHP na linha de comandos](https://phpsos.de/pt/php/php-cli/).

## Docker: as imagens PHP oficiais

As imagens oficiais existem em várias variantes: `cli` para a linha de comandos, `apache` com Apache e mod_php, `fpm` para a operação atrás do Nginx ou de outro proxy, e ainda variantes Alpine para imagens pequenas. Um arranque rápido com Apache:

```bash
docker run --rm -p 8080:80 -v "$PWD":/var/www/html php:8.4-apache
```

As imagens contêm os modelos `php.ini-development` e `php.ini-production` no diretório `$PHP_INI_DIR`. Localmente faz sentido o modelo de desenvolvimento, porque mostra os erros. Para produção, a documentação da imagem recomenda expressamente o modelo de produção. As extensões instalam-se com os scripts auxiliares fornecidos `docker-php-ext-configure`, `docker-php-ext-install` e `docker-php-ext-enable`. Como funcionam tags e digests explica-o [Imagens Docker oficiais do PHP](https://phpsos.de/pt/blog/offizielle-php-docker-images/).

## DDEV: ambientes prontos para CMS e frameworks

O DDEV assenta no Docker e configura para um projeto servidor web, PHP, base de dados e serviços auxiliares. Os guias de arranque rápido seguem quase sempre o mesmo padrão:

```bash
ddev config --project-type=wordpress --docroot=web
ddev start
ddev composer install
ddev launch
```

Como tipos de projeto, o DDEV conhece, entre outros, `wordpress`, `typo3`, `shopware6`, `laravel`, `symfony`, `drupal11`, `magento2` e o tipo geral `php`. A versão do PHP define-se em `.ddev/config.yaml`; segundo a documentação, são possíveis versões de 5.6 a 8.5, e a predefinição é a 8.4:

```yaml
# .ddev/config.yaml (excerto)
php_version: "8.3"
webserver_type: nginx-fpm   # em alternativa apache-fpm
```

Assim, o ambiente local corresponde à versão em produção, mesmo que esta ainda não seja a mais recente.

## Desenvolvimento local, nível de patches e PHP2Shell

Após o PHP2Shell, vários fornecedores de plataformas chamaram a atenção para um erro de raciocínio típico. A Vercel sublinha, segundo o seu boletim, que não basta atualizar o ambiente de desenvolvimento local, o código da aplicação ou os plugins; decisivo é o ambiente de execução PHP que realmente serve as páginas. Ter localmente o PHP 8.4.27 não protege o servidor com o 8.4.26.

Inversamente, o ambiente de desenvolvimento traz riscos próprios, que podem migrar para a produção:

1. **ini de desenvolvimento em produção:** o `display_errors` está ativado no `php.ini-development`. Se este ficheiro chegar ao servidor, os visitantes veem caminhos e mensagens de erro. Ver [Desativar a apresentação de erros em produção](https://phpsos.de/pt/blog/display-errors-produktion/).
2. **Ficheiros de teste esquecidos:** ficheiros `phpinfo()`, dumps de bases de dados ou ficheiros `.env` com dados de acesso não pertencem ao deployment.
3. **Servidores de desenvolvimento abertos:** `php -S` ou contentores com portas publicadas em computadores na rede.
4. **Imagens desatualizadas:** as imagens locais não são atualizadas por si; após uma versão de segurança do PHP, também o ambiente de desenvolvimento deve ser reconstruído, para que os testes corram com a versão corrigida.

> **Dica:**
> Defina a versão do PHP num único ponto, por exemplo no Dockerfile ou em `.ddev/config.yaml`, e altere-a nas atualizações em conjunto com a configuração do servidor.

## Como ajuda concretamente o PHP SOS?

No [contrato de manutenção de segurança](https://phpsos.de/pt/leistungen/security-wartungsvertrag/), asseguramos que o desenvolvimento e a operação se ajustam:

- **Confronto:** comparamos a versão do PHP e as extensões dos ambientes de desenvolvimento, teste e produção.
- **Fluxo de atualização:** as novas versões do PHP são aplicadas primeiro no ambiente de teste e depois em produção, sempre com reinício.
- **Verificar o deployment:** zelamos para que nenhum ini de desenvolvimento, ficheiros de teste ou dados de acesso cheguem ao servidor.
- **Documentação:** sabe a qualquer momento que versão corre onde.


## Perguntas frequentes

**Posso usar o servidor web integrado do PHP publicamente?**  
Não. O manual do PHP diz expressamente que o servidor iniciado com php -S se destina ao desenvolvimento e não deve ser usado numa rede pública. Para a operação, o que cabe é o PHP-FPM com Nginx ou Apache.

**O que é o DDEV?**  
O DDEV é uma ferramenta que assenta no Docker e cria ambientes de desenvolvimento prontos para projetos PHP. Conhece tipos de projeto para WordPress, TYPO3, Shopware 6, Laravel, Drupal e outros sistemas.

**Basta atualizar a versão local do PHP?**  
Não. Contra vulnerabilidades como o PHP2Shell conta o ambiente de execução PHP que realmente serve as páginas, ou seja, o do servidor. O ambiente local deve, porém, ter a mesma versão, para que os testes sejam conclusivos.

**Que php.ini devo usar localmente?**  
Localmente faz sentido o php.ini-development, porque mostra os erros. Em produção deve usar-se o php.ini-production. As imagens Docker oficiais trazem ambos os modelos.

## Fontes

- [Manual do PHP: servidor web integrado](https://www.php.net/manual/en/features.commandline.webserver.php)
- [Docker Official Image: PHP](https://hub.docker.com/_/php)
- [DDEV](https://ddev.com/)
