CLI

railyard est un seul binaire Go par-dessus l’API REST de Railyard : déployez, suivez les logs, exécutez des commandes, gérez les variables d’environnement, les domaines, les bases de données et les serveurs depuis votre terminal. Aucun runtime requis.

Installation

Un seul binaire, sans dépendances, pour macOS et Linux sur arm64 et amd64. Rien n’est codé en dur : la CLI parle avec n’importe quel Railyard où vous vous connectez.

brew install almokhtarbr/railyard/railyard           # Homebrew
curl -fsSL https://app.railyard.run/install.sh | sh   # one-line installer (verifies the sha256)

Plus tard, au lieu de brew upgrade :

railyard upgrade   # replaces this binary with the newest build your Railyard serves
railyard version   # prints the installed build

Connexion

railyard login

Confirm code ABCD2345 in your browser: https://app.railyard.run/cli/auth/ABCD2345
Logged in to https://app.railyard.run

C’est le flux d’authentification par appareil (même idée que gh auth login ou fly auth login) : la CLI ouvre cette URL dans votre navigateur, vous tapez le code affiché dans le terminal dans le tableau de bord déjà connecté, et la CLI récupère un jeton créé pour vous (jamais de mot de passe ni de jeton tapé dans le terminal). Elle se connecte à app.railyard.run; définissez RAILYARD_API pour la faire pointer ailleurs.

Vos jetons d’API, clés SSH, comptes cloud et fournisseurs Git sont réunis sur une seule page du tableau de bord : Paramètres → Access & tokens (app.railyard.run/access).

railyard whoami    # team, token scope, limits (alias: me)
railyard logout    # forget the saved token

Configuration et CI

Le jeton et l’URL de l’API sont enregistrés dans ~/.railyard/config.json (mode 0600). Pour la CI ou les conteneurs, sautez login et définissez plutôt des variables d’environnement; elles l’emportent toujours sur le fichier :

Variable	Remplace
RAILYARD_API (ou RAILYARD_API_URL)	l’URL du control plane
RAILYARD_TOKEN	le jeton porteur
RAILYARD_CONFIG	le chemin du fichier de configuration (par défaut ~/.railyard/config.json)

--json sur n’importe quelle commande affiche la réponse brute de l’API au lieu d’un tableau.

Lier une application à un répertoire

cd my-app && railyard link my-app   # writes ./.railyard.json: {"app": "my-app"}
railyard deploy --follow            # app argument now optional in this directory
railyard unlink

Les commandes qui prennent [app] se replient sur l’application liée, trouvée en remontant depuis le répertoire courant jusqu’au premier .railyard.json. Partout ailleurs, <app> est un id ou un nom (un préfixe non ambigu fonctionne aussi).

Complétion du shell

railyard completion zsh  > "${fpath[1]}/_railyard"
railyard completion bash > /etc/bash_completion.d/railyard
railyard completion fish > ~/.config/fish/completions/railyard.fish

Applications

railyard apps
railyard app [app]
railyard open [app]
railyard create <name> <git-url> [flags]
railyard templates [--verified]
railyard launch <template> [--server id]
railyard clone [app]
railyard promote [app]

• apps : id · name · dernier statut de déploiement · url, une par ligne.
• app : le JSON complet pour une application.
• open : affiche et ouvre l’URL de l’application dans votre navigateur.
• Options de create : --server <id|hostname>, --ref <branch>, --port <n> (détecté depuis le dépôt si omis), --addons postgres,redis,…, --db-extensions <ext,…>.
• templates : le catalogue en un clic; launch en déploie un maintenant.
• clone : copie l’application dans une copie de staging; promote livre la release d’une application de staging en production (comme les pipelines Heroku).

railyard create my-app https://github.com/me/my-app --ref main --port 3000
railyard clone my-app && railyard promote my-app-staging

Déploiements

railyard deploy [app] [flags]
railyard deploys [--app <app>] [--status <s>]
railyard deploy:logs <id> [--follow]
railyard deploy:approve|reject|cancel <deploy-id>
railyard releases [app]
railyard rollback <app> <version> [--code-only] [--message "note"]
railyard deploy-window <app> off | <mon,tue,...> <09:00> <17:00> [zone]

Options de deploy : --ref <branch|tag|sha> déploie cette référence une fois sans changer la branche suivie, --message "note", --follow diffuse le log de build et de release, --force saute les vérifications de premier déploiement, --at <ISO 8601> le planifie (annulez avec deploy:cancel), --anyway déploie hors de la fenêtre de déploiement.

deploy --local construit le répertoire courant avec votre Docker au lieu du builder de l’équipe, le pousse, et déploie cette image une fois, comme fly deploy --local-only :

railyard deploy [app] --local [--image repo[:tag]]

--image pousse vers votre propre registre (votre docker login) au lieu du registre de build de l’équipe; un dépôt sans tag reçoit :local-<UTC timestamp>.

deploy-window : les push et les déploiements automatiques hors de la fenêtre attendent qu’elle s’ouvre; deploy --anyway l’outrepasse. rollback redéploie le commit d’une release antérieure et restaure ses variables d’environnement (--code-only garde celles d’aujourd’hui).

railyard deploy --ref v1.4.2 --message "hotfix" --follow
railyard rollback my-app 112 --message "bad migration"
railyard deploy-window my-app mon,tue,wed,thu,fri 09:00 17:00 America/New_York

Déploiements Git

railyard git:remote [app] [--remote name]
railyard git:strict <app> on|off

git:remote ajoute un remote git railyard qui pointe vers cette application et un assistant d’identifiants git qui répond avec votre jeton, donc git push railyard main déploie exactement ce commit et renvoie le log de build en continu. git:strict (activé par défaut) rejette un push dont le build échoue, donc la branche reste sur son ancien commit; off accepte d’abord le push et déploie après.

cd my-app && railyard git:remote
git push railyard main

Chaque push est limité à 1 Go. Les dépôts poussés comptent aussi dans un quota par équipe (5 Go par défaut); le dépasser rejette le push avec l’utilisation et une suggestion de supprimer les applications vers lesquelles vous ne poussez plus. Railyard exécute git gc sur les dépôts poussés chaque nuit pour les garder petits.

Exécution

railyard logs [app] [--follow] [--process web] [--tail 200]
railyard logs:search <app> <text|/regex/> [--level error] [--range 24h] [--process web]
railyard ps [app]
railyard restart [app] [--process web]
railyard run <app> [--process worker] [--exec] -- <command...>
railyard scale <app> <process>=<n> …
railyard wake [app]
railyard sleep <app> <10|30|60|360|1440|off>

run démarre un nouveau conteneur ponctuel depuis la release actuelle (comme heroku run), ou exécute dans le conteneur déjà en cours avec --exec; il diffuse la sortie et se termine avec le code de sortie de la commande distante elle-même. sleep arrête les conteneurs de l’application après ce nombre de minutes d’inactivité et wake, ou la prochaine requête, la ramène; off le désactive.

railyard logs my-app --follow --process web
railyard run my-app -- bin/rails db:migrate
railyard scale my-app web=2 worker=1
railyard sleep my-app 30

Variables de configuration et domaines

railyard env [app] [--reveal[=KEY]]
railyard env:set <app> KEY=VALUE …
railyard env:unset <app> KEY
railyard configs
railyard domains [app]
railyard domain:add <app> <hostname> [--redirect]
railyard domain:rm <app> <domain-id>

env masque les valeurs sauf avec --reveal (toutes) ou --reveal KEY (une). configs liste les entrées de configuration à l’échelle de l’équipe (lecture seule depuis la CLI).

railyard env my-app --reveal SECRET_KEY_BASE
railyard env:set my-app RAILS_ENV=production LOG_LEVEL=info
railyard domain:add my-app www.example.com --redirect

Bases de données et volumes

railyard db:query <app> "<sql>" [--write]
railyard db:backups [app]
railyard db:backup [app]
railyard db:restore <backup-id>
railyard db:url <backup-id>
railyard volumes [app]
railyard volume:backup <app> <volume-name>
railyard volume:restore <backup-id>

db:query est en lecture seule sauf avec --write (nécessite un jeton à portée write). db:url retourne un lien de téléchargement signé pour une sauvegarde.

railyard db:query my-app "select count(*) from users"
railyard db:backup my-app
railyard volume:backup my-app data

Manifeste

railyard manifest:pull [app] [--secrets] [--out railyard.yml]
railyard manifest:apply [app] <file.yml>
railyard manifest:validate [file.yml]

manifest:pull affiche l’application sous forme de railyard.yml (--secrets inclut les valeurs des variables); manifest:apply en applique un à l’application. manifest:validate vérifie un fichier local (./railyard.yml si omis) sans l’appliquer ni avoir besoin d’une application — une clé inconnue reçoit une suggestion (contaner_port → « did you mean container_port? »); se termine avec le code 0 et affiche « is valid » sans problème, ou le code 1 en les listant.

railyard manifest:pull my-app --out railyard.yml
railyard manifest:apply my-app railyard.yml
railyard manifest:validate railyard.yml

Observabilité

railyard metrics [app] [--range 1h|24h|7d|30d]
railyard autoscale <app> --max N [--min N] [--p95 ms] [--cpu %]
railyard autoscale <app> off

metrics affiche les requêtes, le p95, le taux d’erreur et les points de terminaison les plus lents. autoscale ajuste les répliques web entre --min/--max une fois que la latence p95 ou le CPU dépasse les seuils donnés; off retire les limites.

railyard metrics my-app --range 7d
railyard autoscale my-app --max 5 --min 1 --p95 300 --cpu 80

Notifications et webhooks

railyard notify
railyard webhooks

Listes à l’échelle de l’équipe des règles de notification et des points de terminaison webhook (lecture seule depuis la CLI; créez-les et modifiez-les depuis le tableau de bord).

Serveurs

railyard servers
railyard server <id>
railyard server:cordon <server-id>
railyard server:uncordon <server-id>
railyard server:reboot <server-id>
railyard server:power-cycle <server-id>
railyard server:prune <server-id>
railyard server:resize <server-id> <size>

cordon empêche que de nouvelles applications soient placées sur un serveur sans déplacer ce qui s’y trouve déjà; prune nettoie les images et volumes Docker inutilisés.

railyard server:cordon srv-7
railyard server:resize srv-7 s-4vcpu-8gb

Réseau

railyard tunnel [app] [web|db|postgres|redis|<process>] [-p local-port]

Alias : proxy. Transfère un port local vers un conteneur ou une base de données sur le serveur de l’application, comme fly proxy / railway connect. Écoute sur localhost (le port distant par défaut); un tunnel de base de données affiche une URL postgres://…@localhost:<port>/… prête à l’emploi. Rien n’est ouvert vers l’internet : les octets voyagent CLI → control plane (votre jeton) → agent → conteneur.

railyard tunnel my-app db -p 5433

Recherche et importations

railyard search:reindex [app]
railyard import

search:reindex exécute la commande de réindexation de l’application dans un nouveau conteneur ponctuel. import ouvre l’importateur Heroku/Render/Fly dans votre navigateur.

Codes de sortie

0 ok · 2 l’API a retourné une erreur (message sur stderr) · 3 non connecté ou mauvais usage · 64 mauvais usage de commande. railyard run se termine plutôt avec le code de sortie de la commande distante elle-même.

Voir aussi

• docs/API.md : l’API REST avec laquelle la CLI communique.