Potato को लोकल या क्लाउड में चलाना

Potato आपकी अपनी मशीन पर दो कमांड से चलता है, और potato deploy एक और कमांड से उसी कॉन्फ़िग को क्लाउड होस्ट पर डाल देता है। यह पृष्ठ हर आम स्थिति के लिए एक होस्ट सुझाता है और उसकी कमांड देता है। नीचे दिए गए क्लाउड टारगेट के लिए Potato 2.10.0 या उसके बाद का संस्करण चाहिए। इस संस्करण ने AWS, Heroku, Fly, Railway, Hetzner, Vultr, Linode और OpenStack को उन DigitalOcean, Render और HuggingFace टारगेट में जोड़ा जो 2.9 में पहले से थे।

टास्क कहाँ चलाएँ, यह चुनना

सही होस्ट इस पर निर्भर करता है कि टास्क को कितने समय तक चालू रहना है और उसका ख़र्च कौन उठाएगा। तालिका में दी गई लागतें वे अनुमान हैं जो Potato 2.10.0 हर टारगेट के डिफ़ॉल्ट आकार के लिए प्रिंट करता है, और --dry-run आपके चुने हुए आकार का अनुमान प्रिंट करता है।

AWS पर Lightsail इस्तेमाल करें, जिसे --provider aws बनाता है। इसकी तय कीमत में IPv4 पता और 60 GB डिस्क शामिल हैं, और इसे केवल lightsail:* अनुमतियाँ चाहिए, इसलिए यह सीमित IAM रोल के तहत भी काम करता है। EC2 टारगेट (aws-ec2) उन खातों के लिए है जिनमें Lightsail बंद है।

Jetstream2 NSF द्वारा वित्तपोषित एक शोध क्लाउड है। ACCESS आवंटन के साथ इसकी कोई लागत नहीं है, और हर इंस्टेंस को एक DNS नाम मिलता है, इसलिए एनोटेटरों को एक सामान्य होस्टनेम और सामान्य प्रमाणपत्र दिखता है। डिफ़ॉल्ट इंस्टेंस हर घंटे 2 सर्विस यूनिट खर्च करता है, यानी एक साल में लगभग 17,500, इसलिए अध्ययन ख़त्म होने पर उसे नष्ट कर दें।

Potato को अपनी मशीन पर चलाना

Potato को Python 3.9 या उससे नया संस्करण चाहिए। इसे इंस्टॉल करें और एक टास्क शुरू करें:

pip install potato-annotation
potato start myproject/config.yaml -p 8000

टास्क http://localhost:8000 पर है, और कोई दूसरा उस तक नहीं पहुँच सकता। potato start कॉन्फ़िग और डेटा फ़ाइलों को वहीं से पढ़ता है जहाँ वे रखी हैं, इसलिए रीस्टार्ट करने पर बदलाव लागू हो जाता है। टास्क लिखते समय यही कमांड इस्तेमाल करें। त्वरित शुरुआत पहला कॉन्फ़िग बनाती है, और इंस्टॉलेशन वैकल्पिक extras और वर्चुअल एनवायरनमेंट को कवर करता है।

प्रकाशित Docker इमेज के लिए होस्ट पर Python की ज़रूरत नहीं है। इसमें Potato और उसकी निर्भरताएँ हैं, और आपका प्रोजेक्ट फ़ोल्डर, config.yaml और उसके डेटा के साथ, /app पर माउंट होता है:

docker run -p 8000:7860 -v "$PWD/myproject:/app" ghcr.io/davidjurgens/potato:latest

कंटेनर पोर्ट 7860 पर सर्व करता है, जिसे यह कमांड आपकी मशीन के पोर्ट 8000 से जोड़ती है। प्रोडक्शन सेटअप इमेज के टैग, उसके एनवायरनमेंट वेरिएबल, और Linux होस्ट पर आने वाली फ़ाइल-स्वामित्व त्रुटि को कवर करता है।

potato share से एक अस्थायी सार्वजनिक लिंक

potato share टास्क चलाता है और जब तक कमांड चल रही है तब तक उसे एक सार्वजनिक HTTPS लिंक पर उपलब्ध रखता है। इसके लिए एक टनल क्लाइंट चाहिए, और यह cloudflared, Tailscale या ngrok में से, इसी क्रम में, जो भी इंस्टॉल हो उसे इस्तेमाल करता है:

brew install cloudflared
potato share myproject/config.yaml

Ctrl-C दबाने पर, लैपटॉप के स्लीप में जाने पर या नेटवर्क बदलने पर लिंक काम करना बंद कर देता है, और एनोटेशन आपकी अपनी डिस्क पर रहते हैं। टनल खोलने से पहले potato share प्रिंट करता है कि कौन साइन इन कर पाएगा और आपसे पुष्टि माँगता है, क्योंकि उसके बाद कॉन्फ़िग के साइन-इन नियम लिंक रखने वाले हर व्यक्ति पर लागू होते हैं। कुछ विश्वविद्यालय नेटवर्क trycloudflare.com लिंक ब्लॉक करते हैं, और --backend tailscale इस ब्लॉक से बचाता है। पायलट या लैब मीटिंग के लिए potato share इस्तेमाल करें, और ऐसे किसी भी टास्क के लिए क्लाउड होस्ट जिस पर कोई प्रतिभागी अगले दिन लौट सकता है।

एक कमांड से क्लाउड पर तैनात करना

potato deploy up आपका मौजूदा कॉन्फ़िग लेता है, सर्वर बनाता है, HTTPS प्रमाणपत्र लेता है, प्रोजेक्ट अपलोड करता है, टास्क शुरू करता है और URL प्रिंट करता है। अपने टारगेट का extra इंस्टॉल करें, फिर चलाने से पहले योजना देख लें:

pip install 'potato-annotation[deploy]'            # most targets
pip install 'potato-annotation[deploy-aws]'        # the three AWS targets
pip install 'potato-annotation[deploy-openstack]'  # Jetstream2 and other OpenStack clouds
 
potato deploy up myproject/config.yaml --provider aws --dry-run
potato deploy up myproject/config.yaml --provider aws

--dry-run के लिए किसी खाते की ज़रूरत नहीं है। यह हर वह संसाधन प्रिंट करता है जो तैनाती बनाएगी, मासिक लागत, और आपके कॉन्फ़िग की हर वह सेटिंग जो सार्वजनिक सर्वर पर जोखिम भरी है। --dry-run के बिना Potato वही योजना दिखाता है और कुछ भी बनाने से पहले आपकी पुष्टि का इंतज़ार करता है। उसी कॉन्फ़िग पर up दोबारा चलाने से मौजूदा तैनाती अपडेट होती है, और पहले up के बाद status, logs, pull और destroy को --provider की ज़रूरत नहीं होती।

तेरह क्लाउड टारगेट

Potato 2.10.0 तेरह क्लाउड टारगेट पर तैनात करता है। इनमें सबसे बड़ा फ़र्क यह है कि रीस्टार्ट के बाद डिस्क बचती है या नहीं, और इसी से तय होता है कि तैनाती को अगले खंड में बताए गए बैकअप की ज़रूरत है या नहीं।

सात VM टारगेट (aws, aws-ec2, openstack, hetzner, vultr, linode और digitalocean) एक ही तरह से सेट अप होते हैं। हर एक को उस तैनाती के लिए बनाई गई एक deploy key, केवल पोर्ट 22, 80 और 443 खोलने वाला फ़ायरवॉल, Let's Encrypt प्रमाणपत्र के साथ Caddy, और systemd सर्विस के रूप में Potato मिलता है, और potato deploy logs और pull इन सब पर काम करते हैं। Fly, Railway, Render और ECS Express प्रकाशित इमेज चलाते हैं और कंटेनर शुरू होने पर आपका प्रोजेक्ट डाउनलोड करते हैं। Railway, Render और ECS Express उसे बैकअप स्टोरेज से लाते हैं, इसलिए तीनों को --backup चाहिए, और डिस्क वाली Railway या Render सर्विस को भी इसकी ज़रूरत है। Fly पर 512 KB से छोटा प्रोजेक्ट Machine के कॉन्फ़िगरेशन के अंदर ही भेजा जाता है और उसे किसी स्टोरेज की ज़रूरत नहीं होती।

Google Cloud Run, Azure Container Apps और AWS App Runner टारगेट नहीं हैं। Cloud Run और Azure Container Apps जो स्टोरेज देते हैं वह SQLite डेटाबेस को सुरक्षित रूप से नहीं रख सकता, और App Runner 30 अप्रैल 2026 को नए ग्राहकों के लिए बंद हो गया। Azure पर Docker इमेज चलाने वाली VM काम करती है।

डिस्क मिटाने वाले होस्ट के लिए बैकअप

Heroku, ECS Express, Render के मुफ़्त टियर और HuggingFace Spaces पर सर्वर रीस्टार्ट होने पर डिस्क मिट जाती है। --backup हर पाँच मिनट में एनोटेशन आउटपुट और प्रोजेक्ट डेटाबेस के स्नैपशॉट को HuggingFace डेटासेट या S3 बकेट में कॉपी करता है, और जब कोई सर्वर खाली डिस्क के साथ शुरू होता है तो उन्हें वापस ले आता है:

potato deploy up myproject/config.yaml --provider heroku --backup hf --hf-token hf_...
potato deploy up myproject/config.yaml --provider heroku --backup s3 --s3-bucket my-bucket

Heroku और ECS Express --backup के बिना तैनात करने से इनकार करते हैं, जब तक --demo यह घोषित न करे कि एनोटेशन फेंके जा सकते हैं। रीस्टोर एनोटेशन के साथ खातों की सूची भी वापस लाता है, इसलिए एनोटेटर उन्हीं पासवर्ड से साइन इन करते हैं और वहीं से आगे बढ़ते हैं जहाँ रुके थे, और यह डिस्क पर पहले से मौजूद एनोटेशन को कभी ओवरराइट नहीं करता। --s3-endpoint S3 बैकअप को Cloudflare R2, Backblaze B2, MinIO या किसी विश्वविद्यालय के ऑब्जेक्ट स्टोर पर भेजता है। बैकअप VM टारगेट पर भी काम करता है, जहाँ यह डेटा की एक दूसरी प्रति सर्वर से बाहर रखता है।

potato deploy के बाहर, कॉन्फ़िग में एक backup ब्लॉक आपके अपने चलाए सर्वर पर यही काम करता है। hosting extra इंस्टॉल करें, जो HuggingFace और S3 क्लाइंट देता है, सर्वर के एनवायरनमेंट में HF_TOKEN सेट करें, और किसी मौजूदा कॉन्फ़िग में यह ब्लॉक जोड़ें:

backup:
  schedule_minutes: 5
  restore_on_boot: true
  sinks:
    - type: huggingface
      repo_id: lab/pilot-annotations

destroy से पहले एनोटेशन निकालना

potato deploy pull किसी तैनाती का इकट्ठा किया हुआ सब कुछ टाइमस्टैम्प वाली डायरेक्टरी में डाउनलोड करता है और जाँचता है कि क्या पहुँचा, और potato deploy destroy सर्वर को हटाता है। इन्हें इसी क्रम में चलाएँ:

potato deploy pull myproject/config.yaml
potato deploy destroy myproject/config.yaml

destroy ऐसी तैनाती को हटाने से इनकार करता है जिसका कभी pull नहीं हुआ, और शून्य फ़ाइलें लौटाने वाला pull गिना नहीं जाता। pull project.sqlite को फ़ाइल की तरह नहीं, बल्कि SQLite के backup कमांड से कॉपी करता है, क्योंकि WAL मोड वाले डेटाबेस की फ़ाइल कॉपी में हाल का काम छूट सकता है। Fly और Railway पर ऐप नष्ट करने से उसका वॉल्यूम मिट जाता है, इसलिए अगर आपने बैकअप भी नहीं चलाया था तो pull ही एकमात्र प्रति है।

दूसरे लोगों के खातों के लिए deploy बटन

potato deploy button वे फ़ाइलें लिखता है जिन्हें कोई होस्टिंग प्लेटफ़ॉर्म आपकी git रिपॉज़िटरी से एक-क्लिक तैनाती देने के लिए पढ़ता है, और README बैज प्रिंट करता है। इसका उपयोग तब करें जब सहयोगियों, छात्रों या किसी दूसरी लैब को आपका टास्क अपने खातों में चलाना हो:

potato deploy button studies/pilot/config.yaml --target heroku \
    --backup hf --hf-backup-repo lab/pilot-annotations

टारगेट हैं heroku, render, aws और railway। aws टारगेट एक CloudFormation "Launch Stack" टेम्पलेट लिखता है जो Lightsail इंस्टेंस बनाता है, और railway के लिए कमांड चरण प्रिंट करती है, क्योंकि Railway अपने डैशबोर्ड से टेम्पलेट प्रकाशित करता है। आपका config.yaml बिना बदलाव के रहता है, और कमांड उसके बगल में तैनाती सेटिंग्स लागू की हुई एक प्रति, potato.deploy.yaml, लिखती है। रिपॉज़िटरी में कोई secret नहीं जाता। Heroku, Render और AWS टेम्पलेट तैनाती के समय सत्र और एडमिन keys बनाते हैं। Heroku, Render और AWS बटन के लिए --backup ज़रूरी है, और तैनात करने वाला व्यक्ति उसके क्रेडेंशियल देता है।

आगे पढ़ें

Potato दस्तावेज़ में हर टारगेट का अपना पृष्ठ है:

• Potato इंस्टॉल करना और चलाना और टास्क तैनात करना, potato deploy का पूरा जीवनचक्र
• AWS: Lightsail, EC2 और ECS Express, हर एक के लिए ज़रूरी IAM अनुमतियों के साथ
• Jetstream2 और OpenStack, आवंटन का अनुरोध कैसे करें यह भी
• Hetzner, Vultr और Linode और DigitalOcean
• Fly.io, Railway, Render, Heroku और HuggingFace Spaces
• बैकअप, एनोटेशन वापस पाना और Deploy बटन
• अस्थायी URL पर टास्क साझा करना

इस साइट पर, प्रोडक्शन सेटअप आपके द्वारा प्रबंधित सर्वर पर gunicorn और Docker के तहत Potato चलाने को कवर करता है, और रिवर्स प्रॉक्सी उसे URL पथ उपसर्ग के तहत सर्व करने को कवर करता है।