---
title: "Executar, acompanhar e pagar uma aplicação com o erpc worker"
description: "Veja se a aplicação roda e o custo por hora, faça rollback de uma release, meça a latência RPC do servidor, faça backup do estado e encerre a cobrança por hora."
canonical: "https://erpc.global/pt/doc/erpc-cli/worker-status-and-billing/"
locale: "pt"
---

# 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

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

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

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

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