OpenBot AI iş arkadaşları kendi sunucunuzda nasıl kurulur?

OpenBot AI iş arkadaşlarınızı kendi sunucunuzda barındırdığınızda elde ettikleriniz

OpenBot AI iş arkadaşlarını, kontrolünüz altındaki donanım üzerinde bir ağ geçidi (gateway) sunucusu ve her bot için bir container çalıştırarak kendi sunucunuzda barındırırsınız. Her bot container'ı, kendi Chromium tarayıcısını ve oturumlar arasında kalıcı olan bir tarayıcı profiline sahip kendi çalışma alanı birimini (workspace volume) beraberinde getirir. Bir botun bilgisayar, dosya, MCP (model context protocol) sunucusu veya bir arayüz bileşeni üzerinde gerçekleştirdiği her eylem, bu ağ geçidinden geçer. Ağ geçidi, eylem gerçekleşmeden önce onu bir politika ile denetler ve gerçekleştikten sonra kaydeder. Ağ geçidinin çevrelediği ajan döngüsü henüz yabancı olduğunuz bir konuysa, sıfırdan AI ajanları öğrenme bölümündeki aşamalı yol, bir bota tarayıcı ve giriş bilgilerinizi vermeden önce küçük bir tanesini kendiniz yazmanızı sağlar.

OpenBot, CopilotKit tarafından MIT lisansı altında github.com/CopilotKit/openbot adresinde yayımlanmaktadır. İlk etiketli sürüm olan v0.0.1, 17 Ağustos 2026 tarihinde yayımlanmıştır ve proje kendisini alfa aşamasında ve aktif geliştirilmekte olan bir proje olarak tanımlamaktadır. Bu projeyi, henüz geliştirilme aşamasında olan ancak ciddi bir tasarıma sahip bir yapı olarak değerlendirin.

Bu mimarinin ilginç kısmı aynı zamanda maliyetli olan kısmıdır. Her ajan için bir tarayıcı çalıştırmak, çoğu kişinin planlamayı unuttuğu bir bellek maliyeti doğurur; bu nedenle kurulumdan önce boyutlandırma işlemi yapılmalıdır.

Ağ geçidinin her eyleme nasıl karar verdiği

3001 numaralı port üzerindeki API sunucusu, bir botun bilgisayarına giden tek yoldur. Bir tarayıcı eylemi çalıştırılmadan önce ağ geçidi, hedefi bir sayfa anlık görüntüsünden çözer, bağlama karşı CEL (common expression language) ilke kurallarını değerlendirir, kararı içeren bir denetim satırı yazar ve ancak o zaman container'ı çağırır. Eğer yürütme bundan sonra başarısız olursa, ikinci bir satır yazar. Belgeler sınırı açıkça belirtir: bilgisayar ilkeye karar vermez, eylem sınırı sunucu ağ geçididir. Bu ayrımın OpenBot dışında da bir adı vardır; çünkü döngü, araç tanımları, izin kontrolleri ve oturum durumu bir araya gelerek modelin etrafına sarılı bir çerçeve oluşturur ve bu ağ geçidi, bu çerçevenin izin tarafını temsil eder.

İlke varsayılan olarak reddetme (deny-by-default) şeklindedir ve reddetme kuralları, izin verme kurallarından önce değerlendirilir. Başarısızlık yönü, kural sözdiziminden daha önemlidir. Eksik bir ilke hiçbir şeye izin vermez ve bozuk bir kural, reddetme veya izin verme kuralı olmasına bakılmaksızın engelleme yönünde başarısız olur; bu nedenle ilkenizdeki bir hata, hesaplarınızda serbestçe dolaşan bir bot yerine, takılıp kalmış bir bota neden olur. Bu katman, botun ne okuduğunu değil, ne yaptığını yönetir; bu nedenle aracıya yönelik talimatlar içeren bir sayfa ayrı bir sorun olarak kalır ve bu, kendi SearXNG örneğinizden gelen sonuçları bir aracıya verdiğinizde karşılaştığınız istem enjeksiyonu (prompt injection) yüzeyi ile aynıdır.

Denetim izi PostgreSQL içinde tutulur, bu nedenle yeniden başlatma sonrasında varlığını korur. Kontrol devirleri computer.help_requested, computer.control_taken ve computer.control_released olarak kaydedilir; botun bir insandan yardım istediğini ve insanın kontrolü nasıl geri verdiğini bu şekilde görürsünüz. Sırlar, değer olarak değil, karakter sayısı olarak kaydedilir. Dosya işlemleri, içeriği değil, yolu ve boyutu kaydeder. Arkasında bir tarayıcı olmadan aynı kontrol sınırını istiyorsanız, yapay zeka aracı eylemlerini onay mekanizmalarıyla kısıtlamak bu daha dar kapsamlı durumu ele alır.

Bir botun RAM ve disk maliyeti

Proje, arm64 mimarisinde tek bir Bot için ölçülen değerleri yayınlamaktadır. OpenBot tarafından sağlanan tek boyutlandırma verileri bunlardır ve bunlar tek bir mimarideki tek bir botu tanımlar; bu nedenle bunları bir kapasite planı olarak değil, bir başlangıç noktası olarak değerlendirin.

[
  {
    "label": "Measured, one Bot",
    "memory_gb": 0.55,
    "disk_gb": 5.3,
    "vcpu": 0.06
  },
  {
    "label": "Documented minimum",
    "memory_gb": 2,
    "disk_gb": 8,
    "vcpu": 1
  },
  {
    "label": "Documented recommended",
    "memory_gb": 4,
    "disk_gb": 10,
    "vcpu": 2
  }
]

Bir Bot için tepe bellek kullanımı 0.55 GB olarak ölçülmüştür; belgelenen minimum değer 2 GB, önerilen değer ise 4 GB'dir. Ölçülen değer ile minimum değer arasındaki fark, Chromium'un yük altında büyümesi için bırakılan alandır; çünkü bir tarayıcının bellek kullanımı boşta olduğu ana göre değil, açık olan sayfalara göre değişir. Boştaki CPU kullanımı, ölçülen aralığın en üstünde bir çekirdeğin 0.06 kadarıdır, yani CPU darboğaz yaratacak kaynak değildir. Asıl kaynak disktir. Sadece imajın boyutu 5.3 GB'dir, önerilen birim boyutu ise 10 GB'dir. Bu kadar büyük olmasının nedeni, Playwright'ın Firefox ve WebKit ikililerini Chromium ile birlikte barındırmasıdır.

Bu verilerin hiçbiri, birden fazla botun toplam maliyetini göstermez ve proje bunun için bir rakam yayınlamamaktadır. Belgelenen minimum değer, projenin yayınlamayı uygun gördüğü bir sayıdır; yük altında gözlemlenmiş bir değer değildir. PhotoPrism ve Immich arasında seçim yaparken yayınlanan değerler yerine ölçülen RAM taban değerlerinin dikkate alınmasının nedeni de budur. Kendi ölçümlerinizi yapın. Bir bot başlatın, ona açık bir sayfa ile gerçek bir görev verin ve çalışırken container'ı izleyin.

docker stats --no-stream
free -m

Botun container'ı için MEM USAGE sütununu bot başına düşen değer olarak alın, üzerine gateway ve PostgreSQL maliyetlerini ekleyin ve ardından bu toplamı aynı anda çalışmasını beklediğiniz bot sayısıyla çarpın. Boştaki bir bot bile bir tarayıcı süreci tutar, bu nedenle çarpan sadece meşgul olan botlara değil, var olan tüm botlara uygulanır. Bu aritmetik, bir kodlama ajanı VPS'i için RAM ve CPU boyutlandırma işleminde kullanılanla aynıdır ve bunun tarayıcı tarafı VPS üzerinde ajanlar için headless tarayıcı çalıştırma bölümünde ele alınmıştır.

Bir Chromium detayı küçük planları etkiler. OpenBot, Chromium'u --disable-dev-shm-usage ile başlatır, böylece tarayıcı /dev/shm yerine /tmp dizinine yazar. Bu, küçük bir /dev/shm alanına sahip sunucularda oluşabilecek çökmeleri önler ve yükü kök dosya sisteminize taşır; önerilen disk boyutunun imaj boyutundan daha büyük olmasının bir nedeni de budur.

OpenBot, bir VPS üzerinde nasıl self-host edilir?

Docker, Bun 1.3 veya daha yeni bir sürüm, bir CopilotKit Intelligence projesi ve bir model API anahtarına ihtiyacınız vardır. Geliştirme dokümantasyonu ayrıca sunucuda lsof, python3 ve curl bulunmasını bekler. main yerine etiketli bir sürümü klonlayın; çünkü main, alfa aşamasındaki bir projede uyarı olmaksızın değişebilir.

git clone --branch v0.0.1 https://github.com/CopilotKit/openbot.git
cd openbot
cp .env.example .env

Intelligence projesini hazırlayın. Bu üç komut, çalışma zamanı anahtarını ve lisans belirtecini ortam dosyanıza yazar.

npx --yes copilotkit@latest login
npx --yes copilotkit@latest project select
npx --yes copilotkit@latest license --write

Depolanan kimlik bilgilerini şifreleyen anahtarı oluşturun ve çıktıyı .env dosyasına KEY_ENCRYPTION_KEY olarak ekleyin. OPENAI_API_KEY değerinizi aynı dosyaya ekleyin veya BOT_PROVIDER değişkenini eşleşen anahtarla anthropic ya da google olarak ayarlayın.

openssl rand -base64 32

Ardından kurulumu yapın ve başlatın.

bun install
bash scripts/start.sh

scripts/start.sh, Docker servislerini ayağa kaldırır, veritabanı migrasyonlarını çalıştırır, sunucuyu ve uygulamayı başlatır, son olarak sağlık kontrollerini yapar. İşlem tamamlandığında uygulama 3010 numaralı portta, API ise 3001 numaralı portta yanıt verir. Betik, port çakışmalarını raporlar ve halihazırda çalışan eşleşen bir servise dokunmaz; bu nedenle betiği iki kez çalıştırmak güvenlidir.

Dış dünyaya açmadan önce sunucunun kendisinden kontrol edin.

curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:3010
ss -ltnp | grep -E ':(3010|3001|4100|4500|5432)'

İlk komuttan gelen bir 200, uygulamanın hizmet verdiğini gösterir. İkinci komut, bu portların hangi adreslere bağlı olduğunu gösterir; VPS üzerinde önemli olan yanıt budur. 127.0.0.1:3001 ifadesini içeren bir satır, bağlantının sadece sunucuya özel olduğunu belirtir. 0.0.0.0:3001 ifadesini içeren bir satır ise sunucuya yönlendirme yapabilen herkesin bu servise erişebileceği anlamına gelir.

Tek konteyner imajı

Dağıtım belgeleri ayrıca uygulamayı, API'yi ve Chromium'u barındıran ve 3001 numaralı port üzerinden hizmet veren tek bir imaj sunar.

docker build -t openbot .
docker run -p 127.0.0.1:3001:3001 --env-file .env \
  -e EMBEDDED_POSTGRES=on -v openbot-data:/var/lib/postgresql/data openbot

EMBEDDED_POSTGRES=on, PostgreSQL'i konteyner içinde çalıştırır ve başlangıçta migrasyonları uygular. Adlandırılmış birim (named volume), yeniden dağıtım sonrasında denetim geçmişini korur; bu birim olmadan her yeniden derleme işlemi söz konusu geçmişi siler. Eğer DATABASE_URL değerini yönetilen bir veritabanına yönlendirirseniz, üzerinde vector eklentisinin etkinleştirilmesi gerekir. RDS, Cloud SQL ve Azure Database gibi yönetilen servisler bu eklentiyi destekler ancak hiçbiri sizin yerinize etkinleştirmez. Bu nedenle, yeni bir yönetilen veritabanına karşı yapılan migrasyon, vector sütun türü henüz mevcut olmadığından başarısız olur.

Veritabanı harici olduğunda migrasyonları bir sürüm adımı olarak çalıştırın.

docker run --rm --env-file .env openbot \
  sh -c "cd /app/server && bun x drizzle-kit migrate --config=drizzle.config.ts"

Söz konusu imaj, tarayıcı portunu kasıtlı olarak yayınlanmamış halde bırakır. Ayrıca supervisor bileşenini de dışarıda tutar; çünkü supervisor, sunucusuz (serverless) platformların sağlamadığı Docker soketine ihtiyaç duyar. Supervisor olmadan her bot tek bir tarayıcıyı ve dolayısıyla tek bir oturum kümesini paylaşır; bu da bot başına konteyner çalıştırmayı değerli kılan izolasyonu ortadan kaldırır. Eğer buraya gelme nedeniniz bot başına ayrı oturumlar açmaksa, compose yığınını COMPUTER_SUPERVISOR_URL ve SUPERVISOR_TOKEN ayarları yapılmış şekilde, bu takası kabul ettiğiniz bir ana makinede çalıştırın. Docker soketiyle iletişim kurabilen bir süreç, ayrıcalıklı bir konteyner başlatabilir; bu da pratikte ana makine üzerinde root yetkisine sahip olması anlamına gelir. Bu durum, OpenBot'u kodlama ajanlarına tek kullanımlık bir VM verme mantığıyla kendi makinesinde tutmak için iyi bir nedendir.

OPENBOT_SINGLE_USER neden bir dizüstü bilgisayar ayarıdır

.env.example, OPENBOT_SINGLE_USER=true ile birlikte gelir. Bu ayar, her isteği tek bir yönetici olarak kabul eder ve oturum açma işlemini tamamen atlar. Dizüstü bilgisayarda bu bir kolaylıktır, çünkü porta erişebilen tek istemci sizsiniz. Bir VPS üzerinde ise bu, 3010 numaralı porta ulaşan ilk kişinin, şifrelenmiş kimlik bilgilerini saklayan ve halihazırda hesaplarınızda oturum açmış bir tarayıcıyı yöneten bir sistemin yöneticisi olacağı anlamına gelir.

Bunu çalıştırmanın iki dürüst yolu vardır. OPENBOT_SINGLE_USER=true ayarını koruyun, her portu 127.0.0.1 adresine bağlayın ve uygulamaya yalnızca bir SSH tüneli veya özel bir ağ arayüzü üzerinden erişin.

ssh -N -L 3010:127.0.0.1:3010 -L 3001:127.0.0.1:3001 you@your-vps

Uygulama bu durumda kendi tarayıcınızda http://localhost:3010 adresinde yer alır; bu güvenli bir bağlam olarak kabul edilir, dolayısıyla oturum açma çerezleri ve canlı ekranın ihtiyaç duyduğu tarayıcı özellikleri düzgün çalışır. Diğer yol ise tek kullanıcılı modu kapatmak ve gerçek bir kimlik sağlayıcısı yapılandırmaktır. Google, Microsoft Entra, Okta, SAML ve OIDC desteklenmektedir. Herhangi bir sağlayıcı ayrıca 32 karakter veya daha uzun bir BETTER_AUTH_SECRET, OAuth geri çağrıları için genel API temel URL'sine ayarlanmış bir BETTER_AUTH_URL, INITIAL_ADMIN_EMAILS ve TRUSTED_ORIGINS gerektirir. Sağlayıcı kimlik bilgileri eksiksiz olmalıdır, çünkü yarım yapılandırılmış bir sağlayıcı açık erişime geri dönmek yerine başlatma işlemini durdurur. Hesap ekleme nedeniniz, ekipteki her kişinin kendi tarayıcısı yerine kendi temsilcisine sahip olmasını istemesi ise, OneCLI bu yapı üzerine inşa edilmiştir, kişi başına bir korumalı alan (sandboxed) temsilcisi ve tek bir ağ geçidinde tutulan model anahtarları ile çalışır.

Uygulamaya genel bir isim üzerinden erişilebiliyorsa, önüne TLS (taşıma katmanı güvenliği) koyun. localhost dışındaki herhangi bir yerde düz http:// üzerinden sunulan bir sayfa güvenli bir bağlam değildir; bu nedenle Secure olarak işaretlenmiş çerezler saklanmaz ve oturum açma işlemi, OpenBot'ta bir hata varmış gibi görünen bir şekilde başarısız olur.

Düşük seviyeli portların güvenlik duvarı ile kısıtlanması

OpenBot'un kendi güvenlik notu, düşük seviyeli servis uç noktalarının tokenlar ile korunduğunu, bunların gizli tutulması gerektiğini ve ağ geçidini (gateway) atlatmak için kullanılmamaları gerektiğini belirtir. Tokenlar ikinci koruma katmanıdır. Birinci koruma katmanı ise portun dışarıdan hiç erişilemez olmasıdır.

Aracı bilgisayar (agent-computer) 4100 portunu dinler ve COMPUTER_TOKEN gerektirir. Bot uç noktaları 4200 ve 4201 portlarını dinler. Denetleyici (supervisor) ana makinede 4500, kendi container'ı içerisinde ise 4300 portunu dinler. PostgreSQL 5432 portunu dinler. Bunların hiçbiri genel bir ağ arayüzünde yer almamalıdır; tek kullanıcılı bir kurulumda uygulama ve API de aynı şekilde dışarıya kapalı olmalıdır.

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw enable
sudo ufw status verbose

Burada, güvenlik duvarının yeterli olduğunu varsayan kullanıcıların düştüğü bir tuzak bulunmaktadır. Bir container portunu -p 3001:3001 ile yayınlamak, Docker'ın bir DNAT kuralı oluşturmasına neden olur. Bu durumda trafik FORWARD yolu üzerinden işlenir ve ufw'nin varsayılan reddetme kuralının uygulandığı INPUT zincirinden asla geçmez. ufw status komutu hala Status: active çıktısını verse bile port dışarıya açık kalır. Yayınlanan portu eşleme (mapping) sırasında -p 127.0.0.1:3001:3001 şeklinde loopback adresine bağlayın veya compose dosyanızda ana makine adresini ayarlayın. Doğrulamayı ufw status ile değil, ss -ltnp ile yapın. Bu tuzak sadece OpenBot'a özgü değildir; bu nedenle sunucuda yayınladığınız diğer tüm container'lar için aynı kontrolü gerçekleştirin; buna 90'ların video dükkanı olarak yeniden yapılandırılmış bir Jellyfin kütüphanesi sunan servis de dahildir.

OpenBot çevrimdışı bir yığın değildir

Dağıtım planınızı yapmadan önce bunu göz önünde bulundurun. OpenBot, kalıcı iş parçacıklarını ve konuşma belleğini sunucunuzun dışında tutan bir CopilotKit Intelligence projesine bağımlıdır. Sunucu, başlatma sırasında INTELLIGENCE_API_URL, INTELLIGENCE_GATEWAY_WS_URL, INTELLIGENCE_API_KEY ve COPILOTKIT_LICENSE_TOKEN değerlerini doğrular; bu dört değerin bir arada bulunması gerekir, aksi takdirde başlatma başarısız olur. Ağustos 2026 itibarıyla ücretsiz bir plan mevcuttur ve Intelligence'ın kendisi de self-host edilebilir durumdadır; bu nedenle hızlı başlangıç kılavuzunda gösterilenden daha fazla çaba ile tamamen yerel bir dağıtım mümkündür.

Model, ikinci dış bağımlılıktır. Kutudan çıktığı haliyle herhangi bir model içermez. BOT_PROVIDER, openai, anthropic veya google değerlerini kabul eder ve OPENAI_BASE_URL, OpenAI yolunu herhangi bir uyumlu uç noktaya yönlendirir. Token'ların kendi donanımınızda kalmasını istiyorsanız LLM'i self-host etmek için VPS üzerinde Ollama çalıştırma yöntemi burada devreye girer. Tarayıcı kontrolü bir modelden çok şey bekler, bu nedenle bir modele karar vermeden önce yerel bir modeli gerçek bir görev üzerinde test edin.

Şimdilik tek bir kopya çalıştırın

Ağ geçidi, sayfa anlık görüntülerini sunucu süreci belleğinde önbelleğe alır. İki kopya olduğunda, bir süreç tarafından alınan anlık görüntü diğeri tarafından görülemez; bu nedenle işlemler, rastgele görünen element-not-found hatalarıyla kesintili olarak başarısız olur. Dağıtım belgeleri bu konuda nettir: tek bir kopya çalıştırın ve platformunuzun maksimum örnek sayısını 1 olarak sabitleyin. Bu sınırlama, anlık görüntü önbelleğe alma işlemi veritabanına taşındığında sona erecektir. O zamana kadar OpenBot'u ölçeklendirmek için kutu sayısını artırmak yerine kutunun kapasitesini artırın. Botlar arasındaki izolasyon, tıpkı self-hosted agent sandboxes yapısının bir ajanın hatalarını diğerlerinden uzak tutması gibi, bot başına düşen container'lar aracılığıyla sağlanmaya devam eder.

Hata modları ve karşılaşacağınız durumlar

.env doldurulduktan hemen sonra başlatma işlemi sonlanıyor. Sunucu, herhangi bir hizmet vermeden önce yapılandırmayı doğrular. Eksik bir Intelligence bloğu, eksik bir KEY_ENCRYPTION_KEY veya istemci kimliği olup gizli anahtarı olmayan bir OAuth sağlayıcısı, sessizce hata vermek yerine başlatma işlemini durdurur. İlk hata mesajını okuyun, ilgili alanı düzeltin ve yeniden başlatın.

Yönetilen bir veritabanında geçişler (migrations) başarısız oluyor. vector eklentisi varsayılan olarak etkin değildir; bu nedenle geçiş işlemi, PostgreSQL'in tanımadığı bir sütun türüyle karşılaşır. Süper kullanıcı olarak bağlanın, CREATE EXTENSION vector; komutunu çalıştırın ve ardından geçiş adımını tekrar başlatın.

Uygulama yükleniyor ancak oturum açma işlemi kalıcı olmuyor. Genel bir adres üzerinden şifrelenmemiş http:// kullanıyorsunuz. Bu güvenli bir bağlam olmadığından Secure çerezi reddedilir. Ön tarafa TLS ekleyin veya tarayıcının localhost görmesini sağlamak için SSH tüneli kullanın.

Botlar, ayrı olmasını beklediğiniz oturumları paylaşıyor. Supervisor çalışmıyor; bu nedenle bot başına bir bilgisayar ortamı yok ve her bot paylaşılan tarayıcıyı kullanıyor. COMPUTER_SUPERVISOR_URL ayarının yapıldığından ve supervisor'ın Docker soketine erişebildiğinden emin olun.

Bir bot duruyor ve yardım istiyor. Bu, tasarımın beklendiği gibi çalıştığı anlamına gelir. Denetim izi computer.help_requested kaydını tutar, canlı ekran üzerinden kontrolü devralırsınız ve devir işlemi her iki tarafta da kayıt altına alınır.

FAQ

OPENBOT_SINGLE_USER ayarını bir VPS dağıtımında açık bırakmak güvenli midir?

Yalnızca ağ geçidine internet üzerinden erişilemediği durumlarda güvenlidir. OPENBOT_SINGLE_USER=true, oturum açma gerektirmeksizin her isteği tek bir yönetici olarak kabul eder; bu nedenle portu açabilen herkes dağıtımın, depolanan kimlik bilgilerinin ve oturum açmış tarayıcının kontrolünü ele geçirir. Tüm portların 127.0.0.1 adresine bağlandığı ve uygulamaya bir SSH tüneli veya özel ağ arayüzü üzerinden eriştiğiniz durumlarda bu kullanım kabul edilebilir. Genel bir arayüzde bu ayarı kapatın ve Google, Microsoft Entra, Okta veya OIDC yapılandırmalarını BETTER_AUTH_SECRET, BETTER_AUTH_URL, INITIAL_ADMIN_EMAILS ve TRUSTED_ORIGINS ile birlikte kullanın.

Bir OpenBot botu ne kadar RAM tüketir?

Projenin arm64 mimarisindeki tek bir bot için yayınladığı veriler, bellek kullanımının en yüksek 0.55 GB olduğunu, belgelenen minimum değerin 2 GB ve önerilen değerin 4 GB olduğunu göstermektedir. Aynı anda çalışan birden fazla bot için yayınlanmış bir veri yoktur, çünkü her bot kendi Chromium örneğini çalıştırır. Bir botu gerçek bir görev üzerinde çalıştırın, ilgili container'ın bellek kullanımını docker stats ile okuyun, ağ geçidi ve veritabanı tüketimini ekleyin ve ardından aynı anda çalışmasını beklediğiniz bot sayısıyla çarpın.

OpenBot'u self-host etmek için bir CopilotKit hesabına ihtiyacım var mı?

Evet. OpenBot, kalıcı iş parçacıkları ve bellek için bir CopilotKit Intelligence projesine bağımlıdır; Intelligence API URL'si, ağ geçidi WebSocket URL'si, API anahtarı ve lisans token'ı ayarlanmadığı sürece sunucu başlatılamaz. Ağustos 2026 itibarıyla ücretsiz bir plan mevcuttur ve Intelligence kendi sunucunuzda barındırılabilir; dolayısıyla ek çalışma ile barındırılan bağımlılık kaldırılabilir. Ayrıca kendi model API anahtarınızı sağlamanız gerekir, çünkü OpenBot ile birlikte hiçbir model gelmez.

Neden her bot ortak bir tarayıcı yerine kendi tarayıcısını kullanıyor?

Çünkü bir tarayıcı profili bir kimliktir. Paylaşılan bir tarayıcı, paylaşılan çerezler ve paylaşılan oturumlar anlamına gelir; bu durumda bir hesaba giriş yapan bir bot, o hesaba giriş yapmış tüm botlar demektir. Bot başına container yapısı, her bir iş arkadaşına kendi profilini ve kendi giriş bilgilerini sağlar. Bunun maliyeti bellektir, çünkü bot başına düşen Chromium, boyutlandırmadaki en büyük kalemdir.

Güvenlik duvarında hangi OpenBot portları açık olmalıdır?

Düşük seviyeli portların hiçbiri açılmamalıdır. 4100 üzerindeki agent-computer, 4200 ve 4201 üzerindeki bot uç noktaları, 4500 üzerindeki supervisor ve 5432 üzerindeki PostgreSQL özel kalmalıdır. Proje bunları token'lar ile korur ve her halükarda erişilemez tutmanızı önerir. Yalnızca bir kullanıcının erişmesi gereken portları yayınlayın ve -p 3001:3001 ile yayınlanan bir container portunun, ufw üzerindeki varsayılan reddetme (default-deny) kuralına bakılmaksızın erişilebilir olduğunu unutmayın; çünkü Docker'ın DNAT kuralı, bu trafiği INPUT yerine FORWARD yoluna yönlendirir.