Ejecuta, supervisa y paga una aplicación con erpc worker

erpc worker status muestra si tu aplicación se está ejecutando y cuánto cuesta por hora. Cada inicio muestra primero su precio, y erpc worker delete --release-server finaliza el gRPC, Shreds y Unlimited RPC que la aplicación usa por horas y, después, su servidor por horas.

Esta página describe ERPC CLI v0.1.0-rc.4, una versión preliminar.

Comprobar una aplicación

$ 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 muestra si la aplicación está bloqueada o en ejecución, qué release y desde cuándo. Cuando has iniciado sesión, también muestra cuánto cuesta el entorno por hora, cada elemento con el precio que se cobra a tu cuenta por él, y el crédito de tu cuenta y cuánto tiempo durará. --json incluye lo mismo en hourly.charged.

De un elemento que no está entre los cargos de la cuenta se dice que no está entre ellos, no que ha finalizado, porque esa lista puede ir un minuto por detrás de un inicio. Sin sesión, o cuando no se pueden leer los cargos de tu cuenta, status indica lo que hay registrado.

Controlar la aplicación

Comando	Qué hace
`erpc worker logs -n 200`, `logs -f`	El log de la aplicación y del agente. Un carácter de control en una línea se imprime como `?`
`erpc worker start`	Ejecuta la aplicación, enviando la clave cuando el worker está bloqueado
`erpc worker stop`, `stop --lock`	La detiene; `--lock` además quita la clave de la memoria
`erpc worker restart`	La detiene y la vuelve a iniciar
`erpc worker releases`	Las releases que se conservan en el servidor (`deploy.keep_releases`)
`erpc worker rollback`, `rollback --to <release>`	Vuelve a la release anterior, o a la indicada. Se rechaza, dejando la release en uso como estaba, cuando el puerto de la comprobación de salud de esa release es ahora el de otro worker en ejecución
`erpc worker api <PATH>`	Lee la API de la aplicación desde esta máquina, con la API todavía en el loopback del servidor (`-X POST`, `-d '{...}'` para un cambio)
`erpc worker trades [--profit]`	Las operaciones de la aplicación en su servidor
`erpc worker list`	Las aplicaciones de esta máquina y dónde está desplegada cada una; `--prune` quita aquellas cuyo `erpc.toml` ya no existe

El API_TOKEN de la aplicación se lee aquí y llega al servidor por la entrada estándar, sin pasar por ninguna línea de comandos ni por ningún journal. Todos los comandos de worker aceptan --env <name> (predeterminado default) y --json, salvo secret unlock y secret lock, que se refieren al keystore de esta máquina y no a una aplicación, y no aceptan --env. Ejecutado desde cualquier sitio, un comando encuentra su aplicación por el nombre con el que erpc la conoce; secret put, secret rm, key import, firewall allow y firewall deny toman la aplicación solo por --dir.

Cómo funcionan los cargos por horas

Cada inicio muestra primero su precio. En un terminal, un inicio solo se produce tras un sí; con --yes, la línea de comandos que nombra lo que se va a iniciar es el sí.
Un producto por horas se paga con ERPC Credit, que se compra por adelantado, y se rechaza un inicio que el crédito no cubre. Los precios están en la página Precios y en el ERPC Web Dashboard.
Un VPS nuevo queda registrado en cuanto se nombra, antes de estar listo. El siguiente despliegue lo retoma en lugar de comprar otro.
En deploy, un inicio que no obtuvo respuesta se vuelve a enviar, nunca como uno nuevo. Su clave de solicitud sigue registrada ([env.<name>.starting]), así que ejecutar de nuevo el mismo comando envía la misma solicitud. Tras algunas respuestas sigue ahí hasta que la quites a mano (Una compra que erpc no puede registrar). erpc worker run no guarda ningún registro, así que su siguiente ejecución hace una solicitud nueva.
Despliega los entornos de uno en uno. Dos despliegues del mismo entorno iniciados a la vez pueden comprar dos, y eso no está admitido.
Si una línea sigue existiendo lo decide lo que se cobra a la cuenta. erpc nunca finaliza una línea que no se factura por horas: finalízala en el dashboard.

Eliminar una aplicación

erpc worker delete elimina el worker. erpc worker delete --release-server también finaliza sus líneas y, después, su servidor por horas. Lo que no se pudo finalizar sigue registrado, y una línea que no se factura por horas se nombra, para que la finalices en el dashboard.

Una eliminación simple rechaza un VPS comprado al que nunca se llegó, porque lo olvidaría mientras se sigue cobrando. Una eliminación simple de un VPS por horas al que sí se llegó lo quita del registro mientras todavía se cobra, y avisa de ello.
--forget no intenta contactar con un servidor al que ya no se puede llegar, y --forget-line <id> quita del registro una línea finalizada fuera de erpc.

Medir la latencia RPC desde el servidor

erpc worker bench mide el tiempo de las llamadas RPC desde el servidor del entorno: el RPC compartido de ERPC, su Unlimited RPC y cualquier otro, uno al lado del otro. El agente del servidor mide cada llamada, así que las cifras son lo que obtiene la aplicación.

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 acepta getSlot, getBlockHeight, getLatestBlockhash o getHealth.
--no-shared deja fuera el RPC compartido. Un valor de --url puede ser la propia URL, una referencia op://…, keychain:… o keystore:… (al lugar donde se guarda una URL que contiene una clave; nunca a la entrada de la clave de trading, que se rechaza), o - (se lee de la entrada estándar o se pide sin que se vea). Se rechazan más de seis endpoints.
El bench imprime p50, p90, p99, el mínimo y el máximo, los fallos con el primer motivo y cuántos slots iba cada respuesta por detrás de la más reciente de la misma ronda.
Las claves llegan al servidor solo por la entrada estándar, y la tabla muestra el esquema, el host y el puerto.

Hacer una copia de seguridad de los datos de estado de la aplicación

erpc worker backup on hace cada día una copia de seguridad de los datos de estado de la aplicación en ERPC Global Storage, cifrada con restic, a la hora --at del servidor y dentro de los 30 minutos siguientes. Se necesita un plan de almacenamiento (erpc storage buy 5).

Lo que se copia son los datos de estado de la aplicación, /var/lib/private/erpc-worker-<id>. Las releases no, porque un despliegue las vuelve a poner. Los datos de Redis y PostgreSQL no están cubiertos.
El servidor no puede borrar instantáneas. Nunca tiene la sesión de erpc, la clave de administrador de la cuenta ni su contraseña maestra.
Un servidor comprometido sí puede leer las instantáneas de todas las máquinas de la cuenta, incluidas las de esta máquina; conservar después de off la clave del repositorio, que restic nunca cambia; añadir instantáneas con el nombre de otra máquina, así que, si eso ocurre, comprueba qué elige restore latest; y llenar el almacenamiento de la cuenta, lo que detiene las copias de seguridad de todas las máquinas. erpc worker backup off revoca primero la clave de acceso del servidor, responda o no el servidor.
restic copia los archivos tal como están mientras el worker se ejecuta, así que una base de datos puede necesitar su propio volcado para restaurarse de forma coherente. Una ejecución que se perdió mientras el servidor estaba apagado se ejecuta cuando vuelve a estar encendido.
erpc worker backup off, status y now detienen la copia de seguridad, informan sobre ella y la ejecutan. Las instantáneas se mantienen después de off, y erpc backup prune --host depura las antiguas.

Restaura desde esta máquina, después de ejecutar erpc backup init en ella:

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

Varios entornos y máquinas

Varios workers en un mismo servidor se ejecutan cada uno como su propia unidad, comparten la tabla del firewall del servidor y cada uno abre solo su propio puerto.
Una aplicación puede tener varios entornos ([env.staging], [env.prod]), cada uno con su propio servidor y sus propias líneas.
Un entorno puede guardar los datos de su servidor en 1Password en lugar de en erpc.toml. Entonces cualquier máquina con sesión iniciada en esa bóveda, con el repositorio de la aplicación, puede ejecutar todos los comandos; se avisa de las referencias keychain: y keystore: en una aplicación así, porque otra máquina no puede leerlas. Un entorno nuevo guarda sus datos en 1Password cuando erpc login guarda allí la sesión; deploy --vault <vault-id> indica otra bóveda, y deploy --inline guarda los datos en erpc.toml.