---
title: "Eine Anwendung mit erpc worker betreiben, überwachen und bezahlen"
description: "Sehen, ob Ihre Anwendung läuft und was sie pro Stunde kostet, Release zurückrollen, RPC-Latenz vom Server messen, Zustand sichern, stündliche Kosten beenden."
canonical: "https://erpc.global/de/doc/erpc-cli/worker-status-and-billing/"
locale: "de"
---

# 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

```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` 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](https://erpc.global/de/price/) und im [ERPC Web Dashboard](https://dashboard.erpc.global/de).
- **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](https://erpc.global/de/doc/erpc-cli/worker-troubleshooting/#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
```

- `--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
```

## 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`.
