Node.js

• Start: npm start quando o package.json tem um script start; o app precisa escutar na $PORT e em 0.0.0.0 (HOST, BIND_ADDRESS e variáveis documentadas parecidas são definidas para você).
• Gerenciador de pacotes: npm, pnpm, yarn ou bun, escolhido a partir do seu lockfile.
• Workers: um script npm run worker é oferecido como worker.
• Front ends estáticos: use um site estático em vez disso — sem necessidade de processo de servidor.
• Builds grandes de front end são ajustados automaticamente à memória do servidor de build (build methods).

Etapa de build

O script build do seu package.json roda antes do start sem nenhuma configuração sua — para Next.js, Nuxt, SvelteKit e frameworks server-rendered parecidos, isso é next build/nuxt build/vite build detectado direto das suas dependências, e o servidor inicia com o comando correspondente a cada um (next start, node .output/server/index.mjs…). Um app que só produz saída estática (Gatsby, Create React App, uma SPA Vite simples) é servido como um build estático sem nenhum processo de servidor — veja sites estáticos para pular o servidor por completo em vez de rodar um só para servir arquivos.

Workers são um segundo processo, não um segundo app

web e worker são a mesma imagem, iniciados com um script diferente — um único código-fonte e um único build, vários tipos de processo, cada um escalado separadamente. Um script npm run worker é oferecido automaticamente; declare qualquer outro você mesmo:

web: npm start
worker: npm run worker

ou adicione um na aba Workers do app sem mudar o repositório, e escale qualquer um deles pela CLI:

railyard scale my-app worker=2

O Node não tem uma convenção única de queue, então um executor de jobs baseado em Redis como o BullMQ só precisa do seu próprio script — a REDIS_URL é injetada automaticamente assim que ioredis, bullmq ou bull é uma dependência. Veja Workers e jobs agendados para cron.

Configuração e secrets

Tudo que process.env lê é uma variável comum: defina em Variables, ou railyard env:set my-app KEY=VALUE pela CLI, e o mesmo build roda sem alterações de staging até produção — paridade dev/prod, não um bundle diferente por ambiente. Aponte para um banco de dados ou Redis rodando como serviço próprio no canvas com ${{redis.RAILYARD_PRIVATE_URL}} — resolvido por ambiente. Veja Variáveis e secrets.

Fazendo o deploy

• A partir de um repositório: cole a URL do Git, ou escolha no seletor depois que o GitHub estiver conectado — o Railyard lê o package.json, preenche o comando de start, o gerenciador de pacotes e qualquer banco de dados que suas dependências declararem, e faz deploy a cada push.
• Pela CLI: railyard create my-app https://github.com/me/my-app --addons postgres,redis, ou railyard git:remote && git push railyard main dentro do repositório.
• Um clique só: adicione o botão de deploy ao seu README, ou publique no catálogo de templates para qualquer pessoa lançar com os addons e variáveis já preenchidos.