DEV Community: Igor Araujo

[Boost]

Igor Araujo — Fri, 19 Sep 2025 13:40:28 +0000

Martin Jambon for Semgrep

Sep 19 '25

Make Faster and Better GitHub PRs With This Graphite Workflow

#github #git #gitlab #graphite

Comments 1

7 min read

Coolify: A Revolução do Deploy Self-Hosted

Igor Araujo — Fri, 19 Sep 2025 13:34:19 +0000

🎙️ Em um momento em que o controle sobre a infraestrutura se torna cada vez mais estratégico, muitas equipes buscam alternativas ao modelo “vendor lock-in” das grandes plataformas de nuvem. É nesse contexto que o Coolify surge como um protagonista: uma plataforma open source que oferece a simplicidade do Heroku ou do Vercel, mas com a liberdade de rodar em qualquer servidor que você controle.

Se você já sonhou em ter sua própria plataforma como serviço (PaaS), com deploy automático, monitoramento, banco de dados gerenciado e integrações modernas — tudo sem depender de terceiros — o Coolify é a resposta.

O que é o Coolify?

O Coolify é um PaaS open source que transforma seu servidor em uma plataforma completa de deploy e gestão de aplicações.
Ele abstrai a complexidade de containers, redes e orquestração, oferecendo uma experiência parecida com serviços comerciais como Heroku, Netlify ou Railway, mas mantendo você no controle total da sua infraestrutura.

👉 Em termos simples: com o Coolify, você conecta seu repositório Git, define variáveis de ambiente e clica em deploy. O resto — build, containerização, orquestração e exposição — acontece de forma automática.

Por que o Coolify é diferente?

✨ Alguns diferenciais que fazem o Coolify ganhar espaço:

Self-hosted de verdade:

Você pode rodar no seu próprio VPS, servidor dedicado ou até no desktop.
Sem custos ocultos ou dependência de provedores.

Suporte nativo a múltiplos runtimes:

Node.js, PHP, Python, Go, Rust, Ruby, Java e mais.
Bancos de dados como PostgreSQL, MySQL, Redis e MongoDB, com provisioning automático.

Deploy simplificado via Git:

Conecte GitHub, GitLab ou Bitbucket.
O Coolify faz build automático (usando Nixpacks ou Dockerfile, se você preferir).

Ambientes isolados:

Cada aplicação roda em containers separados.
Gestão de domínios, SSL com Let’s Encrypt e balanceamento de carga embutido.

Extensível:

Suporte a APIs, webhooks e configurações avançadas.
Flexibilidade para adaptar à sua stack existente.

Como funciona na prática?

🔧 O ciclo com o Coolify é direto:

Instalação (em qualquer servidor Linux com Docker):

   curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash

Configuração inicial:

Acesse o painel web.
Crie sua conta admin.
Configure domínios e certificados SSL.

Conexão ao repositório:

Integre seu GitHub/GitLab/Bitbucket.
Escolha o projeto a ser deployado.

Deploy automático:

O Coolify detecta a linguagem.
Usa Nixpacks para gerar a imagem (ou um Dockerfile customizado).
Provisiona banco, aplica variáveis e expõe o serviço.

Gerenciamento contínuo:

Logs em tempo real.
Escalabilidade horizontal (múltiplas réplicas).
Backups e restauração de bancos com um clique.

Casos de uso

🌍 O Coolify é ideal para:

Startups que querem reduzir custos de cloud, mas não abrir mão de agilidade.
Empresas com compliance rígido, que precisam manter dados dentro de servidores próprios.
Equipes DevOps que desejam simplificar o deploy sem sacrificar o controle.
Desenvolvedores independentes que querem hospedar projetos pessoais com experiência de nível enterprise.

Comparativo com outras soluções

Ferramenta	Tipo	Abordagem	Pontos Fortes	Pontos Fracos
Heroku	PaaS SaaS	Cloud centralizada	Simplicidade, ecossistema	Custos altos, vendor lock-in
Vercel/Netlify	PaaS SaaS	Serverless focado em web	Deploy rápido, edge functions	Limitado para backends pesados
Render/Railway	PaaS SaaS	Nuvem gerenciada	Automação moderna, integrações	Custos crescem com escala
Coolify	PaaS Self	Open source + Docker	Controle total, multi-runtime, extensível	Curva inicial de setup maior

Integrações e ecossistema

✨ O Coolify conversa naturalmente com:

Provedores Git (GitHub, GitLab, Bitbucket).
Certbot/Let’s Encrypt para SSL automático.
Docker como motor principal.
Nixpacks para builds declarativos.
Banco de dados integrados (Postgres, MySQL, Redis, MongoDB).

Desafios e limitações

Infraestrutura é sua responsabilidade: você precisa cuidar de atualizações, backups do servidor e segurança.
Curva de aprendizado inicial: configurar ambientes complexos pode exigir algum conhecimento de Docker e redes.
Menor suporte enterprise comparado a players SaaS, embora a comunidade esteja crescendo rápido.

O futuro do Coolify

O Coolify se posiciona como parte de uma tendência maior: a de empoderar desenvolvedores com plataformas self-hosted que replicam a experiência premium da cloud.
Ele representa uma ponte entre o mundo DIY do Docker/Kubernetes e a simplicidade de players como Heroku e Vercel.

💡 Em médio prazo, é possível imaginar o Coolify expandindo sua base para suportar multi-servidores com orquestração estilo Kubernetes, integrando métricas nativas de observabilidade e até criando um marketplace de extensões da comunidade.

Conclusão

O Coolify é mais do que uma alternativa de deploy: é uma declaração de independência da nuvem centralizada.
Ele devolve ao desenvolvedor o controle sobre sua infraestrutura, sem abrir mão da simplicidade que tornou os PaaS tão populares.

🌍 Para quem deseja unir custo-eficiência, liberdade e experiência moderna de deploy, o Coolify merece um lugar de destaque na sua stack.
Pode ser o momento de transformar aquele VPS ocioso em uma plataforma robusta de deploy — e descobrir que o futuro da sua infraestrutura pode estar nas suas próprias mãos.

Nixpacks: Automação de Builds Moderna e Declarativa

Igor Araujo — Wed, 17 Sep 2025 20:09:08 +0000

🎙️ Em um cenário em que a experiência do desenvolvedor (DX) é cada vez mais determinante para a produtividade das equipes, surgem ferramentas que vão além do “simples build de aplicações”. Entre elas, o Nixpacks vem ganhando destaque por propor uma abordagem declarativa, reprodutível e escalável para construção de ambientes de execução.

Se você já se frustrou com Dockerfiles gigantes, divergências entre ambientes ou builds inconsistentes em servidores diferentes, o Nixpacks pode representar exatamente o salto de qualidade que faltava na sua stack.

O que é o Nixpacks?

O Nixpacks é uma ferramenta open source criada pela equipe da Railway, projetada para gerar automaticamente imagens de container a partir do código-fonte. Diferente de soluções tradicionais baseadas em buildpacks (como os do Heroku ou do Paketo), ele utiliza o Nix — um sistema de gerenciamento de pacotes e ambientes declarativos — como alicerce.

👉 Em termos simples: o Nixpacks inspeciona seu repositório, entende as dependências do projeto (linguagem, pacotes, versões, binários necessários) e gera uma imagem Docker de forma determinística, reprodutível e otimizada.

Por que o Nixpacks é diferente?

✨ Existem alguns pilares que fazem o Nixpacks se destacar:

Determinismo:

O Nix garante que o mesmo código irá gerar exatamente o mesmo ambiente, em qualquer máquina.
Sem “funcionava na minha máquina, mas não no CI”.

Zero Dockerfiles (quando você quiser):

O Nixpacks gera automaticamente a configuração de build.
Você pode customizar, mas não precisa escrever manualmente cada comando.

Imagens enxutas:

O processo resulta em containers otimizados, com apenas as dependências necessárias.
Isso reduz o tempo de deploy e os custos de armazenamento/transporte de imagens.

Multilíngue e poliglota:

Suporta Node.js, Python, Go, Rust, PHP, Java, entre outros.
Também é possível combinar linguagens no mesmo ambiente (ex: Node + Python).

Como funciona na prática?

🔧 O ciclo de uso é simples:

Instalação:

   curl -fsSL https://nixpacks.com/install.sh | bash

Build de uma aplicação:

   nixpacks build . -o my-app-image

Esse comando:

Analisa o repositório.
Identifica linguagem, dependências e scripts de execução.
Constrói uma imagem Docker otimizada.

Execução do container:

   docker run -p 8080:8080 my-app-image

Customização (se necessário):

Adicione um arquivo nixpacks.toml para declarar versões, dependências extras ou scripts de build.

Exemplo:

 [phases.setup]
 nixPkgs = ["nodejs-20_x", "yarn"]

 [phases.build]
 cmd = "yarn build"

 [phases.start]
 cmd = "yarn start"

Casos de uso

🌍 O Nixpacks é particularmente valioso em alguns cenários:

Startups e equipes ágeis: reduzir tempo gasto com configuração de builds.
Ambientes poliglotas: quando o mesmo serviço precisa conciliar múltiplas linguagens.
CI/CD: garantir reprodutibilidade e consistência em cada pipeline.
Ambientes isolados e auditáveis: segurança e conformidade exigem que dependências sejam claras e controladas.

Comparativo com outras soluções

Ferramenta	Base Tecnológica	Abordagem	Pontos Fortes	Pontos Fracos
Dockerfile	Docker	Imperativa	Controle total, padrão do mercado	Verboso, difícil de manter
Buildpacks	Paketo/Heroku	Declarativa	Simplicidade, automação	Menos flexível, acoplado ao ecossistema
Nixpacks	Nix	Declarativa + Reprodutível	Determinismo, otimização, poliglota	Curva de aprendizado do Nix

Integrações e ecossistema

✨ O Nixpacks pode ser integrado diretamente com:

Railway (PaaS que o criou, onde funciona de forma nativa).
Docker (gera imagens compatíveis).
CI/CD pipelines (GitHub Actions, GitLab CI, CircleCI etc.).
Outros provedores de nuvem: basta usar a imagem gerada.

Desafios e limitações

Nenhuma tecnologia é perfeita, e com o Nixpacks não é diferente:

Curva de aprendizado: para customizações mais avançadas, entender Nix é importante — e Nix tem fama de ser complexo.
Menos maduro que Dockerfile: a comunidade ainda está crescendo e nem todas as linguagens possuem detecção perfeita.
Debugging: em builds automáticos, às vezes é difícil entender o que exatamente deu errado.

O futuro do Nixpacks

O Nixpacks aponta para uma tendência maior: a busca por infraestruturas declarativas, reprodutíveis e otimizadas por padrão.
Assim como Terraform transformou a infraestrutura em código, e Kubernetes mudou a forma como orquestramos workloads, o Nixpacks está pavimentando o caminho para um futuro em que a construção de ambientes não dependa de scripts frágeis, mas de declarações confiáveis.

💡 É possível imaginar um cenário em que ferramentas como o Nixpacks sejam integradas de forma nativa às principais plataformas de deploy, reduzindo drasticamente a fricção entre o código escrito e o serviço rodando em produção.

Conclusão

O Nixpacks é mais do que uma ferramenta de build: é um manifesto contra o caos dos ambientes imprevisíveis.
Ele simplifica a vida do desenvolvedor, garante consistência entre máquinas e servidores, e prepara o terreno para um ciclo de entrega contínua mais estável e confiável.

🌍 Se você lidera equipes ou projetos que sofrem com divergências entre ambientes, builds demorados ou imagens infladas, vale a pena experimentar o Nixpacks. Talvez você descubra que o futuro dos seus deploys pode ser muito mais simples — e elegante — do que você imagina.

DTOs no PHP: o alicerce de um backend claro, seguro e escalável

Igor Araujo — Tue, 09 Sep 2025 17:24:10 +0000

Quando a gente fala de arquitetura limpa no backend, tem um ingrediente que separa o improviso do profissionalismo: os DTOs. Eles tornam o fluxo de dados previsível, seguro e fácil de evoluir — especialmente em times que querem escalar com excelência e responsabilidade. Abaixo, um guia direto ao ponto, no meu estilo, para você adotar DTOs no seu PHP (com exemplo plug-and-play).

1) O que são DTOs (Data Transfer Objects)

DTO é um objeto simples, somente com dados, feito para transportar informações entre camadas (Controller → Use Case/Service → Repository, filas, etc.).
Sem regra de negócio, sem acesso a banco, sem side effects. Apenas um contrato explícito do que entra e do que sai.

2) Por que usar DTOs (e por que isso importa)

Clareza e contrato: o DTO define o formato dos dados. Diminui “adivinhação” e quebra de compatibilidade entre camadas.
Imutabilidade: com readonly, você evita mutações silenciosas e bugs difíceis. O que o caso de uso recebeu é o que será processado.
Segurança e governança: ao fechar o formato dos dados, você reduz risco de fields “perdidos” ou inputs inesperados.
Testabilidade: é simples criar DTOs em testes e simular cenários sem precisar de Request/Model.
Evolução controlada: novas versões de endpoints/fluxos podem ter novos DTOs (v2, v3…) sem quebrar o legado.

3) Como usar DTO no PHP “apenas definindo uma classe”

Abaixo está o seu exemplo de DTO — já no padrão moderno do PHP 8.x, com constructor property promotion e propriedades readonly:

<?php

namespace App\Domain\Entidade\DTO;

class NovaEntidadeDTO
{
    public function __construct(
        public readonly string $nome,
        public readonly string $cnpj,
        public readonly array $json = [],
        public readonly string $cep,
        public readonly string $rua,
        public readonly string $numero,
        public readonly string $complemento,
        public readonly string $bairro,
        public readonly string $cidade,
        public readonly string $estado,
        public readonly string $cnpj_correios
    ) {}

    public static function fromRequest($request): self
    {
        return new self(
            nome: $request->nome,
            cnpj: $request->cnpj,
            json: $request->json ?? [],
            cep: $request->cep,
            rua: $request->rua,
            numero: $request->numero,
            complemento: $request->complemento,
            bairro: $request->bairro,
            cidade: $request->cidade,
            estado: $request->estado,
            cnpj_correios: $request->cnpj_correios
        );
    }

    public function toArray(): array
    {
        return [
            'nome' => $this->nome,
            'cnpj' => $this->cnpj,
            'json' => $this->json,
            'cep' => $this->cep,
            'rua' => $this->rua,
            'numero' => $this->numero,
            'complemento' => $this->complemento,
            'bairro' => $this->bairro,
            'cidade' => $this->cidade,
            'estado' => $this->estado,
            'cnpj_correios' => $this->cnpj_correios
        ];
    }
}

Como integrar no fluxo (exemplo Laravel — mas serve para qualquer stack)

Controller (valida, cria o DTO e chama o caso de uso/serviço):

public function store(Request $request, CriaEntidade $service)
{
    // 1) Validação (exemplo)
    $request->validate([
        'nome' => ['required','string'],
        'cnpj' => ['required','string'],
        'json' => ['nullable','array'],
        'cep' => ['required','string'],
        'rua' => ['required','string'],
        'numero' => ['required','string'],
        'complemento' => ['nullable','string'],
        'bairro' => ['required','string'],
        'cidade' => ['required','string'],
        'estado' => ['required','string'],
        'cnpj_correios' => ['required','string'],
    ]);

    // 2) Transformação segura
    $dto = \App\Domain\Entidade\DTO\NovaEntidadeDTO::fromRequest($request);

    // 3) Orquestração de negócio
    $entidade = $service->handle($dto);

    return response()->json($entidade, 201);
}

Service/Use Case (consome o DTO e persiste via Model/Repository):

final class CriaEntidade
{
    public function handle(\App\Domain\Entidade\DTO\NovaEntidadeDTO $dto)
    {
        // Persistência simples usando o array do DTO
        return \App\Models\Entidade::create($dto->toArray());
    }
}

Observação prática (Laravel): se você tiver um campo do formulário chamado json, ele pode colidir conceitualmente com $request->json() (que é um método). No seu código acima funciona porque você usa $request->json como “propriedade”. Se quiser blindar isso, uma alternativa é criar também um fromArray(array $data): self e passar $request->validated().

Dicas para levar ao próximo nível (quando fizer sentido)

Value Objects: transformar CNPJ, CEP e UF em tipos próprios (com validação) aumenta a qualidade e reduz bugs.
Factories nomeadas: NovaEntidadeDTO::fromWebhook(...), ::fromCli(...) — ótimas quando as fontes de dados variam.
Versionamento: NovaEntidadeV1DTO, NovaEntidadeV2DTO ajudam a evoluir contratos sem quebrar integrações.
Anotações de static analysis: adicione docblocks para o shape de arrays (@var array<string,mixed>), melhorando insights de Psalm/PHPStan.

Conclusão: DTOs elevam a engenharia — clareza, segurança e escala. Em ambientes corporativos, onde governança e padronização importam, eles criam um vocabulário comum entre produto, dev e negócio. Seguimos construindo com ciência, colaboração e propósito.

Infraestrutura como Código não é uma escolha técnica. É uma questão de sobrevivência estratégica.

Igor Araujo — Sat, 17 May 2025 19:39:02 +0000

Em um cenário onde a agilidade deixou de ser diferencial para se tornar pré-requisito, ainda existem empresas que tratam infraestrutura como um custo fixo, estático, centralizado — e, muitas vezes, emocionalmente preso à stack de um único fornecedor.

Essa escolha, além de técnica, é cultural. E, quase sempre, onerosa.

Infrastructure as Code (IaC) não é sobre versionar configurações.
É sobre versionar decisões de negócio.
É sobre transformar infraestrutura em linguagem de produto.
É sobre dar a sua infra, a mesma adaptabilidade que o mercado exige da sua estratégia.

A pergunta não é mais “por que usar IaC?”
A pergunta é:

Quantas decisões financeiras, técnicas e operacionais sua empresa está deixando de tomar por não conseguir abstrair a própria infraestrutura?

Porque enquanto sua equipe debate qual cloud é "melhor", a concorrência já está rodando workloads em múltiplos provedores, otimizando custo e latência em tempo real.

Uma infraestrutura agnóstica não é luxo. É alavanca.
Workload de alto throughput? Roda no provedor mais barato por GB/s.

Funções específicas com melhor suporte em outro ambiente? Roda lá.

Região mais próxima do usuário? Você escolhe. Não é a cloud que decide.

Quem domina a infraestrutura como código, domina o custo, o risco e a mudança.
E em um cenário onde tudo muda o tempo todo, isso equivale a dominar o jogo.

O problema não é a nuvem.
É a falta de soberania sobre ela.

Sem IaC, sua empresa não tem flexibilidade.
Sem IaC, a migração custa caro, demora, trava deploys e desincentiva inovação.
Sem IaC, o custo real não aparece na fatura da cloud — aparece na inércia da estratégia.

Otimização não é uma planilha. É arquitetura.
Empresas que querem falar de FinOps, mas não abstraem infraestrutura, estão caindo na mesma armadilha de sempre:
cortar sem entender, economizar sem medir, reagir sem planejar.

IaC não é sobre “como rodar melhor”.
É sobre “onde rodar melhor”.
É sobre liberdade. E liberdade, no contexto de tecnologia, é custo controlado.

A infraestrutura deixou de ser suporte.
Ela virou estratégia.

E quem ainda não entendeu isso, vai continuar pagando caro por aquilo que deveria estar controlando.

A falsa sensação de inovação: como projetos de IA mal conduzidos estão reforçando velhas ineficiências

Igor Araujo — Wed, 14 May 2025 22:11:33 +0000

Não é porque você usa IA que sua empresa se tornou inovadora.
Na verdade, em muitos casos, a Inteligência Artificial está apenas automatizando ineficiências antigas com uma interface moderna.

Projetos que prometem disrupção acabam, muitas vezes, apenas acelerando processos que já não faziam sentido.
A lógica da produtividade é mantida — só que com dashboards animados, fluxos de decisão opacos e modelos que ninguém sabe exatamente como (ou por que) estão rodando.

O sintoma mais comum?
Organizações que celebram o uso de IA, mas seguem reféns de decisões centralizadas, dados desorganizados e silos de informação.

Automatizar sem repensar processos é como pavimentar uma estrada que leva ao lugar errado — só que mais rápido, com menos atrito e mais custo de nuvem.

Alguns exemplos reais (e dolorosos):
Times de atendimento treinados para depender de respostas geradas por IA, mas sem autonomia para validar ou adaptar.

Sistemas de recomendação que reforçam viéses de negócio ao invés de questioná-los.

Geração automática de relatórios que ninguém lê, mas que seguem ocupando pipelines de dados e horas de reunião.

Estamos otimizando a superfície. Mas ignorando a estrutura.

A inovação de verdade exige desconforto.
Ela exige repensar modelos mentais, estruturas de poder, rituais de decisão.
E isso não vem no pacote do modelo pré-treinado.

Não é sobre IA. É sobre a coragem de rever o que a IA está expondo.
Sua cultura de dados, seu fluxo de valor, suas métricas de sucesso.

A pergunta que incomoda — e precisa ser feita:
Quantos dos seus projetos de IA estão realmente criando valor… e quantos estão apenas te deixando ocupado?

Se o resultado final é “mais um processo automatizado que ninguém entende e poucos usam”, talvez você não esteja inovando.
Talvez só tenha terceirizado sua complacência para um algoritmo.

A IA pode ser o espelho mais brutal da ineficiência institucional.
O problema não é a tecnologia. É o que ela está revelando — e o que você está escolhendo ignorar.

A Inteligência Artificial Generativa não ameaça empregos. Ela ameaça estruturas empresariais obsoletas.

Igor Araujo — Tue, 13 May 2025 19:50:07 +0000

Muito já se discutiu sobre as funcionalidades da IA Generativa: modelos de linguagem, engenharia de prompts, automação de conteúdo. Mas o verdadeiro ponto de inflexão não está na tecnologia em si — e sim na sua capacidade de subverter modelos de operação que antes pareciam inquestionáveis.

Não se trata mais de "adotar IA" como ferramenta, mas de compreender a IA como um agente de transformação organizacional.

Alguns sinais são evidentes:
Reuniões que antes geravam atas são hoje analisadas em tempo real, com recomendações geradas automaticamente para subsidiar decisões.

Propostas comerciais que levavam horas para serem montadas agora podem ser redigidas em minutos, com base em dados contextuais e históricos de negociação.

Campanhas de marketing não precisam mais ser montadas do zero: são concebidas, testadas e ajustadas por sistemas autônomos com base em comportamento e intenção.

A IA Generativa não está apenas automatizando processos.
Ela está redefinindo a noção de produtividade, escopo de trabalho e tempo de resposta.

E, talvez mais importante: está alterando o que esperamos das organizações e dos profissionais que nelas atuam.

O risco real não é ser substituído pela IA.
É ser superado por quem a entendeu como fundamento estratégico — e não como um simples recurso auxiliar.

Não é mais suficiente usar IA.
É preciso pensar com IA, projetar estruturas com IA, e redesenhar valor com IA.

A pergunta, então, não é mais “como aplicar essa tecnologia?”.
A pergunta que se impõe é:

Sua organização está preparada para repensar seus fundamentos operacionais à luz da Inteligência Artificial Generativa — ou será refém de sua própria inércia?

📌 O debate precisa sair do nível técnico e alcançar o nível estratégico.
A IA Generativa não é uma revolução do como. É uma disrupção do por que e para quem as coisas são feitas.