Eseguire, monitorare e pagare un'app con erpc worker

erpc worker status mostra se la tua app è in esecuzione e quanto costa all'ora. Ogni avvio mostra prima il suo prezzo, e erpc worker delete --release-server termina le linee gRPC, Shreds e Unlimited RPC che l'app usa a ore, poi il suo server orario.

Questa pagina descrive ERPC CLI v0.1.0-rc.4, una versione pre-release.

Controllare un'app

$ 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 mostra se l'app è bloccata o in esecuzione, quale release e da quando. Quando hai effettuato l'accesso, mostra anche quanto costa l'ambiente all'ora, ogni voce con il prezzo che viene addebitato al tuo account, e il credito del tuo account con quanto durerà. --json riporta le stesse informazioni sotto hourly.charged.

Una voce che non è tra gli addebiti dell'account viene indicata come non presente tra di essi, non come terminata, perché quell'elenco può essere in ritardo di un minuto rispetto a un avvio. Senza una sessione, o quando gli addebiti del tuo account non si possono leggere, status riporta ciò che resta registrato.

Gestire l'app

Comando	Cosa fa
`erpc worker logs -n 200`, `logs -f`	Il log dell'app e dell'agente. Un carattere di controllo in una riga viene stampato come `?`
`erpc worker start`	Avvia l'app, inviando la chiave quando il worker è bloccato
`erpc worker stop`, `stop --lock`	La ferma; `--lock` toglie anche la chiave dalla memoria
`erpc worker restart`	La ferma e la avvia di nuovo
`erpc worker releases`	Le release conservate sul server (`deploy.keep_releases`)
`erpc worker rollback`, `rollback --to <release>`	Torna alla release precedente, o a quella indicata. Viene rifiutato, lasciando invariata la release in uso, quando la porta di health check di quella release appartiene ora a un altro worker in esecuzione
`erpc worker api <PATH>`	Legge l'API dell'app da questa macchina, mentre l'API resta sul loopback del server (`-X POST`, `-d '{...}'` per una modifica)
`erpc worker trades [--profit]`	Le operazioni di trading dell'app sul suo server
`erpc worker list`	Le app su questa macchina e dove è distribuita ciascuna; `--prune` toglie quelle il cui `erpc.toml` non esiste più

Il valore API_TOKEN dell'app viene letto qui e raggiunge il server tramite standard input, mai su una riga di comando né in un journal. Ogni comando del worker accetta --env <name> (predefinito default) e --json, tranne secret unlock e secret lock, che riguardano il keystore di questa macchina e non un'app, e non accettano --env. Eseguito da qualsiasi posizione, un comando trova la sua app tramite il nome con cui erpc la conosce; secret put, secret rm, key import, firewall allow e firewall deny accettano l'app solo tramite --dir.

Come funzionano gli addebiti orari

Ogni avvio mostra prima il suo prezzo. In un terminale, un avvio avviene solo dopo un sì; con --yes, la riga di comando che nomina ciò che va avviato vale come sì.
Un prodotto orario si paga con ERPC Credit, che si acquista in anticipo, e un avvio che il credito non copre viene rifiutato. I prezzi sono su Prezzi e nella ERPC Web Dashboard.
Un nuovo VPS viene registrato non appena ha un nome, prima di essere pronto. La distribuzione successiva lo riprende invece di acquistarne un altro.
Per deploy, un avvio che non ha ricevuto risposta viene inviato di nuovo, mai come nuovo avvio. La sua chiave di richiesta resta registrata ([env.<name>.starting]), quindi eseguire di nuovo lo stesso comando invia la stessa richiesta. Dopo alcune risposte resta lì finché non la rimuovi a mano (Un acquisto che erpc non riesce a registrare). erpc worker run non registra nulla, quindi la sua esecuzione successiva fa una nuova richiesta.
Distribuisci un ambiente alla volta. Due distribuzioni dello stesso ambiente avviate insieme possono acquistare due volte, e questo non è supportato.
Se una linea esiste ancora lo decide ciò che viene addebitato all'account. Una linea non fatturata a ore non viene mai terminata da erpc: terminala nella dashboard.

Rimuovere un'app

erpc worker delete rimuove il worker. erpc worker delete --release-server termina anche le sue linee, poi il suo server orario. Ciò che non è stato possibile terminare resta registrato, e una linea non fatturata a ore viene indicata per nome, da terminare nella dashboard.

Un delete semplice rifiuta un VPS acquistato e mai raggiunto, perché lo dimenticherebbe mentre è ancora addebitato. Un delete semplice di un VPS orario già raggiunto lo toglie dal registro mentre è ancora addebitato, e lo segnala con un avviso.
Con --forget, erpc non tenta di raggiungere un server che non è più raggiungibile, e --forget-line <id> toglie dal registro una linea terminata al di fuori di erpc.

Misurare la latenza RPC dal server

erpc worker bench cronometra le chiamate RPC dal server dell'ambiente: l'RPC condiviso di ERPC, il suo Unlimited RPC e qualsiasi altro, uno accanto all'altro. L'agente sul server cronometra ogni chiamata, quindi i numeri sono quelli che ottiene l'app.

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 accetta getSlot, getBlockHeight, getLatestBlockhash o getHealth.
--no-shared esclude l'RPC condiviso. Un valore di --url può essere l'URL stesso, un riferimento op://…, keychain:… o keystore:… (al punto in cui è conservato un URL che contiene una chiave; mai alla voce della chiave di trading, che viene rifiutata), oppure - (letto dallo standard input, oppure chiesto e digitato senza che venga mostrato). Più di sei endpoint vengono rifiutati.
Il bench stampa p50, p90, p99, minimo e massimo, gli errori con il primo motivo, e di quanti slot ogni risposta era indietro rispetto alla più aggiornata dello stesso round.
Le chiavi raggiungono il server solo tramite standard input, e la tabella mostra schema, host e porta.

Fare il backup dei dati di stato dell'app

erpc worker backup on esegue ogni giorno il backup dei dati di stato dell'app su ERPC Global Storage, cifrato da restic, all'orario --at del server ed entro i 30 minuti successivi. Serve un piano storage (erpc storage buy 5).

Ciò che finisce nel backup sono i dati di stato dell'app, /var/lib/private/erpc-worker-<id>. Le release no, perché una distribuzione le rimette al loro posto. I dati di Redis e PostgreSQL non sono coperti.
Il server non può eliminare gli snapshot. Non possiede mai la sessione di erpc, la chiave di amministrazione dell'account né la sua password master.
Un server compromesso può leggere gli snapshot di tutte le macchine dell'account, compresi quelli di questa macchina; conservare dopo off la chiave del repository, che restic non cambia mai; aggiungere snapshot con il nome di un'altra macchina, quindi dopo un caso del genere controlla cosa sceglie restore latest; e riempire lo storage dell'account, il che ferma i backup di tutte le macchine. erpc worker backup off revoca per prima cosa la chiave di accesso del server, che il server risponda o no.
restic copia i file così come sono mentre il worker è in esecuzione, quindi un database può aver bisogno di un proprio dump per essere ripristinato in modo coerente. Un'esecuzione saltata mentre il server era spento viene eseguita quando torna attivo.
erpc worker backup off, status e now fermano il backup, ne riportano lo stato e lo eseguono. Gli snapshot restano dopo off, e erpc backup prune --host sfoltisce quelli vecchi.

Ripristina da questa macchina, dopo aver eseguito erpc backup init su di essa:

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

Più ambienti e più macchine

Più worker su un server vengono eseguiti ciascuno come unità propria, condividono la tabella del firewall del server e ognuno apre solo la propria porta.
Un'app può avere più ambienti ([env.staging], [env.prod]), ciascuno con il proprio server e le proprie linee.
Un ambiente può tenere i dati del proprio server in 1Password invece che in erpc.toml. In quel caso qualsiasi macchina che ha effettuato l'accesso a quel vault, con il repository dell'app, può eseguire ogni comando; per i riferimenti keychain: e keystore: in un'app di questo tipo viene mostrato un avviso, perché un'altra macchina non può leggerli. Un nuovo ambiente tiene i propri dati in 1Password quando erpc login tiene lì la sessione; deploy --vault <vault-id> indica un altro vault, e deploy --inline tiene i dati in erpc.toml.