Vibe coded uygulamayı production'a taşımak: güvenlik dışında kalan her şey
Vibe coding aracıyla yazdırdığın bir uygulamayı production'a taşımak altı ayrı işten geçiyor. Güvenlik ayrı bir yazıda, burada geri kalan operasyon yolu var.
Lovable, Bolt, v0, Cursor ya da Replit ile yazdırdığın bir uygulamayı production'a taşımak altı ayrı işten geçiyor: domaini kendi hesabına bağlamak, ortam değişkenlerini doğru ortamlara ayırmak, aracın demo veritabanından gerçek bir veritabanına geçmek, yedeklemeyi bir takvime bağlamak, izleme ve uyarıları açmak, her deploy'u bir staging kontrolünden geçirmek. Güvenlik bu listede yok. RLS politikaları, sızan anahtarlar ve webhook imzaları kendi güvenlik kontrol listemizde. Bu yazı geri kalanını kapatıyor: demo olmaktan çıktıktan sonra elinde kalan iş.
TL;DR
Sıralı altı iş var: domaini taşı, ortam değişkenlerini ortamlara göre ayır, demo veritabanından çık, yedeklemeyi takvime bağla, izlemeyi aç, her deploy'u kullanıcıya ulaşmadan önce bir staging adımından geçir. Aşağıdaki her başlık tam hamleyi söylüyor. Güvenlik ayrı bir iş, sonda bağlantısı var.
"Yapay zeka uygulamanı yayınla" içeriklerinin çoğu ilk deploy butonunda bitiyor. Altı hafta sonra ücretsiz veritabanı planının bağlantı sınırına çarpması ya da staging adımı hiç olmadığı için kötü bir commit'in doğrudan production'a gitmesi gibi konulara girmiyor. Bu yazı demoda çalışan ve şimdi gerçek kullanıcıyla, gerçek trafikle, gerçek arızayla karşılaşması gereken uygulama için yazıldı.
Domain ve DNS: aracın kendi alt alanından kendi hesabına taşımak
Lovable, Bolt ve benzerleri varsayılan olarak kendi alt alanlarına yayın yapıyor. Kendi domaininize geçmek, DNS'i kodu nereye deploy ettiysen oraya yönlendirmek demek, kod GitHub'a çıkarıldıktan sonra genelde Vercel'e. Apex domain için (ornek.com) bu bir A kaydı, bir alt alan için (www.ornek.com) bir CNAME kaydı. Vercel panelinin Domains sayfası projenize özel tam değeri gösteriyor, kayıt doğru çözümlendiğinde SSL sertifikasını otomatik veriyor ve yeniliyor.
Her seferinde atlanan bir nokta var: sadece A/CNAME kaydını değil, nameserver'ları da taşıyorsan önce mevcut MX kayıtlarını kopyala. Nameserver'ı taşıyıp MX'i unutmak, o domaine gelen e-postayı sessizce öldürür, birisi "form bildirimi hiç gelmedi" diyene kadar fark edilmez.
Ölçüm
Komut: curl -s -o /dev/null -D - https://lumiasoft.com/
Kendi production domainimizde çalıştırdık. Sonuç: strict-transport-security: max-age=63072000 ve server: Vercel, bizim tarafımızda hiçbir manuel sertifika ayarı olmadan. Doğru yayına alınmış bir domain böyle görünüyor: SSL ve HSTS başlığı elle ayarladığımız bir şey değil, platformdan geliyor.
Ortam değişkenleri: tek bir .env dosyasından gerçek bir secret yönetimine
Vibe coding araçları her anahtarı, genel olanı da gizli olanı da, tek bir .env dosyasına yazıyor, çünkü kendi sandbox'ları içinde bu ikisi arasında pratik bir fark yok. Gerçek bir host'ta bu fark önemli. Vercel değişkenleri Config (proje erişimi olan herkese okunabilir) ve Secret (kaydedildikten sonra sadece yazılabilir) olarak ikiye ayırıyor, her birini Production, Preview ya da Development'a bağımsız olarak bağlıyor. Sadece sunucu tarafında kullanılan bir anahtarın NEXT_PUBLIC_ öneki taşımasına hiç gerek yok, taşırsa o değer doğrudan tarayıcıya giden bundle'a düşüyor.
Sert bir tavan da var: Vercel ortam değişkenlerini her deployment için toplam 64 KB ile sınırlıyor, tek bir değişken bu boyutu geçemiyor, Edge runtime ya da Middleware değişkenleri için sınır daha da düşük, 5 KB. Vibe coding ile yazılan bir uygulama buna nadiren yaklaşır ama uzun bir sertifika ya da JWT'yi bir değişkene yapıştırmadan önce bilinmesi gereken bir sınır.
Ölçüm: kendi production kod tabanımız
Komut: grep -rohE "process\.env\.[A-Z0-9_]+" src | sort -u, bu sitenin kendi reposunda çalıştırıldı.
10
NEXT_PUBLIC_ önekli, bilerek tarayıcıya giden değişken
26
sunucu tarafında kalan sır: API anahtarı, SMTP, admin oturumu, webhook
Oran kabaca 1:2.6, yani tarayıcıya giden her bir değişkenin yanında tarayıcıya hiç ulaşmaması gereken iki buçuk sır duruyor. Vibe coding aracının tek .env dosyası bu ayrımı görünmez kılıyor. Gerçek bir host seni bunu açıkça yapmaya zorluyor.
Demo veritabanından production'a geçiş
Lovable ve Bolt genelde kendi şemsiyeleri altında bir Supabase projesi açıyor, fikri kanıtlamak için, production yükünü taşımak ya da aracın aboneliğinden daha uzun ömürlü olmak için değil. Kendi sahip olduğun bir veritabanına geçmek şemanı ve verini dışa aktarmak, kendi Supabase (ya da düz Postgres) projeni kurmak ve gerçek trafiği yönlendirmeden önce her bağlantı dizesini değiştirmek demek. Taşıdıktan sonra RLS testlerini tekrar çalıştır, eski projede çalışan bir politika otomatik olarak taşınmıyor; bunu nasıl test edeceğini aşağıda bağlantısı olan güvenlik kontrol listemizde tam olarak gösteriyoruz.
Taşıdıktan sonra çoğu kişiyi yakalayan bir detay var: Supabase'in kendi önerisi, serverless fonksiyonlar için bağlantı havuzunu fonksiyon başına tek bağlantıya sabitlemek, çünkü fonksiyon her istekte sıfırdan çağrılıyor ve varsayılan 10 bağlantılık bir havuz boyutu eşzamanlı trafik altında veritabanının bağlantı sınırını hızlıca tüketebiliyor. Tek satırlık bir ayar ama uygulama canlıya çıkıp trafik gerçek olana kadar fark edilmiyor.
Yedekleme: tek seferlik ayar değil, takvime bağlı bir rutin
Supabase'in Free katmanında otomatik bir yedekleme servisi yok: supabase db dump komutunu kendin çalıştırıp sonucu platform dışında bir yerde saklaman bekleniyor. Point-in-time recovery da orada yok. Ücretli katmanlar otomatik günlük yedek ekliyor, PITR ise bunun üzerine ücretli bir ek paket.
PITR fiyatı 7 günlük geri dönüş penceresinde ayda yaklaşık 100 dolardan başlıyor, 28 günlük pencerede 400 dolara kadar çıkıyor, altında en az Small compute paketi gerektiriyor. Bunların hiçbiri bir işe yaramıyor, ta ki biri yedeği gerçekten geri yükleyip test edene kadar. Bunu yayın gününde değil, önceden yap.
İzleme ve uyarılar: kim, ne zaman haber alıyor
Bu, güvenlik kontrol listemizdeki hata takibi testinden farklı bir şey; o test bir hatayı tetikleyip bir yerde göründüğünü doğrulamanı istiyor. Burada süregen bir pratikten bahsediyoruz: production URL'ini düzenli aralıklarla kontrol eden bir uptime kontrolü, tek bir olayı değil zaman içindeki hata oranını gösteren bir panel, kimsenin okumadığı bir log satırı değil gerçek bir kişiye ulaşan bir uyarı. Vercel OpenTelemetry tracing'i kutudan çıktığı gibi destekliyor, yani fonksiyon izlerin sadece Vercel panelinde değil zaten kullandığın herhangi bir APM aracına da akabiliyor.
Uyarı eşiğini ve kimin sahip olacağını yayından önce karar ver, ilk olayda değil. "Birisi fark eder" bir izleme planı değil.
Deploy hattı: commit'ten canlıya kaç adım var
Vibe coding aracının deploy butonu doğrudan production'a gidiyor. Uygulamayı kendin host etmeye başladığında, her commit gerçek kullanıcıya ulaşmadan önce önce bir preview deployment'tan, sonra bir staging kontrolünden geçmeli.
Rollback adımı hattın kendisinden daha önemli. Vercel'de önceki production deployment'ı, yeni sürüm bir şeyi bozarsa anında geri alınabilecek şekilde hazır duruyor; bu seçeneği ihtiyacın olmadan önce aklında tut.
Ölçek sınırları: ücretsiz plan gerçekte nerede tıkanıyor
Trafik demoda gördüğünden fazlasına çıkmadan önce bilinmesi gereken birkaç rakam var. Vercel fonksiyonları Hobby ve Pro'da eşzamanlılığı otomatik olarak 30.000 eşzamanlı çalıştırmaya kadar ölçekliyor, Enterprise'da bu 100.000'in üzerine çıkıyor. Production'da iki hafta, preview'de 48 saat boyunca tetiklenmeyen fonksiyonlar arşivleniyor ve bir sonraki çağrıda cold start'a kabaca bir saniye daha ekliyor. Fluid compute artık varsayılan olduğu için fonksiyon süre sınırları çoğu kişinin tahmin ettiğinden daha yüksek: Hobby'de varsayılan ve maksimum 300 saniye, Pro ve Enterprise'da 800 saniyeye kadar, beta bir katmanla 1800 saniyeye kadar çıkabiliyor; çoğu kişinin hâlâ plan yaptığı eski 10 saniyelik sınırdan çok farklı bir tablo.
Veritabanı tarafında gerçek sınır genelde CPU değil, bağlantı sayısı: ücretsiz bir Supabase projesinin pooler'ı, birkaç serverless fonksiyon eşzamanlı olarak ona vurduğu anda hızla tükeniyor. Bu yüzden yukarıdaki veritabanı bölümündeki tek bağlantılık havuz ayarı sadece teoride değil pratikte de önemli.
Ne zaman bu yol haritası yetmiyor
Bu yazı operasyon tarafını kapatıyor, işin tamamını değil. Uygulama bugünkünden gerçekten daha fazla trafik taşıması gerekiyorsa gerçek bir mimari incelemesinin yerini tutmuyor, güvenlik kontrol listesindeki sekiz maddenin de yerini tutmuyor; ikisi de önemli, biri diğerinin yerine geçmiyor. Buradaki altı işin hepsini yaptın ve uygulama hâlâ sorun çıkarıyorsa, ya da ekibinin bunu sürekli sahiplenecek zamanı yoksa, bu farklı bir konuşma: yapay zeka projesi tamamlama hizmetimiz tam bu noktadan devralmak için var.
Güvenlik tarafını henüz yapmadıysan önce vibe coding güvenlik kontrol listesi yazımıza bak, ya da aynı sekiz soruyu daha hızlı geçmek için yayına hazırlık kontrolü aracımızı kullan. Proje hâlâ aracın kendi export'unda duruyorsa ve kendi reponuza taşınmadıysa, export rehberimiz bundan önceki adım.
İki listedeki kritik maddeler hâlâ açıksa ve ekibin bunları tek başına kapatamıyorsa, yapay zeka projesi tamamlama hizmetimiz tam bu yol haritasının bittiği yerden devralıyor.
Sık sorulan sorular
Bunların hepsini aynı anda yapmam gerekiyor mu?
Hayır. Domain ve ortam değişkenleri önce gelir, çünkü onlar olmadan geri kalanı çalışmıyor. Veritabanı taşıması ve yedekleme sonra gelir. İzleme ve deploy hattı, uygulama yeni altyapısında oturduktan sonra eklenebilir.
Uygulamayı hangi araç yazdığına göre değişiyor mu?
Detaylar değişiyor: Lovable ve Bolt Supabase'e yaslanıyor, Replit kendi hosting modeline sahip, v0 projeleri genelde zaten doğrudan Vercel'e deploy oluyor. Hangi araç kodu yazmış olursa olsun altı iş aynı kalıyor.
Kendi veritabanıma geçmek, aracın planında kalmaktan daha mı maliyetli?
Genelde evet, ama bu kendi verine sahip olmanın ve aracın aboneliğine ya da sınırlarına bağlı kalmamanın maliyeti. Ücretsiz katmandaki bir Supabase ya da Vercel projesi, bu bir gerçek masrafa dönüşmeden önce erken aşama trafiğin çoğunu karşılıyor.
Burada en çok atlanan tek adım hangisi?
Yedekleme. Bir yedeğin var olduğunu doğrulamak kolay. Gerçek bir geri yüklemeyi kimse ihtiyacı olana kadar test etmiyor, tam da çalışmadığını öğrenmek için en kötü an.
Güvenlik bu zaman çizelgesinde nereye düşüyor?
Güvenlik kontrol listesini bu yol haritasından önce çalıştır, sonra değil; açık bir RLS politikasıyla canlıya çıkan bir uygulama için hazır bir deploy hattı, açığı production'a daha hızlı taşımaktan başka bir şey yapmıyor.