SSD Nodes Learn Hosting plans →
Rehberler Matt ConnorYazan Matt Connor · Güncellendi 2026-08-21

VPS Uzerinde Deer Workflow Kurulumu ve Yapilandirma

Deer Workflow ile araci grafiklerini TypeScript uzerinden yonetin. Bun kullanarak VPS kurulumunu yapin, surumleri sabitleyin ve systemd ile basiz calistirma adimlarini ogrenin.

Ne inşa ediyorsunuz

Deer Workflow, aracı grafikleri (agent graphs) için kod öncelikli bir çalışma zamanıdır: kontrol akışı, inceleyebileceğiniz bir TypeScript dosyasında yer alır ve kodlama aracı yalnızca muhakeme gerektiren kısımları gerçekleştirir. Bu kılavuz, sistemi tek bir Ubuntu VPS üzerine kurar, örnek bir grafiği systemd altında başsız (headless) olarak çalıştırır ve makine tarafından okunabilir olay akışını, gece saat üçte bir çalışma başarısız olduğunda arama yapabileceğiniz bir günlük dosyasına yazar.

Bileşenler küçüktür. Bun, CLI'ı çalıştırır. Bir adet kodlama aracı CLI'ı (Codex veya Claude Code), model işlerini yürütür. Sabitlenmiş bir npm paketi çalışma zamanını barındırır. Bir adet TypeScript dosyası grafiğinizi tutar. Bir systemd servisi ve zamanlayıcısı, grafiği bir takvime göre çalıştırır. Buradaki metnin büyük bölümü, aslında sorun çıkaran kısımları ele alır: systemd birimi içindeki PATH, oturum açma kabuğu olmayan bir oturumdaki aracı kimlik bilgileri ve Temmuz 2026'da ilk kez yayınlanan bir bağımlılığın sabitlenmesi.

Görsel oluşturucu, kod veya sadece ajana komut istemi gönderme

Bir modeli kullanarak iş otomatize eden bir self-host kullanıcısı, üç farklı yöntemden birini seçer ve her biri farklı şekillerde başarısız olur.

Görsel oluşturucu size bir tuval, düğüm kütüphanesi ve programcı olmayan birinin de açabileceği bir kullanıcı arayüzü sunar. Bu gerçek bir avantajdır ve alan, seçilebilecek self-hosted n8n alternatifleri üzerine tam bir inceleme yapılabilecek kadar kalabalıktır. Bunun maliyeti, mantığın bir arayüz tarafından yazılan bir JSON belgesi olarak sonuçlanmasıdır. Bu belgedeki değişiklik farkları (diff) karmaşıktır; bu nedenle bir değişikliği incelemek, yamayı okumak yerine tuvali açmayı gerektirir.

Bir ajana doğrudan komut istemi göndermek ikinci yöntemdir. Tüm işi bir paragrafta tanımlarsınız ve modelin sıraya, yeniden denemelere ve ne zaman duracağına karar vermesine izin verirsiniz. Bu yöntem, model farklı bir karar verene kadar çalışır. Ortada bir değişiklik farkı yoktur çünkü bir yapı yoktur: plan konuşmanın içinde yaşamıştır ve konuşma sona erdiğinde plan da kaybolur.

Kod ile orkestrasyon ise üçüncü yöntemdir. Adımların sırası, dağılım (fan-out), yeniden denemeler ve hata yönetimi, git üzerinde tutulan sıradan TypeScript kodlarıdır. Model, yalnızca yargılama gerektiren noktalarda çağrılır, başka hiçbir yerde değil. Bunun maliyeti, birinin bu kodu yazması ve bakımını yapması gerekliliğidir; ayrıca TypeScript bilmeyen bir iş arkadaşı bu kodu düzenleyemez.

Graf çalışma zamanının sağladıkları ve maliyeti

  • İnceleyebileceğiniz kontrol akışı. Graf bir dosyadır. Yeniden deneme politikasındaki bir değişiklik, bir kutunun yerinin değişmesi olarak değil, bir pull request içerisinde üç satırlık bir değişiklik olarak görünür.
  • Sürüm kontrolünde hata yönetimi. Dördüncü adım başarısız olduğunda ne olacağı yazılıdır, test edilmiştir ve altyapınızın geri kalanıyla birlikte etiketlenmiştir.
  • Değiştirebileceğiniz bir aracı. Çalışma zamanı; Codex, Claude Code ve Pi için adaptörler ile birlikte gelir. Bir adımı çalıştıran modeli değiştirmek, yalnızca bir import işleminden ibarettir.
  • İzleyebileceğiniz bir yürütme. Aşamalar ve olaylar, çalışma zamanından yapılandırılmış veri olarak çıkar; bu sayede başsız (headless) bir çalıştırma, sorgulayabileceğiniz bir kayıt bırakır.

Modelin içinde çalıştığı döngüyü tasarlamak, tek bir istemi (prompt) iyileştirmekten daha genel bir uygulamadır ve buna döngü mühendisliği denir; graf çalışma zamanı ise bunu yapmanın somut bir yoludur. Maliyeti ise kurulumdur: kurulacak bir çalışma zamanı, kimlik doğrulaması yapılacak bir aracı CLI, programcı olmayanlar için bir arayüzün olmaması ve takip edilmesi gereken yeni bir bağımlılık.

Proje yeni olduğundan sürümü sabitleyin

Deer Workflow, MIT lisanslı ve yeni bir projedir. 19 Ağustos 2026 itibarıyla depo, main üzerinde 47 commit içermektedir. npm üzerinde üç yayınlanmış sürüm bulunmaktadır: 26 Temmuz 2026 tarihinde 0.0.1 ve 0.1.0, 27 Temmuz 2026 tarihinde ise 0.2.0 sürümleri yayınlanmıştır. Her biri için bir git etiketi mevcuttur ve sürümler arasındaki değişiklikleri changelog dosyasından takip edebilirsiniz. Unreleased bölümü halihazırda deer-workflow agent komutunu kaldırmıştır; bu nedenle main ve en yeni yayınlanan sürüm artık aynı CLI arayüzünü sunmamaktadır.

Bu durum projeden kaçınmak için bir neden değildir. Aksine, tam olarak belirli bir sürümü kurmak ve hangi sürümü kurduğunuzu bilmek için bir nedendir.

  • Bir aralık belirtmek yerine tam bir sürüm kurun.
  • Bu sürümü, grafiklerinizin bulunduğu depo ile aynı yerde kayıt altına alın.
  • Herhangi bir yükseltme işleminden sonra, zamanlayıcı grafiği tekrar çalıştırmadan önce kendi grafiğinizi manuel olarak bir kez çalıştırın.

Bun ve bir agent çalışma zamanı kurun

Aşağıdaki tüm işlemler sudo yetkilerine sahip normal bir kullanıcı olarak gerçekleştirilir. İşlemleri root kullanıcısı olarak çalıştırmayın. Agent CLI araçları, kimlik bilgilerini oturum açan kullanıcının ev dizini altında saklar; systemd biriminin bu bilgilere erişebilmesi için daha sonra aynı kullanıcıyla çalıştırılması gerekir.

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

Bun yükleyicisi bir zip arşivini açtığı için öncelikle unzip paketinin yüklü olması gerekir. Yükleyici, PATH satırlarını shell profilinize ekler. Mevcut shell oturumunuz bu dosyayı zaten okumuş durumdadır; bu nedenle yeni bir shell açın veya bu iki satırı kendiniz ~/.bashrc dosyasına ekleyip dosyayı yeniden yükleyin.

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

Bu komut bir sürüm numarası yazdırır. bun: command not found hatası, kurulumun başarısız olduğu anlamına gelmez; yalnızca PATH satırının bulunduğunuz shell oturumunda eksik olduğunu gösterir. Herhangi bir şeyi yeniden yüklemeden önce ls ~/.bun/bin komutunu çalıştırın.

Şimdi agent çalışma zamanını kuralım. Codex CLI varsayılan araçtır ve npm üzerinden kurulur. Global kurulumun root yetkisi gerektirmemesi için kullanıcı düzeyinde bir npm öneki (prefix) ayarlayın.

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

command -v codex komutu, $HOME/.npm-global/bin altında bir yol yazdırmalıdır. codex komutunu tek başına çalıştırmak CLI arayüzünü açar; burada ChatGPT hesabınızla oturum açın. Ekranı görebiliyorken bu işlemi şimdi bir kez gerçekleştirin.

Claude Code alternatif bir çalışma zamanı olarak kullanılabilir ve kendi yükleyicisine sahiptir.

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

Başarılı bir kurulum, 2.1.211 (Claude Code) gibi bir sürüm numarası yazdırır. Oturum açmak için claude komutunu bir kez çalıştırın. Bu süreç, barındırdığınız diğer tüm agent'lar ile aynı sınıftadır ve dosyalarınıza aynı erişim yetkilerine sahiptir; bu nedenle VPS üzerinde kodlama agent'ı çalıştırma bölümündeki hesap ve güvenlik sıkılaştırma notları burada da aynen geçerlidir.

Deer Workflow kurulumu ve sürüm sabitleme

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

command -v komutu, genellikle /home/<your user>/.bun/bin/deer-workflow olan mutlak yolu yazdırır. Bu yolu bir yere not edin. systemd birimi, yalın dosya adını kullanamaz.

Kurulum komutunda sürüm bilgisini koruyun. @0.2.0 kısmını kaldırmak, komutu çalıştırdığınız gün mevcut olan en yeni sürümü kurar; 47 commit içeren bir projede bu durum, kimsenin takip etmediği bir zamanlayıcı altında CLI aracının değişmesine neden olabilir.

Grafikleri bir git deposuna yerleştirin

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

Codex, bir git deposu içinde çalışıp çalışmadığını kontrol eder; bu nedenle CodexAgentConfig, bir depo sağlayamadığınız durumlar için skipGitRepositoryCheck seçeneğini barındırır. Kendi VPS'nizde bir depo sağlayabilirsiniz ve sağlamalısınız: bir grafik koddur ve orkestrasyonu kod olarak yazma gerekçesi, kod sürüm kontrolü altında değilse geçersiz kalır. systemd sizin yerinize oluşturmayacağı için logs dizinini şimdi oluşturun.

Bir grafik yazın

Bir iş akışı, standart bir TypeScript modülüdür. Modül; bir isim, açıklama ve sıralı aşama listesini içeren meta nesnesini ve işleyiciyi default olarak veya adlandırılmış bir run dışa aktarımı olarak dışa aktarır. İşleyicinin içinde paketten gelen yardımcıları çağırırsınız. phase() çalışmanın hangi aşamada olduğunu işaretler, log() bir ilerleme satırı yazar, agent() kodlama aracısına bir istem gönderir, parallel() bir görev listesini eş zamanlı olarak çalıştırır ve pipeline() bir öğe listesini birkaç aşamadan geçirir.

Bunu ~/workflows/log-triage.ts olarak kaydedin.

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))}`);
}

Bu dosyadaki dört detay önem taşır.

  • agent() çağrısı üzerindeki schema, yapılandırılmış çıktı talep eder ve çağrı, ayrıştırılmış nesneyi döndürür. found.patterns, grafiğin geri kalanının üzerinde döngü kurabileceği gerçek bir dizidir. Bir şema olmadan agent() bir metin döndürür ve düz metni ayrıştırmak zorunda kalırsınız.
  • sandbox, ilgili adımın nelere erişebileceğine karar verir. read-only yazma işlemlerini engeller, workspace-write korumalı yazmalara izin verir ve danger-full-access korumayı kaldırır. Bu ayar çağrı bazında yapıldığından, bir grafik geniş kapsamlı okuma yapıp tek bir noktaya yazabilir.
  • parallel(), promise değil fonksiyon alır. map((pattern) => () => agent(...)) bir thunk listesi oluşturur, böylece çalışma zamanı her birinin ne zaman başlayacağına karar verir. agent(...) doğrudan geçilirse, liste oluşturulduğu anda her çağrı başlatılır.
  • parallel() içindeki başarısız bir görev null durumuna dönüşür ve çalışma devam eder; çünkü kısmi tamamlanmaya tasarım gereği izin verilir. Bu nedenle notes.filter(Boolean) bir süsleme değildir: onu atlarsanız, başarısız olan dal bir sonraki adımın istemine null metnini ekler.

Sade agent() yardımcısı, varsayılan çalışma zamanı olan Codex'i kullanır. Bir adımı Claude Code'a göndermek için aracı sınıfını içe aktarın ve doğrudan çağırın.

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.");

Değiştirilebilir bir aracının pratikteki görünümü budur: tek bir içe aktarma ve bir kurucu; grafik ise değişmeden kalır. CLI üzerindeki --agent codex|claude|pi bayrağı, bir açıklamadan iş akışı dosyası oluşturan deer-workflow create aracına aittir. Bu bayrak, deer-workflow run tarafından kullanılan çalışma zamanını değiştirmez.

Önce manuel olarak çalıştırın, ardından headless moduna geçin

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

Etkileşimli modda bir terminal arayüzü elde edersiniz: bir tarafta meta aşamaları, diğer tarafta canlı günlük kayıtları yer alır. Otomasyona geçmeden önce tam bir çalıştırma sürecini bu şekilde izleyin. Eğer ajan oturum açmamışsa veya girdiğiniz veriler işleyici imzasıyla eşleşmiyorsa, bunu bir sonraki hafta günlük dosyasında aramak yerine saniyeler içinde fark edersiniz.

Otomasyon için girdiyi bir dosyaya taşıyın. ~/workflows/input.json dosyasını kaydedin:

{ "service": "nginx", "hours": 24 }
deer-workflow run ./log-triage.ts --input-file ./input.json --print >> logs/run.jsonl

--print (kısa formu -p), arayüzü kapatır ve olay akışını her satırda bir JSON nesnesi olacak şekilde stdout'a yazar. Bu modda stdout'a başka hiçbir veri gönderilmez; bu nedenle veriyi doğrudan bir .jsonl dosyasına eklemek, her satırı ayrıştırılabilir bir dosya elde etmenizi sağlar.

Olay akışı ve gece saat 03:00'te neyin aranacağı

Her satır type, sequence, timestamp, workflowId, depth ve scriptPath içerir. Türler workflow:start, workflow:meta, workflow:end, workflow:error, workflow:phase:start, workflow:phase:end ve log şeklindedir. Aşama olayları phase, bitiş olayları durationMs, bir log olayı message ve bir workflow:error olayı ise name, message ve genellikle stack ile birlikte error taşır.

Bu yapı, gece saat üçte aklınıza gelen iki soruyu yanıtlamak için yeterlidir: işlem tamamlandı mı ve nerede durdu.

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

Şu anda gerçekleşmekte olan bir çalışmayı izlemek için dosyayı takip edin: tail -f logs/run.jsonl | jq -c 'select(.type == "log")'. Tek bir çalışma az sayıda satır yazar ancak dosya sürekli büyür; bu nedenle zamanlayıcı birkaç haftadır çalışıyorsa ~/workflows/logs/*.jsonl için bir logrotate kuralı ekleyin.

systemd altında çalıştırma

Uzun süre çalışan bir daemon yerine, bir oneshot servisi ve bir zamanlayıcı (timer) kullanın. Grafik başlar, çalışır ve çıkar. /etc/systemd/system/log-triage.service dosyasını yazın ve deploy kısmını kendi kullanıcı adınızla değiştirin.

[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

Ardından /etc/systemd/system/log-triage.timer komutunu çalıştırın:

[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

Servisi önce manuel olarak başlatın. Sağlıklı bir çalışma, birimin başarıyla devre dışı kalmasıyla sonuçlanır ve logs/run.jsonl, workflow:end ile biten bir olay bloğu kazanır. Ancak bu aşamadan sonra zamanlayıcıyı etkinleştirin. list-timers bir sonraki planlanan çalışmayı yazdırır ve Persistent=true, sunucu kapalıyken kaçırılan bir çalışmanın bir sonraki açılışta bir kez gerçekleşeceği anlamına gelir. StandardOutput=append: olay akışını dosyaya gönderir ve günlüğü diğer her şey için bırakır, böylece journalctl -u log-triage.service okunabilir kalır.

Grafik neden kabukta çalışıyor da systemd altında başarısız oluyor?

Şu dört maddeyi bu sırayla kontrol edin.

Unit ikili dosyaları bulamıyor. systemd hiçbir zaman ~/.bashrc dosyasını okumaz ve varsayılan PATH değeri ne ~/.bun/bin ne de ~/.npm-global/bin dizinlerini içerir. Unit bir saniyeden kısa sürede başarısız olur ve journalctl -u log-triage.service komutun çalıştırılamadığını gösterir. ExecStart içinde mutlak yol kullanılmasının ve Environment=PATH= içinde her iki dizinin de listelenmesinin nedeni budur: çalışma zamanının, bir aracı adımı başlattığında codex veya claude dosyalarını bulması gerekir.

Aracı kimlik bilgilerini bulamıyor. Aracı CLI, giriş bilgilerini ev dizininden okur; bu nedenle User= ve Environment=HOME= değerlerini açıkça ayarlayın ve oturum açtığınız ev dizinini tanımlayın. workflow:start aşamasına ulaşan ve kendi kodunuzdan ziyade aracı CLI'dan gelen bir workflow:error mesajı üreten bir çalıştırma, neredeyse her zaman bu sorundan kaynaklanır.

Çalıştırma 90 saniye sonra sonlandırılıyor. Type=oneshot için systemd, başlatma zaman aşımını tüm komuta uygular ve varsayılan süre 90 saniyedir. Bir aracı grafiği dakikalar sürebilir. Günlük kaydı Start operation timed out. Terminating. mesajını içerir, unit başarısız durumda sonlanır ve günlük dosyası workflow:end olmadan yarım kalmış bir çalıştırma içerir. TimeoutStartSec=3600 bu süreye bir saat verir. Zaman aşımı nedeniyle asla sonlandırılmamasını tercih ederseniz infinity kullanın.

Göreli yollar başka bir yerde çözümleniyor. ./log-triage.ts ve ./input.json, WorkingDirectory dizinine göre belirlenir. Bu satırı çıkarırsanız systemd süreci, dosyaların hiçbirinin bulunmadığı / dizininde başlatır.

Orkestratörün yapabilecekleri

Zamanlayıcı üzerinde aracı adımlarını çalıştıran bir orkestratör, sunucunuzda denetimsiz şekilde hareket eden bir süreçtir. İki kontrol mekanizması ve bir bütçe önemlidir.

İlk kontrol, her agent() çağrısındaki korumalı alandır (sandbox). read-only, yalnızca okuma yapan (loglar, metrikler, özetlenen bir depo) her adım için doğru varsayılandır. Gerçekten yazma işlemi yapması gereken adımları workspace-write seviyesine taşıyın ve danger-full-access kullanmak yerine yazılabilir alanı additionalWritableDirectories ile kısıtlı tutun.

İkinci kontrol bir insandır. Bazı adımlar asla denetimsiz çalışmamalıdır: e-posta göndermek, para transferi yapmak, veri silmek veya üretim yapılandırmasını değiştirmek. Kod öncelikli bir grafikte onay mekanizmasını yerleştirmek kolaydır, çünkü adım bir kod satırından ibarettir. Çalışmayı durdurun, önerilen eylemi kaydedin, insan yanıtını bekleyin ve ardından devam edin. Aracı eylemlerinin önüne onay mekanizması koyma bu modeli bütünüyle ele alır ve bir zamanlayıcının başlattığı her grafikte bulunmalıdır.

Bütçe ise paradır. Her agent() çağrısı tam bir aracı oturumudur ve parallel() aynı anda birkaç tane başlatır; bu nedenle on iki dala ayrılan bir grafik, raporu kimse okumasa bile her gece on iki oturum çalıştırır. VPS üzerinde yapay zeka aracı maliyetlerini kontrol altında tutma içindeki ölçüm ve limitler, zamanlanmış bir grafiğe doğrudan uygulanır.

Çalışma zamanını (runtime) yükseltmeden önce değişiklik günlüğünü (changelog) okuyun, yeni tam sürümü yükleyin ve grafiğinizi --print ile manuel olarak bir kez çalıştırın. Bu kadar yeni bir projede CLI yüzeyi hala değişmektedir: Unreleased bölümü, 0.2.0 sürümünde var olan bir komutu şimdiden kaldırmıştır. Zamanlayıcı altındaki bir grafik, yalnızca sabitlediğiniz sürüm ve bizzat izlediğiniz son çalışma kadar güvenilirdir.

FAQ

Bun gerekli mi, yoksa Node.js Deer Workflow'u çalıştırır mı?

Bun kurun. Yayınlanan paket, deer-workflow ikili dosyasını bir TypeScript kaynak dosyası olan src/cli.ts konumuna yönlendirir ve belgeler Bun'ı bir ön koşul olarak listeler. Bun, TypeScript'i doğrudan çalıştırdığı için herhangi bir derleme adımı gerekmez. Kurulumu sudo apt install -y unzip ve ardından curl -fsSL https://bun.com/install | bash ile yapın, ardından bun --version ile doğrulayın. Codex CLI'ı npm üzerinden kurarsanız, Node.js ve npm'e ayrıca ihtiyacınız olacaktır.

İş akışım terminalde çalışıyor ancak systemd altında neden başarısız oluyor?

Bunun nedeni neredeyse her zaman PATH, HOME veya başlatma zaman aşımıdır. systemd, shell profilinizi okumaz; bu nedenle ExecStart, deer-workflow için mutlak yolu içermeli ve Environment=PATH=, codex veya claude dosyalarını barındıran dizini göstermelidir. Agent CLI, kimlik bilgilerini $HOME konumundan okur; bu yüzden User= ve Environment=HOME= değişkenlerini oturum açtığınız hesapla eşleşecek şekilde ayarlayın. Ayrıca Type=oneshot, 90 saniyelik bir başlatma zaman aşımına sahiptir; bu süre, agent çalışmasını yarıda keser ve günlükte Start operation timed out. Terminating. hatasını bırakır, bu yüzden TimeoutStartSec=3600 değerini ayarlayın.

Bir adım için Codex yerine Claude Code'u nasıl kullanırım?

Standart agent() yardımcısı, varsayılan çalışma zamanı olan Codex'i kullanır. Paketten ClaudeAgent öğesini içe aktarın, yapılandırın ve Claude Code'un işlemesini istediğiniz adımlar için .run() metodunu çağırın. --agent codex|claude|pi bayrağı, bir açıklamadan iş akışı dosyası oluşturan deer-workflow create komutuna aittir ve deer-workflow run üzerinde bir etkisi yoktur. Hangi agent'ı kullanırsanız kullanın, kendi CLI'ının kurulu olması ve servisin çalıştığı kullanıcı ile oturum açılmış olması gerekir.

Hangi Deer Workflow sürümünü kurmalıyım?

Test ettiğiniz sürümü kurun. 19 Ağustos 2026 itibarıyla en yeni yayınlanan sürüm, 27 Temmuz 2026 tarihli 0.2.0'dır ve depo 47 commit içermektedir. Kurulum komutuna @0.2.0 veya bu metni okuduğunuz sırada güncel olan sürümü yazın, bu numarayı grafiklerinizle birlikte git üzerinde tutun ve her yükseltmeden sonra zamanlayıcı tekrar devreye girmeden önce bir grafiği manuel olarak çalıştırın.