ERPC

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 की जाँच करें

$ 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 -fapp का और एजेंट का लॉग। किसी पंक्ति में control character ? के रूप में छपता है
erpc worker startapp चलाता है, और 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 कवर नहीं करता, वह अस्वीकार होता है। कीमतें मूल्य और ERPC Web Dashboard पर हैं।
  • नया VPS नाम दिए जाते ही रिकॉर्ड में दर्ज हो जाता है, तैयार होने से पहले ही। अगला deploy दूसरा खरीदने के बजाय उसी को अपना लेता है।
  • deploy के लिए, जिस start का कोई जवाब नहीं आया, उसे फिर से भेजा जाता है, कभी नए start के रूप में नहीं। उसकी request key रिकॉर्ड में दर्ज रहती है ([env.<name>.starting]), इसलिए वही कमांड फिर से चलाने पर वही request भेजी जाती है। कुछ जवाबों के बाद यह तब तक रहती है जब तक आप इसे हाथ से न हटाएँ (ऐसी खरीद जिसे 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 में रखता है।
पिछलाफ़ायरवॉल और WAFअगलाविफल होने पर