Open Connector Kendi Sunucunuzda Nasıl Barındırılır?

Open Connector bir AI aracısı için ne yapar?

Open Connector'ı kendi altyapınızda barındırmak, AI aracılarınız ile çağırdıkları her software as a service (SaaS) API'si arasına tek bir kimlik doğrulama ağ geçidi yerleştirir. Böylece aracı hiçbir zaman sağlayıcı belirtecini taşımaz. Bu ürün, OOMOL Lab tarafından sunulan 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ı işlemlerini HTTP ve MCP (model context protocol) üzerinden sunar.

Sorun ikinci entegrasyonda başlar. Her sağlayıcının kendine ait bir OAuth (open authorization) akışı, refresh token ömrü ve scope adı vardır. Beş sağlayıcıyı bir aracıya elle bağlamak, token süresi dolmadan çalışması gereken beş redirect işleyicisi, beş kimlik bilgisi deposu ve beş yenileme döngüsü anlamına gelir. Bu kodu neredeyse hiç kimse yazmaz. Bunun yerine her hizmet için uzun ömürlü bir personal access token oluşturulur ve bu token aracı yapılandırmasına, bir environment dosyasına veya doğrudan prompt'a yapıştırılır. Ardından bu token, aracının çalıştırdığı her tool tarafından okunabilir ve transcript'e yazılır. Bu durum gizli bilgileri AI aracıların dışında tutma bölümünde açıklanan güvenlik açığıdır.

Kimlik doğrulama ağ geçidi kimlik bilgisini ikiye ayırır. Ağ geçidi sağlayıcı kimlik bilgisini saklar ve OAuth akışını yürütür. Aracı, yalnızca ağ geçidine karşı geçerli olan bir runtime token alır. Aracı bir işlem çağırdığında ağ geçidi saklanan kimlik bilgisini yükler, bunu sunucu tarafında dış isteğe ekler ve yalnızca response body'yi döndürür. Aracı sağlayıcının access token'ını hiçbir zaman almaz. Bu nedenle sızdırılmış bir aracı transcript'i, GitHub hesabınız yerine iptal edilebilen tek bir runtime token'ın ele geçirilmesiyle sınırlı kalır.

Katalogda 1,000'den fazla sağlayıcı ve 10,000 hazır işlem listelenir. Bu sayı projenin kendi beyanıdır ve dışarıdan doğrulanabilecek bir bilgi değildir. Doğrulanabilen yapı şudur: her işlem için bir HTTP endpoint'i, her sağlayıcı için bir saklanan bağlantı ve her aracı için bir token.

Barındırılan bir bağlayıcı hizmeti kullanmak yerine Open Connector neden kendisi barındırılmalıdır

Barındırılan bir bağlayıcı hizmeti aynı işi yapar ve bağladığınız her sağlayıcıya ait yenileme belirteçlerini saklar. Google veya GitHub için bir yenileme belirteci, e-postalarınıza ve depolarınıza erişim sağlayan uzun ömürlü bir kriptografik anahtardır ve genellikle parola değişikliğinden sonra da geçerliliğini korur. Bu hizmetin güvenliği ihlal edilirse sizin sunucunuzun güvenliği de ihlal edilmiş olur. Kendiniz barındırmak, bu kayıtları kiraladığınız ve yönettiğiniz bir makinedeki SQLite veritabanına taşır. Kayıtlar, makinenizden hiç ayrılmayan bir anahtarla korunur.

Başlamadan önce maliyeti açıkça değerlendirin. Bu VPS, yönettiğiniz en değerli sunucu haline gelir. Tek bir dosyada çok sayıda hizmet için geçerli kimlik bilgileri saklanır. Bu nedenle sunucuya, parola yöneticisinin barındırıldığı bir ana makine gibi yaklaşılmalıdır: yalnızca 443 numaralı portu açan bir güvenlik duvarı kullanılmalı, paylaşılan oturum açma hesapları kullanılmamalı, en az bir kez geri yüklenmiş bir yedek bulundurulmalı ve sunucu yanıt vermeyi durdurduğunda uyarı üretilmelidir. Parola kasanızı bu makinede barındırmayacaksanız bağlayıcıyı da bu makinede barındırmayın.

Kurulumdan önce bir sürümü sabitleyin

Open Connector yeni bir projedir. Repository ilk olarak 29 June 2026 tarihinde yayımlandı. 1 August 2026 itibarıyla en yeni etiketli sürüm v1.3.3'tür. Bu sürüm 30 July 2026 tarihinde yayımlandı ve latest etiketini de taşır. Registry ayrıca main üzerindeki en yeni commit'ten oluşturulan tip etiketini de yayımlar.

Bu kadar yeni bir projede hareketli etiketler sık sık değişir. İki sürüm ilerleyen bir docker compose pull, agent'ınızın bağımlı olduğu bir endpoint'i değiştirebilir. Bunun sonucunda akşamı sorunu agent kaynaklı sanarak hata ayıklamakla geçirebilirsiniz. Image'ı bir sürüm etiketine sabitleyin. Sürüm notlarını okuduktan sonra, yükseltme işlemini karar verdiğiniz zaman yapın.

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

Konteyner başlamadan önce şunlara sahip olmanız gerekir:

• Ubuntu 24.04 veya buna yakın bir sürüm üzerinde Compose eklentisine sahip Docker
• A kaydı bu VPS'yi gösteren bir ana bilgisayar adı; örneğin connect.example.com
• Bu ana bilgisayar adı için TLS'yi (transport layer security) sonlandıran bir ters proxy
• Aşağıda oluşturulan 2 rastgele gizli değer

Birden çok Docker Compose uygulaması için Traefik ters proxy proxy tarafını kapsar. Tek bir uygulama için başlangıçtan sona aynı sertifika yapılandırması Docker ve HTTPS ile VPS üzerinde n8n kılavuzunda açıklanır.

Önce gizli değerleri oluşturun. Şifreleme anahtarı, depolanan kimlik bilgilerini şifreler. Yönetici belirteci web konsolunu ve tüm /api yüzeyini korur. Bu değerlerin hiçbir varsayılanı yoktur. Buna rağmen çalışma zamanı bunlar olmadan sorunsuz 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

İlk başlatmadan önce her iki değeri de şimdi parola yöneticinize kopyalayın. Şifreleme anahtarının kurtarma yolu yoktur. Bunun nedeni aşağıdaki hata listesinde açıklanır.

Şimdi compose.yaml. Bu dosya upstream örneğinden 2 noktada farklıdır. Her iki değişiklik 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ş etiketin kullanılmasıdır. İkinci değişiklik bağlantı noktasıdır. Upstream dosyası, ana makinedeki tüm arabirimlere bağlanan 3000:3000 değerini yayımlar. Docker, yayımlanan bağlantı noktalarını paket ufw filtre zincirine ulaşmadan önce NAT (network address translation) tablosuna yazar. Bu nedenle ufw deny 3000 bu bağlantı noktasını kapatmaz. Bu, Docker bağlantı noktalarının ufw'yi atlamasının nedeni bölümünde açıklanan tuzaktır. 127.0.0.1:3000:3000 yazıldığında bağlantı noktası yalnızca loopback arabiriminde yayımlanır. Ters proxy aynı ana makineden bağlanır.

:? her değişkeni gerekli olarak işaretler. Böylece yığın, .env eksik olduğunda kimlik bilgileri şifrelenmeden başlamak yerine başlamayı reddeder. Değerleri compose dosyası yerine .env içinde tutmak, Docker Compose env dosyaları ve gizli değerler bölümündeki kalıptır.

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ı başladıktan sonra { "ok": true } sorusunu yanıtlar. ss çıktısı 127.0.0.1:3000 olmalıdır. 0.0.0.0:3000 okuyan bir satır, bağlantı noktası eşlemesinin hâlâ upstream eşlemesi olduğu ve ağ geçidinin doğrudan tüm internete yanıt verdiği anlamına gelir. Sağlık denetiminde connection refused alınması, konteynerin henüz dinlemediği anlamına gelir. Bu durumda proxy üzerinde değişiklik yapmadan önce günlükleri 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 bilgisayar adı gerektirir?

OOMOL_CONNECT_ORIGIN, genellikle atlanan ayardır. Atlandığında OAuth, sağlayıcı hatası gibi görünen bir şekilde bozulur. Çalışma zamanı, yeniden yönlendirme URI'sini bu kaynak üzerinden <origin>/oauth/callback biçiminde oluşturur. Kaynak ayarlanmadığında http://localhost:3000 varsayılan olarak kullanılır. Bu nedenle çalışma zamanı sağlayıcıya http://localhost:3000/oauth/callback yeniden yönlendirme URI'sini gönderirken OAuth uygulamanızda https://connect.example.com/oauth/callback kayıtlıdır. İki dize farklı olduğundan GitHub şu yanıtı verir:

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 nedenle URI'nin dış dünyadan erişilebilen bir adres olması gerekir. Sağlayıcılar, localhost dışındaki durumlarda düz http:// değerini reddeder. Bu dağıtımın bir ana bilgisayar adına ve sertifikaya ihtiyaç duymasının tek nedeni budur. Kaynak değerini ilk başlatmadan önce ayarlayın; çünkü değer başlangıçta okunur. .env veya compose.yaml dosyasını düzenledikten sonra uygulamak için docker compose up -d komutunu yeniden çalıştırın.

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

Önce OAuth uygulamasını sağlayıcıda oluşturun. GitHub üzerinde yol Settings, ardından Developer settings, sonra OAuth Apps ve New OAuth App şeklindedir. Yetkilendirme geri çağırma URL'sini https://connect.example.com/oauth/callback olarak ayarlayın. Client ID ve client secret değerlerini saklayın.

Her /api çağrısı admin token taşır. Bu nedenle token'ı kabuk oturumu için bir kez dışa aktarın.

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

Bu listeleme, çalışma zamanının her sağlayıcı için beklediği yönlendirme URI'sini gösterir. Bu nedenle origin değerinin geçerli olduğunu doğrulamanın en hızlı yoludur. Değer hâlâ localhost olarak görünüyorsa container eski değerle çalışıyordur ve OAuth akışı son adımda başarısız olur.

Client kimlik bilgilerini kaydedin, 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. Bu değeri tarayıcıda açın ve kapsamları onaylayın. Sağlayıcı tarayıcıyı /oauth/callback adresine geri gönderir. Çalışma zamanı burada kodu değiş tokuş eder ve kimlik bilgisini kaydeder. Origin adresinizdeki web console, aynı admin token arkasında bir form kullanarak aynı adımları uygular. Düz API key kullanan sağlayıcılar bu işlemlerin tümünü atlar: {"authType":"api_key","values":{"apiKey":"..."}} ile PUT /api/connections/<service>, anahtarı doğrudan kaydeder.

Her aracıya kimlik bilgisi yerine bir çalışma zamanı belirteci verin

Aracı, ağ geçidinde yönetici API'sinin ürettiği bir çalışma zamanı belirteciyle 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ıtta oct_ ile başlayan bir belirteç bulunur. Her aracı için bir belirteç oluşturun ve bu belirteci ilgili aracının adıyla adlandırın. Kimliği belirlenemeyen bir belirteci iptal etmek, tüm belirteçleri iptal etmek anlamına gelir. Ardından aracı, işlemleri normal 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 bir kapsayıcıdır. Sağlayıcı yükü data altında bulunur. GitHub belirteci bu yanıtın hiçbir yerinde bulunmaz. MCP istemcisi için aynı bearer başlığıyla https://connect.example.com/mcp adresine yönlendirme yapılır. Ağ geçidi, API başına tek bir araç yerine search_actions ve execute_action gibi keşif araçları sunar. Bu yaklaşım, aracının araç listesini küçük tutar. Bir VPS üzerinde MCP sunucularını çalıştırma bu bağlantının istemci tarafını açıklar.

Tamamlandı olarak değerlendirmeden ö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, /v1 çağrısının bearer belirteci olmadan yapılmasını önerir. Bu nedenle çalışma zamanı kimlik doğrulaması yapılandırılmadan yapılan bir kurulum, porta erişebilen herkes için işlemleri yürütür. Kimlik doğrulaması olmadan yaptığınız çağrı 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 ters proxy üzerinde /api, /v1 ve /mcp erişimini aracıların geldiği adreslerle sınırlandırın. Dünya genelinden yalnızca /oauth/callback erişilebilir kalmalıdır. Sağlayıcının tarayıcı yönlendirmesi için gereken tek yol budur.

Eylem listesini aracının ihtiyaç duyduğu düzeye indirme

Arkasında bin sağlayıcı bulunan bir ağ geçidini dil modeline sunmak geniş bir saldırı yüzeyi oluşturur. İki denetim bunu daraltır.

OOMOL_CONNECT_ALLOWED_ACTIONS, virgülle ayrılmış bir izin listesi alır ve service.* ile * değerlerini destekler. OOMOL_CONNECT_BLOCKED_ACTIONS engel listesidir ve engel listesi önceliklidir. İzin listesini github.get_current_user,github.list_issues olarak ayarlamak, aracı ne isterse istesin diğer tüm eylemlerin reddedileceği anlamına gelir. Bu, bir hatayla olay arasındaki farktır. Çalışma zamanı belirteçleri, genel kurallara ek olarak kendi eylem kurallarını taşır. Bu belirteçlerin allowedProxies listesi başlangıçta boştur. Bu nedenle POST /v1/proxy/:service, izin verilene kadar reddedilir. Bu proxy uç noktası, kimlik bilgileriniz eklenmiş ham bir isteği bir sağlayıcıya iletir. Bu nedenle belirli bir aracının ihtiyaç duymadığı sürece bu alanı boş bırakın.

OOMOL_CONNECT_ALLOW_PRIVATE_NETWORK varsayılan olarak false değerini kullanır. Bu değer, self-hosted bir sağlayıcı bağlantısının 169.254.169.254 üzerindeki bulut meta veri hizmeti veya aynı ağdaki veritabanınız gibi özel bir adrese yönelmesini engeller. Bu seçeneği kapalı bırakın. Yalnızca kendiniz barındırdığınız bir sağlayıcı için açın.

Her belirteci barındıran kutunun yedeğini alın

İki unsur önemlidir ve her biri diğeri olmadan kullanılamaz. connector-data birimi içindeki /app/data/connect.sqlite veritabanı, mühürlenmiş kimlik bilgilerini tutar. .env içindeki şifreleme anahtarı bunların mührünü açar. Anahtar olmadan birim yedeği hiçbir şeyi geri yükleyemez. Birim olmadan anahtar da hiçbir şeyi geri yükleyemez. Bu nedenle anahtar parola yöneticisinde tutulmalı, birim ise normal yedekleme döngüsüne dahil edilmelidir.

SQLite dosyasını kopyalamadan önce container durdurulmalıdır. Yazma işlemi sırasında alınan bir kopya, bozuk bir veritabanı olarak geri yüklenebilir.

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 dizininizin adı ile _connector-data ifadesinin birleşimidir. Bu nedenle ilk komut orada bulunur. Gerçek adı üçüncü komuta yapıştırın. Arşivi VPS üzerindeki restic yedekleri ile VPS dışına gönderin. Bu işlem, arşiv dışarı çıkmadan önce onu şifreler. Bunun nedeni, söz konusu arşivin kimlik bilgileri deposu olmasıdır.

Çalışma zamanı, son işlem çalıştırmalarını denetim kayıtları olarak tutar. Varsayılan olarak bu kayıtların sayısı 5,000'dir. Böylece konsol, hangi agent'ın neyi ve ne zaman çalıştırdığını gösterebilir. Bir agent beklenmedik şekilde davrandığında okunması gereken ilk kayıt budur. Bir Uptime Kuma durum sayfasını https://connect.example.com/health üzerine de yönlendirin. Gateway yanıt vermeyi durdurduğunda agent'lar anlaşılması zor hatalar verir. Gateway'in devre dışı olduğunu bilmek, agent çıktısını incelemek için harcanacak bir saati kurtarır.

İşler neyi bozar ve göreceğiniz ileti

Sağlayıcıdaki redirect_uri_mismatch. Origin ile kayıtlı geri çağırma URL'si farklıdır. /api/oauth/configs içindeki tam dizeyi sağlayıcının uygulama ayarlarıyla karşılaştırın. https ile http arasındaki kısmı ve sondaki eğik çizgiyi de kontrol edin.

Her /api çağrısı 401 döndürüyor. Yönetici belirteci üst bilgisi eksik veya yanlış yazılmıştır. Üst bilgi Authorization: Bearer <token> şeklindedir. Web konsolu da aynı belirteci ister.

Container çalışıyor ve kimlik bilgileri düz metin olarak duruyor. Bu durum, OOMOL_CONNECT_ENCRYPTION_KEY container'a hiç ulaşmadığında oluşur. Runtime başlatmayı reddetmek yerine kimlik bilgisi kayıtlarını şifrelenmemiş olarak saklar. Bunu kendi kurulumunuzda doğrulayın: Tanıyabileceğiniz bir API key ile bir sağlayıcı bağlayın, ardından veritabanında bu anahtarı arayı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 sayı, anahtarın etkin olmadığını gösterir. Bu durumda .env dosyasının compose.yaml ile aynı dizinde bulunduğunu ve docker compose config değerinin değeri gösterdiğini kontrol edin. Anahtar ayarlandığında aynı arama 0 döndürür. Bunun nedeni, kaydın AES-256-GCM ile (advanced encryption standard, 256-bit key, Galois/counter mode) mühürlenmesidir.

Geri yüklemeden sonra hiçbir şey çözülemiyor. Şifreleme anahtarı değişmiş veya kaybolmuştur. Tasarım gereği anahtar hiçbir zaman verilerin yanına yazılmaz. Bu nedenle kurtarma yolu yoktur ve hiçbir destek talebi yardımcı olmaz. Her sağlayıcıyı yeniden bağlayın. Anahtar döndürme, ayrı bir anahtar değişkeni ve runtime içindeki bir data komutu aracılığıyla desteklenir. Bu nedenle herhangi bir anahtar döndürme işlemi yapmadan önce güncel sürüm notlarını okuyun.

Agent, catalog'da görebildiği bir action'ın adını içeren bir hata veriyor. Discovery ve execution birbirinden ayrıdır. Bir action search_actions içinde görünebilir. Buna rağmen OOMOL_CONNECT_ALLOWED_ACTIONS tarafından, denylist nedeniyle veya ilgili runtime token'ının kendi kuralları gereği reddedilebilir.

Yükseltmeler. Volume'ü yedekleyin, image tag'ini yeni sürümle değiştirin, ardından docker compose pull && docker compose up -d çalıştırın. Bir migration satırı için docker compose logs -n 50 connector çıktısını izleyin. Sisteme yeniden güvenmeden önce health check'i ve gerçek bir action'ı tekrar çalıştırın. Geri alma işlemi eski tag'i yeniden ayarlamak anlamına gelir. Bu işlem yalnızca tag'i sabitlediğiniz için çalışır.

FAQ

Open Connector'ı kendi ortamımda barındırmak için genel erişime 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 üzerinde çalışan bir ağ geçidi yeterlidir. OAuth için pratikte evet. Sağlayıcı, tarayıcıyı geri çağırma URL'nize yönlendirir. Bu nedenle URL'nin genel internet üzerinden çözümlenebilmesi gerekir. Sağlayıcılar localhost dışında 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. <origin>/oauth/callback değerini sağlayıcının OAuth uygulamasına kaydedin.

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

Kaydedilen kimlik bilgileri şifresi çözülerek okunamaz. Kurtarma seçeneği yoktur. Anahtar, kasıtlı olarak verilerle aynı yerde saklanmaz. Bu nedenle veritabanını elinde bulunduran hiç kimse, siz de dahil olmak üzere, anahtarı okuyamaz. Tek seçeneğiniz yeni bir anahtar belirlemek ve tüm sağlayıcıları yeniden bağlamaktır. Anahtarı bir parola yöneticisinde, veritabanını ise yedekleme döngünüzde saklayın. Geri yükleme işlemi her ikisini de gerektirir.

AI aracım sağlayıcının erişim belirtecini görebilir mi?

Ağ geçidi üzerinden çağrı yaptığında göremez. Aracı, oct_ ile başlayan bir çalışma zamanı belirteciyle kimlik doğrulaması yapar. Ağ geçidi, sağlayıcı kimlik bilgisini sunucudaki giden isteğe ekler ve yalnızca yanıtı döndürür. Bu özelliği bozan iki durum vardır: kimlik bilginiz eklenmiş ham istekleri ileten /v1/proxy/:service uç noktası ve izinlerinin başlangıçta boş olmasının bilinçli bir nedeni vardır; ayrıca bir API anahtarını araca kendiniz yapıştırmanız da ağ geçidini tamamen devre dışı bırakır.

Ağ geçidine genel internet üzerinden erişilebilmeli mi?

Yalnızca /oauth/callback erişilebilir olmalıdır. Docker'ın NAT kurallarının güvenlik duvarınızı aşarak erişim sağlamaması için kapsayıcı portunu 127.0.0.1 üzerinde yayımlayın ve ters proxy'yi öne yerleştirin. Ardından authorization üst bilgisi olmadan tek bir eylem çağrısını test edin. Çağrı başarılı olursa /api, /v1 ve /mcp değerlerini proxy üzerinde, aracıların kullandığı adreslerle sınırlandırın. Kimliği doğrulanmış çağrıların çalışabildiği tek çağrı türü olana kadar bu işlemi sürdürün.

Open Connector üretim kullanımı için hazır mı?

Apache 2.0 lisansına sahiptir ve hızlı gelişmektedir: depo 29 June 2026 tarihinde yayımlandı ve v1.3.3 30 July 2026 tarihinde yayımlandı. Bu nedenle bu kılavuzdaki her sürüm numarasını 1 August 2026 tarihindeki bir anlık görüntü olarak değerlendirin. Uygulamayı bir sürüm etiketi sabitleyerek çalıştırın. latest veya tip üzerinde çalıştırmayın. Her yükseltmeden önce sürüm notlarını okuyun. Bir kez geri yüklediğiniz bir volume yedeğini saklayın. Tasarım, sahibi olduğunuz bir sistem için sağlamdır. Risk mimariden değil, sürümlerin hızlı değişmesinden kaynaklanır.