---
title: "erpc worker से app चलाएँ, उस पर नज़र रखें और उसका भुगतान करें"
description: "देखें कि app चल रहा है या नहीं और प्रति घंटे उसकी लागत क्या है, रिलीज़ रोलबैक करें, सर्वर से RPC latency मापें, state बैकअप करें, प्रति-घंटा शुल्क समाप्त करें।"
canonical: "https://erpc.global/hi/doc/erpc-cli/worker-status-and-billing/"
locale: "hi"
---

# erpc worker से app चलाएँ, उस पर नज़र रखें और उसका भुगतान करें

`erpc worker status` दिखाता है कि आपका app चल रहा है या नहीं और प्रति घंटे उसकी लागत क्या है। हर start पहले अपना मूल्य दिखाता है, और `erpc worker delete --release-server` उन gRPC, Shreds और Unlimited RPC को समाप्त करता है जिन्हें app प्रति घंटे के हिसाब से इस्तेमाल करता है, फिर उसके प्रति-घंटा सर्वर को।

यह पेज ERPC CLI `v0.1.0-rc.4` के बारे में है, जो एक प्री-रिलीज़ है।

## किसी 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` दिखाता है कि app लॉक है या चल रहा है, कौन-सी रिलीज़ है, और कब से। जब आप लॉग इन हों, तो वह यह भी दिखाता है कि environment की प्रति घंटे लागत क्या है, हर item उस मूल्य के साथ जो आपके account से उसके लिए लिया जाता है, और आपके account का credit, साथ में यह कि वह कितने समय चलेगा। `--json` यही जानकारी `hourly.charged` के तहत देता है।

जो item account के शुल्कों में नहीं है, उसके बारे में कहा जाता है कि वह उनमें नहीं है, उसे समाप्त नहीं कहा जाता, क्योंकि वह सूची किसी start से एक मिनट पीछे हो सकती है। Session के बिना, या जब आपके account के शुल्क पढ़े नहीं जा सकते, `status` बताता है कि रिकॉर्ड में क्या दर्ज है।

## App को नियंत्रित करें

| कमांड | यह क्या करता है |
| --- | --- |
| `erpc worker logs -n 200`, `logs -f` | app का और एजेंट का लॉग। किसी पंक्ति में control character `?` के रूप में छपता है |
| `erpc worker start` | app चलाता है, और worker लॉक हो तो key भेजता है |
| `erpc worker stop`, `stop --lock` | इसे रोकता है; `--lock` key को मेमोरी से भी हटा देता है |
| `erpc worker restart` | इसे रोककर फिर से शुरू करता है |
| `erpc worker releases` | सर्वर पर रखी गई रिलीज़ (`deploy.keep_releases`) |
| `erpc worker rollback`, `rollback --to <release>` | पिछली रिलीज़ पर, या नाम दी गई रिलीज़ पर वापस जाता है। जब उस रिलीज़ का हेल्थ चेक पोर्ट अब किसी दूसरे चल रहे worker का हो, तो यह अस्वीकार होता है, और इस्तेमाल में चल रही रिलीज़ जैसी थी वैसी ही रहती है |
| `erpc worker api <PATH>` | इस मशीन से app का API पढ़ता है, जबकि API सर्वर के loopback पर ही रहता है (बदलाव के लिए `-X POST`, `-d '{...}'`) |
| `erpc worker trades [--profit]` | सर्वर पर app के trades |
| `erpc worker list` | इस मशीन पर मौजूद apps और हर एक कहाँ deploy किया गया है; `--prune` उन्हें हटा देता है जिनका `erpc.toml` अब नहीं है |

App का `API_TOKEN` यहाँ पढ़ा जाता है और standard input के ज़रिए सर्वर तक पहुँचता है, किसी कमांड लाइन पर नहीं और किसी journal में नहीं। हर worker कमांड `--env <name>` (default `default`) और `--json` लेती है, सिवाय इसके कि `secret unlock` और `secret lock`, जो किसी app के बारे में नहीं बल्कि इस मशीन के keystore के बारे में हैं, कोई `--env` नहीं लेते। कहीं से भी चलाने पर, कमांड अपने app को उस नाम से ढूँढती है जिससे erpc उसे जानता है; `secret put`, `secret rm`, `key import`, `firewall allow` और `firewall deny` app को सिर्फ़ `--dir` से लेते हैं।

## प्रति-घंटा शुल्क कैसे काम करते हैं

- **हर start पहले अपना मूल्य दिखाता है।** टर्मिनल पर, start सिर्फ़ "हाँ" के बाद होता है; `--yes` के साथ, वह कमांड लाइन जो बताती है कि क्या शुरू करना है, वही "हाँ" है।
- **प्रति-घंटा product का भुगतान ERPC Credit से होता है**, जो पहले से खरीदा जाता है, और जिस start को credit कवर नहीं करता, वह अस्वीकार होता है। कीमतें [मूल्य](https://erpc.global/hi/price/) और [ERPC Web Dashboard](https://dashboard.erpc.global/hi) पर हैं।
- **नया VPS नाम दिए जाते ही रिकॉर्ड में दर्ज हो जाता है,** तैयार होने से पहले ही। अगला deploy दूसरा खरीदने के बजाय उसी को अपना लेता है।
- **`deploy` के लिए, जिस start का कोई जवाब नहीं आया, उसे फिर से भेजा जाता है, कभी नए start के रूप में नहीं।** उसकी request key रिकॉर्ड में दर्ज रहती है (`[env.<name>.starting]`), इसलिए वही कमांड फिर से चलाने पर वही request भेजी जाती है। कुछ जवाबों के बाद यह तब तक रहती है जब तक आप इसे हाथ से न हटाएँ ([ऐसी खरीद जिसे erpc रिकॉर्ड में दर्ज नहीं कर पाता](https://erpc.global/hi/doc/erpc-cli/worker-troubleshooting/#ऐसी-खरीद-जिसे-erpc-रिकॉर्ड-में-दर्ज-नहीं-कर-पाता))। `erpc worker run` कोई रिकॉर्ड नहीं रखता, इसलिए उसका अगला run नई request बनाता है।
- **एक बार में एक ही environment deploy करें।** एक ही environment के दो deploy साथ-साथ शुरू हों तो वे दो बार खरीद सकते हैं, और यह समर्थित नहीं है।
- **कोई लाइन अब भी मौजूद है या नहीं, यह इससे तय होता है कि account से किस चीज़ का शुल्क लिया जा रहा है।** जिस लाइन का बिल प्रति घंटे नहीं बनता, उसे erpc कभी समाप्त नहीं करता: उसे dashboard में समाप्त करें।

## App हटाएँ

`erpc worker delete` worker को हटाता है। `erpc worker delete --release-server` उसकी लाइनें भी समाप्त करता है, फिर उसका प्रति-घंटा सर्वर। जो समाप्त नहीं हो सका, वह रिकॉर्ड में दर्ज रहता है, और जिस लाइन का बिल प्रति घंटे नहीं बनता, उसका नाम बताया जाता है, ताकि उसे dashboard में समाप्त किया जाए।

- सादा delete ऐसे VPS को अस्वीकार करता है जो खरीदा गया पर जिस तक कभी पहुँचा नहीं गया, क्योंकि वह शुल्क लगते रहने के दौरान उसे भूल जाता। जिस प्रति-घंटा VPS तक पहुँचा जा चुका है, उसका सादा delete उसे रिकॉर्ड से हटा देता है जबकि उसका शुल्क अब भी लग रहा होता है, और इसकी चेतावनी देता है।
- `--forget` के साथ, erpc ऐसे सर्वर तक पहुँचने की कोशिश नहीं करता जिस तक अब पहुँचा नहीं जा सकता, और `--forget-line <id>` erpc के बाहर समाप्त की गई लाइन को रिकॉर्ड से हटाता है।

## सर्वर से RPC latency मापें

`erpc worker bench` environment के सर्वर से RPC calls का समय मापता है: ERPC का shared RPC, उसका Unlimited RPC, और कोई भी दूसरा, साथ-साथ। सर्वर पर मौजूद एजेंट हर call का समय मापता है, इसलिए संख्याएँ वही हैं जो 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://<vault-id>/<item-id>/url   # another provider's RPC
```

- `--method` में `getSlot`, `getBlockHeight`, `getLatestBlockhash` या `getHealth` दिया जा सकता है।
- `--no-shared` shared RPC को छोड़ देता है। `--url` की value खुद URL हो सकता है, एक `op://…`, `keychain:…` या `keystore:…` reference (उस जगह का, जहाँ key वाला URL रखा है; trading key की एंट्री का कभी नहीं, उसे अस्वीकार किया जाता है), या `-` (standard input से पढ़ा जाता है, या बिना दिखे टाइप करने के लिए कहा जाता है)। छह से ज़्यादा endpoints अस्वीकार किए जाते हैं।
- Bench p50, p90, p99, min और max छापता है, पहली वजह के साथ failures, और यह कि हर जवाब उसी round के सबसे ताज़ा जवाब से कितने slots पीछे था।
- Keys सिर्फ़ standard input से सर्वर तक पहुँचती हैं, और table में scheme, host और port दिखते हैं।

## App के state का बैकअप लें

`erpc worker backup on` हर दिन app के state का ERPC Global Storage पर बैकअप लेता है, restic से एन्क्रिप्ट करके, सर्वर के समय के हिसाब से `--at` पर और उसके बाद 30 मिनट के भीतर। एक स्टोरेज प्लान ज़रूरी है (`erpc storage buy 5`)।

- **बैकअप में** app का state होता है, `/var/lib/private/erpc-worker-<id>`। रिलीज़ का बैकअप नहीं होता, क्योंकि deploy उन्हें वापस ले आता है। Redis और PostgreSQL का डेटा कवर नहीं होता।
- **सर्वर स्नैपशॉट डिलीट नहीं कर सकता।** उसके पास कभी erpc session, account की admin key या उसका मास्टर पासवर्ड नहीं होता।
- **किसी और के कब्ज़े में चला गया सर्वर** account की हर मशीन के स्नैपशॉट पढ़ सकता है, इस मशीन के भी; `off` के बाद repository की key अपने पास रख सकता है, जिसे restic कभी नहीं बदलता; किसी दूसरी मशीन के नाम से स्नैपशॉट जोड़ सकता है, इसलिए ऐसा होने के बाद जाँचें कि `restore latest` क्या चुनता है; और account का स्टोरेज भर सकता है, जिससे हर मशीन के बैकअप रुक जाते हैं। `erpc worker backup off` सबसे पहले सर्वर की access key रद्द करता है, सर्वर जवाब दे या न दे।
- **restic फ़ाइलों को जैसी हैं वैसी ही कॉपी करता है** जबकि worker चल रहा होता है, इसलिए किसी database को सुसंगत रूप में पुनर्स्थापित करने के लिए उसके अपने dump की ज़रूरत पड़ सकती है। सर्वर बंद रहने के दौरान छूटा run, सर्वर वापस आने पर चलता है।
- `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
```

## कई environment और मशीनें

- एक सर्वर पर कई workers में से हर एक अपनी यूनिट के रूप में चलता है, वे सर्वर की फ़ायरवॉल table साझा करते हैं, और हर एक सिर्फ़ अपना पोर्ट खोलता है।
- एक app के कई environment हो सकते हैं (`[env.staging]`, `[env.prod]`), हर एक का अपना सर्वर और अपनी लाइनें।
- कोई environment अपने सर्वर की जानकारी `erpc.toml` के बजाय 1Password में रख सकता है। तब उस vault में लॉग इन कोई भी मशीन, app की repository के साथ, हर कमांड चला सकती है; ऐसे app में `keychain:` और `keystore:` references के बारे में चेतावनी दी जाती है, क्योंकि दूसरी मशीन उन्हें पढ़ नहीं सकती। नया environment अपनी जानकारी 1Password में तब रखता है जब `erpc login` session को वहाँ रखता है; `deploy --vault <vault-id>` कोई दूसरा vault चुनता है, और `deploy --inline` जानकारी को `erpc.toml` में रखता है।