Nixpacks vs Docker: O Guia Definitivo sobre Tamanho, Velocidade e por que a Railway Abandonou o Nixpacks

A decisão Nixpacks vs Docker costumava ser simples: trocar controlo por conveniência. Mas em 2025, a Railway, a equipa que criou o Nixpacks, colocou-o em modo de manutenção e lançou o Railpack como seu substituto. Isso muda completamente os cálculos. Esta é a comparação completa entre docker e nixpacks com tamanhos reais de imagens, dados de velocidade de compilação, código lado a lado e um quadro de decisão que considera onde as coisas realmente estão em 2026.

Nixpacks vs Docker num Relance

Se precisa de implementar sem um Dockerfile e a sua stack é suportada, o Nixpacks (ou o seu sucessor Railpack) coloca-o a funcionar em segundos. Se lhe importa o tamanho da imagem, a velocidade de compilação ou a otimização para produção, um Dockerfile personalizado ganha sempre.

Uma coisa importante a entender desde já: o Nixpacks não substitui o Docker. Gera um Dockerfile nos bastidores e utiliza o BuildKit do Docker para produzir imagens compatíveis com OCI. É uma camada de abstração sobre o Docker, não uma alternativa ao mesmo.

O que é o Nixpacks? (E como difere do Nix)

O Nixpacks é uma ferramenta de compilação criada pela Railway que deteta automaticamente a linguagem e o framework da sua aplicação, gerando depois uma imagem de contentor sem qualquer configuração. Envia o código, o Nixpacks trata do resto. Essa é a proposta e, para aplicações simples, cumpre genuinamente o prometido.

Eis como é uma compilação do Nixpacks:

# Zero config -- Nixpacks detects your stack automatically
nixpacks build . --name my-app

# Or with a custom start command
nixpacks build . --name my-app --start-cmd "node dist/index.js"

O Nixpacks analisa o seu código-fonte à procura de ficheiros como package.json, requirements.txt ou go.mod e escolhe o "provider" correto, o seu termo para receitas de compilação específicas de cada linguagem. Foi desenhado para ser mais rápido e simples do que os buildpacks ao estilo Heroku e, durante algum tempo, foi o construtor padrão da Railway.

Como o Nixpacks Deteta a Sua Stack

O pipeline de deteção é direto: o Nixpacks percorre a raiz do seu projeto à procura de ficheiros de configuração conhecidos. Encontrou um package.json? Provider Node.js. Encontrou requirements.txt ou pyproject.toml? Provider Python. Chega até a lidar com monorepos até certo ponto, embora as coisas se compliquem com estruturas de projeto não padrão.

Nix vs Nixpacks: Não São a Mesma Coisa

Isto confunde quase toda a gente (incluindo a maioria dos artigos que aparecem nas pesquisas por esta consulta). O Nix é um gestor de pacotes funcional e sistema de compilação focado em builds reproduzíveis. O Nixpacks é uma ferramenta específica que usa pacotes Nix internamente para resolver dependências. Estão relacionados, mas são diferentes, como dizer que "npm" e "create-react-app" são a mesma coisa porque um usa o outro.

O contexto crítico para 2026: o Nixpacks está em modo de manutenção. A Railway deixou de adicionar funcionalidades e criou o Railpack para abordar limitações fundamentais. Os projetos existentes continuam a funcionar, mas não há roteiro para melhorias.

Docker e Dockerfiles: O Padrão da Indústria

Já conhece o Docker. Portanto, vamos saltar o parágrafo "O Docker é uma plataforma de contentorização" e focar-nos no que importa para esta comparação.

Um Dockerfile dá-lhe controlo explícito, camada por camada, sobre a sua imagem de contentor. Escolhe a imagem base, controla quais os ficheiros copiados, especifica exatamente quais as dependências instaladas e otimiza o resultado final com compilações multi-stage. Eis um exemplo pronto para produção:

# Multi-stage Node.js Dockerfile -- optimized for size
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
RUN npm run build

FROM node:20-alpine
WORKDIR /app
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/dist ./dist
EXPOSE 3000
CMD ["node", "dist/index.js"]

As funcionalidades chave do Docker relevantes para esta comparação: as compilações multi-stage permitem separar as dependências de tempo de compilação da imagem de runtime. A cache de camadas através do BuildKit torna as compilações subsequentes rápidas e previsíveis. E a seleção da imagem base (Alpine, distroless, scratch) dá-lhe controlo direto sobre o tamanho da imagem e a superfície de ataque.

O conhecimento de Docker é também universalmente transferível. Todos os fornecedores de cloud, todas as plataformas CI/CD, todos os alvos de implementação entendem um Dockerfile.

Nixpacks vs Docker: Comparação Direta

Configuração e Implementação

O maior argumento de venda do Nixpacks é a implementação sem configuração. Para uma aplicação Node.js standard, literalmente não precisa de nenhum ficheiro de configuração. Envia o código, obtém um contentor. Com o Docker, precisa de escrever e manter um Dockerfile.

Quando precisa de personalizar o Nixpacks, usa o nixpacks.toml:

# nixpacks.toml -- customize Nixpacks behavior
[phases.setup]
nixPkgs = ["...", "ffmpeg"]  # Add system dependencies

[phases.build]
cmds = ["npm run build"]

[start]
cmd = "node dist/index.js"

O Dockerfile equivalente é mais verboso, mas muito mais explícito:

FROM node:20-alpine
RUN apk add --no-cache ffmpeg
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build
CMD ["node", "dist/index.js"]

Para um hackathon ou protótipo, o Nixpacks poupa-lhe tempo real. Para qualquer coisa que vá manter por mais do que um fim de semana, esse Dockerfile paga-se a si próprio em capacidade de depuração e potencial de otimização.

Veredito: Empate. O Nixpacks ganha em velocidade de implementação. O Docker ganha em manutenibilidade a longo prazo. Escolha com base no seu cronograma.

Tamanho da Imagem

É aqui que a comparação se torna brutal. As imagens do Nixpacks são grandes. Não estamos a falar de "ligeiramente maiores", estamos a falar de 10-17x maiores do que um Dockerfile otimizado para a mesma aplicação.

Um caso bem documentado: um desenvolvedor migrou uma aplicação Next.js do Nixpacks para um Dockerfile personalizado e viu a imagem encolher de 1.3GB para 76.83MB, uma redução de 17x. Isto não é invulgar.

A razão resume-se à arquitetura. O Nixpacks despeja tudo em /nix/store, ferramentas de compilação, compiladores, símbolos de debug, bibliotecas de que nunca precisará em runtime, tudo numa única camada massiva. As compilações multi-stage do Docker permitem-lhe descartar tudo exceto os artefactos de runtime reais.

Veredito: O Docker ganha decisivamente. Não é uma decisão difícil. Se o tamanho da imagem importa para o seu projeto, e quase sempre importa para produção, o Docker é a única opção real.

Velocidade de Compilação e Cache

As primeiras compilações com Nixpacks são tipicamente mais lentas porque descarrega pacotes Nix do zero. De acordo com os próprios dados da Railway, uma compilação típica do Nixpacks demora cerca de 1 minuto e 27 segundos, contra 15 segundos para uma compilação de Dockerfile e 6 segundos para uma imagem pré-compilada.

As compilações subsequentes contam uma história mais matizada. A cache binária do Nix pode acelerar as coisas, mas é menos previsível do que a cache de camadas do Docker. Uma alteração ao seu package.json invalida amplamente a cache do Nix, enquanto a cache de camadas do Docker apenas recompila as camadas a partir do passo alterado em diante.

A cache de camadas do Docker é também mais transparente. Pode ver exatamente quais as camadas que mudaram e porquê. A cache do Nixpacks é mais uma caixa negra, ou acerta ou falha, e depurar falhas de cache na store do Nix requer especialização que a maioria das equipas não tem.

Veredito: O Docker ganha. Mais previsível, mais rápido tanto para primeiras como para compilações em cache, e mais fácil de depurar quando a cache falha.

Suporte de Linguagens e Frameworks

O Nixpacks deteta automaticamente cerca de 20 linguagens e frameworks: Node.js, Python, Go, Rust, Java, Ruby, PHP, .NET, Elixir e mais. Para stacks suportadas, a deteção é genuinamente impressionante, escolhe a versão correta do runtime, configura o comando de compilação e define o comando de início automaticamente.

O Docker suporta qualquer coisa para a qual possa escrever um Dockerfile. Isso é efetivamente ilimitado. Runtimes exóticos, toolchains personalizadas, monorepos multilinguagem, se corre em Linux, o Docker trata disso.

A diferença na fixação de versões importa mais do que pensa. O Nixpacks usa versionamento baseado em commits para pacotes Nix. Não pode dizer "Python 3.11.4", obtém a versão que o commit do Nix fornecer. O Docker dá-lhe controlo exato de versão: FROM python:3.11.4-slim é determinístico.

Veredito: O Docker ganha em flexibilidade. O Nixpacks é conveniente se a sua stack estiver na lista de suportadas. O Docker trata de tudo, com controlo preciso de versões.

Prontidão para Produção e Segurança

As imagens do Nixpacks incluem muito mais pacotes do que a sua aplicação realmente precisa. Isso traduz-se numa superfície de ataque maior, mais binários significam mais potenciais vulnerabilidades. A camada inchada /nix/store contém compiladores, ferramentas de compilação e bibliotecas que não têm lugar numa imagem de produção.

O Docker dá-lhe opções como Alpine (mínimo), distroless (sem shell, sem gestor de pacotes) ou mesmo FROM scratch para linguagens compiladas. Estas imagens mínimas contêm apenas o que a sua aplicação precisa para correr, reduzindo drasticamente a superfície de ataque.

A depuração é outra lacuna. As imagens do Nixpacks têm uma estrutura de diretórios desconhecida centrada em /nix/store com caminhos baseados em hash. Se algo correr mal em produção, passará tempo a perceber a disposição do sistema de ficheiros antes de sequer começar a resolver o problema.

Veredito: O Docker ganha para produção. Superfície de ataque menor, ferramentas de depuração familiares e pipelines de análise de segurança estabelecidos favorecem todos o Docker.

Experiência do Desenvolvedor

É aqui que o Nixpacks brilha genuinamente. Para um desenvolvedor que nunca escreveu um Dockerfile, passar do código para um contentor em execução num único comando é mágico. nixpacks build ., feito. Sem sintaxe para aprender, sem imagem base para escolher, sem ordenação de camadas em que pensar.

A curva de aprendizagem do Docker não é íngreme, mas é real. Escrever um Dockerfile eficiente requer compreender a cache de camadas, compilações multi-stage, .dockerignore e a distinção entre COPY e ADD. É conhecimento que compensa, mas leva tempo a adquirir.

O compromisso a longo prazo vale a pena considerar. O conhecimento de Nixpacks é específico da plataforma, é útil na Railway, Coolify e num punhado de outras plataformas. O conhecimento de Docker é universal e transferível para qualquer emprego, qualquer fornecedor de cloud, qualquer alvo de implementação.

Veredito: O Nixpacks ganha para começar. O Docker ganha para utilidade ao longo da carreira. Se está a aprender, comece com o Nixpacks para implementar rapidamente, depois aprenda Docker para produção.

Lado a Lado: A Mesma App, Duas Formas

Vejamos a diferença prática. Eis uma API Node.js Express configurada para ambas as ferramentas.

Nixpacks (zero config, sem ficheiro necessário):

# Nixpacks auto-detects Node.js from package.json
# No configuration file required
nixpacks build . --name express-api

# Result: ~900MB image

Para o Nixpacks, nem sequer precisa de um nixpacks.toml se a sua app for standard. Lê o package.json, deteta o script de compilação e configura o comando de início.

Docker (Dockerfile multi-stage otimizado):

# Dockerfile for the same Express API
FROM node:20-alpine AS deps
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production

FROM node:20-alpine
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY ./src ./src
EXPOSE 3000
CMD ["node", "src/index.js"]

Agora uma app Python FastAPI:

Nixpacks (zero config):

# Nixpacks detects Python from requirements.txt
nixpacks build . --name fastapi-app

# Result: ~1.1GB image

Docker (Dockerfile otimizado):

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY ./app ./app
EXPOSE 8000
CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000"]

Eis o output lado a lado:

# Image size comparison
$ docker images
REPOSITORY          TAG       SIZE
express-api-nix     latest    924MB    # Nixpacks build
express-api         latest    83MB     # Docker multi-stage
fastapi-nix         latest    1.12GB   # Nixpacks build
fastapi-app         latest    92MB     # Docker slim

A versão Nixpacks "simplesmente funciona" sem esforço. A versão Docker demora 10-15 minutos a escrever mas produz uma imagem que é 10x menor, implementa mais rápido e custa menos para armazenar e transferir.

O Problema do Tamanho da Imagem: Por que o Nixpacks Cria Contentores de 800MB

O inchaço da imagem não é um bug que possa configurar para desaparecer, é uma consequência fundamental de como o Nix funciona nos bastidores.

O Que Está Realmente Dentro de uma Imagem de 1.3GB

Quando o Nixpacks compila a sua app, o gestor de pacotes Nix resolve cada dependência (incluindo as de tempo de compilação) e copia-as para /nix/store. Essa store torna-se numa única camada massiva na sua imagem de contentor. Dentro de uma imagem Node.js típica construída com Nixpacks, encontrará:

• Compiladores de compilação (gcc, g++) que só eram necessários durante npm install
• Cabeçalhos de desenvolvimento para módulos nativos que talvez nem use
• Símbolos de debug que adicionam centenas de MB
• Bibliotecas de sistema não utilizadas puxadas como dependências transitivas do Nix
• Todos os metadados da store do Nix, hashes, referências de derivação e grafos de dependência

Por que Não Pode Simplesmente Otimizar Isso

O Docker resolve isto com compilações multi-stage: compila numa fase, copia apenas o output para uma fase de runtime limpa. O Nixpacks não tem mecanismo equivalente. A arquitetura /nix/store trata todos os pacotes como uma única unidade atómica. Não pode escolher a dedo quais os pacotes Nix que entram na imagem final.

Pode tentar limitar pacotes no nixpacks.toml sendo explícito sobre aptPkgs e pacotes Nix, mas as dependências de runtime principais do Nix continuam a ser incluídas. O teto prático para otimização do Nixpacks ainda o deixa com imagens 5-8x maiores do que uma compilação Docker equivalente.

O custo real de imagens de 800MB+: implementações mais lentas, custos mais elevados de armazenamento de registo de contentores, arranques a frio mais longos em plataformas serverless e mais consumo de largura de banda cada vez que um nó puxa a imagem. Para uma startup a executar 10 réplicas com implementações frequentes, esses gigabytes extra somam-se em tempo e dinheiro.

Quando o tamanho da imagem importa, e importa para qualquer coisa além de um protótipo, a resposta é direta: escreva um Dockerfile.

O Fator Railpack: Por que a Railway Abandonou o Nixpacks

Este é o contexto que muda tudo sobre o debate nixpacks vs docker. Em março de 2025, a Railway, a equipa que construiu o Nixpacks e o implementou em 14 milhões de compilações de apps, anunciou que estava a mudar.

As suas razões foram específicas e técnicas:

1. Versionamento baseado em commits, os pacotes Nix não usam semver. Não pode pedir "Node 20.11.1." Obtém a versão que um commit específico do Nix fornecer, tornando as compilações reproduzíveis mais difíceis do que deveriam ser.
2. Tamanhos de imagem massivos, A arquitetura /nix/store tornava a otimização estruturalmente impossível. Os mais de 200.000 utilizadores da Railway estavam a implementar imagens desnecessariamente inchadas.
3. Cache imprevisível, A cache binária do Nix funcionava de forma inconsistente, levando a compilações lentas que frustravam os desenvolvedores.

O Que o Railpack Melhora em Relação ao Nixpacks

O Railpack abandona o Nix totalmente. Usa uma base Ubuntu com gestores de pacotes standard (apt, ferramentas específicas de linguagem) e compilações multi-fase adequadas. Os resultados são significativos:

• Imagens Node.js: 38% menores que o Nixpacks
• Imagens Python: 77% menores que o Nixpacks
• Suporte semver adequado: peça node@20 ou [email protected] e obtenha exatamente isso
• Cache previsível: cache baseada em camadas standard que os desenvolvedores compreendem

O Railpack ainda está em beta. Atualmente suporta Node.js, Python, Go, PHP e HTML estático. Rust, Ruby, Java e várias outras linguagens que o Nixpacks trata ainda não estão disponíveis no Railpack.

Docker vs Nixpacks vs Railpack: Tabela Resumo

Suporte de Plataforma: Onde Cada Ferramenta Funciona

A sua escolha de contentorização depende parcialmente de onde está a implementar. Eis quais as plataformas de implementação modernas suportam quais ferramentas de compilação:

Algumas conclusões: O Docker é a única ferramenta de compilação suportada em todo o lado. Se a portabilidade da plataforma importa, um Dockerfile é a sua aposta mais segura. O suporte do Nixpacks está concentrado em ferramentas PaaS auto-hospedadas (Coolify, Dokploy) e algumas plataformas geridas (Kinsta). O Railpack é exclusivo da Railway por agora.

Quando Usar Cada Um: Quadro de Decisão

Eis a matriz de decisão. Se a sua situação corresponder a uma linha, a recomendação foi testada em projetos reais.

Três regras práticas:

1. A prototipar? Use ferramentas sem configuração (Nixpacks, Railpack). Não perca tempo a escrever um Dockerfile para algo que poderá deitar fora.
2. A ir para produção? Escreva um Dockerfile. Os 30 minutos que investir poupam horas de depuração de imagens inchadas e compilações imprevisíveis.
3. Já está no Nixpacks? Não entre em pânico a migrar. Planeie uma mudança para Railpack ou Docker quando o seu projeto atingir naturalmente um marco.

Como a Techsy Aborda Implementações de Contentores

Já implementámos apps de produção tanto com Nixpacks como com Dockerfiles personalizados, por isso eis a nossa opinião honesta.

Para protótipos de clientes e MVPs, começamos frequentemente com construtores sem configuração. Removem fricção durante a fase em que está a iterar funcionalidades diariamente e ainda não sabe se o projeto vai vingar. O Nixpacks (ou agora o Railpack na Railway) é perfeito para isto, implemente em segundos, foque-se no produto.

No momento em que um projeto chega à produção, mudamos para Dockerfiles otimizados. O nosso processo é este:

1. Auditar a imagem atual, verificar tamanho, identificar pacotes desnecessários, analisar vulnerabilidades
2. Escrever um Dockerfile multi-stage, separar dependências de compilação do runtime
3. Configurar cache de camadas adequada, ordenar instruções COPY para maximizar hits de cache
4. Escolher a imagem base certa, Alpine para a maioria das apps, distroless para serviços críticos de segurança
5. Integrar no CI/CD, compilar, testar, enviar para o registo, implementar

Ajudámos startups a passar de imagens Nixpacks de mais de 1GB para imagens Docker abaixo de 100MB, cortando tempos de implementação em 5x e poupando dinheiro significativo em custos de registo de contentores.

A construir algo e não tem certeza sobre a sua configuração de implementação? Obtenha uma consulta gratuita, ajudamo-lo a escolher a abordagem certa para o seu projeto.

Perguntas Frequentes

O Nixpacks está obsoleto?

Sim. O Nixpacks está em modo de manutenção desde 2025. A Railway (o seu criador) construiu o Railpack como sucessor. Os projetos Nixpacks existentes continuam a funcionar e recebem correções críticas de bugs, mas não estão a ser adicionadas novas funcionalidades ou providers de linguagem. Para novos projetos, considere o Railpack ou um Dockerfile personalizado.

O que substituiu o Nixpacks?

O Railpack, construído pela Railway (a mesma equipa por trás do Nixpacks). Elimina totalmente a dependência do Nix, usando compilações baseadas em Ubuntu com gestores de pacotes standard. O resultado: imagens Node.js 38% menores e imagens Python 77% menores em comparação com o Nixpacks, com suporte adequado de versões semver.

Por que são as imagens do Nixpacks tão grandes?

A arquitetura da store do Nix copia todos os pacotes, incluindo dependências de tempo de compilação como compiladores e símbolos de debug, para uma única camada grande. Não há equivalente às compilações multi-stage do Docker para remover ficheiros desnecessários. Uma app Node.js simples tipicamente produz uma imagem de 800MB-1.3GB via Nixpacks contra 50-100MB com um Dockerfile otimizado.

Devo usar Nixpacks ou Docker?

Para prototipagem rápida em plataformas suportadas, o Nixpacks permite-lhe implementar sem configuração. Para apps de produção onde o tamanho da imagem, segurança e desempenho de compilação importam, um Dockerfile personalizado dá-lhe imagens 10-50x menores e muito mais controlo. Dado o estado obsoleto do Nixpacks, o Docker é o investimento a longo prazo mais seguro.

Podem o Nixpacks e o Docker ser usados juntos?

Sim. O Nixpacks gera um Dockerfile nos bastidores e usa o motor BuildKit do Docker para produzir imagens. Muitas equipas usam o Nixpacks para ambientes de desenvolvimento e staging (iteração rápida, zero config) enquanto mantêm um Dockerfile personalizado para implementações de produção.

Qual é a diferença entre Nix e Nixpacks?

O Nix é um gestor de pacotes funcional e sistema de compilação focado em builds reproduzíveis. O Nixpacks é uma ferramenta de compilação criada pela Railway que usa pacotes Nix para detetar automaticamente linguagens e contentorizar aplicações. São ferramentas relacionadas mas diferentes, o Nix é a tecnologia subjacente, o Nixpacks é o wrapper opinativo construído sobre ele.

A Railway ainda suporta o Nixpacks?

A Railway ainda suporta o Nixpacks para projetos existentes, mas o construtor padrão para novos projetos é agora o Railpack. Também pode usar um Dockerfile personalizado na Railway. Para mudar, basta adicionar um Dockerfile à raiz do seu projeto, a Railway deteta-o automaticamente e usa-o em vez do Nixpacks.

O Nixpacks é mais rápido que o Docker?

Geralmente não. As primeiras compilações com Nixpacks são mais lentas devido aos downloads de pacotes Nix (cerca de 1 minuto e 27 segundos contra 15 segundos para uma compilação de Dockerfile, segundo os benchmarks da Railway). As compilações em cache podem ser comparáveis para alterações simples, mas a cache de camadas do Docker é globalmente mais previsível e granular.

Como mudo do Nixpacks para um Dockerfile na Railway?

Adicione um Dockerfile à raiz do seu projeto. A Railway deteta-o automaticamente e prioriza-o sobre o Nixpacks, sem necessidade de alterar definições. Escreva um Dockerfile multi-stage otimizado para a sua stack, envie-o e a Railway trata do resto.

Que plataformas usam o Nixpacks?

Coolify, Dokploy, Kinsta e Dokku (via plugin) ainda usam ativamente o Nixpacks. A Railway transitou para o Railpack como padrão. Render, Fly.io e Vercel usam os seus próprios sistemas de compilação proprietários. O Docker é a única abordagem de compilação suportada em todas as plataformas.

O Nixpacks é bom para produção?

O Nixpacks é mais adequado para desenvolvimento e staging do que para produção. Os grandes tamanhos de imagem (800MB+), opções limitadas de otimização e estado obsoleto tornam-no uma escolha arriscada para cargas de trabalho de produção. Para produção, um Dockerfile personalizado ou Railpack (se estiver na Railway) são ambas opções mais fortes.

Veredito Final

O Docker é a melhor escolha para a maioria dos desenvolvedores que se preocupam com qualidade de produção. Ganha em cinco de sete categorias, e as duas categorias que o Nixpacks ganha (velocidade de configuração, DX para iniciantes) importam mais durante a prototipagem, uma fase que é temporária por definição.

O Nixpacks serviu um propósito real: provou que a contentorização sem configuração é possível e valiosa. Mas as suas limitações fundamentais, imagens inchadas, cache imprevisível, versionamento baseado em commits, levaram os seus próprios criadores a construir algo melhor. O Railpack poderá eventualmente oferecer o melhor dos dois mundos (sem configuração com tamanhos de imagem razoáveis), mas ainda está em beta com suporte limitado de linguagens.

Eis a recomendação prática: se está a começar um novo projeto na Railway, deixe o Railpack tratar das suas compilações. Se está a implementar noutro local, ou se se dirige para produção, invista os 30 minutos para escrever um Dockerfile adequado. Esse pequeno custo inicial poupa-o de depurar imagens de 1GB, implementações lentas e uma ferramenta de compilação que já não evolui.

Fontes

• Por que Estamos a Abandonar o Nix - Blog da Railway
• Documentação Oficial do Nixpacks
• Substituir Nixpack por uma Imagem Docker na Railway - Apvarun
• Melhores Práticas Docker - Documentação Oficial
• Documentação Oficial do Railpack
• Repositório GitHub do Nixpacks