Eine Anwendung mit erpc worker betreiben, überwachen und bezahlen

erpc worker status zeigt, ob Ihre Anwendung läuft und was sie pro Stunde kostet. Jeder Start zeigt zuerst seinen Preis, und erpc worker delete --release-server beendet gRPC, Shreds und Unlimited RPC, die die Anwendung stündlich abgerechnet nutzt, und danach ihren stündlich abgerechneten Server.

Diese Seite beschreibt ERPC CLI v0.1.0-rc.4, eine Vorabversion.

Eine Anwendung prüfen

$ 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 zeigt, ob die Anwendung gesperrt ist oder läuft, welches Release und seit wann. Wenn Sie angemeldet sind, zeigt es außerdem, was die Umgebung pro Stunde kostet, jeden Posten mit dem Preis, der Ihrem Konto dafür berechnet wird, sowie das Guthaben Ihres Kontos und wie lange es reicht. --json liefert dasselbe unter hourly.charged.

Ein Posten, der nicht unter den abgerechneten Posten des Kontos steht, wird als nicht darunter gemeldet und nicht als beendet bezeichnet, weil diese Liste einem Start um eine Minute hinterherhinken kann. Ohne Sitzung oder wenn die abgerechneten Posten Ihres Kontos nicht gelesen werden können, zeigt status, was festgehalten ist.

Die Anwendung steuern

Befehl	Was er tut
`erpc worker logs -n 200`, `logs -f`	Das Log der Anwendung und des Agenten. Ein Steuerzeichen in einer Zeile wird als `?` ausgegeben
`erpc worker start`	Startet die Anwendung und sendet den Schlüssel, wenn der Worker gesperrt ist
`erpc worker stop`, `stop --lock`	Stoppt sie; `--lock` entfernt außerdem den Schlüssel aus dem Arbeitsspeicher
`erpc worker restart`	Stoppt sie und startet sie erneut
`erpc worker releases`	Die auf dem Server behaltenen Releases (`deploy.keep_releases`)
`erpc worker rollback`, `rollback --to <release>`	Geht zum vorherigen Release zurück oder zum genannten. Wird abgelehnt, und das laufende Release bleibt unverändert, wenn der Health-Check-Port dieses Releases jetzt einem anderen laufenden Worker gehört
`erpc worker api <PATH>`	Liest die API der Anwendung von diesem Rechner aus, während die API auf dem Loopback des Servers bleibt (`-X POST`, `-d '{...}'` für eine Änderung)
`erpc worker trades [--profit]`	Die Trades der Anwendung auf ihrem Server
`erpc worker list`	Die Anwendungen auf diesem Rechner und wo jede bereitgestellt ist; `--prune` entfernt die, deren `erpc.toml` nicht mehr existiert

Das API_TOKEN der Anwendung wird hier gelesen und erreicht den Server über die Standardeingabe, auf keiner Befehlszeile und in keinem Journal. Jeder Worker-Befehl akzeptiert --env <name> (Standard default) und --json, außer dass secret unlock und secret lock, die den Keystore dieses Rechners betreffen und keine Anwendung, kein --env akzeptieren. Von überall aus gestartet, findet ein Befehl seine Anwendung unter dem Namen, unter dem erpc sie kennt; secret put, secret rm, key import, firewall allow und firewall deny nehmen die Anwendung nur über --dir entgegen.

So funktionieren stündliche Kosten

Jeder Start zeigt zuerst seinen Preis. An einem Terminal erfolgt ein Start nur nach einem Ja; mit --yes ist die Befehlszeile, die nennt, was gestartet wird, das Ja.
Ein stündlich abgerechnetes Produkt wird aus ERPC Credit bezahlt, das vorab gekauft wird, und ein Start, den das Guthaben nicht deckt, wird abgelehnt. Die Preise stehen auf der Seite Preise und im ERPC Web Dashboard.
Ein neuer VPS wird festgehalten, sobald er benannt ist, noch bevor er bereit ist. Die nächste Bereitstellung übernimmt ihn, statt einen weiteren zu kaufen.
Bei deploy wird ein Start, auf den keine Antwort kam, erneut gesendet, nie als neuer. Sein Anfrageschlüssel bleibt festgehalten ([env.<name>.starting]), sodass derselbe Befehl, erneut ausgeführt, dieselbe Anfrage sendet. Nach manchen Antworten bleibt er, bis Sie ihn von Hand entfernen (Ein Kauf, den erpc nicht festhalten kann). erpc worker run hält nichts fest, daher stellt sein nächster Lauf eine neue Anfrage.
Stellen Sie jeweils nur eine Umgebung bereit. Zwei gleichzeitig gestartete Bereitstellungen derselben Umgebung können doppelt kaufen, und das wird nicht unterstützt.
Ob eine Leitung noch existiert, entscheidet sich daran, was dem Konto berechnet wird. Eine nicht stündlich abgerechnete Leitung wird von erpc nie beendet: Beenden Sie sie im Dashboard.

Eine Anwendung entfernen

erpc worker delete entfernt den Worker. erpc worker delete --release-server beendet außerdem seine Leitungen, danach seinen stündlich abgerechneten Server. Was nicht beendet werden konnte, bleibt festgehalten, und eine nicht stündlich abgerechnete Leitung wird genannt, damit Sie sie im Dashboard beenden.

Ein einfaches Löschen lehnt einen VPS ab, der gekauft und nie erreicht wurde, da es ihn vergessen würde, während er berechnet wird. Ein einfaches Löschen eines erreichten, stündlich abgerechneten VPS entfernt dessen Eintrag, während er noch berechnet wird, und warnt davor.
--forget versucht nicht, einen nicht mehr erreichbaren Server zu erreichen, und --forget-line <id> entfernt den Eintrag einer außerhalb von erpc beendeten Leitung.

RPC-Latenz vom Server messen

erpc worker bench misst die Dauer von RPC-Aufrufen vom Server der Umgebung aus: den Shared RPC von ERPC, seinen Unlimited RPC und beliebige andere, nebeneinander. Der Agent auf dem Server misst jeden Aufruf, die Zahlen sind also das, was die Anwendung erhält.

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 akzeptiert getSlot, getBlockHeight, getLatestBlockhash oder getHealth.
--no-shared lässt den Shared RPC weg. Ein --url-Wert kann die URL selbst sein, eine op://…-, keychain:…- oder keystore:…-Referenz (auf den Ort, an dem eine URL mit einem Schlüssel darin aufbewahrt ist; nie auf den Eintrag des Trading-Schlüssels, der abgelehnt wird) oder - (über die Standardeingabe gelesen oder verdeckt abgefragt). Mehr als sechs Endpunkte werden abgelehnt.
Der Benchmark gibt p50, p90, p99, Minimum und Maximum aus, Fehlschläge mit dem ersten Grund und wie viele Slots jede Antwort hinter der aktuellsten derselben Runde lag.
Schlüssel erreichen den Server nur über die Standardeingabe, und die Tabelle zeigt Schema, Host und Port.

Den Zustand der Anwendung sichern

erpc worker backup on sichert den Zustand der Anwendung jeden Tag in ERPC Global Storage, verschlüsselt mit restic, um --at Serverzeit und innerhalb von 30 Minuten danach. Ein Speicherplan ist nötig (erpc storage buy 5).

Gesichert wird der Zustand der Anwendung, /var/lib/private/erpc-worker-<id>. Die Releases nicht, da eine Bereitstellung sie zurückbringt. Redis- und PostgreSQL-Daten sind nicht abgedeckt.
Der Server kann keine Snapshots löschen. Er hält nie die erpc-Sitzung, den Admin-Schlüssel des Kontos oder dessen Master-Passwort.
Ein übernommener Server kann die Snapshots jedes Rechners im Konto lesen, auch die dieses Rechners; den Schlüssel des Repositorys, den restic nie ändert, nach off behalten; Snapshots unter dem Namen eines anderen Rechners hinzufügen, prüfen Sie also danach, was restore latest auswählt; und den Speicher des Kontos füllen, was die Backups jedes Rechners stoppt. erpc worker backup off widerruft zuerst den Zugriffsschlüssel des Servers, ob der Server antwortet oder nicht.
restic kopiert Dateien so, wie sie sind, während der Worker läuft, sodass eine Datenbank für eine konsistente Wiederherstellung einen eigenen Dump brauchen kann. Ein Lauf, der verpasst wurde, während der Server aus war, läuft, sobald er wieder da ist.
erpc worker backup off, status und now stoppen das Backup, berichten darüber und führen es aus. Die Snapshots bleiben nach off erhalten, und erpc backup prune --host dünnt alte aus.

Stellen Sie von diesem Rechner aus wieder her, nachdem Sie dort erpc backup init ausgeführt haben:

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

Mehrere Umgebungen und Rechner

Mehrere Worker auf einem Server laufen jeweils als eigene Unit, teilen sich die Firewall-Tabelle des Servers, und jeder öffnet nur seinen eigenen Port.
Eine Anwendung kann mehrere Umgebungen haben ([env.staging], [env.prod]), jede mit eigenem Server und eigenen Leitungen.
Eine Umgebung kann ihre Serverdaten in 1Password statt in erpc.toml halten. Dann kann jeder Rechner, der bei diesem Tresor angemeldet ist und das Repository der Anwendung hat, jeden Befehl ausführen; vor keychain:- und keystore:-Referenzen in einer solchen Anwendung wird gewarnt, da ein anderer Rechner sie nicht lesen kann. Eine neue Umgebung hält ihre Daten in 1Password, wenn erpc login die Sitzung dort hält; deploy --vault <vault-id> nennt einen anderen Tresor, und deploy --inline hält die Daten in erpc.toml.