Exécuter, surveiller et payer une application avec erpc worker

erpc worker status indique si votre application tourne et ce qu'elle coûte à l'heure. Chaque démarrage affiche d'abord son prix, et erpc worker delete --release-server met fin aux gRPC, Shreds et Unlimited RPC que l'application utilise à l'heure, puis à son serveur horaire.

Cette page décrit ERPC CLI v0.1.0-rc.4, une préversion.

Vérifier une application

$ erpc worker status --env prod
api-prod on 203.0.113.10: running, release 20261101T093000Z-1a2b3c4d, pid 4217, up 2h 14m
  current 20261101T093000Z-1a2b3c4d, previous 20261028T171500Z-9f8e7d6c, 2 releases kept
  WAF: listening on port 8080, forwarding to 127.0.0.1:3000, since 2026-11-01T09:30:12Z; requests 5120, forwarded 5043, blocked 71, connections refused 12, app errors 6, addresses banned now 1
  `erpc worker delete --release-server --env prod` ends what this app is charged for.

$ erpc worker status --env prod
api-prod on 203.0.113.10: running, release 20261101T093000Z-1a2b3c4d, pid 4217, up 2h 14m
  current 20261101T093000Z-1a2b3c4d, previous 20261028T171500Z-9f8e7d6c, 2 releases kept
  WAF: listening on port 8080, forwarding to 127.0.0.1:3000, since 2026-11-01T09:30:12Z; requests 5120, forwarded 5043, blocked 71, connections refused 12, app errors 6, addresses banned now 1
  `erpc worker delete --release-server --env prod` ends what this app is charged for.

status indique si l'application est verrouillée ou en cours d'exécution, quelle release, et depuis quand. Lorsque vous êtes connecté, il affiche aussi ce que l'environnement coûte à l'heure, chaque élément avec le prix facturé à votre compte, ainsi que le crédit de votre compte et la durée qu'il couvre. --json contient les mêmes informations sous hourly.charged.

Un élément qui ne figure pas parmi les frais du compte est signalé comme n'y figurant pas, et non comme ayant pris fin, car cette liste peut avoir une minute de retard sur un démarrage. Sans session, ou lorsque les frais de votre compte ne peuvent pas être lus, status indique ce qui est consigné.

Piloter l'application

Commande	Ce qu'elle fait
`erpc worker logs -n 200`, `logs -f`	Le log de l'application et de l'agent. Un caractère de contrôle dans une ligne est affiché sous la forme `?`
`erpc worker start`	Exécute l'application, en envoyant la clé lorsque le worker est verrouillé
`erpc worker stop`, `stop --lock`	L'arrête ; `--lock` retire aussi la clé de la mémoire
`erpc worker restart`	L'arrête et la redémarre
`erpc worker releases`	Les releases conservées sur le serveur (`deploy.keep_releases`)
`erpc worker rollback`, `rollback --to <release>`	Revient à la release précédente, ou à celle indiquée. Refusé, la release en service restant telle quelle, lorsque le port du contrôle de santé de cette release appartient désormais à un autre worker en cours d'exécution
`erpc worker api <PATH>`	Lit l'API de l'application depuis cette machine, l'API restant sur le loopback du serveur (`-X POST`, `-d '{...}'` pour une modification)
`erpc worker trades [--profit]`	Les trades de l'application sur son serveur
`erpc worker list`	Les applications de cette machine et l'endroit où chacune est déployée ; `--prune` retire celles dont le `erpc.toml` a disparu

Le API_TOKEN de l'application est lu ici et parvient au serveur par l'entrée standard, sur aucune ligne de commande et dans aucun journal. Chaque commande worker accepte --env <name> (par défaut default) et --json, à ceci près que secret unlock et secret lock, qui concernent le keystore de cette machine et non une application, n'acceptent pas --env. Lancée depuis n'importe où, une commande trouve son application par le nom sous lequel erpc la connaît ; secret put, secret rm, key import, firewall allow et firewall deny ne prennent l'application que par --dir.

Comment fonctionnent les frais horaires

Chaque démarrage affiche d'abord son prix. Dans un terminal, un démarrage n'a lieu qu'après un oui ; avec --yes, la ligne de commande qui nomme ce qu'il faut démarrer vaut oui.
Un produit horaire est payé en ERPC Credits, achetés à l'avance, et un démarrage que le crédit ne couvre pas est refusé. Les prix figurent sur la page Tarifs et dans l'ERPC Web Dashboard.
Un nouveau VPS est consigné dès qu'il est nommé, avant d'être prêt. Le déploiement suivant le reprend au lieu d'en acheter un autre.
Pour deploy, un démarrage resté sans réponse est renvoyé, jamais comme un nouveau démarrage. Sa clé de requête reste consignée ([env.<name>.starting]), si bien que relancer la même commande envoie la même requête. Après certaines réponses, elle reste jusqu'à ce que vous la retiriez à la main (Un achat qu'erpc ne peut pas consigner). erpc worker run ne consigne rien, si bien que son exécution suivante fait une nouvelle requête.
Déployez un environnement à la fois. Deux déploiements du même environnement lancés ensemble peuvent en acheter deux, ce qui n'est pas pris en charge.
C'est ce qui est facturé au compte qui détermine si une ligne existe encore. erpc ne met jamais fin à une ligne non facturée à l'heure : mettez-y fin dans le tableau de bord.

Retirer une application

erpc worker delete retire le worker. erpc worker delete --release-server met aussi fin à ses lignes, puis à son serveur horaire. Ce à quoi il n'a pas pu être mis fin reste consigné, et une ligne non facturée à l'heure est nommée, pour que vous y mettiez fin dans le tableau de bord.

Une suppression simple refuse un VPS acheté et jamais joint, puisqu'elle l'oublierait alors qu'il est facturé. Une suppression simple d'un VPS horaire déjà joint le retire du registre alors qu'il est encore facturé, et en avertit.
--forget ne tente pas de joindre un serveur devenu injoignable, et --forget-line <id> retire du registre une ligne à laquelle on a mis fin en dehors d'erpc.

Mesurer la latence RPC depuis le serveur

erpc worker bench chronomètre des appels RPC depuis le serveur de l'environnement : le RPC partagé d'ERPC, son Unlimited RPC, et tout autre, côte à côte. L'agent sur le serveur chronomètre chaque appel, si bien que les chiffres sont ceux qu'obtient l'application.

bash

erpc worker bench                                  # getSlot: shared RPC vs the Unlimited RPC
erpc worker bench --rounds 300 --interval 150      # for a plan that limits calls per second
erpc worker bench --url other=op://<vault-id>/<item-id>/url   # another provider's RPC

erpc worker bench                                  # getSlot: shared RPC vs the Unlimited RPC
erpc worker bench --rounds 300 --interval 150      # for a plan that limits calls per second
erpc worker bench --url other=op://<vault-id>/<item-id>/url   # another provider's RPC

--method accepte getSlot, getBlockHeight, getLatestBlockhash ou getHealth.
--no-shared exclut le RPC partagé. Une valeur de --url peut être l'URL elle-même, une référence op://…, keychain:… ou keystore:… (vers l'endroit où est conservée une URL contenant une clé ; jamais vers l'entrée de la clé de trading, qui est refusée), ou - (lue depuis l'entrée standard, ou demandée et saisie sans affichage). Plus de six endpoints sont refusés.
Le bench affiche p50, p90, p99, min et max, les échecs avec la première raison, et le nombre de slots de retard de chaque réponse sur la plus récente du même tour.
Les clés ne parviennent au serveur que par l'entrée standard, et le tableau affiche le schéma, l'hôte et le port.

Sauvegarder l'état de l'application

erpc worker backup on sauvegarde l'état de l'application chaque jour sur ERPC Global Storage, chiffré par restic, à l'heure --at du serveur et dans les 30 minutes qui suivent. Un forfait de stockage est nécessaire (erpc storage buy 5).

Ce qui est sauvegardé, c'est l'état de l'application, /var/lib/private/erpc-worker-<id>. Les releases ne le sont pas, puisqu'un déploiement les remet en place. Les données Redis et PostgreSQL ne sont pas couvertes.
Le serveur ne peut pas supprimer de snapshots. Il ne détient jamais la session erpc, la clé d'administration du compte ni son mot de passe maître.
Un serveur compromis peut lire les snapshots de toutes les machines du compte, y compris ceux de cette machine ; conserver après off la clé du dépôt, que restic ne change jamais ; ajouter des snapshots sous le nom d'une autre machine, vérifiez donc ce que choisit restore latest ensuite ; et remplir le stockage du compte, ce qui arrête les sauvegardes de toutes les machines. erpc worker backup off révoque d'abord la clé d'accès du serveur, que le serveur réponde ou non.
restic copie les fichiers tels quels pendant que le worker tourne, si bien qu'une base de données peut avoir besoin de son propre dump pour être restaurée de façon cohérente. Une exécution manquée pendant que le serveur était éteint a lieu à son retour.
erpc worker backup off, status et now arrêtent la sauvegarde, en rendent compte et la lancent. Les snapshots restent après off, et erpc backup prune --host élague les anciens.

Restaurez depuis cette machine, après erpc backup init sur celle-ci :

bash

erpc backup restore latest --from-host erpc-worker-<id>-<tag> --path /var/lib/private/erpc-worker-<id> --target ./restored

erpc backup restore latest --from-host erpc-worker-<id>-<tag> --path /var/lib/private/erpc-worker-<id> --target ./restored

Plusieurs environnements et machines

Plusieurs workers sur un même serveur tournent chacun dans leur propre unité, partagent la table du pare-feu du serveur, et chacun n'ouvre que son propre port.
Une application peut avoir plusieurs environnements ([env.staging], [env.prod]), chacun avec son serveur et ses lignes.
Un environnement peut conserver les informations de son serveur dans 1Password au lieu de erpc.toml. Toute machine connectée à ce coffre, avec le dépôt de l'application, peut alors exécuter toutes les commandes ; les références keychain: et keystore: d'une telle application font l'objet d'un avertissement, puisqu'une autre machine ne peut pas les lire. Un nouvel environnement conserve ses informations dans 1Password lorsque erpc login y conserve la session ; deploy --vault <vault-id> désigne un autre coffre, et deploy --inline conserve les informations dans erpc.toml.