Fazendo deploy de uma aplicação Next.js sem conta na Vercel
O Next.js é feito pra rodar na Vercel, que é um padrão ótimo até a fatura começar a rastrear invocações de função e requisições de edge em vez de um número fixo que você consegue de fato prever. O framework em si não exige isso — um next build seguido de next start é só um processo Node, o que significa que ele roda do mesmo jeito em qualquer lugar onde um processo Node consiga rodar, incluindo num servidor que você possui.
O que realmente acontece no push
Não há nenhuma configuração específica do Next.js pra escrever. O Railyard lê o package.json, detecta o script build, e pra uma dependência do Next.js especificamente roda next build antes de iniciar a aplicação com next start — a mesma detecção que trata Nuxt e SvelteKit também, já que o padrão (o framework declara uma etapa de build, o framework fornece seu próprio comando de start) é compartilhado pelos três. O gerenciador de pacotes — npm, pnpm, yarn ou bun — é identificado a partir de qual lockfile já está no repositório, não chutado.
railyard create my-app https://github.com/me/my-appou cole a mesma URL Git no dashboard depois que o GitHub estiver conectado. De qualquer forma, todo push depois do primeiro reconstrói e faz o deploy de novo automaticamente — o mesmo fluxo de trabalho de git push que a Vercel popularizou, rodando contra uma infraestrutura que não é medida por requisição.
A única decisão que vale tomar deliberadamente: estático ou servidor
Uma aplicação Next.js que usa output: "export" (ou nunca toca em uma funcionalidade só-servidor — sem API routes, sem server actions, sem ISR) produz uma saída puramente estática. Isso é uma coisa significativamente diferente, e mais barata, de rodar do que uma aplicação renderizada no servidor, e o Railyard trata dela assim: um export estático é servido sem nenhum processo Node por trás, enquanto qualquer coisa usando renderização no lado do servidor, API routes ou server actions mantém o processo completo do next start vivo. Saber que tipo de aplicação está de fato sendo lançada — antes de se preocupar com custo de hospedagem — é a primeira pergunta útil, não algo pra pensar depois.
Variáveis de ambiente funcionam do mesmo jeito que localmente
process.env.WHATEVER lê o que estiver definido em Variables, ou via railyard env:set my-app KEY=VALUE pela CLI — o mesmo artefato de build roda sem mudanças desde uma branch de preview até a produção, então um deploy de staging nunca está rodando um bundle diferente do que vai pro ar. Um addon de banco de dados se resolve pra ${{postgres.RAILYARD_PRIVATE_URL}}, restrito por ambiente automaticamente.
Trabalho em segundo plano não precisa de uma segunda aplicação
Se a aplicação precisa de um queue worker ao lado do processo web — e-mails, webhooks, qualquer coisa que não deveria bloquear uma requisição — isso é um segundo script no mesmo package.json, não um segundo repositório ou um segundo deploy: npm run worker é identificado como seu próprio tipo de processo escalável ao lado do web, compartilhando um único build.
Veja a referência completa de Node.js: Node.js docs, Deploying from a repository.