Vercel Hobby sınırları bir seyahat dizinini Cloudflare'e itti ve 650 satırlık yapılandırma dosyası baştan yazılmak zorunda kaldı

Orta ölçekli bir seyahat dizinini işleten bir geliştirici, bir deployment depolama uyarısı ve plan şartlarıyla uyumsuzluk nedeniyle sitede kalmayı sürdürülemez hale getirdikten sonra, siteyi Vercel'in ücretsiz Hobby planından Cloudflare Workers'a taşıma sürecini belgeledi. dev.to'da tedagentic kullanıcı adıyla yazan yazar, rutin bir ayar işi gibi görünen ancak sonunda tersine mühendislik alıştırmasına dönüşen süreci anlatıyor.

Ücretsiz hosting neden çalışmayı bıraktı

Yaklaşık 800 önceden render edilmiş sayfası, birikmiş 190 yönlendirme kuralı ve küçük bir arka uç veritabanı olan site, ömrü boyunca Hobby kademesinde kaldı. Gönderiye göre bunu sonlandıran iki şey oldu. İlki, deployment depolamasının yüzde 75'inin kullanıldığını bildiren bir e-posta geldi. İkincisi, site ortaklık komisyonu kazanırken Hobby ticari olmayan kullanıma ayrıldığından, yazarın kendi itirafıyla site bu plana baştan uygun değildi. Sitenin bulunduğu aşamada Pro kademesi için ayda 20 dolar ödemek mantıklı değildi. Cloudflare'in ücretsiz kademesi statik dosyaları ücretsiz sunuyor ve günlük 100.000 isteklik worker kotası, sitenin ortalama 16.000 rakamının rahatça üzerinde yer alıyor.

Gözüktüğü gibi olmayan ayar dosyası

Depodaki vercel.json, yönlendirmeler, header ve rewrite'larla 650 satırı aşıyor. Cloudflare'in eşdeğer bir kural listesi yok ve dosyayı okumuyor; dolayısıyla dosyanın kodladığı her davranışın sıfırdan yazılan küçük bir worker — dosyanın tek doğruluk kaynağı olarak kalması için özgün vercel.json'u içe aktaran yaklaşık 120 satırlık bir kod — tarafından yeniden üretilmesi gerekti. Worker, yazarın Vercel'in işlem sırası olarak belirlediği düzeni izliyor: önce ilk eşleşmenin kazandığı ve query string'lerin korunduğu yönlendirmeler, ardından veritabanı API'sine same-origin proxy, sonra statik dosyalar, sonra uzantısız yollar için app-shell 200 yanıtı; dosyadaki header'lar her yanıta uygulanıyor. Çekirdek kısmı, /guides/:city gibi Vercel yol kalıplarını adlandırılmış yakalama grupları içeren düzenli ifadelere derliyor.

Dokümantasyon okumak yerine eski hostu ölçmek

Hiçbir belge Vercel'in bu dosyayla tam olarak ne yaptığını belirtmediğinden, yazar eski deployment'ı kendi URL'sinde erişilebilir tuttu ve onu bir şartname gibi ele alarak, sitemap'teki her URL ve 202 yönlendirme durumu boyunca yanıtları karşılaştırdı. Bu karşılaştırma bir yönlendirme döngüsü yakaladı: worker'ın ilk sürümü yolları büyük-küçük harfe duyarsız eşliyordu, bu yüzden karışık harfli bir URL'yi küçük harfli biçimine gönderen kural kendine yönlendirme yapmaya başladı — Vercel aslında büyük-küçük harfe duyarlı eşleşiyor ve bu davranış dosyada hiçbir yerde belirtilmiyor. Diğer bulgular arasında, sitenin kalıcı 308 kullandığı yerde Cloudflare'in /index.html ve .html son eklerini 307 geçici yönlendirmeyle kaldırması (arama motorları bunları farklı ele alıyor, bu yüzden worker bunları dönüştürüyor); Vercel'in metin yanıtlarına Cloudflare'in eklemediği bir charset bildirimi eklemesi; ve robots.txt, sitemap.xml ile favicon.ico'nun app-shell fallback'inden çıkarılması ihtiyacı — böylece eksik bir dosya HTML dolu bir 200 döndürmüyordu. Düzeltmelerden sonra 610 sitemap sayfasının tümü durum kodu, başlık, canonical URL, robots etiketi ve ana başlıkta eşleşti, kasıtlı tek bir iyileştirme dışında her yönlendirme eşleşti ve headless tarayıcı, veritabanından veri çeken sayfaların doğru render edildiğini doğruladı. Yazar, uygulamalı işi adım adım onaylanmış biçimde Claude Code'a borçlu olduğunu belirtiyor.

Geçiş ve gerçekten bozulan şey

Kesin geçiş dört satırlık bir betikti — DNS zaten Cloudflare'deydi — iki kaydı kaldırıp host adlarını worker'a bağladı. Eski kayıtlar önce yedeklendi, Vercel projesi build'ler devre dışı bırakılarak tutuldu ve geri alma dakikalar sürerdi. Tek gerçek arıza banaldi: otomatik build'ler varlık yükleme aşamasında 10013 hatasıyla öldü, çünkü deploy token'ı doğru izinleri olmayan, farklı bir siteden kalma bir tokendi. Yeni bir token sorunu çözdü ve başarısız build'ler son iyi sürümü yerinde bıraktığından canlı site hiçbir zaman risk altında olmadı.

Yanlış anlaşılan bir panel rakamı

Depolama uyarısı ikinci bir ders taşıyor. Yazar paneldeki 8,81 GB rakamını okuduktan sonra 90 eski deployment'ı sildi ve bir haftalık saklama süresi belirledi; rakam kıpırdamadı. Ardından bir teori geldi — 158 build boyunca kabaca 56 MB'lık, kayan 30 günlük bir build sayımı — ve bu tahminin üzerine bir izleme aracı kuruldu. Bir gün sonra panel yaklaşık 230 MB gösterdi, açıklamayı geçersiz kıldı ve yazar düşüşü hangi değişikliğin ürettiğini hâlâ söyleyemiyor.

Neden önemli

Bu, ücretsiz kademe tavanları ve ticari kullanım şartlarının, büyüyen herhangi bir sitenin "ücretsiz" hostunu sessizce sonlandırmasına somut bir örnek; ancak aktarılabilir kısım yöntemin kendisi: yerine geçecek sistemi canlı sitenin yanında kur, eski platformu referans olarak çalışır tut ve eşitliği gerçek yanıtları ölçerek kanıtla. Daha derin uyarı şu: eşleşme anlamları, durum kodları, yanıt header'ları, hatta panel rakamları dahil her örtük platform davranışı, bağlı olduğunuz ama hiç okumadığınız bir koddur ve onun tek eksiksiz şartnamesi, çalışan sistemin kendisidir.