Deer Workflow को VPS पर कैसे इंस्टॉल और सेटअप करें

आप क्या बना रहे हैं

Deer Workflow एजेंट ग्राफ के लिए एक कोड-फर्स्ट रनटाइम है: इसका कंट्रोल फ्लो एक TypeScript फाइल में रहता है जिसे आप रिव्यू कर सकते हैं, और एक कोडिंग एजेंट केवल उन हिस्सों पर काम करता है जहाँ निर्णय लेने की आवश्यकता होती है। यह गाइड इसे एक Ubuntu VPS पर इंस्टॉल करती है, एक उदाहरण ग्राफ को systemd के तहत हेडलेस चलाती है, और मशीन-रीडेबल इवेंट स्ट्रीम को एक लॉग फाइल में लिखती है जिसे आप रात के तीन बजे रन फेल होने पर सर्च कर सकते हैं।

इसके घटक छोटे हैं। Bun CLI को चलाता है। एक कोडिंग एजेंट CLI, जैसे Codex या Claude Code, मॉडल का काम करता है। एक पिन किया गया npm पैकेज रनटाइम को होल्ड करता है। एक TypeScript फाइल आपके ग्राफ को रखती है। एक systemd सर्विस और टाइमर इसे शेड्यूल पर चलाते हैं। यहाँ दी गई अधिकांश जानकारी उन हिस्सों को कवर करती है जो वास्तव में खराब होते हैं: systemd यूनिट के अंदर PATH, बिना लॉगिन शेल वाले सेशन में एजेंट क्रेडेंशियल्स, और जुलाई 2026 में पहली बार पब्लिश की गई डिपेंडेंसी को पिन करना।

विजुअल बिल्डर, कोड, या केवल प्रॉम्प्टिंग एजेंट

एक self-hoster जो किसी मॉडल के साथ काम को स्वचालित (automate) कर रहा है, वह तीन स्वरूपों में से एक चुनता है, और वे अलग-अलग तरीकों से विफल होते हैं।

एक विजुअल बिल्डर आपको एक कैनवास, एक नोड लाइब्रेरी और एक ऐसा यूजर इंटरफेस देता है जिसे एक गैर-प्रोग्रामर भी खोल सकता है। यह एक वास्तविक लाभ है, और यह क्षेत्र इतना भरा हुआ है कि इसमें से चुनने के लिए self-hosted n8n alternatives का पूरा सर्वेक्षण उपलब्ध है। इसकी कीमत यह है कि लॉजिक अंततः एक JSON डॉक्यूमेंट के रूप में समाप्त होता है जिसे UI द्वारा लिखा जाता है। उस डॉक्यूमेंट का diff बहुत शोर वाला (noisy) होता है, इसलिए किसी बदलाव की समीक्षा करने का अर्थ है पैच पढ़ने के बजाय कैनवास को खोलना।

एक एजेंट को सीधे प्रॉम्प्ट करना दूसरा स्वरूप है। आप पूरे कार्य का वर्णन एक पैराग्राफ में करते हैं और मॉडल को क्रम, पुनः प्रयास (retries) और रुकने का समय तय करने देते हैं। यह तब तक काम करता है जब तक कि वह किसी दिन अलग तरह से निर्णय न ले ले। इसका कोई diff नहीं होता, क्योंकि कोई artifact नहीं होता: योजना बातचीत में रहती है, और बातचीत समाप्त हो चुकी होती है।

कोड में ऑर्केस्ट्रेशन तीसरा स्वरूप है। चरणों का क्रम, fan-out, पुनः प्रयास और त्रुटि प्रबंधन (error handling) git में सामान्य TypeScript होते हैं। मॉडल को केवल उन बिंदुओं पर कॉल किया जाता है जहाँ निर्णय की आवश्यकता होती है और कहीं नहीं। इसकी कीमत यह है कि किसी को वह कोड लिखना और बनाए रखना पड़ता है, और एक सहकर्मी जो TypeScript नहीं लिखता, वह इसे संपादित (edit) नहीं कर सकता।

Graph runtime के लाभ और लागत

• Control flow जिसे आप review कर सकते हैं। Graph एक file है। Retry policy में किया गया बदलाव pull request में तीन बदली हुई lines के रूप में दिखता है, न कि किसी move किए गए box के रूप में।
• Version control में failure handling। जब step चार fail होता है, तो क्या होगा, यह लिखा हुआ होता है, test किया जाता है, और आपके बाकी infrastructure के साथ tag किया जाता है।
• एक agent जिसे आप swap कर सकते हैं। Runtime में Codex, Claude Code और Pi के लिए adapters होते हैं। किसी step को चलाने वाले model को बदलना केवल एक import का काम है।
• एक execution जिसे आप watch कर सकते हैं। Phases और events runtime से structured data के रूप में बाहर आते हैं, इसलिए headless run का एक record रहता है जिसे आप query कर सकते हैं।

सामान्य अभ्यास, जिसमें model जिस loop के अंदर चलता है उसे design करना शामिल है न कि केवल एक prompt को बेहतर बनाना, loop engineering कहलाता है, और graph runtime इसे करने का एक ठोस तरीका है। इसकी लागत setup है: install करने के लिए एक runtime, authenticate करने के लिए एक agent CLI, non-programmers के लिए कोई interface नहीं, और एक नई dependency जिस पर नज़र रखनी पड़ती है।

प्रोजेक्ट नया है, इसलिए version को pin करें

Deer Workflow MIT licensed है और यह नया है। 19 August 2026 तक, repository में main पर 47 commits हैं। npm पर तीन published versions उपलब्ध हैं: 26 July 2026 को 0.0.1 और 0.1.0, और 27 July 2026 को 0.2.0। प्रत्येक के लिए एक git tag मौजूद है, और changelog में आप देख सकते हैं कि उनके बीच क्या बदलाव हुए हैं। इसके Unreleased section में deer-workflow agent command को पहले ही हटा दिया गया है, इसलिए main और सबसे नया published version अब वही CLI प्रदान नहीं करते हैं।

यह प्रोजेक्ट से बचने का कारण नहीं है। यह एक सटीक version install करने और यह जानने का कारण है कि आपने कौन सा version install किया है।

• हमेशा एक सटीक version install करें, कभी भी range का उपयोग न करें।
• उस version को अपने graphs वाली repository में ही record करें।
• किसी भी upgrade के बाद, timer द्वारा उसे दोबारा run करने से पहले, अपने graph को एक बार manually run करके देखें।

Bun और एक agent runtime इंस्टॉल करें

नीचे दी गई सभी प्रक्रियाएं sudo अधिकारों वाले एक सामान्य user के रूप में चलाएं। इसे root के रूप में न चलाएं। Agent CLIs क्रेडेंशियल्स को उस user की home directory में स्टोर करते हैं जिसने sign in किया है, और बाद में systemd unit को उन्हें खोजने के लिए उसी user के रूप में चलना पड़ता है।

sudo apt update
sudo apt install -y curl unzip jq git nodejs npm
curl -fsSL https://bun.com/install | bash

Bun इंस्टॉलर एक zip archive को unpack करता है, इसलिए unzip का पहले से मौजूद होना आवश्यक है। इंस्टॉलर आपके shell profile में PATH लाइन्स जोड़ता है, और आपका वर्तमान shell उस फ़ाइल को पहले ही पढ़ चुका है, इसलिए एक नया shell खोलें या इन दो लाइनों को स्वयं ~/.bashrc में जोड़ें और इसे reload करें।

export BUN_INSTALL="$HOME/.bun"
export PATH="$BUN_INSTALL/bin:$HOME/.npm-global/bin:$PATH"

bun --version

यह एक version number प्रिंट करता है। bun: command not found का मतलब है कि आप जिस shell में हैं उसमें PATH लाइन गायब है, न कि इंस्टॉलेशन विफल हुआ है। कुछ भी दोबारा इंस्टॉल करने से पहले ls ~/.bun/bin चलाएं।

अब agent runtime की बारी है। Codex CLI डिफ़ॉल्ट है, और यह npm से इंस्टॉल होता है। एक user-level npm prefix सेट करें ताकि global इंस्टॉलेशन के लिए root की आवश्यकता न पड़े।

npm config set prefix "$HOME/.npm-global"
npm install -g @openai/codex
command -v codex
codex

command -v codex को $HOME/.npm-global/bin के अंतर्गत एक path प्रिंट करना चाहिए। codex को अकेले चलाने पर CLI खुलता है, जहाँ आप अपने ChatGPT account के साथ sign in करते हैं। इसे अभी एक बार कर लें, जब आप स्क्रीन देख पा रहे हों।

Claude Code एक वैकल्पिक runtime के रूप में काम करता है और इसका अपना इंस्टॉलर है।

curl -fsSL https://claude.ai/install.sh | bash
claude --version

एक सफल इंस्टॉलेशन 2.1.211 (Claude Code) जैसा version प्रिंट करता है। लॉग इन करने के लिए एक बार claude चलाएं। यह उसी श्रेणी की प्रक्रिया है, जिसे आपकी फ़ाइलों तक वही पहुंच प्राप्त है जो आपके द्वारा होस्ट किए गए किसी अन्य agent को होती है, इसलिए VPS पर कोडिंग एजेंट चलाना में दिए गए account और hardening संबंधी नोट्स यहाँ बिना किसी बदलाव के लागू होते हैं।

Deer Workflow इंस्टॉल करें और सटीक version पिन करें

bun install --global @deerwork-ai/deer-workflow@0.2.0
command -v deer-workflow

command -v absolute path प्रिंट करता है, जो सामान्यतः /home/<your user>/.bun/bin/deer-workflow होता है। इसे कहीं कॉपी कर लें। systemd unit में आप केवल नाम का उपयोग नहीं कर सकते।

install command में version को बनाए रखें। @0.2.0 को हटाने पर जिस दिन आप इसे run करेंगे, उस दिन का सबसे नया version इंस्टॉल हो जाएगा। 47 commits वाले प्रोजेक्ट में यह किसी ऐसे timer के तहत CLI को बदल सकता है जिसे कोई monitor नहीं कर रहा है।

Graphs को git repository में रखें

mkdir -p ~/workflows/logs
cd ~/workflows
git init

Codex यह जाँचता है कि क्या वह किसी git repository के अंदर चल रहा है, इसीलिए CodexAgentConfig में skipGitRepositoryCheck विकल्प दिया गया है, उन स्थितियों के लिए जहाँ आप इसे repository नहीं दे सकते। अपने VPS पर आप इसे एक repository दे सकते हैं और आपको ऐसा करना भी चाहिए: एक graph कोड है, और यदि कोड version control के अंतर्गत नहीं है, तो orchestration को कोड के रूप में लिखने का तर्क व्यर्थ हो जाता है। अभी logs directory बनाएँ, क्योंकि systemd आपके लिए इसे नहीं बनाएगा।

एक ग्राफ लिखें

Workflow एक साधारण TypeScript module है। यह meta को export करता है, जो एक object है जिसमें नाम, विवरण और चरणों (phases) की क्रमित सूची होती है, और यह handler को default के रूप में या एक named run export के रूप में export करता है। Handler के भीतर आप package से helpers को call करते हैं। phase() यह चिह्नित करता है कि run किस stage में है, log() एक progress line लिखता है, agent() coding agent को एक prompt भेजता है, parallel() एक साथ कार्यों (tasks) की एक सूची चलाता है, और pipeline() कई stages के माध्यम से items की एक सूची को push करता है।

इसे ~/workflows/log-triage.ts के रूप में save करें।

import { agent, log, parallel, phase } from "@deerwork-ai/deer-workflow";

export const meta = {
  name: "log-triage",
  description: "Groups recent service errors and writes one short report.",
  phases: [{ title: "Collect" }, { title: "Classify" }, { title: "Report" }],
  exampleArgs: { service: "nginx", hours: 24 },
};

export default async function workflow(args: { service: string; hours: number }) {
  if (!args?.service) throw new Error("input needs a service name");

  phase("Collect");
  log(`Reading ${args.hours}h of logs for ${args.service}`);
  const found = await agent<{ patterns: string[] }>(
    `Read the last ${args.hours} hours of journalctl -u ${args.service} and list the distinct error patterns.`,
    {
      sandbox: "read-only",
      schema: {
        type: "object",
        properties: { patterns: { type: "array", items: { type: "string" } } },
        required: ["patterns"],
        additionalProperties: false,
      },
    },
  );

  phase("Classify");
  log(`Classifying ${found.patterns.length} patterns`);
  const notes = await parallel(
    found.patterns.map((pattern) => () =>
      agent(`Explain this error and its most likely cause: ${pattern}`, { sandbox: "read-only" }),
    ),
  );

  phase("Report");
  return agent(`Write a short operations report from these notes: ${JSON.stringify(notes.filter(Boolean))}`);
}

उस file में चार विवरण महत्वपूर्ण हैं।

• agent() call पर schema structured output के लिए अनुरोध करता है, और call parsed object को return करती है। found.patterns एक वास्तविक array है जिस पर ग्राफ का शेष भाग loop कर सकता है। Schema के बिना, agent() एक string return करता है और आप prose को parse कर रहे होते हैं।
• sandbox यह तय करता है कि वह step किस चीज़ को touch कर सकता है। read-only writes को block करता है, workspace-write guarded writes की अनुमति देता है, और danger-full-access guard को हटा देता है। इसे प्रति call set किया जाता है, इसलिए एक ग्राफ व्यापक रूप से पढ़ सकता है और एक ही स्थान पर लिख सकता है।
• parallel() functions लेता है, promises नहीं। map((pattern) => () => agent(...)) thunks की एक सूची बनाता है, इसलिए runtime यह तय करता है कि प्रत्येक कब शुरू होगा। agent(...) को सीधे pass करने से सूची बनते ही हर call शुरू हो जाएगी।
• parallel() के भीतर एक failed task null बन जाता है और run जारी रहता है, क्योंकि partial completion को design द्वारा अनुमति दी गई है। इसलिए notes.filter(Boolean) केवल सजावट नहीं है: इसे छोड़ दें और एक failed branch अगले step के prompt में null text डाल देगी।

साधारण agent() helper default runtime, Codex का उपयोग करता है। किसी एक step को Claude Code पर भेजने के लिए, agent class को import करें और उसे सीधे call करें।

import { ClaudeAgent } from "@deerwork-ai/deer-workflow";

const claude = new ClaudeAgent({ sandbox: "read-only" });
const summary = await claude.run<string>("Summarise ./report.md in five lines.");

व्यवहार में swappable agent ऐसा दिखता है: एक import और एक constructor, जिसके चारों ओर का ग्राफ अपरिवर्तित रहता है। CLI पर --agent codex|claude|pi flag deer-workflow create से संबंधित है, जो विवरण से एक workflow file generate करता है। यह उस runtime को नहीं बदलता जिसका उपयोग deer-workflow run करता है।

इसे एक बार मैन्युअल रूप से चलाएं, फिर हेडलेस मोड में

cd ~/workflows
deer-workflow run ./log-triage.ts --input '{"service":"nginx","hours":24}'

इंटरैक्टिव रूप से आपको एक टर्मिनल इंटरफ़ेस मिलता है: एक तरफ meta के चरण और दूसरी तरफ लाइव लॉग। किसी भी चीज़ को ऑटोमेट करने से पहले इस तरह एक पूरा रन देखें। यदि एजेंट लॉग इन नहीं है, या आपका इनपुट हैंडलर सिग्नेचर से मेल नहीं खाता है, तो आप इसे अगले सप्ताह लॉग फ़ाइल में खोजने के बजाय कुछ ही सेकंड में देख लेंगे।

ऑटोमेशन के लिए, इनपुट को एक फ़ाइल में ले जाएं। ~/workflows/input.json को सेव करें:

{ "service": "nginx", "hours": 24 }

deer-workflow run ./log-triage.ts --input-file ./input.json --print >> logs/run.jsonl

--print, जिसका संक्षिप्त रूप -p है, इंटरफ़ेस को बंद कर देता है और इवेंट स्ट्रीम को stdout पर लिखता है, प्रति पंक्ति एक JSON ऑब्जेक्ट। इस मोड में stdout पर कुछ और नहीं जाता है, इसलिए सीधे .jsonl फ़ाइल में अपेंड करने से आपको एक ऐसी फ़ाइल मिलती है जिसकी हर पंक्ति पार्स हो सकती है।

इवेंट स्ट्रीम, और रात के 3 बजे क्या grep करना है

प्रत्येक लाइन में type, sequence, timestamp, workflowId, depth और scriptPath होते हैं। इनके प्रकार workflow:start, workflow:meta, workflow:end, workflow:error, workflow:phase:start, workflow:phase:end और log हैं। Phase इवेंट्स में phase होता है, end इवेंट्स में durationMs होता है, एक log इवेंट में message होता है, और एक workflow:error इवेंट में error के साथ name, message और आमतौर पर stack होता है।

रात के तीन बजे आपके सामने आने वाले दो सवालों के जवाब देने के लिए यह संरचना पर्याप्त है: क्या यह पूरा हुआ, और यह कहाँ रुका।

grep workflow:error logs/run.jsonl
jq -r 'select(.type == "workflow:error") | .error.message' logs/run.jsonl
jq -r 'select(.type == "workflow:phase:end") | [.phase, .durationMs] | @tsv' logs/run.jsonl
jq -r 'select(.type == "log") | .message' logs/run.jsonl

अभी चल रहे रन को देखने के लिए, इस फाइल को फॉलो करें: tail -f logs/run.jsonl | jq -c 'select(.type == "log")'। एक रन में कुछ ही लाइनें लिखी जाती हैं, लेकिन फाइल का आकार लगातार बढ़ता रहता है, इसलिए जब टाइमर को चलते हुए कुछ सप्ताह हो जाएं तो ~/workflows/logs/*.jsonl के लिए एक logrotate नियम जोड़ दें।

इसे systemd के अंतर्गत चलाएं

लंबे समय तक चलने वाले daemon के बजाय, oneshot service और एक timer का उपयोग करें। graph शुरू होता है, चलता है और फिर बंद हो जाता है। /etc/systemd/system/log-triage.service लिखें और deploy को अपने user से बदलें।

[Unit]
Description=Log triage workflow
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
User=deploy
WorkingDirectory=/home/deploy/workflows
Environment=HOME=/home/deploy
Environment=PATH=/home/deploy/.bun/bin:/home/deploy/.npm-global/bin:/usr/local/bin:/usr/bin:/bin
ExecStart=/home/deploy/.bun/bin/deer-workflow run ./log-triage.ts --input-file ./input.json --print
StandardOutput=append:/home/deploy/workflows/logs/run.jsonl
StandardError=journal
TimeoutStartSec=3600

इसके बाद /etc/systemd/system/log-triage.timer करें:

[Unit]
Description=Run the log triage workflow every night

[Timer]
OnCalendar=*-*-* 03:00:00
Persistent=true

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl start log-triage.service
systemctl status log-triage.service
sudo systemctl enable --now log-triage.timer
systemctl list-timers log-triage.timer

सबसे पहले service को मैन्युअल रूप से शुरू करें। एक सफल run के बाद unit सफलतापूर्वक deactivate हो जाती है, और logs/run.jsonl में events का एक ब्लॉक दिखाई देता है जो workflow:end पर समाप्त होता है। इसके बाद ही timer को enable करें। list-timers अगली निर्धारित run का समय दिखाता है, और Persistent=true का अर्थ है कि सर्वर बंद रहने के दौरान यदि कोई run छूट गई है, तो वह अगले boot पर एक बार चलेगी। StandardOutput=append: event stream को file में भेजता है और बाकी सब कुछ journal के लिए छोड़ देता है, जिससे journalctl -u log-triage.service पढ़ने योग्य बना रहता है।

मेरा ग्राफ शेल में काम करता है लेकिन systemd के अंतर्गत विफल क्यों हो जाता है?

इस क्रम में इन चार बिंदुओं की जाँच करें।

यूनिट बाइनरी फाइलों को ढूंढ नहीं पा रही है। systemd कभी भी ~/.bashrc को नहीं पढ़ता है, और इसके डिफ़ॉल्ट PATH में न तो ~/.bun/bin होता है और न ही ~/.npm-global/bin। यूनिट एक सेकंड से भी कम समय में विफल हो जाती है और journalctl -u log-triage.service कमांड नाम पर exec विफल होने का संकेत देता है। यही कारण है कि ExecStart एक absolute path का उपयोग करता है, और यही कारण है कि Environment=PATH= अभी भी दोनों निर्देशिकाओं को सूचीबद्ध करता है: जब रनटाइम एक एजेंट स्टेप शुरू करता है, तो उसे स्वयं codex या claude को ढूंढना होता है।

एजेंट अपने क्रेडेंशियल्स को ढूंढ नहीं पा रहा है। एजेंट CLI अपना लॉगिन होम डायरेक्टरी से पढ़ता है, इसलिए User= और Environment=HOME= को स्पष्ट रूप से सेट करें और इसे वह होम डायरेक्टरी दें जिसके साथ आपने साइन इन किया है। यदि कोई रन workflow:start तक पहुँचता है और फिर एक ऐसा workflow:error उत्पन्न करता है जिसका संदेश आपके स्वयं के कोड के बजाय एजेंट CLI से आता है, तो इसका कारण लगभग हमेशा यही होता है।

रन को 90 सेकंड के बाद समाप्त (kill) कर दिया जाता है। Type=oneshot के लिए, systemd पूरे कमांड पर अपना स्टार्ट टाइमआउट लागू करता है, और डिफ़ॉल्ट समय 90 सेकंड है। एक एजेंट ग्राफ को पूरा होने में मिनटों का समय लगता है। जर्नल Start operation timed out. Terminating. रिकॉर्ड करता है, यूनिट विफल स्थिति में समाप्त हो जाती है, और लॉग फ़ाइल में बिना workflow:end के आधा रन ही दर्ज हो पाता है। TimeoutStartSec=3600 इसे एक घंटे का समय देता है। यदि आप चाहते हैं कि इसे समय सीमा के आधार पर कभी भी समाप्त न किया जाए, तो infinity का उपयोग करें।

सापेक्ष पथ (Relative paths) कहीं और रिजॉल्व हो रहे हैं। ./log-triage.ts और ./input.json, WorkingDirectory के सापेक्ष होते हैं। उस लाइन को हटा दें तो systemd प्रक्रिया को / में शुरू कर देता है, जहाँ इनमें से कोई भी फ़ाइल मौजूद नहीं होती है।

ऑर्केस्ट्रेटर क्या करने के लिए अधिकृत है

एक ऑर्केस्ट्रेटर जो टाइमर पर एजेंट स्टेप्स चलाता है, वह आपके सर्वर पर बिना किसी की निगरानी के काम करने वाली एक प्रक्रिया है। इसमें दो नियंत्रण और एक बजट मायने रखते हैं।

पहला नियंत्रण प्रत्येक agent() कॉल पर सैंडबॉक्स है। read-only किसी भी ऐसे स्टेप के लिए सही डिफ़ॉल्ट है जो केवल डेटा पढ़ता है: जैसे लॉग, मेट्रिक्स, या कोई रिपॉजिटरी जिसका आप सारांश बना रहे हैं। जब किसी स्टेप को वास्तव में लिखने की आवश्यकता हो, तो उसे workspace-write पर ले जाएं, और danger-full-access का उपयोग करने के बजाय additionalWritableDirectories के साथ लिखने योग्य क्षेत्र को छोटा रखें।

दूसरा नियंत्रण एक व्यक्ति है। कुछ स्टेप्स को कभी भी बिना निगरानी के नहीं चलना चाहिए: जैसे ईमेल भेजना, पैसे ट्रांसफर करना, डेटा हटाना, या प्रोडक्शन कॉन्फ़िगरेशन बदलना। कोड-फर्स्ट ग्राफ में गेट लगाना आसान है, क्योंकि स्टेप कोड की एक लाइन होती है। रन को रोकें, प्रस्तावित कार्रवाई को रिकॉर्ड करें, मानवीय उत्तर की प्रतीक्षा करें, और फिर जारी रखें। एजेंट क्रियाओं के सामने अप्रूवल गेट लगाना इस पैटर्न को पूरी तरह से कवर करता है, और यह किसी भी ऐसे ग्राफ का हिस्सा होना चाहिए जिसे टाइमर शुरू करता है।

बजट का अर्थ है पैसा। प्रत्येक agent() कॉल एक पूर्ण एजेंट सत्र है, और parallel() एक साथ कई सत्र शुरू करता है। इसलिए, यदि कोई ग्राफ बारह शाखाओं में विभाजित होता है, तो वह हर रात बारह सत्र चलाएगा, चाहे कोई रिपोर्ट पढ़े या न पढ़े। VPS पर AI एजेंट की लागत को नियंत्रण में रखना में दिए गए मापन और सीमाएं सीधे शेड्यूल्ड ग्राफ पर लागू होते हैं।

रनटाइम को अपग्रेड करने से पहले, चेंजलॉग पढ़ें, नया सटीक वर्ज़न इंस्टॉल करें, और --print के साथ अपने ग्राफ को एक बार मैन्युअल रूप से चलाएं। इतने नए प्रोजेक्ट में CLI इंटरफ़ेस अभी भी बदल रहा है: Unreleased सेक्शन पहले ही एक ऐसी कमांड को हटा चुका है जो 0.2.0 में मौजूद थी। टाइमर के तहत चलने वाला ग्राफ केवल उतना ही विश्वसनीय है जितना कि वह वर्ज़न जिसे आपने पिन किया है और वह अंतिम रन जिसे आपने वास्तव में देखा है।

FAQ

क्या मुझे Bun की आवश्यकता है, या Node.js पर Deer Workflow चल जाएगा?

Bun इंस्टॉल करें। प्रकाशित पैकेज अपनी deer-workflow बाइनरी को src/cli.ts, जो कि एक TypeScript सोर्स फाइल है, की ओर पॉइंट करता है, और डॉक्यूमेंटेशन में Bun को एक पूर्व-आवश्यकता (prerequisite) के रूप में सूचीबद्ध किया गया है। Bun सीधे TypeScript को निष्पादित करता है, इसलिए इसमें कोई बिल्ड स्टेप नहीं है। इसे sudo apt install -y unzip के बाद curl -fsSL https://bun.com/install | bash चलाकर इंस्टॉल करें, फिर bun --version के साथ पुष्टि करें। यदि आप Codex CLI को npm से इंस्टॉल करते हैं, तो आपको अभी भी अलग से Node.js और npm की आवश्यकता होगी।

मेरा वर्कफ़्लो टर्मिनल में क्यों चलता है लेकिन systemd के अंतर्गत विफल हो जाता है?

इसका कारण लगभग हमेशा PATH, HOME, या स्टार्ट टाइमआउट होता है। systemd आपके शेल प्रोफाइल को नहीं पढ़ता है, इसलिए ExecStart को deer-workflow के पूर्ण पथ (absolute path) की आवश्यकता होती है और Environment=PATH= को उस डायरेक्टरी की आवश्यकता होती है जिसमें codex या claude मौजूद हो। एजेंट CLI अपने क्रेडेंशियल्स को $HOME से पढ़ता है, इसलिए User= और Environment=HOME= को उस अकाउंट पर सेट करें जिससे आपने साइन इन किया है। साथ ही, Type=oneshot में 90 सेकंड का डिफ़ॉल्ट स्टार्ट टाइमआउट होता है, जो एजेंट रन को बीच में ही समाप्त कर देता है और जर्नल में Start operation timed out. Terminating. छोड़ देता है, इसलिए TimeoutStartSec=3600 सेट करें।

मैं किसी स्टेप के लिए Codex के बजाय Claude Code का उपयोग कैसे करूँ?

साधारण agent() हेल्पर डिफ़ॉल्ट रनटाइम, Codex का उपयोग करता है। पैकेज से ClaudeAgent को इम्पोर्ट करें, इसे कॉन्फ़िगर करें, और उन स्टेप्स के लिए .run() को कॉल करें जिन्हें आप Claude Code द्वारा हैंडल करवाना चाहते हैं। --agent codex|claude|pi फ्लैग deer-workflow create से संबंधित है, जो कि विवरण से वर्कफ़्लो फ़ाइल जेनरेट करने वाला कमांड है, और यह deer-workflow run को प्रभावित नहीं करता है। आप जिस भी एजेंट का उपयोग करते हैं, उसे उसी यूजर के रूप में इंस्टॉल और लॉग इन होना चाहिए जिस यूजर के रूप में सर्विस चल रही है।

मुझे Deer Workflow का कौन सा वर्ज़न इंस्टॉल करना चाहिए?

वही सटीक वर्ज़न जिसका आपने परीक्षण किया है। 19 अगस्त 2026 तक, सबसे नया प्रकाशित वर्ज़न 0.2.0 है, जो 27 जुलाई 2026 का है, और रिपॉजिटरी में 47 कमिट्स हैं। इंस्टॉल कमांड में @0.2.0, या जो भी इसे पढ़ते समय वर्तमान हो, लिखें। उस नंबर को अपने ग्राफ के साथ git में रखें, और हर अपग्रेड के बाद टाइमर द्वारा दोबारा चलने से पहले एक ग्राफ को मैन्युअल रूप से चलाकर देखें।