--- title: "Exécuter, surveiller et payer une application avec erpc worker" description: "Voir si l'application tourne et son coût horaire, faire un rollback, mesurer la latence RPC côté serveur, sauvegarder son état, mettre fin à ses frais horaires." canonical: "https://erpc.global/fr/doc/erpc-cli/worker-status-and-billing/" locale: "fr" --- # 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 ```text $ 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 ` | 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 ` | 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 ` (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](https://erpc.global/fr/price/) et dans l'[ERPC Web Dashboard](https://dashboard.erpc.global/fr). - **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..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](https://erpc.global/fr/doc/erpc-cli/worker-troubleshooting/#un-achat-querpc-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 ` 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:////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-`. 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-- --path /var/lib/private/erpc-worker- --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 ` désigne un autre coffre, et `deploy --inline` conserve les informations dans `erpc.toml`.