TypePHP, o compilador que transforma PHP em binário nativo
Marcos Marcolin • 27 de agosto de 2026 • 6 min de leitura
PHP Open Source performanceRecentemente, a equipe do Swoole colocou em open source um projeto que me chamou bastante atenção: o TypePHP, um compilador AOT (Ahead-of-Time) para PHP.
Pra quem não é familiar com o termo, AOT significa que o código é compilado antes de rodar, virando um binário pronto, ao contrário do PHP tradicional, que interpreta o código (ou compila trechos em tempo real, no caso do JIT) a cada execução.
A ideia é simples de explicar: você escreve PHP, e ele compila esse código para código nativo, passando por C++ no meio do caminho. Na prática, isso permite gerar executáveis, extensões PHP e bibliotecas compartilhadas.
E a pergunta que fica é: o que isso muda para quem já desenvolve em PHP?
Sumário
- PHP que vira executável
- Um worker que fica rodando
- E as extensões PHP?
- Onde isso realmente faz sentido?
- E a performance?
- O que ainda não é
- Para quem o TypePHP é interessante?
- Vale a pena acompanhar?
- Em resumo
- Conclusão
PHP que vira executável
Estamos acostumados a executar PHP assim:
php app.php
Ou, numa aplicação web:
HTTP Request
↓
Nginx
↓
PHP-FPM
↓
Código PHP
↓
Response
Com o TypePHP existe outra possibilidade:
PHP
↓
TypePHP
↓
C++
↓
compilador nativo
↓
executável
Por exemplo:
<?php
function calculate(int $n): int
{
$result = 0;
for ($i = 0; $i < $n; $i++) {
$result += $i * $i;
}
return $result;
}
echo calculate(1000000);
Em vez de distribuir o arquivo .php, a ideia é compilar esse código para um executável que roda direto com ./app.
O TypePHP tem uma CLI própria, tpc, com diferentes modos de compilação: bin, ext e lib.
Isso abre uma possibilidade que a gente não costuma associar ao PHP: distribuir uma aplicação como programa nativo. Imagine uma ferramenta:
mytool backup
mytool migrate
mytool analyze
Em vez de o usuário precisar instalar PHP, Composer, dependências e extensões, você distribui um único executável.
Um worker que fica rodando
Outra possibilidade é criar programas que ficam vivos continuamente. Por exemplo, um worker:
RabbitMQ
↓
┌──────────────────────┐
│ my-worker │
│ │
│ pega job │
│ processa │
│ salva resultado │
│ espera próximo │
│ ... │
└──────────────────────┘
Em vez de pensar só em scripts PHP executados sob demanda, você tem um ./my-worker rodando o tempo todo.
Isso se aproxima do modelo que já conhecemos em aplicações Go, Rust, Node.js, Java etc.
Claro que o TypePHP não transforma automaticamente qualquer aplicação PHP num servidor concorrente: networking, event loop, concorrência e comunicação continuam dependendo do runtime e das bibliotecas usadas. Mesmo assim, ter um processo nativo persistente escrito em PHP já muda bastante o jogo.
E as extensões PHP?
O TypePHP também gera extensões nativas. Por exemplo:
<?php
function hello(string $name): string
{
return "Olá, {$name}!";
}
Compilando no modo ext:
tpc hello.php --mode=ext -o hello
O resultado é uma extensão nativa, hello.so, carregada normalmente pelo PHP:
php -d extension=./hello.so -r "echo hello('Marcos');"
Isso cria uma ponte entre o mundo PHP e o código nativo, sem precisar escrever toda a implementação em C ou C++.
Onde isso realmente faz sentido?
Eu não encaro o TypePHP como uma forma de pegar uma aplicação Laravel inteira e transformá-la num executável. O cenário que faz mais sentido pra mim é outro:
Aplicação PHP
│
┌───────────┴───────────┐
│ │
regras de negócio processamento
HTTP / ORM / etc. pesado
│
▼
TypePHP
│
▼
código nativo
Você continua usando PHP onde ele é excelente, mas experimenta código compilado em partes específicas, como:
- processamento de grandes volumes de dados;
- parsers;
- algoritmos e processamento numérico;
- workers;
- CLIs;
- agentes;
- ferramentas de infraestrutura;
- componentes que precisam ser distribuídos como binários.
E existe uma vantagem a mais para software comercial: o cliente não precisa receber seu código PHP original. O próprio projeto cita proteção do código-fonte como uma das vantagens da compilação AOT. Isso não torna um binário impossível de analisar (engenharia reversa continua existindo), mas é bem diferente de entregar uma pasta cheia de arquivos .php.
E a performance?
É a primeira coisa que vem à cabeça quando o assunto é compilação nativa, mas eu tomaria cuidado com a expectativa.
Não significa que "Laravel + TypePHP = aplicação 10x mais rápida".
Se sua aplicação passa a maior parte do tempo esperando MySQL, Redis ou APIs externas, compilar o PHP não vai resolver esse gargalo. O ganho potencial é muito mais interessante em código que realmente consome CPU:
for ($i = 0; $i < 100000000; $i++) {
$result += $i * $i;
}
O TypePHP também trabalha com tipos nativos, como int, float e bool, e containers tipados, dando ao compilador mais informação para gerar código nativo.
Eu vejo a performance como uma vantagem real do projeto, mas não como o motivo principal para acompanhar ele.
O que ainda não é
O TypePHP ainda está em desenvolvimento e trabalha com um subconjunto da linguagem PHP.
Isso acontece porque PHP é extremamente dinâmico:
$method = $foo;
$object->$method();
call_user_func($callback);
Quanto mais dinâmica é a aplicação, mais difícil é determinar em tempo de compilação o que aquele código vai fazer. Por isso, não espere pegar qualquer projeto PHP existente, especialmente uma aplicação grande e cheia de recursos dinâmicos, e simplesmente gerar um executável.
TypePHP ainda não é "Go escrito em PHP". Mas pode ser um caminho e tanto pro futuro da linguagem.
Para quem o TypePHP é interessante?
Se você trabalha exclusivamente com Laravel, Symfony e APIs tradicionais, talvez o TypePHP não mude muita coisa no seu dia a dia, pelo menos por enquanto.
Mas ele passa a fazer muito sentido se você desenvolve:
- ferramentas CLI;
- workers e consumidores de filas;
- processamento de arquivos;
- parsers;
- ferramentas de infraestrutura;
- agentes que ficam rodando na máquina;
- software comercial que precisa ser distribuído;
- extensões PHP;
- código que possui gargalos de CPU.
Nesses casos, o TypePHP deixa de ser curiosidade e vira mais uma ferramenta na caixa.
Vale a pena acompanhar?
Eu acho que sim. Não porque você deveria abandonar PHP-FPM, Laravel ou Symfony amanhã, mas porque o projeto está explorando uma possibilidade que historicamente não era muito comum no ecossistema PHP:
PHP
│
┌──────┼──────┐
│ │ │
▼ ▼ ▼
Web Worker CLI
│ │ │
PHP-FPM binário binário
Um desenvolvedor PHP pode continuar usando toda a experiência que já tem na linguagem e, em determinados cenários, começar a produzir software nativo.
Na minha experiência com extensões PHP e ferramentas de linha de comando, já tenho algumas ideias em mente pra testar o TypePHP e gerar meus primeiros binários nativos.
Em resumo
- Você continua escrevendo PHP.
- O TypePHP compila para código nativo.
- Você pode gerar binários, extensões e bibliotecas.
- Código tipado pode se beneficiar de otimizações nativas.
- O projeto ainda está em desenvolvimento.
Conclusão
O ponto central do TypePHP não é fazer o PHP rodar mais rápido. É a possibilidade de mudar o tipo de software que conseguimos construir e distribuir usando a linguagem.
Hoje, quando pensamos em um:
- CLI;
- daemon;
- worker;
- agente;
- serviço de infraestrutura;
é muito comum escolher Go ou Rust.
Com um compilador como o TypePHP, começamos a fazer uma pergunta diferente: será que ainda precisamos trocar de linguagem, ou podemos continuar usando PHP e compilar essa parte para código nativo?
Ainda é cedo para responder. Mas, como desenvolvedor PHP, é exatamente por isso que eu vou ficar de olho no TypePHP.
O projeto está aberto no GitHub: TypePHP.
Até a próxima e abraços! 🐘