OpenTag'i VPS'te self-host etme rehberi

OpenTag bir agent belirtildiğinde ne yapar

OpenTag, bir Slack thread'inde veya GitHub issue'sunda yapılan @mention işlemini, sahibi olduğunuz bir makinede çalışan bir coding agent oturumuna dönüştürür. Bir kullanıcı issue üzerine @opentag investigate this yorumunu ekler. Bir listener platform olayını alır, imzasını doğrular, mention bilgisini bağlı bir projeyle eşleştirir, yerel checkout üzerinde bir coding agent başlatır ve sonucu aynı thread'e gönderir.

Proje MIT lisanslıdır ve amplifthq/opentag adresinde bulunur. Ağustos 2026 itibarıyla en yeni etiketli sürüm, 28 July 2026 tarihinde yayımlanan v0.9.0 sürümüdür ve npm paketi olarak dağıtılır. Resmî bir container image bulunmadığından sabitlenmesi gereken sürüm npm sürümüdür. Aşağıdaki her komut bu sürümü sabitler.

GitHub tarafı nedeniyle bu proje laptop projesi olmaktan çıkar ve VPS projesine dönüşür. GitHub, repository olaylarını bir kez kaydettiğiniz URL'ye HTTP isteği göndererek iletir. Bu nedenle söz konusu URL'nin yarın da aynı adreste yanıt vermesi gerekir.

Dört bileşen

Listener, platform olaylarını alır ve her platformun kendine ait bir listener bileşeni vardır. GitHub listener bileşeni, 3050 portunda /github/webhooks yolunu kullanan bir HTTP endpoint'idir. Slack Events API listener bileşeni, 3040 portunda /slack/events adresinde çalışır. Slack ayrıca Socket Mode ile çalışabilir. Bu modda uygulama dışarıya doğru bir WebSocket bağlantısı açar ve gelen bağlantılar için port açılması gerekmez.

Dispatcher, koordinatör bileşendir. Varsayılan olarak 3030 portunu dinler, çalışma durumunu OPENTAG_DATABASE_PATH ile belirtilen yerel veritabanı dosyasında tutar ve her çalışma için denetim kaydı oluşturur. Bu porta hiçbir dış sistemin erişmemesi gerekir.

Runner, yerel daemon'dır. İşleri yoklar, bir çalışmayı üstlenir, çalışma üzerinde lease tutar ve çalışma devam ettiği sürece varsayılan olarak her 15 saniyede bir heartbeat gönderir. Proje hedefi eksikse veya kendi yapılandırmasındaki allowlist dışında kalıyorsa üstlenilen çalışmayı reddeder. Bu kontrol, bir GitHub olayının agent'ı hiç bağlamadığınız bir repository'ye yönlendirmesini engeller.

Executor, coding agent'ın kendisidir. OpenTag, agent'ı ACP (agent client protocol) üzerinden başlatır. ACP, standart giriş ve çıkış üzerinden kullanılan bir JSON-RPC protokolüdür. Böylece agent, OpenTag'ın sağladığı çalışma dizini içinde child process olarak çalışır. Yerleşik adlar arasında echo, codex, claude-code, cursor, opencode, hermes ve openclaw bulunur. Örnek yapılandırmayla birlikte gelen executor olan echo ile başlanmalıdır. Bu executor, bir model kodunuza dokunmadan önce tüm akışın çalıştığını doğrular.

Sıra hiçbir zaman değişmez: platform olayı, signature kontrolü, çalışma kaydı, üstlenme, agent, thread'e yanıt.

Bir laptop ve tunnel neden yeterli değildir

GitHub kurulum kılavuzu, ngrok http 3050 komutunu çalıştırmanızı ve tunnel host bilgisini repository webhook yapılandırmasına yapıştırmanızı ister. Bu yöntem ilk on dakika çalışır. Ücretsiz bir tunnel host, işlem her yeniden başlatıldığında değişir ve laptop uykuya geçtiğinde kullanılabilirliğini kaybeder. GitHub eski payload URL bilgisini saklar ve bu adrese istek göndermeyi sürdürür. Bu nedenle webhook ayarlarındaki Recent Deliveries sekmesi hatalarla dolar, ancak thread sessiz kalır. Kimse bir hafta boyunca bunu fark etmez. Çünkü hiçbir işlem yapmayan bir webhook, hakkında kimsenin söz etmediği bir botla aynı şekilde görünür.

Bir VPS, sorun çıkaran iki noktayı düzeltir. DNS adı değişmez. Böylece bir kez yapıştırılan payload URL doğru kalır. Makine uykuya geçmez. Bu nedenle 02:00'de yazılan bir yoruma yanıt verilebilir. Önce sunucuyu doğru şekilde hazırlayın: yeni bir VPS üzerindeki ilk on dakika, bu kılavuzun varsaydığı login user ve firewall yapılandırmasını açıklar.

Slack istisnadır. Socket Mode'da dışarıya doğru bağlantı kurar ve public URL gerektirmez. Bu nedenle yalnızca Slack kullanılan bir deployment dışarıya kapalı kalabilir. GitHub'da bunun eşdeğeri yoktur. Repository webhook'ları inbound HTTP kullanır. Bu da public endpoint, TLS (transport layer security) ve signature check gerektirir.

Ubuntu üzerinde sabitlenmiş bir sürümden OpenTag self-host kurulumu

OpenTag v0.9.0, Node.js 22 veya daha yeni bir sürüm gerektirir. Ubuntu 24.04 kendi deposunda Node 18 sürümünü sunar. Bu nedenle NodeSource üzerinden kurulum yapılmalıdır.

curl -fsSL https://deb.nodesource.com/setup_22.x -o nodesource_setup.sh
sudo -E bash nodesource_setup.sh
sudo apt install -y nodejs
node -v

node -v çıktısı v22 veya daha yüksek olmalıdır. Node 20 kullanıldığında kurulum bir EBADENGINE uyarısı verir ve CLI başladıktan sonra başarısız olabilir.

Servise ayrı bir kullanıcı hesabı verin. Agent bu kullanıcının izinleriyle çalışır. Bu nedenle hesabın oturum açma hesabınız olmaması ve root olmaması gerekir. VPS üzerinde en az ayrıcalıklı kullanıcılar, bu ayrımın ek adıma neden değer olduğunu açıklar.

sudo adduser --disabled-password --gecos "" opentag
sudo loginctl enable-linger opentag
sudo npm install -g @opentag/cli@0.9.0
command -v opentag

command -v opentag, /usr/bin/opentag gibi bir yol yazdırmalıdır. Linux üzerinde linger ayarı önemlidir. OpenTag arka plan servisini systemd üzerinden kurar. Linger etkin değilse kullanıcı servisi SSH oturumu kapandığı anda durur.

Kurulumu bu kullanıcıyla çalıştırın.

sudo -iu opentag opentag setup

Kurulum altı bilgi ister: CLI dili, yerel dinleme adresi, coding agent, üzerinde çalışılacak yerel proje, kaydedilecek platform kimlik bilgileri ve çalıştırma yöntemi. Dinleme adresini 127.0.0.1 olarak bırakın. nginx TLS termination işlemini yapar ve trafiği bu adrese iletir. Böylece dinleyicilerin dışarıdan erişilebilir olması gerekmez. GitHub için ayrıca owner/repo biçiminde repository, pull request açılmasına izin verilip verilmeyeceği, webhook portu (varsayılan olarak 3050) ve token sorulur. Sonda background service mode seçilmelidir. Zaten bir config dosyanız varsa ve servisi soru sormadan kurmak istiyorsanız opentag setup --service bunu yapar.

Config /home/opentag/.config/opentag/config.json konumuna, runtime state ise /home/opentag/.local/state/opentag konumuna yazılır. Kurulum dosyayı yazdıktan sonra bu anahtarlar elle kontrol edilmelidir.

{
  "runnerId": "runner_local",
  "dispatcherUrl": "http://localhost:3030",
  "runnerToken": "...",
  "approvalMode": "ask",
  "repositories": []
}

Eski paylaşılan pairingToken yerine runner kapsamındaki bearer token olan runnerToken tercih edilmelidir. Secret reference ile değiştirilmediği sürece config dosyası kimlik bilgilerini düz metin olarak tutar. Secret reference kullanıldığında değer, başlangıçta environment üzerinden veya diskteki bir dosyadan okunur. Her iki durumda da bu dosya sunucudaki en hassas öğedir: mode 600 olmalı, sahibi opentag olmalı ve hiçbir zaman bir git repository içinde bulunmamalıdır. Konunun daha geniş açıklaması secret bilgileri AI agent'larından uzak tutma bölümündedir.

Herhangi bir şeyi dışarı açmadan önce kurulumu kontrol edin.

sudo -iu opentag opentag doctor
sudo -iu opentag opentag status

opentag doctor dispatcher'ı, binding'leri, checkout'ları ve executor'ları kontrol eder. opentag status config ve runtime state bilgilerini yazdırır. Run'lar mevcut olduğunda tek bir run kapsamına da alınabilir. Bir platformu bu sunucuya yönlendirmeden önce doctor tarafından bildirilen tüm sorunları düzeltin.

TLS'yi öne alın ve yalnızca iki yolu açın

nginx, TLS sonlandırması yapar ve tam olarak iki yolu yönlendirir. Diğer tüm istekler 404 döndürür. Böylece sunucuyu bulan bir tarayıcı, arka planda ne çalıştığı hakkında bilgi edinemez.

/etc/nginx/sites-available/opentag üzerinde, aşağıdaki iki location ile basit bir port 80 server bloğu yazın. Ardından TLS bölümünü Certbot'un eklemesine izin verin.

sudo apt install -y nginx certbot python3-certbot-nginx
sudo ln -s /etc/nginx/sites-available/opentag /etc/nginx/sites-enabled/opentag
sudo nginx -t && sudo systemctl reload nginx
sudo certbot --nginx -d opentag.example.com

nginx -t, syntax is ok ve test is successful çıktısını verir. Siteyi devre dışı bırakan bir yeniden yükleme ile yazım hatası arasındaki tek güvenlik kontrolü budur. Ubuntu 24.04 üzerinde nginx ile Certbot, yenileme işlemini ve bir ACME (otomatik sertifika yönetimi ortamı) challenge işleminin başarısız olabileceği durumları açıklar. Tamamlanmış blok aşağıdaki gibi görünür.

server {
    listen 443 ssl;
    server_name opentag.example.com;

    ssl_certificate     /etc/letsencrypt/live/opentag.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/opentag.example.com/privkey.pem;

    client_max_body_size 2m;

    location = /github/webhooks {
        proxy_pass http://127.0.0.1:3050;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
    }

    location = /slack/events {
        proxy_pass http://127.0.0.1:3040;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
    }

    location / {
        return 404;
    }
}

location = /github/webhooks içindeki = tam eşleşmedir. Port numarasından sonra başka bir içerik bulunmayan proxy_pass, özgün URI'yi değiştirmeden iletir. = kaldırılırsa /github/webhooks/ altındaki her yol da yönlendirilir. Bu, listener'ın ihtiyaç duyduğundan daha geniş bir saldırı yüzeyi oluşturur.

Güvenlik duvarı kapsamı dar tutulur.

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw status

3030, 3040 ve 3050 numaralı portlar hiçbir zaman açılmaz. Bu portların tüm arayüzlerde değil, loopback üzerinde bağlı olduğunu doğrulayın.

sudo ss -tlnp

Her OpenTag satırı 127.0.0.1:3030 veya benzeri şekilde görünmelidir. 0.0.0.0:3050 şeklindeki bir satır, listener'ın kendisini tüm internete açtığı ve onu yalnızca ufw'nin durdurduğu anlamına gelir. Bu durum, tek bir firewall hatasıyla açık bir agent trigger'ına dönüşebilir. ufw firewall temelleri, varsayılan deny davranışının gerçekte ne yaptığını açıklar.

Ön kapıyı iki kontrol doğrular. curl -I https://opentag.example.com/, nginx'ten 404 döndürür. Bu sonuç, sertifikanın geçerli olduğunu ve catch-all yapılandırmasının kapalı olduğunu gösterir. İmza taşımayan /slack/events veya /github/webhooks isteği hiçbir zaman 200 döndürmemelidir.

Her imza doğrulanmalıdır; URL herkese açıktır

Payload URL'sini herkes bulabilir. Bu URL repository ayarlarında, tarayıcı geçmişinde veya bir ticket'a eklenmiş ekran görüntüsünde yer alabilir. İmza, gerçek bir GitHub delivery ile birinin elle oluşturduğu isteği birbirinden ayıran tek unsurdur.

GitHub her delivery işlemini webhook secret ile imzalar ve sonucu x-hub-signature-256 header'ında gönderir. OpenTag bu header'ı platforms.github.webhookSecret değerine karşı doğrular. Projenin hardening notlarında kural doğrudan belirtilir: /github/webhooks üzerinde imzasız source event'leri kabul edilmemelidir. Slack her isteği SLACK_SIGNING_SECRET ile imzalar ve timestamp ekler. Böylece ele geçirilmiş bir body saatler sonra yeniden kullanılamaz.

Bunun atlanması küçük bir risk değildir. Doğrulanmayan bir endpoint, @opentag içeren elle yazılmış bir issue_comment payload'ını kabul eder. Bunun ardından OpenTag, token'ınızı kullanarak checkout dizininizde bir coding agent çalıştırır ve bu agent yabancının talimatlarını izler. Yanıt, sahte payload'ın belirttiği thread'e gönderilir.

OpenTag bunun üzerine iki katman daha ekler. Source delivery işlemleri delivery ID ile izlenir. Böylece aynı event yeniden gönderildiğinde ikinci bir çalışma başlatılmaz. Runner çağrıları idempotency key kabul eder. Bu nedenle bir çağrı yeniden oynatıldığında, başka bir audit event eklenmeden başarı döndürülür.

Rate limit'ler yapılandırılabilir ve etkinleştirilmelidir. OPENTAG_RATE_LIMIT_WINDOW_MS ve OPENTAG_RATE_LIMIT_MAX_REQUESTS istek hızını sınırlar, OPENTAG_MAX_REQUEST_BODY_BYTES body boyutunu sınırlar ve boyutu aşan bir payload 413 request_body_too_large ile reddedilir. OPENTAG_RATE_LIMIT_DISABLED=true yerel geliştirme için vardır ve public bir sunucuda kullanılmamalıdır. Aynı notlardaki bir başka kural şöyledir: public relay URL'si HTTPS kullanmalıdır. CLI, plain HTTP'ye yalnızca localhost için izin verir.

Bot gerçekte hangi token kapsamlarına ihtiyaç duyar?

GitHub üzerinde OpenTag, GitHub App yerine ayrıntılı izinli bir personal access token kullanır. Belgelerde App yönteminin planlandığı ve bugün varsayılan CLI kurulumu olmadığı belirtilir. Bunun gözden kaçan bir sonucu vardır: Bot, token'ı oluşturan kullanıcı olarak yorum yapar. Bu nedenle token, her triage yanıtında adının görünmesini kabul edeceğiniz bir hesap altında oluşturulmalıdır.

Kapsamı kurulum kılavuzunda belirtildiği kadar dar tutun. Only select repositories seçeneğini belirleyin ve bir repository seçin. Issues: Read and write ile Pull requests: Read and write izinlerini verin. Bir mention'ı okumak ve thread içinde yanıt vermek için bu izinler yeterlidir.

Eksik olan izne dikkat edin: code için write erişimi yoktur. preparePullRequestBranch true olarak ayarlanmadıkça OpenTag branch push etmez. Ayrıca code yazan token ile yorum yazan token'ın ayrı olması için githubApplyToken bulunur. Bu token'ları birbirinden ayrı tutun ve read-and-comment yolu birkaç hafta çalışana kadar write token'ı etkinleştirmeyin.

Kaçınılması gereken yapılandırma, All repositories genelinde Contents: Read and write izinlerine sahip bir token kullanmaktır. Bu repository'lerden herhangi birinde yorum yapabilen herkes, artık commit haklarına sahip bir agent'ı yönlendirebilir. Denetim kaydı da bu işlemi token sahibinin yaptığını gösterir. Kapsamı, agent bunu hak ettiğini kanıtladıktan sonra her seferinde bir repository olacak şekilde genişletin.

Slack üzerinde bot kapsamları app_mentions:read, chat:write, reactions:write ve channels:history değerleridir. Private channel'lar ayrıca groups:history iznini ve message.groups event'ine aboneliği gerektirir. Socket Mode için connections:write kapsamına sahip, xapp- ile başlayan bir app-level token gerekir. channels:history, botun eklendiği public channel'ların message history kayıtlarını okur. Bu nedenle botu her yere eklemek yerine, kullanılacağı channel'lara ekleyin.

Bir sorunu uçtan uca yönlendirme

İlk olarak webhook yapılandırılmalıdır. Repository içinde Settings, ardından Webhooks ve Add webhook seçilmelidir. Payload URL değeri https://opentag.example.com/github/webhooks, content type değeri application/json olmalıdır. Secret olarak kurulum sırasında oluşturulan değer kullanılmalıdır. Yalnızca Issue comments ve Pull request review comments abonelikleri seçilmelidir.

Kaydedildikten hemen sonra GitHub bir ping delivery gönderir. Recent Deliveries bölümünü açıp isteğin sunucuya ulaşıp ulaşmadığı kontrol edilmelidir. Buradaki 502 yanıtı, nginx'in listener'a erişemediğini gösterir. Bu, GitHub kaynaklı değil, yerel bir sorundur.

Şimdi işlem test edilmelidir. Bir hatayı açıklayan issue açılıp şu yorum eklenmelidir:

@opentag triage this. Reproduce the report against the current main branch, then reply with the file and function most likely responsible, plus the test you would write first.

Beklenen sıra şöyledir. Recent Deliveries, issue_comment delivery kaydını 2xx yanıtıyla gösterir. Dispatcher bir run kaydı oluşturur. Runner bu kaydı alır ve heartbeat göndermeye başlar. Executor checkout'u açar ve çalışır. Yanıt, aynı issue thread'i içinde yorum olarak görünür. sudo -iu opentag opentag status, run devam ederken durumunu gösterir. Böylece tahmin yürütmek yerine süreç izlenebilir.

İlk gerçek run başlamadan önce approvalMode değeri ask olarak ayarlanmalıdır. ask modunda run duraklatılır ve durum değişikliğine yol açan herhangi bir işlem yapılmadan önce bir kişinin onayı beklenir. auto ve autonomous modları da kullanılabilir. Ancak bunlar, bir ay boyunca transcript kayıtları incelenmiş bir repository için daha sonra tercih edilmelidir.

Slack tarafında aynı run, kanalda /bind owner/repo ile başlar. Ardından bir mention gönderilir. Bot ayrıca /help, /status, /doctor, /stop ve /unbind confirm değerlerine yanıt verir. Binding değiştirme yetkisi OPENTAG_SLACK_BINDING_ADMIN_USER_IDS ile sınırlandırılmalıdır. Bu değer, virgülle ayrılmış Slack user ID listesidir. Bunun nedeni, binding'in bir public channel ile sunucudaki checkout arasındaki eşleştirme olmasıdır.

Triage, okuma yaptığı ve yazma işlemi gerçekleştirmediği için iyi bir başlangıç yoludur. Ayrıca yanıtın değerlendirilmesi kolaydır. Bir sonraki adım, agent'ın issue yerine diff üzerinde yorum yaptığı Review işlemidir: self-hosted pull request review agent, pull request'lere yönlendirilmiş aynı mimaridir. Agent'ın çalışırken kendi sistemlerinize erişmesini istiyorsanız bunun için VPS üzerinde MCP sunucuları kullanılmalıdır.

Herkesin önünde agent yanlış yaptığında ne olur?

Yanlış yapacaktır. Önemli olan bunun maliyetidir.

Herkese açık bir issue altındaki yanlış yanıt, ekibinizin tanıdığı bir adla yayımlanan bir yorumdur ve GitHub, yorum yayımlandığı anda bu issue'ya abone olan herkese e-posta gönderir. Yorumu silmek, e-postayı geri çekmez. Aynı durum Slack bildirimi için de geçerlidir. Yanıtın özel ortamda doğru olacağını varsaymak yerine, herkese açık ortamda yanlış olabileceğini varsayarak planlama yapılmalıdır.

Dört tercih zararı sınırlar ve bunlar, yazılabilecek herhangi bir prompt'tan daha önemlidir.

• ask modunda çalıştırılmalıdır. Böylece agent öneride bulunur, bir kişi onay verir ve yanlış bir planın maliyeti tek bir tıklamayla sınırlı kalır.
• preparePullRequestBranch varsayılan false değerinde bırakılmalıdır. Böylece hatalı bir çalışmanın en kötü sonucu yanlış bir branch olur; yanlış bir değişiklik uygulanmaz.
• Başlangıçta tek bir repository ve tek bir channel bağlanmalıdır. Runner, project target yerel allowlist dışında kaldığında çalışmayı reddeder. Böylece bağlı olmayan bir repository agent'ı kendi içine çekemez.
• Commenting token, apply token'dan ayrı tutulmalıdır. Böylece write erişiminin iptal edilmesi triage işlemlerini de durdurmaz.

Yanlış yönde ilerleyen bir çalışma için Slack'te /stop komutu bulunur. Her çalışma ayrıca, onu başlatan mention'ı ve agent'ın yaptığı işlemleri içeren bir audit kaydı bırakır. Daha sonra hatanın nerede oluştuğunu belirlemek için bu kayıt incelenir.

Sosyal boyut, yapılandırma kadar önemlidir. Bot, insanların bir makineyle iletişim kurduğunu bildiği ve botun hata yapabileceğini kabul ettiği tek bir channel'a eklenmelidir. İnsan tarafından incelendiği varsayılan kırk kişilik bir channel'da verilen kendinden emin ancak yanlış bir yanıtın maliyeti, sağlanan triage tasarrufundan daha yüksek olabilir. Channel açıklamasında botun sorumlusunun ve çıktısını kimin kontrol ettiğinin belirtilmesi gerekir.

Yedekler, yükseltmeler ve sürüm sabitleme

Her şeyi iki yol tutar: /home/opentag/.config/opentag/config.json ve /home/opentag/.local/state/opentag. İlkinde kimlik bilgileriniz, ikincisinde çalıştırma geçmişi ve veritabanı dosyası bulunur. İkisinin de yedeği 600 modu ile alınmalı ve sunucu dışında saklanmalıdır. Bunların kaybedilmesi, sunucuyu yeniden kurmak yerine token'ların ve eşlemelerin yeniden oluşturulmasını gerektirir.

Yükseltme, sürümün değiştirilmesi ve servisin yeniden başlatılmasıdır.

sudo npm install -g @opentag/cli@0.9.0
sudo -iu opentag opentag service stop
sudo -iu opentag opentag service start
sudo -iu opentag opentag doctor

@latest sürümünü takip etmek yerine sürümü sabitleyin. Bu yazılım, canlı bir token kullanarak deponuz üzerinde bir kodlama aracısı çalıştırır. Bu nedenle gece yayımlanan bir sürüm, bu yapı üzerinde incelenmemiş bir değişiklik anlamına gelir. Güvenlik politikası geriye dönük düzeltmeleri içermez ve düzeltmeler yalnızca en yeni sürümde yayımlanır. Bu nedenle sürüm sabitleme, değişiklik günlüğünü okuyup bilinçli biçimde yükseltme yapmayı gerektirir. Bu, sonsuza kadar v0.9.0 sürümünde kalmak anlamına gelmez. Temmuz 2026'ya kadarki geçmişte ayda birkaç sürüm yayımlandığı görülür. Bu da her sürüm değişikliğinden önce sürüm notlarının okunması için iyi bir nedendir.

FAQ

OpenTag çalıştırmak için VPS gerekir mi, yoksa bir laptop yeterli olur mu?

Yalnızca Slack için bir laptop yeterlidir; çünkü Socket Mode dışa doğru bir WebSocket bağlantısı açar ve gelen bağlantılar için port gerekmez. GitHub farklı çalışır. Repository webhook'ları, bir kez kaydettiğiniz URL'ye gelen HTTP üzerinden iletilir. Bu nedenle adres sabit kalmalı ve siz uyurken de yanıt vermelidir. Ücretsiz bir hesaptaki tunnel host her yeniden başlatmada değişir. GitHub ise eski adrese gönderim yapmayı sürdürür. Bu durum, repository içindeki Recent Deliveries sekmesinde başarısız kayıtlar ve thread'de sessizlik olarak görülür. Sabit DNS adına ve sertifikaya sahip bir VPS her iki sorunu da ortadan kaldırır.

OpenTag hangi GitHub izinlerine ihtiyaç duyar?

Only select repositories ile sınırlandırılmış fine-grained personal access token kullanılmalıdır. Bu token için Issues: Read and write ile Pull requests: Read and write izinleri yeterlidir. Bu izinler bir mention'ı okumayı ve thread içinde yanıt vermeyi sağlar. preparePullRequestBranch değeri true olarak ayarlanmadığı sürece kod yazma izni gerekmez. Bu değer true olduğunda OpenTag branch gönderir. Kod yazma token'ını yorum yazma token'ından ayrı tutmak için githubApplyToken de bulunur. Tüm repository'lere erişen ve contents write izni olan bir token kullanılmamalıdır. Çünkü bu repository'lerden herhangi birine yorum yazabilen herkes commit atabilen bir agent'ı yönlendirebilir.

Hatalı ilerleyen bir çalışmayı nasıl durdurabilirim?

Slack bunun için özel olarak bir /stop komutu sağlar. Sunucuda opentag status komutu hangi işlemlerin çalıştığını gösterir. opentag service stop ise daemon'ı durdurur ve tek bir çalışmayı değil, tüm pipeline'ı sonlandırır. Bu komutlara ihtiyaç duymamak için approvalMode değerini ask olarak ayarlayın. Böylece çalışmalar herhangi bir değişiklik yapmadan önce bir kişinin onayını bekler. Ayrıca preparePullRequestBranch değerini false olarak bırakın. Bu durumda hatalı bir çalışma branch oluşturmak yerine yorum üretir.

Thread sessiz kalırken webhook neden 502 döndürüyor?

502 hatası OpenTag'den değil, nginx'den kaynaklanır. Proxy'nin listener'a ulaşamadığı anlamına gelir. /var/log/nginx/error.log çıktısında connect() failed (111: Connection refused) while connecting to upstream görülür. Listener durmuş olabilir veya proxy_pass satırında belirtilenden farklı bir portta çalışıyor olabilir. sudo ss -tlnp komutunu çalıştırın. GitHub için 127.0.0.1:3050, Slack için 127.0.0.1:3040 üzerinde bir listener'ın dinlediğini doğrulayın. Ardından binding'leri ve executor'ları görmek için opentag doctor komutunu çalıştırın.