Workers for Platforms

Workers for Platforms nedir?

Bir SaaS ürünü kuruyorsun ve müşterilerin kendi mantıklarını yazabilmesini istiyorsun. E-ticaret platformunda mağaza sahibi özel bir kargo hesaplama fonksiyonu yazsın. CMS’te tema geliştiricisi sunucu tarafı bir dönüşüm eklesin. Otomasyon aracında kullanıcı kendi webhook işleyicisini tanımlasın.

Bu, güvenilmeyen kodu ölçekte çalıştırmak demektir — ve klasik çözümleri (konteyner havuzu, sanal makine, VM izolasyonu) pahalı ve yavaştır.

Workers for Platforms bu modeli Cloudflare’in isolate mimarisi üzerine kurar. Müşteri Worker’ları bir dispatch namespace içinde toplanır; senin yazdığın bir dispatch Worker gelen isteği inceleyip hangi müşteri kodunun çalışacağına karar verir.

Cloudflare resmî olarak üç kullanıcı adı veriyor: Shopify Oxygen (birebir “built on Workers for Platforms”), Grafbase ve Triplit.

Nasıl çalışır?

Mimari

İstek → Dispatch Worker (senin kodun)
           │  hangi müşteri? hangi Worker?
           ▼
        Dispatch namespace
           ├── musteri-a Worker'ı
           ├── musteri-b Worker'ı
           └── musteri-c Worker'ı

Müşteri Worker’ları doğrudan internetten erişilemez. Yalnızca senin dispatch Worker’ın üzerinden çalışırlar — yani yetkilendirme, hız sınırlama ve yönlendirme tamamen senin kontrolünde.

Dispatch Worker

export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    const musteriId = url.hostname.split(".")[0];   // musteri-a.platform.com

    // Kendi yetkilendirme ve kotam burada
    if (!(await musteriAktifMi(env, musteriId))) {
      return new Response("Hesap askıda", { status: 402 });
    }

    try {
      const musteriWorker = env.DISPATCHER.get(musteriId);
      return await musteriWorker.fetch(request);
    } catch (h) {
      if (h.message.startsWith("Worker not found")) {
        return new Response("Bu müşteri için Worker tanımlı değil", { status: 404 });
      }
      throw h;
    }
  },
};

Müşteri Worker’ı yükleme

# Namespace yönetimi
npx wrangler dispatch-namespace create production
npx wrangler dispatch-namespace list
npx wrangler dispatch-namespace get production
npx wrangler dispatch-namespace rename eski yeni

# Müşteri Worker'ını namespace'e yükle
npx wrangler deploy --dispatch-namespace production

const form = new FormData();

form.append("metadata", JSON.stringify({
  main_module: "index.js",
  // Binding'ler BURAYA konur — wrangler yapılandırma dosyası olarak yüklenemez
  bindings: [
    { type: "kv_namespace", name: "VERI", namespace_id: kvId },
    { type: "plain_text", name: "MUSTERI_ID", text: musteriId },
  ],
  keep_bindings: ["secret_text"],   // mevcut sırları koru
}));

form.append("index.js", new Blob([musteriKodu], { type: "application/javascript+module" }), "index.js");

await fetch(
  `https://api.cloudflare.com/client/v4/accounts/${hesapId}` +
  `/workers/dispatch/namespaces/production/scripts/${musteriId}`,
  { method: "PUT", headers: { Authorization: `Bearer ${token}` }, body: form },
);

Outbound Worker — müşteri egress’ini kontrol etme

Müşteri kodunun dışarıya ne gönderdiğini denetlemek istersin. Outbound Worker bunu sağlar: müşteri Worker’ının yaptığı her fetch senin kodundan geçer.

Ne zaman kullanılır, ne zaman kullanılmaz

Uygun olduğu işler

• Müşterilerin sunucu tarafı kod yazabildiği SaaS platformları
• Çok kiracılı eklenti/tema ekosistemleri
• Müşteri başına özelleştirilebilir yönlendirme veya dönüşüm mantığı
• Kendi platformunun altında “fonksiyon olarak hizmet” sunmak

Uygun olmadığı işler

• Kendi kodunu çalıştırmak. Düz Workers yeterli.
• Workflows gerektiren müşteri mantığı. Desteklenmiyor.
• Tam kabuk erişimi veya dosya sistemi gerektiren müşteri kodu. Bunun için Sandboxes var.
• Az sayıda müşteri. Dispatch namespace altyapısı kurmak, üç müşteri için fazla karmaşıktır; service binding’lerle daha basit çözülür.
• Egress kontrolünün mutlak olması gereken durumlar. Yukarıdaki iki kör nokta var.

Somut örnekler

1. Müşteri başına kota ve yetkilendirme

export default {
  async fetch(request, env) {
    const musteriId = new URL(request.url).hostname.split(".")[0];

    // Kota kontrolü — müşteri Worker'ı çalışmadan ÖNCE
    const sayac = env.KOTA.getByName(`musteri:${musteriId}`);
    const { izin, kalan } = await sayac.kontrol();
    if (!izin) {
      return new Response("Aylık kota doldu", { status: 429 });
    }

    const worker = env.DISPATCHER.get(musteriId);
    const yanit = await worker.fetch(request);

    // Müşteri Worker'ının yanıtına kendi başlıklarını ekle
    const cikti = new Response(yanit.body, yanit);
    cikti.headers.set("X-Kalan-Kota", String(kalan));
    return cikti;
  },
};

2. Müşteri Worker’ına sınırlı kaynak verme

// Upload API metadata'sında her müşteriye kendi izole kaynakları verilir
const metadata = {
  main_module: "index.js",
  bindings: [
    // Müşterinin yalnızca kendi KV alanına erişimi var
    { type: "kv_namespace", name: "VERI", namespace_id: musteriKvId },
    // Müşteri kendi kimliğini değiştiremez
    { type: "plain_text", name: "MUSTERI_ID", text: musteriId },
  ],
  // Kaynak sınırları
  limits: { cpu_ms: 50 },
};

3. Statik dosya hash’ini tuzlama

Bu, çok kiracılı bir platformda zorunlu bir adımdır.

// YANLIŞ — aynı içerik farklı müşteriler arasında paylaşılır
const hash = sha256(dosyaIcerigi).slice(0, 32);

// DOĞRU — hesap kimliğiyle tuzla
const hash = sha256(hesapId + dosyaIcerigi).slice(0, 32);

Resmî gerekçe: “assets with identical hashes may be shared across them.” Tuzlamazsan iki müşterinin aynı içerikli dosyası aynı depoya düşer.

4. Outbound Worker ile egress denetimi

export default {
  async fetch(request, env) {
    const url = new URL(request.url);

    // Müşteri kodunun iç ağa erişmesini engelle
    if (url.hostname.endsWith(".internal") || url.hostname === "localhost") {
      return new Response("İç ağa erişim engellendi", { status: 403 });
    }

    // Denetim kaydı
    env.LOG.writeDataPoint({
      blobs: [env.MUSTERI_ID, url.hostname],
      doubles: [Date.now()],
    });

    return fetch(request);
  },
};

Demo 1: Dispatch namespace kurma ve iki müşteri yükleme

Adım 1 — Namespace oluştur

npx wrangler dispatch-namespace create production
npx wrangler dispatch-namespace list

Adım 2 — Dispatch Worker’ı yaz ve deploy et

{
  "name": "platform-dispatcher",
  "main": "src/index.ts",
  "compatibility_date": "2026-08-31",
  "dispatch_namespaces": [
    { "binding": "DISPATCHER", "namespace": "production" }
  ]
}

Adım 3 — İki müşteri Worker’ı yükle

Adım 4 — Yönlendirmeyi doğrula

curl -H "Host: musteri-a.platform.com" https://<dispatcher>/
curl -H "Host: musteri-b.platform.com" https://<dispatcher>/

Adım 5 — Olmayan müşteriyi dene

Demo 2: İzolasyon ve egress kontrolü

Adım 1 — Müşteri Worker’ları birbirini görebiliyor mu

Bir müşteri Worker’ından diğerinin KV alanına erişmeyi dene.

Adım 2 — Outbound Worker’ı devreye al

Adım 3 — Kör noktayı doğrula

Durable Object binding’i üzerinden yapılan fetch’in outbound Worker’a düşmediğini göster.

Adım 4 — Log devralmayı doğrula

Ölçüm

Fiyatlandırma

Kesin olan: müşteri Worker’larının çalıştırdığı istek ve CPU süresi normal Workers fiyatlandırmasına tabidir ve script sayısı ayrı bir kalem oluşturur.

Limitler

Müşteri Worker’larının bellek, script boyutu, başlangıç süresi ve subrequest sınırlarında hangi kolonun (Free / Paid) geçerli olduğu resmî olarak yayımlanmamıştır.

Lisanslama ve hukuki çerçeve

Workers for Platforms tescilli bir hizmettir; Cloudflare Hizmet Şartları kapsamındadır.

Sorumluluk zinciri. Bu ürünle müşterilerinin kodunu sen çalıştırıyorsun. Cloudflare’in Kabul Edilebilir Kullanım Politikası senin hesabın üzerinden geçen tüm trafiği kapsar — yani müşterinin kötüye kullanımı senin sorumluluğuna girer. Kendi kullanım şartlarında bunu müşterine yansıtman ve teknik olarak sınırlaman gerekir.

Veri işleme. Müşteri Worker’larının işlediği veri senin hesabın üzerinden akar. Kişisel veri söz konusuysa hem Cloudflare ile aranda hem de müşterinle aranda veri işleme sözleşmeleri gerekir — bu durumda sen hem veri sorumlusu hem veri işleyen konumunda olabilirsin.

Sık yapılan hatalar

Statik dosya hash’ini tuzlamamak. Aynı içerikli dosyalar müşteriler arasında paylaşılır. sha256(hesapId + icerik) kullan.

Outbound Worker’ı tam bir güvenlik sınırı sanmak. Durable Object ve mTLS sertifika binding’lerinden çıkan istekler yakalanmaz.

Binding’leri Wrangler yapılandırma dosyası olarak yüklemeye çalışmak. Upload API’de binding’ler metadata alanına konur.

keep_bindings vermeden PUT atmak. Mevcut binding’ler silinir.

Etiket eklerken PUT .../tags kullanmak. Bu tam değiştirmedir; tek etiket için PUT .../tags/$TAG kullan.

Trusted mode’u sonradan açıp yeniden deploy etmemek. request.cf nesnesi mevcut Worker’larda görünmez.

Müşteri Worker’larında Workflows kullanmaya çalışmak. Desteklenmiyor.

Namespace’i silmeye çalışmadan önce içini boşaltmamak. Tüm müşteri Worker’ları önce silinmelidir.