VPS'e Giriş: Bağımsız geliştirici olarak neden bir VPS'e ihtiyacın var? (2026 Derinlemesine Sürüm)

“Dizüstü bilgisayarım 16G RAM’e sahip bir M3 Pro, neden hâlâ 4 çekirdek ve 8G RAM’i olan bir sunucuya ihtiyacım olsun ki?”

Reddit’teki r/indiehackers alt başlığında yeni başlayanların en sık sorduğu sorulardan biri tam olarak bu. Günümüzde Serverless (örneğin Vercel) ve PaaS (örneğin Supabase) çözümleri her yeri sarmışken, VPS (Virtual Private Server / Sanal Özel Sunucu) biraz “eski usul” gibi görünebilir.

Ama gerçek şu: İşin ticari döngüsünü tam anlamıyla kurabilen ve uzun vadeli kâra ulaşan bağımsız geliştiricilerin elinde mutlaka birkaç tane VPS bulunur.

Bu yazıda, bağımsız geliştirmenin 7 temel acı noktasından yola çıkarak, neden VPS kullanmanın profesyonelleşmeye ve “kod oyuncaklarından” kurtulup gerçek projelere geçişte zorunlu bir adım olduğunu derinlemesine inceleyeceğiz.

1. "Yerel korku"dan kurtulmak: node_modules ve Docker’ın uzay kara deliği problemine çözüm

Bağımsız geliştiricinin en pahalı varlığı dizüstü bilgisayarıdır ama en ucuzu da yine dizüstü bilgisayarının sabit diskidir. Bu yapay zeka destekli kodlama akımının büyük bir kısmı NextJS üzerine kurulu ve bu da beraberinde node_modules felaketini getiriyor. Aslında cc’nin de bb’yi çekmeyi seviyor. cc’nin yürütme sürecini gözlemleerseniz, sürekli /tmp dizinine bir şeyler yazdığını fark edeceksiniz.

Acı nokta: Diskte ve performansta çifte işkence
- node_modules patlaması: Aynı anda 10 proje yürütüyorsan, node_modules tek başına 50 GB’den fazla SSD’nizi yutabilir.
- Docker imajı yığınları: Konteynerleri yerel makinede çalıştırmak sistemi yavaşlatır, fanları inletir.
- İşlemci yükü: PostgreSQL veya Redis gibi ara katmanları yerelde çalıştırmak IDE’nin tepki süresini ciddi şekilde yavaşlatır.
Çözüm: VPS’i “ağır işler merkezine” çevirmek
Yerelde yalnızca hafif bir VS Code + Cursor kurulu tutup, Remote SSH ile VPS’e bağlanman yeterli. Tüm ağır bağımlılıklar ve ortamlar bulutta çalışır; dizüstü bilgisayarın sadece arayüzü görüntülemekle görevlidir.

Node Model

2. “SaaS fatura tazminatına” hayır deyin: Maliyet kontrolüne iş mantığı açısından bakmak

Bağımsız geliştiricinin en korktuğu şey kullanıcı olmaması değil; kullanıcılar daha para ödemeden SaaS faturasının patlamasıdır. Son yıllarda AI programlamayla uğraşırken supabase, clerk gibi araçlarla karşılaşmamak elde değil. Aslında Vercel de dahil hepsi aynı: başlangıçta harika geliyor, ama gittikçe büyüyen bir keyif sanarken bir bakmışsın fatura patlamış. Vercel’in çok ilginç bir tuzağı var: Image bileşeni. Build alırken en iyisi <Image bileşenini kullanmanız yönünde bir öneri görürsünüz, kulağa çok hoş geliyor değil mi? Ama bu bileşen varsayılan olarak Vercel’in resim optimizasyon servisini kullanır; yani her optimize edilen resim için ayrı bir ücret kesilir. Trafiği yüksek sitelerde sadece resim optimizasyon masrafı bile hosting masrafını geçebilir.

Vercel’in Hobby ücretsiz planı çok cazip — deploy, CDN, SSL hepsi dahil. Ama projeniz biraz trafik almaya başladığı an, kabuslar da başlamış olur.

Aşım ücretlerine hızlı bir bakış:

Kaynak	Pro planında dahil	Aşım ücreti
Bant genişliği	1 TB/ay	$0.15/GB (yani $150/TB)
Edge İstekleri	10 milyon/ay	$2/milyon
Serverless çalışma süresi	40 saat/ay	$5/saat
Resim optimizasyonu	5000 resim/ay	$5/1000 resim

Acı Nokta: Bağımlı Olmanın Bedeli
- PaaS Tuzağı: Firebase’in ücretsiz kotası başlarda cazip gelir ama biraz karmaşık yedekleme veya yüksek trafik devreye girince fiyatlar uçuk şekilde artıyor.
- Kimlik Doğrulama Maliyeti: Clerk gibi servisler aylık aktif kullanıcı başına ücret alıyor; bu da sık kullanılan ama düşük kâr marjlı uygulamalar için tam bir kabusa dönüşüyor.
Çözüm: Tam Yığın Kendi Sunucunda Barındırma (Self-hosting)
Aylık 5 dolara çıkan bir VPS üzerinde Docker ile performansı son damlasına kadar kullanıp aynı anda şunları çalıştırabilirsin: veritabanı (PostgreSQL), kimlik doğrulama sistemi (PocketBase) ve analitik aracı (Umami).

图 2：SaaS 订阅 vs. VPS 固定成本曲线对比

💡 Açık konuşmak gerekirse: Kendi sunucunda barındırma elbette belli bir seviyede devops bilgisi gerektiriyor. Fakat son zamanlarda pek çok yurt dışı geliştirici kendi PostgreSQL kurulumlarını yönetme deneyimlerini paylaştı — özellikle Docker ve otomatik yedekleme betikleri sayesinde sandığınızdan çok daha kolay. İlerleyen kısımlarda bunu adım adım nasıl yapacağınızı detaylıca anlatacağım.

3. Gerçek CI/CD: “Tek Kişilik IT Departmanı” Otomasyon Hattını Kurmak

Bağımsız geliştiricinin en büyük rekabet avantajı iterasyon hızıdır. İhtiyaç doğrulaması yaptığın erken aşamalarda Vercel, Cloudflare, Netlify gibi serverless platformlara deploy yapmak harika bir iş çıkarır. Ama bu platformların şöyle bir derdi var: Node implementasyonları eksik, dolayısıyla uzun sürecek task’leri çalıştıramıyorsun. Eskiden local’de paketleme yaparken makinen fanları son sürat uçmaya hazırlanırdı; artık GitHub Actions sayesinde buralara hiç kafanı takmıyorsun. Her şeyi güzelce bir Docker imajına paketliyorsun, sonra… roket kalkışıyor.

Çalışma süresi limiti: Serverless fonksiyonların genellikle 10-60 saniye arası bir timeout limiti olur, varsayılanı genelde 10 saniyedir
Kalıcı süreç yok: WebSocket, uzun bağlantılar (long-polling) ve arka plan task’leri her şeyi bir hayli yorar
Soğuk başlangıç (cold start) gecikmesi: İlk istekte birkaç saniye beklemek zorunda kalabilirsin
Acı Nokta: Manuel deployment’in verimsizliği ve hataları
Hâlâ manuel olarak git pull çalıştırıyorsan, sadece hayatını boşa harcamıyorsun, aynı zamanda production’da facialara davetiye çıkarıyorsun.
Çözüm: VPS tabanlı hafif otomasyon
VPS’i GitHub Actions Runner’ı çalıştırmak için kullan:
1. Git Push pipeline’ı tetikler.
2. VPS otomatik olarak kodu çeker ve Docker imajını inşa eder.
3. Docker Compose container’ları otomatik yeniden başlatır ve sıfır kesinti (zero-downtime) güncellemesi sağlar.

图 3：基于 VPS 的自动化 CI/CD 流水线示意图

Acaba bu yüzden mi bilmiyorum, Cloudflare de artık Pages’i pek öne çıkarmıyor, tekrar Worker’a geri döndü. Bana pek kullanışsız gibi geliyor, sen ne düşünüyorsun?

4. “Ağ Duvarlarını” Aşmak: Sessiz tarayıcılardan sınır ötesi erişime

Pek çok proje lokalde çalışmıyor, sorun kodda değil, ağ ortamında. Geliştirme sırasında kullandığımız bir sürü npm paketi veya diğer kaynaklar, yüzünden network yüzünden canımızı sıkıyor, yoruyor, yıpratıyor ve deli ediyor.

Dert: Değişen IP’ler ve kısıtlı çıkış noktaları
- Sabit IP ihtiyacı: Stripe, PayPal veya banka API’lerine bağlanırken genellikle beyaz listeye almak için sabit bir genel IP gerekir. Ev internetinin dinamik IP’si bu işe hiç yaramaz.
- Ağ ortamı sorunları: Geliştirme sırasında kullandığımız birçok npm paketi, Docker imajı ve GitHub kaynağı, ağ sorunları yüzünden bizi sık sık çıldırtabilir.
- Anti-bot yasağı: Veri kazıma (scraping) ile ilgili bir proje yapıyorsan, ev interneti IP’lerin anti-bot stratejileri tarafından çok kolayca yasaklanır.
Çözüm: VPS’i küresel ağ merkezi olarak kullanmak
- Sabit kimlik: İş akışına kalıcı bir genel IP sağlar; Stripe Webhook, OAuth geri çağırmaları (callback) hep sorunsuz çalışır.
- Ters vekil (reverse proxy) merkezi: Tek bir VPS’e Nginx veya Caddy ekleyerek 10+ alan adını yönetip farklı yerel portlara eşleyebilirsin.
- Geliştirme ortamı hızlandırma: npm install, docker pull komutlarını VPS üzerinde çalıştırarak indirmeleri jet hızında yapar, yerel ağ kısıtlamalarından tamamen kurtulursun.

nginx proxy manager ile aramızda bir kan davası var, kaç kere başıma geldi. Docker imajı kurunca 10 GB civarı yer kaplıyor, hiç anlayamadığım bir durum; Caddy ise çok daha hafif.

5. “Uyurken bile para kazanan” servisi korumak: 7/24 izleme ve felaket kurtarma

Bağımsız geliştiricinin en can sıkıcı anı, sabah uyandığında servisin bütün gece çökmüş olduğunu fark etmesidir; üstelik senin bundan hiç haberin bile olmaz. (Umarım bu sadece varsayımsal bir senaryodur, gerçekten para getiren bir projeye zaten çok sahip çıkarsın!)

Acı nokta: Gözcü eksikliği

Yerel bilgisayar uyku moduna geçiyor, bu yüzden sürekli izleme yapamıyorsun
Ücretsiz dış izleme araçları kontrol sıklığı çok düşük (örneğin 5 dakikada bir), bir sorun olduğunda fark etmen çok geç oluyor ve kullanıcılar çoktan kaybolmuş oluyor
Birçok sorun “ara sıra” ortaya çıkıyor, sen elle kontrol ettiğinde her şey normal görünüyor

Çözüm: Kendi izleme istasyonunu kurmak

Bir VPS üzerinde Uptime Kuma (veya benzeri bir araç) kurarak, dünyanın her yerinden erişim durumunu 30-60 saniyede bir kontrol edebilirsin. Servis çöktüğü anda Telegram, Discord veya e-posta yoluyla anında bildirim alırsın.

İzleme listesi için öneriler:

İzleme Kalemi	Kontrol Sıklığı	Uyarı Yöntemi
HTTP Durum Kodu	60 saniye	Anlık Telegram bildirimi
SSL Sertifika Süresi Doluyor	Her gün	14 gün önceden uyarı
Sunucu Kaynakları	5 dakika	CPU/Bellek %80’i aşarsa uyarı
Veritabanı Bağlantısı	60 saniye	Bağlantı başarısız olursa anlık bildirim

İleri düzey taktikler:

Uptime Kuma ile erişilebilirlik takibi
Sunucu kaynakları için Bezel ya da Netdata; Bezel gayet kullanışlı. Netdata biraz daha ağır kaçıyor.
İkisini birleştir, sağlam bir izleme döngüsü kur.

6. Veri Egemenliği: Bağımsız Geliştiricinin “Son Savunma Hattı”

Sorun: Platforma bağımlılık riski

Verilerin tamamen Firebase’deyse, bir gün hesabın bir uyumluluk sorunu yüzünden kapanırsa, tüm emeğin bir anda sıfırlanır.
Çözüm: VPS üzerinde yerel depolama + off-site yedekleme
- Veri izolasyonu: Veritabanı dosyaları tamamen sana ait.
- Otomatik yedekleme: Basit bir Cron job yaz, her gün verileri şifreleyip S3’e ya da yerel depolama alanına otomatik senkronize et.

7. Bağımsız geliştiriciler için kaynak planlaması: “1 + N” stratejisi

2026’nın tipik geliştirme senaryoları için şu tarz bir dizilim öneriyorum:

Tür	Önerilen Özellik	Temel İşlevi
1 Ana üs	2 çekirdek 4 GB veya 4 çekirdek 8 GB	Nginx, ana veritabanı ve ana ürünü çalıştırmak.
N Nöbetçi sunucu	1 çekirdek 1 GB veya daha düşük	Uptime Kuma izleme, küçük botlar ve test ortamını çalıştırmak.
Neden ayırmak lazım?

İzleme servici, izlediği servislerle aynı makinede olmamalı — yoksa makine çökerse alarmı bile alamazsın.
Test ve canlı ortamları birbirinden izole olmalı, kazara birbirine çarpmamaları için.
Birden fazla küçük sunucu, tek bir koca sunucudan çok daha esnektir.

Reddit’te Hetzner sürekli “fiyat-performans kralı” olarak geçer: aynı fiyata ABD’li bulut sağlayıcılarına göre genellikle 2-3 kat daha iyi donanım verir. Dezavantajı, veri merkezlerinin ağırlıklı olarak Avrupa’da olması; Asya’dan erişimde gecikme biraz daha yüksek olur.