Node.js

• Start: npm start cuando package.json tiene un script start; la app debe escuchar en $PORT y 0.0.0.0 (HOST, BIND_ADDRESS y variables documentadas similares se definen por ti).
• Packager: npm, pnpm, yarn o bun, elegido a partir de tu lockfile.
• Workers: se ofrece un script npm run worker como worker.
• Front ends estáticos: usa en cambio un sitio estático — no necesita proceso de servidor.
• Los builds de front end grandes se ajustan automáticamente a la memoria del build server (build methods).

Paso de build

El script build de tu package.json corre antes de start sin que tengas que configurar nada — para Next.js, Nuxt, SvelteKit y frameworks similares renderizados en servidor, eso es next build/nuxt build/vite build detectado directo de tus dependencias, y el servidor arranca con el comando correspondiente a cada uno (next start, node .output/server/index.mjs…). Una app que solo produce salida estática (Gatsby, Create React App, una SPA de Vite sin más) se sirve como un build estático sin ningún proceso de servidor — consulta sitios estáticos para saltarte el servidor por completo en lugar de correr uno solo para servir archivos.

Los workers son un segundo proceso, no una segunda app

web y worker son la misma imagen, iniciada con un script distinto — un mismo código y un mismo build, varios tipos de proceso, cada uno escalado por su cuenta. Se ofrece automáticamente un script npm run worker; declara cualquier otro tú mismo:

web: npm start
worker: npm run worker

o agrega uno desde la pestaña Workers de la app sin cambiar el repositorio, y escala cualquiera desde la CLI:

railyard scale my-app worker=2

Node no tiene una convención única de queue, así que un BullMQ o un job runner similar basado en Redis solo necesita su propio script — REDIS_URL se inyecta automáticamente en cuanto ioredis, bullmq o bull es una dependencia. Consulta Workers y tareas programadas para cron.

Configuración y secretos

Todo lo que lee process.env es una variable normal: defínela en Variables, o railyard env:set my-app KEY=VALUE desde la CLI, y el mismo build corre sin cambios desde staging hasta producción — paridad dev/prod, no un bundle distinto por entorno. Apunta a una base de datos o Redis que corra como su propio servicio en el canvas con ${{redis.RAILYARD_PRIVATE_URL}} — resuelto por entorno. Consulta Variables y secretos.

Despliégalo

• Desde un repositorio: pega la URL de Git, o elígelo del selector una vez que conectes GitHub — Railyard lee package.json, completa el comando de inicio, el packager y cualquier base de datos que declaren tus dependencias, y despliega con cada push.
• Desde la CLI: railyard create my-app https://github.com/me/my-app --addons postgres,redis, o railyard git:remote && git push railyard main desde dentro del repositorio.
• Con un clic: agrega el botón de despliegue a tu README, o publícalo en el catálogo de plantillas para que cualquiera pueda lanzarlo con sus complementos y variables ya completados.