Open Connector Kendi Sunucunuzda Nasıl Kurulur?

Open Connector'ın bir yapay zeka ajanı için işlevi

Open Connector'ı kendi sunucunuzda barındırmak, yapay zeka ajanlarınız ile çağırdıkları tüm yazılım hizmetleri (SaaS) API'leri arasına tek bir kimlik doğrulama ağ geçidi yerleştirir; böylece ajan hiçbir zaman bir sağlayıcı belirteci (token) tutmaz. Bu, OOMOL Lab tarafından geliştirilen ve Apache 2.0 lisansına sahip açık kaynaklı bir ağ geçididir. Tek bir container olarak çalışır, durumunu tek bir SQLite dosyasında tutar ve sağlayıcı eylemlerini HTTP ve MCP (model context protocol) üzerinden sunar.

Zorluk ikinci entegrasyonda başlar. Her sağlayıcının kendine ait bir OAuth (open authorization) akışı, yenileme belirteci ömrü ve kapsam (scope) isimleri vardır. Bir ajana beş farklı sağlayıcıyı manuel olarak bağlamak; beş adet yönlendirme işleyicisi, beş adet kimlik bilgisi deposu ve belirteç süresi dolmadan önce çalışması gereken beş adet yenileme döngüsü anlamına gelir. Bu kodu neredeyse kimse yazmaz. Bunun yerine her servis için uzun ömürlü bir kişisel erişim belirteci oluşturulur ve bu belirteç ajanın yapılandırma dosyasına, bir environment dosyasına veya doğrudan istemin (prompt) içine yapıştırılır. Bu belirteç, ajanın çalıştırdığı her araç tarafından okunabilir hale gelir ve yapay zeka ajanlarından sırları uzak tutmak başlıklı yazıda açıklanan başarısızlığa yol açarak transkript kayıtlarına sızar.

Bir kimlik doğrulama ağ geçidi, kimlik bilgisini ikiye böler. Ağ geçidi, sağlayıcı kimlik bilgisini saklar ve OAuth akışını yürütür. Ajan ise yalnızca ağ geçidine karşı geçerli olan bir çalışma zamanı belirteci alır. Ajan bir eylem çağırdığında, ağ geçidi saklanan kimlik bilgisini yükler, bunu sunucu tarafında giden isteğe enjekte eder ve yalnızca yanıt gövdesini geri döndürür. Ajan hiçbir zaman sağlayıcı erişim belirtecini almaz; bu nedenle sızdırılan bir ajan transkripti, GitHub hesabınız yerine yalnızca iptal edilebilir bir çalışma zamanı belirtecine mal olur.

Katalog, 1.000'den fazla sağlayıcı ve 10.000'den fazla hazır eylem içerdiğini belirtmektedir; bu, projenin kendi verisidir ve dışarıdan doğrulayabileceğiniz bir şey değildir. Doğrulayabileceğiniz şey ise yapıdır: eylem başına bir HTTP uç noktası, sağlayıcı başına bir saklanan bağlantı ve ajan başına bir belirteç. Eğer bu konunun ajan tarafı sizin için hala yeniyse ve araç çağrısı (tool call) veya MCP sunucusu gibi terimler henüz tam oturmadıysa, sıfırdan yapay zeka ajanları öğrenme rehberi içindeki aşamalı yol haritası; bu tür bir ağ geçidinin halihazırda sahip olduğunuzu varsaydığı döngüleri, araçları ve güvenlik alışkanlıklarını oluşturmanıza yardımcı olur.

Neden barındırılan bir bağlayıcı hizmeti yerine Open Connector'ı kendi sunucunuzda barındırmalısınız

Barındırılan bir bağlayıcı hizmeti aynı işi yapar ve bağlandığınız her sağlayıcı için yenileme belirteçlerini (refresh tokens) tutar. Google veya GitHub için bir yenileme belirteci, e-postalarınıza ve depolarınıza erişim sağlayan uzun ömürlü bir anahtardır ve genellikle parola değişikliğinden etkilenmez. Bu hizmetlerin ihlal edilmesi, sizin de ihlal edilmeniz anlamına gelir. Kendi sunucunuzda barındırma işlemi, bu kayıtları kiraladığınız ve yönettiğiniz bir makinedeki SQLite veritabanına taşır ve asla sunucunuzdan çıkmayan bir anahtarla mühürler.

Başlamadan önce maliyeti açıkça değerlendirin. Bu VPS, çalıştırdığınız en değerli sunucu haline gelecektir. Bir düzine hizmet için çalışan kimlik bilgilerini tek bir dosyada tuttuğu için, bir parola yöneticisi sunucusuna gösterdiğiniz özeni hak eder: yalnızca 443 numaralı portu dışarıya açan bir güvenlik duvarı, paylaşımlı oturum açma yöntemlerinin kullanılmaması, en az bir kez geri yükleme testi yapılmış bir yedekleme ve yanıt vermeyi kestiğinde uyarı gönderen bir izleme sistemi. Parola kasanızı bu makineye koymayacaksanız, bağlayıcıyı da koymayın.

Kurulumdan önce bir sürümü sabitleyin

Open Connector henüz yeni bir projedir. Depo ilk olarak 29 June 2026 tarihinde ortaya çıkmıştır ve 1 August 2026 itibarıyla en yeni etiketli sürüm, 30 July 2026 tarihinde yayınlanan ve aynı zamanda latest etiketini taşıyan v1.3.3 sürümüdür. Kayıt defteri, main üzerindeki en yeni commit'ten oluşturulan bir tip etiketini de yayınlamaktadır.

Bu kadar yeni bir projede değişken etiketler sık sık değişir. İki sürüm atlayan bir docker compose pull, aracınızın bağımlı olduğu bir uç noktayı değiştirebilir ve akşamınızı bunu bir aracı sorunu olarak hata ayıklayarak geçirebilirsiniz. İmajı bir sürüm etiketine sabitleyin ve sürüm notlarını okuduktan sonra, yükseltme yapmaya karar verdiğinizde yükseltin.

Open Connector'ı kendi VPS'nizde TLS arkasında dağıtma

Konteyner başlamadan önce şunlara ihtiyacınız var:

• Ubuntu 24.04 veya benzeri bir dağıtımda Docker ve Compose eklentisi
• A kaydı bu VPS'yi işaret eden bir ana makine adı, örneğin connect.example.com
• Bu ana makine adı için halihazırda TLS (taşıma katmanı güvenliği) sonlandırması yapan bir reverse proxy
• Aşağıda oluşturulan iki rastgele gizli anahtar

Birden fazla Docker Compose uygulaması için Traefik reverse proxy rehberi, proxy tarafını kapsamaktadır. Tek bir uygulama için baştan sona aynı sertifika kurulumu ise Docker ve HTTPS ile VPS üzerinde n8n rehberinde mevcuttur.

Önce gizli anahtarları oluşturun. Şifreleme anahtarı, depolanan kimlik bilgilerini mühürler. Yönetici belirteci ise web konsolunu ve tüm /api yüzeyini korur. İkisinin de varsayılan bir değeri yoktur ve çalışma zamanı, bunlar olmadan da sorunsuz bir şekilde başlar.

mkdir -p ~/open-connector && cd ~/open-connector
umask 077
printf 'OOMOL_CONNECT_ENCRYPTION_KEY=%s\n' "$(openssl rand -base64 32)" > .env
printf 'OOMOL_CONNECT_ADMIN_TOKEN=%s\n' "$(openssl rand -base64 32)" >> .env
chmod 600 .env

Her iki değeri de ilk başlatmadan önce hemen parola yöneticinize kopyalayın. Şifreleme anahtarının kurtarma yolu yoktur; bunun nedeni aşağıda hata listesinde açıklanmıştır.

Şimdi compose.yaml dosyasını oluşturun. Bu dosya, yukarı akış örneğinden iki noktada ayrılır ve her ikisi de önemlidir.

services:
  connector:
    image: ghcr.io/oomol-lab/open-connector:v1.3.3
    restart: unless-stopped
    ports:
      - "127.0.0.1:3000:3000"
    volumes:
      - connector-data:/app/data
    environment:
      OOMOL_CONNECT_DATA_DIR: /app/data
      OOMOL_CONNECT_ORIGIN: "https://connect.example.com"
      OOMOL_CONNECT_ENCRYPTION_KEY: "${OOMOL_CONNECT_ENCRYPTION_KEY:?set this in .env}"
      OOMOL_CONNECT_ADMIN_TOKEN: "${OOMOL_CONNECT_ADMIN_TOKEN:?set this in .env}"

volumes:
  connector-data:

İlk değişiklik, latest yerine sabitlenmiş bir etiket kullanılmasıdır. İkincisi ise porttur. Yukarı akış dosyası 3000:3000 portunu yayınlar ve bu, ana makinedeki tüm arayüzlere bağlanır. Docker, yayınlanan portlarını ufw filtre zinciri paketi görmeden önce NAT (ağ adresi çevirisi) tablosuna yazar; bu nedenle ufw deny 3000 bu portu kapatmaz. Bu durum, Docker portlarının neden ufw'yi baypas ettiği rehberinde açıklanan tuzaktır. 127.0.0.1:3000:3000 yazmak, portu yalnızca loopback arayüzünde yayınlar ve reverse proxy'niz aynı ana makine üzerinden bağlantı kurar.

:?, her değişkenin zorunlu olduğunu belirtir; böylece yığın, kimlik bilgileri şifrelenmemiş halde başlamak yerine .env eksik olduğunda başlamayı reddeder. Değerleri compose dosyası yerine .env içinde tutmak, Docker Compose env dosyaları ve gizli anahtarlar rehberindeki yöntemdir.

docker compose up -d
docker compose logs -n 30 connector
curl -s http://127.0.0.1:3000/health
sudo ss -tlnp | grep 3000

/health, çalışma zamanı ayağa kalktığında { "ok": true } sorusuna yanıt verir. ss, 127.0.0.1:3000 çıktısını vermelidir. 0.0.0.0:3000 ifadesini içeren bir satır, port eşlemesinin hala yukarı akış örneğindeki gibi olduğunu ve ağ geçidinin doğrudan tüm internete yanıt verdiğini gösterir. Sağlık kontrolünde "Connection refused" hatası, konteynerin henüz dinleme yapmadığı anlamına gelir; bu yüzden proxy'ye dokunmadan önce günlük kayıtlarını okuyun.

    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.connector.rule=Host(`connect.example.com`)"
      - "traefik.http.routers.connector.entrypoints=websecure"
      - "traefik.http.routers.connector.tls.certresolver=le"
      - "traefik.http.services.connector.loadbalancer.server.port=3000"

OAuth neden gerçek bir ana makine adı gerektirir

OOMOL_CONNECT_ORIGIN ayarı, kullanıcıların genellikle atladığı bir yapılandırmadır ve bu ayarın atlanması, OAuth sürecinin bir sağlayıcı hatası gibi görünmesine neden olacak şekilde bozulmasına yol açar. Çalışma zamanı (runtime), yönlendirme URI'sini bu orijinden <origin>/oauth/callback biçiminde oluşturur. Ayarlanmadığı takdirde orijin varsayılan olarak http://localhost:3000 değerini alır; bu durumda çalışma zamanı, sağlayıcıya http://localhost:3000/oauth/callback şeklinde bir yönlendirme URI'si gönderir ancak OAuth uygulamanızda https://connect.example.com/oauth/callback kayıtlıdır. İki dizgi birbirinden farklı olduğu için GitHub şu yanıtı döner:

The redirect_uri MUST match the registered callback URL for this application.

Bir OAuth sağlayıcısı, tarayıcıyı bu URI'ye geri yönlendirir; bu da adresin dış dünya tarafından erişilebilir olması gerektiği anlamına gelir. Sağlayıcılar, localhost haricindeki hiçbir durum için düz http:// adresini kabul etmez. Bu dağıtımın bir ana makine adına ve sertifikaya ihtiyaç duymasının temel nedeni budur. Değer başlangıçta okunduğu için orijini ilk başlatmadan önce ayarlayın: .env veya compose.yaml dosyalarını düzenledikten sonra, değişiklikleri uygulamak için docker compose up -d komutunu tekrar çalıştırın.

İlk sağlayıcınızı OAuth üzerinden bağlayın

Öncelikle sağlayıcı tarafında OAuth uygulamasını oluşturun. GitHub üzerinde izlemeniz gereken yol: Settings, ardından Developer settings, daha sonra OAuth Apps ve son olarak New OAuth App şeklindedir. Yetkilendirme geri çağırma (callback) URL'sini https://connect.example.com/oauth/callback olarak ayarlayın. Client ID ve client secret bilgilerini saklayın.

Her /api çağrısı yönetici token'ını taşır, bu nedenle shell oturumu için bu token'ı bir kez dışa aktarın (export).

export ADMIN_TOKEN='paste-the-admin-token'
curl -s https://connect.example.com/api/oauth/configs \
  -H "authorization: Bearer $ADMIN_TOKEN"

Bu liste, çalışma zamanının her sağlayıcı için beklediği yönlendirme URI'sini gösterir; bu, yaptığınız yapılandırmanın geçerli olup olmadığını kontrol etmenin en hızlı yoludur. Eğer hala localhost değerini görüyorsanız, container eski değerle çalışıyordur ve OAuth akışı son adımda başarısız olacaktır.

Client kimlik bilgilerini kaydedin ve ardından bir yetkilendirme başlatın.

curl -s -X PUT https://connect.example.com/api/oauth/configs/github \
  -H "authorization: Bearer $ADMIN_TOKEN" \
  -H 'content-type: application/json' \
  -d '{"clientId":"...","clientSecret":"..."}'

curl -s -X POST https://connect.example.com/api/oauth/authorizations \
  -H "authorization: Bearer $ADMIN_TOKEN" \
  -H 'content-type: application/json' \
  -d '{"service":"github"}'

İkinci çağrı bir authorizationUrl döndürür. Bunu bir tarayıcıda açın, kapsamları (scopes) onaylayın; sağlayıcı tarayıcıyı /oauth/callback adresine geri yönlendirecektir. Çalışma zamanı burada kodu takas eder ve kimlik bilgisini saklar. Kaynağınızdaki web konsolu, aynı yönetici token'ı arkasında bir form aracılığıyla aynı adımları izler. Düz bir API anahtarı kullanan sağlayıcılar tüm bu süreci atlar: PUT /api/connections/<service> ile {"authType":"api_key","values":{"apiKey":"..."}} kullanımı anahtarı doğrudan saklar.

Her aracıya bir çalışma zamanı belirteci atayın, kimlik bilgilerini asla vermeyin

Aracı, yönetici API'si tarafından oluşturulan bir çalışma zamanı belirteci (runtime token) ile ağ geçidinde kimlik doğrulaması yapar.

curl -s -X POST https://connect.example.com/api/runtime-tokens \
  -H "authorization: Bearer $ADMIN_TOKEN" \
  -H 'content-type: application/json' \
  -d '{"name":"research-agent"}'

Yanıt, oct_ ile başlayan bir belirteç içerir. Her aracı için bir tane oluşturun ve bunu ilgili aracının adıyla isimlendirin; çünkü tanımlayamadığınız bir belirteci iptal etmek, hepsini iptal etmeniz anlamına gelir. Aracı daha sonra işlemleri standart HTTP üzerinden çağırır.

curl -s -X POST https://connect.example.com/v1/actions/github.get_current_user \
  -H "authorization: Bearer oct_..." \
  -H 'content-type: application/json' \
  -d '{"input":{}}'

Sağlıklı bir yanıt, success alanı true olan ve sağlayıcı yükünü data altında taşıyan bir zarftır. GitHub belirteci bu yanıtın hiçbir yerinde bulunmaz. Bir MCP istemcisi için, istemciyi aynı bearer başlığı ile https://connect.example.com/mcp adresine yönlendirin; ağ geçidi, her API için ayrı bir araç yerine search_actions ve execute_action gibi keşif araçları sunar, bu da aracının araç listesini küçük tutar. VPS üzerinde MCP sunucuları çalıştırma bölümü, bu bağlantının istemci tarafını ele alır.

İşlemi tamamlanmış saymadan önce bir kontrol daha yapın. authorization başlığını silerek işlem çağrısını tekrarlayın. Projenin kendi hızlı başlangıç kılavuzu, herhangi bir bearer bilgisi olmadan /v1 çağrısı yapar; bu nedenle çalışma zamanı kimlik doğrulaması yapılandırılmamış bir kurulum, porta erişebilen herkes için işlemleri yürütecektir. Kimlik doğrulaması yapılmamış çağrınız başarılı olursa, iki seçeneğiniz vardır: çalışma zamanı belirteçlerini yapılandırıp anonim çağrının artık başarısız olduğunu doğrulayın veya reverse proxy üzerinde /api, /v1 ve /mcp adreslerini yalnızca aracınızın geldiği IP adresleriyle kısıtlayın. Yalnızca /oauth/callback dünyaya açık kalmalıdır, çünkü bu, bir sağlayıcının tarayıcı yönlendirmesinin ihtiyaç duyduğu tek yoldur.

Eylem listesini aracın ihtiyaç duyduğu seviyeye indirin

Arkasına binlerce sağlayıcı yerleştirilmiş bir ağ geçidi, bir dil modeli için oldukça geniş bir saldırı yüzeyi oluşturur. Model, kendisinin yazmadığı metinleri okumaya başladığı anda bu yüzey daha da genişler; çünkü aracın web aramalarına yanıt veren kendi SearXNG örneğiniz tarafından döndürülen bir sayfa, aracın sahip olduğu eylemleri hedef alan talimatlar içerebilir. Bir kodlama aracının çalışan en küçük değişikliği yapmasını sağlayan kısıtlamanın aynısı, izinleri için de geçerlidir: araca yalnızca işin gerektirdiği birkaç eylemi verin, fazlasını değil. İki kontrol mekanizması bu alanı daraltır.

OOMOL_CONNECT_ALLOWED_ACTIONS, virgülle ayrılmış bir izin listesi alır ve service.* ile * ifadelerini anlar. OOMOL_CONNECT_BLOCKED_ACTIONS yasaklılar listesidir ve yasaklılar listesi her zaman önceliklidir. İzin listesini github.get_current_user,github.list_issues olarak ayarlamak, araç ne talep ederse etsin diğer tüm eylemlerin reddedileceği anlamına gelir; bu, basit bir hata ile bir güvenlik olayı arasındaki farktır. Çalışma zamanı belirteçleri (runtime tokens), genel kuralların üzerinde kendi eylem kurallarını taşır ve bunların allowedProxies listesi boş başlar; bu nedenle siz izin verene kadar POST /v1/proxy/:service reddedilir. Bu proxy uç noktası, ham bir isteği kimlik bilgileriniz eklenmiş şekilde bir sağlayıcıya iletir; bu yüzden belirli bir aracın ihtiyacı olmadıkça burayı boş bırakın.

OOMOL_CONNECT_ALLOW_PRIVATE_NETWORK varsayılan olarak false değerindedir; bu, kendi barındırdığınız bir sağlayıcı bağlantısının 169.254.169.254 üzerindeki bulut meta veri servisi veya aynı ağdaki veritabanınız gibi özel adreslere yönlenmesini engeller. Bu ayarı kapalı tutun. Yalnızca kendi barındırdığınız bir sağlayıcı için açın.

Tüm belirteçleri barındıran sunucunun yedeğini alma

İki unsur önem taşır ve her biri diğeri olmadan işlevsizdir. connector-data birimi içindeki /app/data/connect.sqlite konumunda bulunan veritabanı, şifrelenmiş kimlik bilgilerini tutar. .env içindeki şifreleme anahtarı ise bu bilgilerin kilidini açar. Anahtarın olmadığı bir birim yedeği hiçbir şeyi geri yüklemez; aynı şekilde birimin olmadığı bir anahtar da hiçbir işe yaramaz. Bu nedenle anahtarı parola yöneticinizde saklamalı, birimi ise düzenli yedekleme döngünüze dahil etmelisiniz.

SQLite dosyasını kopyalarken container'ı durdurun; çünkü yazma işlemi sırasında alınan bir kopya, veritabanının bozuk olarak geri yüklenmesine neden olabilir.

docker volume ls | grep connector-data
docker compose stop connector
docker run --rm -v open-connector_connector-data:/data -v "$PWD":/backup alpine \
  tar czf /backup/connector-data.tgz -C /data .
docker compose start connector

Birim adı, proje dizininiz ve _connector-data ifadesinden oluşur; ilk komutun orada bulunma nedeni budur: gerçek ismi üçüncü komuta yapıştırın. Arşivi, VPS üzerinden restic yedekleri kullanarak VPS dışına gönderin. Bu yöntem, arşiv sunucudan çıkmadan önce şifrelenmesini sağlar; çünkü söz konusu arşiv kimlik bilgisi deposudur.

Çalışma zamanı, son eylem kayıtlarını denetim kayıtları olarak tutar (varsayılan olarak 5,000 adet). Bu sayede konsol, hangi aracının neyi ve ne zaman çalıştırdığını size bildirebilir. Bir aracı beklenmedik şekilde davrandığında okunması gereken ilk yer bu log dosyasıdır. Ayrıca bir Uptime Kuma durum sayfası üzerinden https://connect.example.com/health adresini izleyin. Ağ geçidi yanıt vermeyi kestiğinde aracılar karmaşık hatalar verebilir; ağ geçidinin kapalı olduğunu bilmek, aracı çıktılarını okuyarak geçireceğiniz bir saatlik süreden tasarruf etmenizi sağlar.

Neler bozulur ve göreceğiniz mesajlar

redirect_uri_mismatch sağlayıcı tarafında. Kaynak ve kayıtlı geri çağırma (callback) URL'si birbirinden farklıdır. /api/oauth/configs içindeki tam dizgeyi, https ile http arasındaki farklar ve sondaki eğik çizgi (trailing slash) dahil olmak üzere sağlayıcının uygulama ayarlarıyla karşılaştırın.

Her /api çağrısı 401 hatası döndürüyor. Yönetici belirteci (admin token) başlığı eksik veya yanlış yazılmış. Başlık Authorization: Bearer <token> şeklindedir ve web konsolu aynı belirteci talep eder.

Container çalışıyor ancak kimlik bilgileri düz metin olarak duruyor. Bu durum, OOMOL_CONNECT_ENCRYPTION_KEY container'a hiç ulaşmadığında gerçekleşir; çünkü çalışma zamanı (runtime), kimlik bilgilerini başlatmayı reddetmek yerine şifrelenmemiş olarak saklar. Kendi kurulumunuzda bunu doğrulayın: tanıyabileceğiniz bir API anahtarı ile bir sağlayıcı bağlayın, ardından veritabanında bu anahtarı aratın.

docker compose cp connector:/app/data/connect.sqlite /tmp/connect.sqlite
grep -c 'github_pat_' /tmp/connect.sqlite
shred -u /tmp/connect.sqlite

0'dan büyük bir değer, anahtarın etkin olmadığını gösterir; bu nedenle .env dosyasının compose.yaml ile aynı dizinde bulunduğundan ve docker compose config değerinin doğru olduğundan emin olun. Anahtar ayarlandığında aynı arama 0 sonucunu döndürür, çünkü kayıt AES-256-GCM (gelişmiş şifreleme standardı, 256-bit anahtar, Galois/sayaç modu) ile mühürlenmiştir.

Geri yükleme sonrasında hiçbir şeyin şifresi çözülmüyor. Şifreleme anahtarı değişmiş veya kaybolmuştur. Tasarım gereği anahtar verilerin yanında tutulmaz, bu nedenle bir kurtarma yolu veya yardımcı olabilecek bir destek talebi yoktur. Tüm sağlayıcıları yeniden bağlayın. Anahtar rotasyonu, çalışma zamanındaki ayrı bir anahtar değişkeni ve veri komutu ile desteklenir; bu nedenle herhangi bir rotasyon işlemi yapmadan önce güncel sürüm notlarını okuyun.

Aracı (agent), katalogda görebildiği bir eylemle ilgili hata alıyor. Keşif ve yürütme birbirinden ayrı süreçlerdir. Bir eylem search_actions içinde görünebilir ancak yine de OOMOL_CONNECT_ALLOWED_ACTIONS, yasaklılar listesi (denylist) veya çalışma zamanı belirtecinin kendi kuralları tarafından reddedilebilir.

Yükseltmeler. Birimi (volume) yedekleyin, görüntü etiketini (image tag) yeni sürüme göre düzenleyin ve ardından docker compose pull && docker compose up -d komutunu çalıştırın. Bir taşıma (migration) satırı için docker compose logs -n 50 connector günlüğünü izleyin; sisteme tekrar güvenmeden önce sağlık kontrolünü ve gerçek bir eylemi yeniden çalıştırın. Geri alma (rollback) işlemi, eski etiketi tekrar yerine koymak anlamına gelir ve bu yalnızca etiketi sabitlediyseniz (pinned) çalışır.

FAQ

Open Connector'ı self-host etmek için herkese açık bir alan adına ihtiyacım var mı?

API anahtarı kullanan sağlayıcılar için hayır: 127.0.0.1 üzerindeki bir ağ geçidi yeterlidir. OAuth için ise pratikte evet. Sağlayıcı, tarayıcıyı geri çağırma (callback) URL'nize yönlendirir; bu nedenle söz konusu URL'nin genel internet üzerinden çözümlenebilir olması gerekir ve sağlayıcılar localhost dışındaki düz http:// bağlantılarını reddeder. İlk başlatmadan önce OOMOL_CONNECT_ORIGIN değerini https:// ana makine adınıza ayarlayın ve <origin>/oauth/callback adresini sağlayıcının OAuth uygulamasında kaydedin.

Open Connector şifreleme anahtarını kaybedersem ne olur?

Depolanan kimlik bilgileri şifresi çözülemez ve bir kurtarma yöntemi yoktur. Anahtar, verilerle birlikte saklanmaması için kasıtlı olarak ayrı tutulur; böylece veritabanını ele geçiren hiç kimse (siz dahil) verileri okuyamaz. Tek seçeneğiniz yeni bir anahtar belirlemek ve her sağlayıcıyı yeniden bağlamaktır. Anahtarı bir parola yöneticisinde, veritabanını ise yedekleme rotasyonunuzda tutun; çünkü geri yükleme işlemi her ikisini de gerektirir.

AI ajanım sağlayıcı erişim belirtecini (access token) görebilir mi?

Ağ geçidi üzerinden çağrı yaptığında göremez. Ajan, oct_ ile başlayan bir çalışma zamanı belirteci ile kimlik doğrulaması yapar; ağ geçidi, sağlayıcı kimlik bilgisini sunucudaki giden isteğe enjekte eder ve yalnızca yanıtı döndürür. Bu özelliği bozan iki durum vardır: kimlik bilgilerinizi ekleyerek ham istekleri ileten ve izinleri bir nedenden dolayı boş başlayan /v1/proxy/:service uç noktası ve ağ geçidini tamamen devre dışı bırakarak API anahtarını doğrudan ajana yapıştırmak.

Ağ geçidi genel internetten erişilebilir olmalı mı?

Yalnızca /oauth/callback erişilebilir olmalıdır. Konteyner portunu 127.0.0.1 üzerinde yayınlayın; böylece Docker'ın NAT kuralları onu güvenlik duvarınızın ötesine açamaz ve önüne bir reverse proxy koyabilirsiniz. Ardından, authorization başlığı olmadan bir eylem çağrısını test edin. Başarılı olursa, kimlik doğrulamalı çağrılar çalışana kadar proxy üzerindeki /api, /v1 ve /mcp erişimlerini ajanlarınızın kullandığı adreslerle kısıtlayın.

Open Connector üretime hazır mı?

Apache 2.0 lisanslıdır ve hızla gelişmektedir: depo 29 Haziran 2026 tarihinde ortaya çıkmış ve v1.3.3 sürümü 30 Temmuz 2026 tarihinde yayınlanmıştır; bu nedenle bu kılavuzdaki her sürüm numarasını 1 Ağustos 2026 tarihine ait bir anlık görüntü olarak değerlendirin. Uygulamayı her zaman bir sürüm etiketine (release tag) sabitleyerek çalıştırın, asla latest veya tip üzerinde çalıştırmayın, her yükseltmeden önce sürüm notlarını okuyun ve daha önce en az bir kez geri yüklemesini test ettiğiniz bir birim (volume) yedeği tutun. Tasarım, sahibi olduğunuz bir sunucu için sağlamdır; buradaki risk mimariden değil, sürüm değişim hızından kaynaklanmaktadır.