Node.js

• Démarrage : npm start quand package.json a un script start; l’application doit écouter sur $PORT et 0.0.0.0 (HOST, BIND_ADDRESS et les variables documentées similaires sont définies pour vous).
• Gestionnaire de paquets : npm, pnpm, yarn ou bun, choisi à partir de votre lockfile.
• Workers : un script npm run worker est proposé comme worker.
• Frontends statiques : utilisez plutôt un site statique, aucun processus serveur requis.
• Les builds de frontend volumineux sont adaptés automatiquement à la mémoire du serveur de build (méthodes de build).

Étape de build

Le script build de votre package.json s’exécute avant start sans aucune configuration de votre part — pour Next.js, Nuxt, SvelteKit et les frameworks server-rendered similaires, c’est next build/nuxt build/vite build détecté directement à partir de vos dépendances, et le serveur démarre avec la commande qui correspond à chacun (next start, node .output/server/index.mjs…). Une application qui ne produit qu’une sortie statique (Gatsby, Create React App, un SPA Vite simple) est servie comme un build statique sans aucun processus serveur — voir sites statiques pour vous passer complètement du serveur plutôt que d’en faire tourner un juste pour servir des fichiers.

Les workers sont un second processus, pas une seconde application

web et worker sont la même image, démarrée avec un script différent — un seul code et un seul build, plusieurs types de processus, chacun mis à l’échelle indépendamment. Un script npm run worker est proposé automatiquement; déclarez les autres vous-même :

web: npm start
worker: npm run worker

ou ajoutez-en un depuis l’onglet Workers de l’application sans toucher au dépôt, et mettez l’un ou l’autre à l’échelle depuis la CLI :

railyard scale my-app worker=2

Node n’a pas de convention unique de queue, donc un exécuteur de tâches BullMQ ou similaire adossé à Redis n’a besoin que de son propre script — REDIS_URL est injecté automatiquement dès que ioredis, bullmq ou bull est une dépendance. Voir Workers et tâches planifiées pour le cron.

Configuration et secrets

Tout ce que process.env lit est une simple variable d’environnement : définissez-la sous Variables, ou avec railyard env:set my-app KEY=VALUE depuis la CLI, et le même build tourne sans changement de staging jusqu’en production — la parité dev/prod, pas un bundle différent par environnement. Pour pointer vers une base de données ou un Redis qui tourne comme son propre service sur le canvas, référencez-le avec ${{redis.RAILYARD_PRIVATE_URL}} — résolu par environnement. Voir Variables et secrets.

Déployez-le

• Depuis un dépôt : collez l’URL Git, ou choisissez-le dans le sélecteur une fois GitHub connecté — Railyard lit package.json, remplit la commande de démarrage, le gestionnaire de paquets et toute base de données que vos dépendances déclarent, et déploie à chaque push.
• Depuis la CLI : railyard create my-app https://github.com/me/my-app --addons postgres,redis, ou railyard git:remote && git push railyard main depuis le dépôt.
• En un clic : ajoutez le bouton de déploiement à votre README, ou publiez-le dans le catalogue de modèles pour que n’importe qui puisse le lancer avec ses addons et variables déjà remplis.