Next.js ve Supabase ile çok kiracılı SaaS geliştirme

Hangi projelerde Next.js ve Supabase birlikte kullanıldı?

İkisini birlikte kullandığımız projeler ile yalnız birini kullananları ayırmak gerekiyor, çünkü teknoloji listesi her projede aynı değil:

• Next.js + Supabase: PTLog, ClinicPulse, PsiLog, Kutylawsuit, EntMoment, Photonza, Sorudaş, ADMERD, HuntLine IQ’nun web uygulaması (Next.js 14), PeakUp’ın yönetim paneli (Next.js 16) ve Karaman’ın restoran ve yönetim panelleri.
• Supabase var, Next.js yok: ozelokul.com’un arayüzü Vite + TanStack Start; RichlyMe, GlowTira ve Macsug Expo ile yazılmış mobil uygulamalar.
• Next.js var, Supabase yok: FitZen’in web sitesi ve Garaj’ın yönetim paneli Firestore kullanıyor; Sora Okulları ve Prime Tobacco statik Next.js siteleri; kendi sitemiz amgsoftwarestudio.com Next.js 16 ile yazıldı ve Cloudflare Workers üzerinde çalışıyor.

Bu ayrım önemli, çünkü aşağıdaki RLS ve test pratiklerinin bir kısmı ozelokul.com ve RichlyMe’den geliyor. Onlar Supabase tarafının kanıtı, Next.js tarafının değil. Next.js tarafında kiracı çözümleme, cron rotaları ve barındırma için PTLog, ClinicPulse, HuntLine IQ ve kendi sitemiz örnek.

Çok kiracılık: kiracı nerede çözülüyor?

Çok kiracılı bir SaaS’ta ilk soru, bir isteğin hangi kiracıya ait olduğunun nerede belirlendiği. Projelerimizdeki cevap: kiracı bilgisi oturuma yazılıyor, izolasyonu veritabanı uyguluyor.

PTLog’da her spor salonu tek bir kod tabanında bir kiracı. Next.js middleware’i gym.ptlog.dev ya da özel alan adını kiracıya çözüyor; Supabase’in custom_access_token_hook’u kiracı, rol ve izin claim’lerini oturum JWT’sine yazıyor. Markalama motoru her ana makine adı için ayrı PWA manifest’i ve sharp ile üretilen ikonlar sunuyor; üye, salonun kendi uygulamasını ana ekranına ekliyor.

ClinicPulse’ta kiracı izolasyonu on tablo ve 34 RLS politikasında; uygulama kodunun where clinic_id = … yazmayı hatırlamasına güvenilmiyor. Yeni bir klinik eklemek tek bir satır, ayrı dağıtım yok. Hassas alanlar AES-256-GCM ile şifreleniyor ve anahtar yoksa uygulama açılmıyor.

ozelokul.com’da kiracı marka, kampüs ise markanın içinde FK ile bağlı bir kapsam. Roller enum değil, 56 izin anahtarı; bütün kontrol private.has_perm() fonksiyonunda toplanıyor ve üyelik ile kapsam tek bir işlemde yazılıyor.

Supabase RLS politikalarını nasıl test ediyoruz?

Bir politikayı okuyup doğru olduğuna karar vermek test değil. Testlerimiz istemcinin rolüne geçip yasaklı işlemi gerçekten deniyor:

• RichlyMe: 38 dosyada 401 test, Docker’sız geçici bir Postgres kümesinde, 49 migration’ın tamamı uygulanmış halde koşuyor. Her test BEGIN … ROLLBACK içinde; test.as_user() JWT claim’lerini ayarlıyor, test.throws() beklenen SQLSTATE’i (çoğunlukla 42501) doğruluyor. Yapısal testler "RLS’i kapalı tablo yok" ve "anon hiçbir şeye erişemiyor" kurallarını sonradan eklenen tablolar için de denetliyor.
• ozelokul.com: 33 pgTAP dosyasında 560 iddia. Ayrıcalık kolonu paketinin ilk iki iddiası testin authenticated rolüyle koştuğunu doğruluyor, çünkü süper kullanıcı RLS’i baypas eder ve her şey boşuna geçer. Mutasyon testinde has_perm’den kampüs kapsamı silinince paket 5 iddiada kırmızıya döndü.
• PTLog: şema, RLS ve güvenlik testleri yerel Postgres 17’de; 45 uçtan uca test üretim derlemesine karşı yaklaşık altı dakikada koşuyor.
• HuntLine IQ: pgTAP testleri supabase test db ile; CI her push’ta çalışıyor.
• PeakUp: 36 veritabanı ve RLS testi pnpm dogrula kapısında.

RLS tek başına nerede yetmiyor?

RLS satırı korur, kolonu korumaz. ozelokul.com’daki yetki denetiminde "kullanıcı kendi profilini güncelleyebilir" politikasının satırın tamamını açtığını canlı bir denemeyle gösterdik: bir veli hesabı tek bir PATCH isteğiyle kendi account_type alanını platform yapabiliyordu. Aynı sınıftan beş yer, kolon GRANT’ları ve bir tetikleyiciyle kapatıldı. Velinin iletişim bilgisi ise bir görünümde case when contact_revealed ile maskeleniyor.

İkinci tuzak politikaların kendisi. Private şemadaki fonksiyonlardan EXECUTE yetkisi alınınca her politika permission denied verdi; çözüm yalnız politikalarda adı geçen 9 fonksiyona yetki vermek oldu. Başka bir RLS’li tabloya bakan politika 42P17 sonsuz döngü hatası verdi ve o erişim SECURITY DEFINER bir fonksiyona taşındı.

Üçüncüsü ekran ile API arasındaki fark. RichlyMe’de bulanık gösterilen bir kanıtın akış satırı sahibinin adını ve saniye hassasiyetindeki yayın zamanını hâlâ taşıyordu: ekran gizliyor, API veriyordu. Plan farkında da aynı ilke geçerli; ozelokul.com’da kilitli bölüm private.section_visible() yüzünden sorguda hiç dönmüyor.

Veritabanı testleri sunucu fonksiyonlarını kapsamadığı için ozelokul.com’da ayrıca 80 mutasyon ucu kapılarına göre haritalandı ve 30’u gerçek JWT’lerle canlı sömürü denemesinden geçti.

Edge Function, cron ve webhook’ları nasıl düzenliyoruz?

RichlyMe’de iş kuralı SQL’de, kimlik ve girdi doğrulaması ince Edge Function kabuklarında duruyor: kimliği doğrula, girdiyi doğrula, tek bir RPC çağır. 17 fonksiyonun 9’u yalnız service role ile çağrılabiliyor. Next.js projelerinde de benzer bir düzen kuruyoruz:

• HuntLine IQ: 25 Edge Function. Stripe ve RevenueCat kendi doğrulamalarını gönderdiği için bu iki webhook --no-verify-jwt ile dağıtılıyor; kalan 23 fonksiyon üyenin token’ını doğruluyor. Günlük cron Next.js tarafındaki /api/cron/* rotalarından tetikleniyor.
• ClinicPulse: 24 saatlik WhatsApp hatırlatmaları api/cron/reminders rotasından gidiyor, gönderim ucu dakikada on istekle sınırlı.
• PeakUp: pg_cron ve tetikleyiciler Edge Function’lara x-peakup-cron başlığındaki ortak sırla bağlanıyor; edge_cagri_sagligi(24) son 24 saatin 401 ve 5xx sayısını paneldeki sistem durumu kartına veriyor. Eksik vault sırrı cron işini hata verdirerek durduruyor, hiçbir şey sessizce ölmüyor.
• Photonza: fotoğrafçı yüklemeleri kalıcı bir Postgres kuyruğuna giriyor; iki dakikada bir uyanan bir Cloudflare container’ı işi FOR UPDATE SKIP LOCKED ile alıyor. Etkinlik, davet ve kredi tek bir veritabanı işleminde oluşturuluyor ve aynı istek kimliğiyle tekrar denemek güvenli.

Next.js’i Vercel’de mi, Cloudflare’de mi barındırmalı?

İkisinde de çalışan ürünümüz var. HuntLine IQ’nun Next.js 14 web uygulaması Vercel’de yayında ve native mobil uygulamalar aynı Supabase verisini kullanıyor. Viralance’ta medya Cloudflare R2’den sunuluyor, Vercel yedek olarak duruyor.

Kendi sitemiz amgsoftwarestudio.com, Next.js 16 App Router kodunu vinext ile derleyip tek bir Cloudflare Worker olarak çalıştırıyor. Worker, anonim GET isteklerindeki herkese açık HTML’i Cache API’de 300 saniye tutuyor ve önbellek anahtarına yayın sürümü kimliğini ekliyor; her yeni yayın kendi anahtarıyla başladığı için temizleme adımı yok. 31 Ekim 2026’da tek bir konumdan aldığımız küçük örnekte önbellekten dönen sayfaların ilk bayt süresi 0,15–0,25 saniyeydi. Workers’ta Next.js görsel optimizasyonuna güvenmek yerine görseller derleme anında yedi genişlikte üretiliyor ve özel bir yükleyiciyle eşleniyor.

Kendi sitemizde yayın bilinçli olarak elle yapılıyor: GitHub Actions yalnız tip kontrolü, lint, testler ve üretim derlemesini doğruluyor ve CI’da Cloudflare dağıtım sırrı yok. Müşteri projelerinde barındırma seçimi keşifte yapılıyor; alan adı, sunucu, veritabanı ve servis hesapları müşterinin adına açılıyor.

Sık sorulan sorular

İLGİLİ STÜDYO NOTLARI