---
title: "Запуск, наблюдение и оплата приложения с erpc worker"
description: "Узнайте, работает ли приложение и сколько стоит в час, откатите релиз, измерьте задержку RPC с сервера, сделайте копию состояния и завершите почасовые списания."
canonical: "https://erpc.global/ru/doc/erpc-cli/worker-status-and-billing/"
locale: "ru"
---

# Запуск, наблюдение и оплата приложения с erpc worker

`erpc worker status` показывает, работает ли ваше приложение и сколько оно стоит в час. Каждый запуск сначала показывает свою цену, а `erpc worker delete --release-server` завершает gRPC, Shreds и Unlimited RPC, которые приложение использует почасово, а затем его почасовой сервер.

Эта страница описывает ERPC CLI `v0.1.0-rc.4` — пререлиз.

## Проверка приложения

```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` показывает, заблокировано приложение или работает, какой релиз запущен и с какого времени. Если вы вошли в аккаунт, он также показывает, сколько окружение стоит в час, — каждую позицию с ценой, которая списывается за неё с вашего аккаунта, — и кредит вашего аккаунта с тем, на сколько его хватит. `--json` передаёт то же самое в `hourly.charged`.

О позиции, которой нет среди списаний аккаунта, сообщается, что её нет среди них, а не что она завершена, потому что этот список может отставать от запуска на минуту. Без сессии или когда списания вашего аккаунта не удаётся прочитать, `status` сообщает то, что числится на учёте.

## Управление приложением

| Команда | Что делает |
| --- | --- |
| `erpc worker logs -n 200`, `logs -f` | Журнал приложения и агента. Управляющий символ в строке выводится как `?` |
| `erpc worker start` | Запускает приложение и отправляет ключ, если воркер заблокирован |
| `erpc worker stop`, `stop --lock` | Останавливает его; `--lock` также удаляет ключ из памяти |
| `erpc worker restart` | Останавливает и снова запускает его |
| `erpc worker releases` | Релизы, хранимые на сервере (`deploy.keep_releases`) |
| `erpc worker rollback`, `rollback --to <release>` | Возвращается к предыдущему релизу или к указанному. Отклоняется, а используемый релиз остаётся как был, если порт проверки работоспособности того релиза теперь занят другим работающим воркером |
| `erpc worker api <PATH>` | Читает API приложения с этой машины, при этом API остаётся на loopback сервера (`-X POST`, `-d '{...}'` для изменения) |
| `erpc worker trades [--profit]` | Сделки приложения на его сервере |
| `erpc worker list` | Приложения на этой машине и где каждое из них развёрнуто; `--prune` убирает те, чей `erpc.toml` исчез |

`API_TOKEN` приложения читается здесь и попадает на сервер через стандартный ввод — ни в какой командной строке и ни в каком журнале его нет. Каждая команда воркера принимает `--env <name>` (по умолчанию `default`) и `--json`, за исключением `secret unlock` и `secret lock`: они относятся к keystore этой машины, а не к приложению, и не принимают `--env`. Запущенная из любого места, команда находит своё приложение по имени, под которым его знает erpc; `secret put`, `secret rm`, `key import`, `firewall allow` и `firewall deny` принимают приложение только через `--dir`.

## Как работают почасовые списания

- **Каждый запуск сначала показывает свою цену.** В терминале запуск происходит только после ответа «да»; с `--yes` таким «да» служит сама командная строка, в которой названо, что запускать.
- **Почасовой продукт оплачивается из ERPC Credit**, который покупается заранее, а запуск, не покрытый кредитом, отклоняется. Цены — на странице [Цены](https://erpc.global/ru/price/) и в [ERPC Web Dashboard](https://dashboard.erpc.global/ru).
- **Новый VPS ставится на учёт, как только он назван,** ещё до того, как он готов. Следующее развёртывание берёт его в работу, а не покупает другой.
- **Для `deploy` запуск, на который не пришёл ответ, отправляется снова, но никогда как новый.** Его ключ запроса остаётся на учёте (`[env.<name>.starting]`), поэтому повторный запуск той же команды отправляет тот же запрос. После некоторых ответов он остаётся, пока вы не удалите его вручную ([Покупка, которую erpc не может поставить на учёт](https://erpc.global/ru/doc/erpc-cli/worker-troubleshooting/#покупка-которую-erpc-не-может-поставить-на-учёт)). `erpc worker run` ничего не ставит на учёт, поэтому при следующем запуске он создаёт новый запрос.
- **Развёртывайте по одному окружению за раз.** Два одновременно начатых развёртывания одного окружения могут совершить две покупки, и это не поддерживается.
- **Существует ли ещё линия, определяется тем, что списывается с аккаунта.** Линию, которая не тарифицируется почасово, erpc никогда не завершает: завершите её в панели.

## Удаление приложения

`erpc worker delete` удаляет воркер. `erpc worker delete --release-server` также завершает его линии, а затем его почасовой сервер. То, что не удалось завершить, остаётся на учёте, а линия, которая не тарифицируется почасово, указывается по имени, чтобы вы завершили её в панели.

- Обычное удаление отклоняет VPS, который был куплен, но к которому ни разу не удалось подключиться, поскольку иначе оно забыло бы его, пока за него идут списания. Обычное удаление почасового VPS, к которому удалось подключиться, снимает его с учёта, хотя за него ещё идут списания, и предупреждает об этом.
- `--forget` не пытается подключиться к серверу, до которого больше невозможно достучаться, а `--forget-line <id>` снимает с учёта линию, завершённую вне erpc.

## Измерение задержки RPC с сервера

`erpc worker bench` замеряет время вызовов RPC с сервера окружения: общий RPC ERPC, его Unlimited RPC и любой другой — бок о бок. Агент на сервере засекает время каждого вызова, поэтому цифры — это то, что получает приложение.

```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` принимает `getSlot`, `getBlockHeight`, `getLatestBlockhash` или `getHealth`.
- `--no-shared` исключает общий RPC. Значением `--url` может быть сам URL, ссылка `op://…`, `keychain:…` или `keystore:…` (на место, где хранится URL с ключом внутри; но никогда не на запись торгового ключа — такая ссылка отклоняется) либо `-` (значение читается со стандартного ввода или запрашивается без отображения на экране). Больше шести endpoint'ов не принимается.
- Замер выводит p50, p90, p99, min и max, сбои с первой причиной и то, на сколько слотов каждый ответ отставал от самого свежего в том же раунде.
- Ключи попадают на сервер только через стандартный ввод, а таблица показывает схему, хост и порт.

## Резервное копирование состояния приложения

`erpc worker backup on` каждый день делает резервную копию состояния приложения в ERPC Global Storage, зашифрованную restic, во время `--at` по часам сервера и в течение 30 минут после него. Нужен тариф хранилища (`erpc storage buy 5`).

- **В резервную копию попадает** состояние приложения, `/var/lib/private/erpc-worker-<id>`. Релизы не попадают, поскольку развёртывание возвращает их на место. Данные Redis и PostgreSQL не охватываются.
- **Сервер не может удалять снимки.** Он никогда не хранит сессию erpc, ключ администратора аккаунта или его мастер-пароль.
- **Захваченный сервер может** прочитать снимки всех машин аккаунта, включая эту; сохранить ключ репозитория, который restic никогда не меняет, и после `off`; добавить снимки под именем другой машины, поэтому после такого захвата проверьте, что выбирает `restore latest`; и заполнить хранилище аккаунта, что останавливает резервное копирование на всех машинах. `erpc worker backup off` сначала отзывает ключ доступа сервера, независимо от того, отвечает ли сервер.
- **restic копирует файлы как есть**, пока воркер работает, поэтому базе данных может понадобиться собственный дамп, чтобы восстановиться в согласованном состоянии. Запуск, пропущенный, пока сервер был выключен, выполняется, когда сервер снова работает.
- `erpc worker backup off`, `status` и `now` останавливают резервное копирование, сообщают о нём и запускают его. Снимки остаются после `off`, а `erpc backup prune --host` прореживает старые.

Восстанавливайте с этой машины после `erpc backup init` на ней:

```bash
erpc backup restore latest --from-host erpc-worker-<id>-<tag> --path /var/lib/private/erpc-worker-<id> --target ./restored
```

## Несколько окружений и машин

- Несколько воркеров на одном сервере работают каждый в своём юните, делят таблицу брандмауэра сервера, и каждый открывает только свой порт.
- У одного приложения может быть несколько окружений (`[env.staging]`, `[env.prod]`), каждое со своим сервером и линиями.
- Окружение может хранить сведения о сервере в 1Password вместо `erpc.toml`. Тогда любая машина, вошедшая в этот сейф, при наличии репозитория приложения может выполнять все команды; о ссылках `keychain:` и `keystore:` в таком приложении выводится предупреждение, поскольку другая машина не может их прочитать. Новое окружение хранит свои сведения в 1Password, если `erpc login` хранит там сессию; `deploy --vault <vault-id>` указывает другой сейф, а `deploy --inline` хранит сведения в `erpc.toml`.