--- title: "Eseguire, monitorare e pagare un'app con erpc worker" description: "Vedi se l'app gira e quanto costa all'ora, torna a una release precedente, misura la latenza RPC dal server, salva i dati di stato e termina gli addebiti orari." canonical: "https://erpc.global/it/doc/erpc-cli/worker-status-and-billing/" locale: "it" --- # 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 ```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` 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 ` | 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 ` | 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 ` (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](https://erpc.global/it/price/) e nella [ERPC Web Dashboard](https://dashboard.erpc.global/it). - **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..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](https://erpc.global/it/doc/erpc-cli/worker-troubleshooting/#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 ` 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:////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-`. 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-- --path /var/lib/private/erpc-worker- --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 ` indica un altro vault, e `deploy --inline` tiene i dati in `erpc.toml`.