Executar, acompanhar e pagar uma aplicação com o erpc worker

O erpc worker status mostra se a sua aplicação está rodando e quanto ela custa por hora. Toda ativação mostra o preço antes, e o erpc worker delete --release-server encerra o gRPC, o Shreds e o Unlimited RPC que a aplicação usa por hora e, depois, o servidor por hora dela.

Esta página descreve o ERPC CLI v0.1.0-rc.4, uma versão de pré-lançamento.

Verificar uma aplicação

$ 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.

O status mostra se a aplicação está bloqueada ou em execução, qual release e desde quando. Quando você está logado, ele também mostra quanto o ambiente custa por hora, cada item com o preço cobrado da sua conta por ele, e o crédito da sua conta com quanto tempo ele dura. O --json traz o mesmo em hourly.charged.

Um item que não está entre as cobranças da conta é descrito como fora delas, e não como encerrado, porque essa lista pode estar um minuto atrasada em relação a uma ativação. Sem uma sessão, ou quando as cobranças da sua conta não podem ser lidas, o status diz o que está registrado.

Controlar a aplicação

Comando	O que faz
`erpc worker logs -n 200`, `logs -f`	O log da aplicação e do agente. Um caractere de controle em uma linha é impresso como `?`
`erpc worker start`	Inicia a aplicação, enviando a chave quando o worker está bloqueado
`erpc worker stop`, `stop --lock`	Para a aplicação; `--lock` também descarta a chave da memória
`erpc worker restart`	Para a aplicação e a inicia de novo
`erpc worker releases`	As releases mantidas no servidor (`deploy.keep_releases`)
`erpc worker rollback`, `rollback --to <release>`	Volta à release anterior, ou à indicada. É recusado, com a release em uso mantida como estava, quando a porta de health check dessa release agora pertence a outro worker em execução
`erpc worker api <PATH>`	Lê a API da aplicação a partir desta máquina, com a API continuando no loopback do servidor (`-X POST`, `-d '{...}'` para uma alteração)
`erpc worker trades [--profit]`	Os trades da aplicação no servidor dela
`erpc worker list`	As aplicações nesta máquina e onde cada uma está implantada; `--prune` remove aquelas cujo `erpc.toml` não existe mais

O API_TOKEN da aplicação é lido aqui e chega ao servidor pela entrada padrão, sem passar por nenhuma linha de comando nem por nenhum journal. Todo comando do worker aceita --env <name> (padrão default) e --json, exceto secret unlock e secret lock, que tratam do keystore desta máquina e não de uma aplicação, e não aceitam --env. Executado de qualquer lugar, um comando encontra a aplicação pelo nome com que o erpc a conhece; secret put, secret rm, key import, firewall allow e firewall deny só recebem a aplicação por --dir.

Como funciona a cobrança por hora

Toda ativação mostra o preço antes. Em um terminal, uma ativação só acontece depois de um sim; com --yes, a linha de comando que nomeia o que ativar é o sim.
Um produto por hora é pago com ERPC Credit, comprado antecipadamente, e uma ativação que o crédito não cobre é recusada. Os preços estão em Preços e no ERPC Web Dashboard.
Uma nova VPS fica registrada assim que é nomeada, antes de ficar pronta. A próxima implantação passa a usá-la em vez de comprar outra.
No deploy, uma ativação que não recebeu resposta é enviada de novo, nunca como uma nova. A chave da requisição fica registrada ([env.<name>.starting]), então executar o mesmo comando de novo envia a mesma requisição. Depois de algumas respostas, ela fica lá até você removê-la manualmente (Uma compra que o erpc não consegue registrar). O erpc worker run não guarda registro, então a próxima execução dele faz uma nova requisição.
Implante um ambiente de cada vez. Duas implantações do mesmo ambiente iniciadas juntas podem resultar em duas compras, e isso não é suportado.
O que decide se uma linha ainda existe é o que é cobrado da conta. Uma linha que não é cobrada por hora nunca é encerrada pelo erpc: encerre-a no dashboard.

Remover uma aplicação

O erpc worker delete remove o worker. O erpc worker delete --release-server também encerra as linhas dele e, depois, o servidor por hora. O que não pôde ser encerrado continua registrado, e uma linha que não é cobrada por hora é indicada pelo nome, para ser encerrada no dashboard.

Um delete simples recusa uma VPS comprada e nunca alcançada, pois a esqueceria enquanto ela é cobrada. Um delete simples de uma VPS por hora já alcançada a tira do registro enquanto ela ainda é cobrada, e avisa disso.
Com --forget, o erpc não tenta alcançar um servidor que não pode mais ser alcançado, e --forget-line <id> tira do registro uma linha encerrada fora do erpc.

Medir a latência RPC a partir do servidor

O erpc worker bench mede o tempo de chamadas RPC a partir do servidor do ambiente: o RPC compartilhado da ERPC, o Unlimited RPC dela e qualquer outro, lado a lado. O agente no servidor mede cada chamada, então os números são o que a aplicação obtém.

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 aceita getSlot, getBlockHeight, getLatestBlockhash ou getHealth.
--no-shared deixa o RPC compartilhado de fora. Um valor de --url pode ser a própria URL, uma referência op://…, keychain:… ou keystore:… (ao lugar onde fica guardada uma URL com uma chave; nunca à entrada da chave de trading, que é recusada), ou - (lido da entrada padrão, ou pedido e digitado sem aparecer na tela). Mais de seis endpoints são recusados.
O bench imprime p50, p90, p99, mínimo e máximo, as falhas com o primeiro motivo, e quantos slots cada resposta estava atrás da mais recente na mesma rodada.
As chaves chegam ao servidor somente pela entrada padrão, e a tabela mostra esquema, host e porta.

Fazer backup do estado da aplicação

O erpc worker backup on faz backup do estado da aplicação todos os dias no ERPC Global Storage, criptografado pelo restic, no horário de --at no fuso do servidor e em até 30 minutos depois. É necessário um plano de armazenamento (erpc storage buy 5).

O que entra no backup é o estado da aplicação, /var/lib/private/erpc-worker-<id>. As releases não entram, já que uma implantação as coloca de volta. Os dados de Redis e PostgreSQL não são cobertos.
O servidor não pode excluir snapshots. Ele nunca guarda a sessão do erpc, a chave de administrador da conta nem a senha mestra dela.
Um servidor comprometido pode ler os snapshots de todas as máquinas da conta, incluindo os desta máquina; manter a chave do repositório, que o restic nunca muda, depois do off; adicionar snapshots com o nome de outra máquina, então verifique o que restore latest escolhe depois de um caso assim; e encher o armazenamento da conta, o que interrompe os backups de todas as máquinas. O erpc worker backup off revoga primeiro a chave de acesso do servidor, quer o servidor responda, quer não.
O restic copia os arquivos como estão enquanto o worker roda, então um banco de dados pode precisar de um dump próprio para ser restaurado de forma consistente. Uma execução perdida enquanto o servidor estava desligado roda quando ele volta.
erpc worker backup off, status e now interrompem o backup, informam sobre ele e o executam. Os snapshots continuam lá depois do off, e o erpc backup prune --host reduz os antigos.

Restaure a partir desta máquina, depois de executar erpc backup init nela:

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

Vários ambientes e máquinas

Vários workers em um mesmo servidor rodam cada um como uma unidade própria, compartilham a tabela de firewall do servidor, e cada um abre somente a própria porta.
Uma aplicação pode ter vários ambientes ([env.staging], [env.prod]), cada um com o próprio servidor e as próprias linhas.
Um ambiente pode guardar os dados do servidor no 1Password em vez do erpc.toml. Assim, qualquer máquina com login nesse cofre e com o repositório da aplicação pode executar todos os comandos; as referências keychain: e keystore: nesse tipo de aplicação geram um aviso, já que outra máquina não consegue lê-las. Um novo ambiente guarda os dados no 1Password quando o erpc login guarda a sessão lá; deploy --vault <vault-id> indica outro cofre, e deploy --inline mantém os dados no erpc.toml.