Geliştirme, Test ve Canlı Ortamlar İçin Hosting Mimarisi

Yeni bir projeye başlarken en çok tartışılan konulardan biri şu olur: “Geliştirme, test (staging) ve canlı ortamları aynı VPS üzerinde mi tutalım, yoksa her biri için ayrı sunucu mu kuralım?” Bu soru sadece teknik bir tercih değildir; maliyet, güvenlik, hız, ekip verimliliği ve gelecekteki ölçeklenebilirlik üzerinde doğrudan etkisi vardır. DCHost ekibi olarak yüzlerce projede gördük ki, başta “nasıl olsa küçük proje” denilen sistemler birkaç ay içinde ciddi trafiğe ve karmaşık bir altyapıya dönüşebiliyor. Yanlış seçilen mimari ise bu noktada yavaşlık, sık kesinti, riskli deploy’lar ve geri dönmesi zor veritabanı sorunlarına yol açabiliyor. Bu yazıda; hangi durumda tek VPS’te çoklu ortamın mantıklı olduğunu, hangi eşiklerden sonra ayrı VPS veya dedicated sunucuya geçmeniz gerektiğini, izolasyonu pratik olarak nasıl sağlayabileceğinizi ve DCHost üzerinde gerçekçi mimari örnekleriyle neler kurabileceğinizi adım adım anlatacağım.

Geliştirme, Test ve Canlı Ortamların Rolü

Geliştirme ortamı nedir?

Geliştirme (development) ortamı, yazılımcıların kodu aktif olarak değiştirdiği, hata yaptığı, denemeler yaptığı ve sık sık reset attığı alandır. Burada amaç, hız ve esnekliktir; milisaniye seviyesinde performans veya %99,9 uptime beklemek yerine, rahatça deneme yapabilmek ön plandadır. Çoğu ekipte geliştiriciler kendi local ortamlarında çalışır, ancak ekip büyüdükçe ortak bir “dev” sunucusuna ihtiyaç doğar. Bu ortamda debug modları açık olabilir, ayrıntılı log tutulur ve genellikle gerçek verinin anonimleştirilmiş bir kopyası kullanılır.

Test / staging ortamı nedir?

Test ya da staging ortamı, canlıya çıkmadan hemen önceki son duraktır. Amaç, canlıya mümkün olduğunca benzeyen bir ortamda yeni sürümü test etmektir. Konfigürasyon, PHP versiyonu, Nginx/Apache ayarları, veritabanı sürümü ve mümkünse veri seti, canlıya çok yakın olmalıdır. Kullanıcıların büyük bölümü burayı görmez; ürün yöneticileri, QA ekibi ve bazen müşterileriniz yeni özellikleri önce burada dener. Özellikle WordPress ve WooCommerce projelerinde, staging ortamının önemi üzerine detaylı anlattığımız WordPress staging ortamı kurulum rehberimize mutlaka göz atın.

Canlı (production) ortam nedir?

Canlı (production) ortam, gerçek kullanıcıların bağlandığı, ödeme yaptığı, verisinin işlendiği, SEO ve marka itibarınızın birebir etkilendiği yerdir. Burada öncelik; performans, güvenlik, veri bütünlüğü ve kesintisiz çalışmadır. Loglar daha kontrollü tutulur, debug modları kapalıdır, erişim yetkileri sıkı şekilde sınırlandırılır. Canlı ortamda yapılacak her değişiklik, belirli bir süreçten geçmeli ve mümkünse otomatik testlerle desteklenmelidir.

Aynı VPS Üzerinde Birden Fazla Ortam Çalıştırmak

Ne zaman mantıklı?

Başlangıç aşamasındaki projelerde veya sınırlı bütçeli küçük ekiplerde, tüm ortamları tek bir güçlü VPS üzerinde toplamak cazip bir seçenektir. Özellikle:

• MVP (minimum uygulanabilir ürün) geliştiriyorsanız,
• Günlük trafik düşükse ve gelir kritik seviyede değilse,
• Ekibiniz küçükse ve operasyon yükünü minimumda tutmak istiyorsanız,
• Sık sık mimari değişiklik ve pivot ihtimaliniz varsa

aynı VPS üzerinde birden fazla ortam çalıştırmak maliyet ve yönetim açısından oldukça avantajlıdır. Tek IP, tek güvenlik duvarı, tek yedekleme politikası ile yola çıkabilirsiniz.

Avantajları

• Düşük maliyet: Birden fazla VPS veya dedicated sunucu masrafı yerine, daha güçlü tek bir VPS ile başlarsınız.
• Daha basit yönetim: Tek panel, tek SSH erişimi, tek monitoring sistemi ile idare edebilirsiniz.
• Benzer konfigürasyon: Dev, staging ve canlı aynı sunucu üzerinde olduğundan, PHP, veritabanı ve sistem kütüphaneleri otomatik olarak aynı kalma eğilimindedir.
• Hızlı kurulum: Özellikle otomasyon kullanmıyorsanız, tek sunucuda ortamları çoğaltmak daha az zaman alır.

Riskleri

Avantajların yanında, tek VPS mimarisinin bazı kritik riskleri vardır:

• Tek hata noktası: VPS’in çökmesi veya disk dolması, tüm ortamları aynı anda etkiler. Bu riski azaltmak için 3‑2‑1 yedekleme stratejisi ve immutable yedekler kritik hale gelir.
• Performans çakışması: Geliştirme ya da load test sırasında CPU/RAM’i zorladığınızda, canlı ortam da aynı kaynakları kullandığı için yavaşlayabilir.
• Yanlış deploy riski: Tek sunucuda çoklu ortam varken, yanlış dizine deploy etmek veya yanlış .env dosyasını düzenlemek daha kolaydır.
• Güvenlik ve veri sızıntısı: Staging ortamında debug açık unutulursa veya yetkisiz erişim sağlanırsa, aynı sunucudaki canlı veri dolaylı olarak riske girebilir.

Aynı VPS’te izolasyonu güçlendirmenin pratik yolları

Ayrı kullanıcı ve izin mimarisi

Tek VPS üzerinde birden fazla ortam çalıştıracaksanız, hepsini tek bir “root + tek kullanıcı” modeline yığmak yerine, her ortam için ayrı Linux kullanıcıları oluşturmanız iyi bir başlangıçtır. Böylece:

• Dev, staging ve prod kodları farklı dizinlerde ve farklı kullanıcı sahipliğinde olur,
• SSH anahtarlarını kullanıcı bazında dağıtarak, ekibin sadece ilgili ortama erişmesini sağlayabilirsiniz,
• sudo yetkilerini sınırlayarak, yanlışlıkla sistem geneline zarar verilmesini önlersiniz.

Bu yaklaşımı daha detaylı görmek isterseniz, Linux VPS’te kullanıcı, grup ve sudo mimarisi rehberimizde çoklu proje ve ekipler için örnek tasarımlar paylaştık.

Alt alan adları ve ayrı sanal host’lar

Genellikle şu yapı tercih edilir:

• canlı: example.com
• staging: staging.example.com
• dev: dev.example.com

Nginx veya Apache tarafında her ortam için ayrı sanal host (server block) tanımlayıp, farklı kök dizinlere yönlendirmek mümkündür. SSL sertifikalarını da ayrı ayrı veya SAN/Wildcard ile yönetebilirsiniz.

Veritabanı izolasyonu

Aynı MySQL veya PostgreSQL sunucusunda bile olsanız:

• Her ortam için ayrı veritabanı kullanın (db_example_dev, db_example_stg, db_example_prod gibi),
• Farklı veritabanı kullanıcıları ve parolalar tanımlayın,
• Prod verisini staging’e taşırken anonimleştirme script’leri kullanın (e-posta, telefon, kişisel verileri maskeleyin).

Böylece yanlış bağlantı ayarı yapsanız bile, staging uygulaması prod veritabanına yazma riskini azaltmış olursunuz.

Docker ile konteyner tabanlı izolasyon

Aynı VPS üzerinde daha güçlü izolasyon istiyorsanız, her ortamı ayrı Docker konteynerleri içinde çalıştırmak iyi bir strateji olabilir. Örneğin:

• dev_app + dev_db konteynerleri,
• staging_app + staging_db konteynerleri,
• prod_app (ve gerekirse ayrı prod_db) konteynerleri

şeklinde bir yapı kurabilirsiniz. Bu modelle ilgili pratik bir başlangıç için, Docker ile VPS’te izole uygulama barındırma rehberimizi inceleyebilirsiniz.

CI/CD ve otomatik deploy

Tek VPS’te bile olsanız, geliştiricilerin doğrudan canlı dizinlere SCP veya FTP ile dosya atmasını istemezsiniz. Bunun yerine Git tabanlı bir akış ve CI/CD pipeline’ı kurgulamak en sağlıklısıdır. Örneğin:

• main branch → üretim (production) dizinine deploy,
• develop branch → staging dizinine deploy,
• feature branch’ler → isteğe bağlı dev ortam deploy’u

Bu akışı GitHub Actions ile otomatikleştirmek için, DCHost VPS üzerinde zero‑downtime yayın örneklerini anlattığımız GitHub Actions ile VPS’e otomatik deploy rehberimize göz atabilirsiniz.

Ayrı VPS veya Sunucularda Ortamları Ayırmak

Ne zaman şart hâline gelir?

Belli bir ölçeği aştığınızda, tüm ortamları tek VPS’te taşımak riskli ve verimsiz hale gelir. Özellikle:

• Günlük trafik on binlerce ziyareti aşıyorsa,
• E-ticaret, SaaS veya kritik kurumsal servisler çalıştırıyorsanız,
• SLA taahhütleriniz ve sözleşmesel uptime beklentileri varsa,
• KVKK / GDPR gibi regülasyonlara uyum takibi yapıyorsanız,
• Load test’ler sırasında canlı ortamı etkilemek istemiyorsanız

artık staging ve dev ortamlarını ayrı VPS’lere taşımayı ciddi şekilde düşünmelisiniz. Canlı ortama mümkün olduğunca en az değişken bırakmak, hata anında teşhisi de çok kolaylaştırır.

Ayrı sunucu mimarisinin avantajları

• Güçlü izolasyon: Staging veya dev ortamında CPU’yu fulleyen bir süreç, canlı ortamı etkilemez.
• Güvenlik: Erişim yetkilerini ortam bazlı ayırabilir, dış dünyaya tamamen kapalı bir dev/staging kurabilirsiniz.
• Esnek ölçekleme: Canlı ortama daha büyük bir VPS veya dedicated sunucu verirken, dev ortamını daha küçük ama çok sayıda instance ile çalıştırabilirsiniz.
• Risklerin ayrıştırılması: Yeni teknolojileri, büyük versiyon güncellemelerini önce staging VPS’inde denersiniz; prod’a sadece test edilmiş konfigürasyon geçer.

Dezavantajlar ve yönetim yükü

Elbette her şeye ayrı sunucu kullanmanın da maliyet ve operasyon tarafında bazı dezavantajları bulunur:

• Ek maliyet: Her ortam için en az bir VPS veya sunucu kiralayacağınız için toplam fatura artar.
• Yönetim karmaşıklığı: Güncelleme, güvenlik duvarı, yedekleme ve izleme süreçlerinin ortam sayısı kadar tekrarlanması gerekir.
• Konfigürasyon sapması riski: Staging ile prod arasında konfigürasyonların zamanla farklılaşması (config drift) mümkündür; bu yüzden otomasyon çok önemlidir.

Pratik mimari örnekleri

1. Küçük-orta ölçek: 2 VPS (Prod ayrı, Dev+Staging aynı)

Birçok DCHost müşterisinin kullandığı pratik çözüm şu şekildedir:

• VPS #1 – Production: Sadece canlı site(ler) ve üretim veritabanı çalışır. Kaynaklar bu ortama odaklanır.
• VPS #2 – Dev + Staging: Geliştirme ve test ortamları burada tutulur; zaman zaman disk snapshot veya otomatik yedek alınır.

Böylece canlı ortamı ayrı tutarak en büyük riski azaltır, ama toplam sunucu sayısını da makul seviyede tutarsınız.

2. Daha olgun yapılar: 3 VPS (Her ortam için ayrı)

Release sıklığı yüksek olan SaaS ürünleri, e-ticaret siteleri veya ajansların kritik projelerinde, genellikle her ortam için ayrı VPS tercih edilir:

• VPS #1 – Prod
• VPS #2 – Staging
• VPS #3 – Dev veya birden çok dev instance

Bu yapı, CI/CD ve otomatik testlerle birleştiğinde, “canlıya çıkmak” kavramını çok daha güvenli ve öngörülebilir hale getirir. WordPress ve Laravel için geliştirme–staging–canlı yolculuğunu anlattığımız yazımızda, bu mimariyi somut adımlarla ele alıyoruz.

3. Ayrı veritabanı sunucusu eklemek

Trafik ve veri hacmi arttıkça, üretim veritabanını da ayrı bir VPS veya dedicated sunucuya taşımak mantıklı hale gelir. Böylece:

• Uygulama (PHP/Node/Laravel/WordPress) sunucusu ile veritabanının kaynak kullanımı ayrılır,
• Veritabanı için özel tuning ve yüksek IOPS sunan NVMe diskli bir sunucu seçebilirsiniz,
• Replikasyon ve yedeklilik senaryolarını esnek şekilde tasarlayabilirsiniz.

Bu konuyu ayrıntılı incelediğimiz veritabanı sunucusunu uygulama sunucusundan ayırma rehberi, özellikle büyüyen WooCommerce ve SaaS projeleri için iyi bir referans noktasıdır.

Karar Matrisi: Aynı VPS mi, Ayrı Sunucu mu?

Değerlendirmeniz gereken temel kriterler

Mimari seçerken aşağıdaki sorulara net cevap vermenizi öneririm:

• Günlük ortalama ziyaretçi sayınız ve beklenen büyüme hızı nedir?
• Aylık cironuz veya proje değeri nedir? 1 saatlik kesintinin maliyeti ne kadar?
• Regülasyon (KVKK/GDPR, PCI DSS, sektör regülasyonları) yükümlülükleriniz var mı?
• Ekip büyüklüğü ve release sıklığı nedir?
• Kaç ayrı uygulama/proje aynı altyapıyı paylaşacak?

Özet tablo

Eğer nereden başlayacağınıza emin değilseniz, mevcut trafiğiniz, projeleriniz ve bütçeniz üzerinden birlikte gerçekçi bir plan yapabiliriz. DCHost olarak hem VPS hem dedicated hem de colocation tarafında, bu tür çok ortamlı mimarileri günlük olarak tasarlayıp işletiyoruz.

Uygulama Türüne Göre Örnek Senaryolar

WordPress ve WooCommerce projeleri

WordPress tabanlı blog veya kurumsal sitelerde başlangıçta tek VPS üzerinde dev+staging+prod kurmak çoğu zaman yeterlidir. Ancak WooCommerce veya yüksek trafikli haber sitelerinde:

• Prod ortamını ayrı bir VPS’e almak,
• Staging’i düzenli olarak prod’dan veri çekip anonimleştiren bir senaryoyla canlıya benzetmek,
• Önemli WooCommerce güncellemelerini önce staging’de test etmek

büyük fark yaratır. WooCommerce özelinde veritabanı ve önbellek ayrıştırmasının ne zaman mantıklı olduğuna dair detayları, WooCommerce için ayrı veritabanı ve cache sunucusu rehberimizde bulabilirsiniz.

Laravel ve diğer backend framework’leri

Laravel, Symfony, NestJS gibi framework’lerle geliştirilen uygulamalarda genellikle CI/CD süreci daha otomatiktir. Bu tip projelerde:

• Dev ortamını genellikle geliştiricilerin local veya paylaşılan bir dev VPS’inde tutmak,
• Staging için prod’a çok benzeyen ayrı bir VPS kullanmak,
• Prod’u ise kaynakları daha geniş bir VPS veya dedicated sunucuya kurmak

uzun vadede hem performans hem güvenlik açısından daha sağlıklıdır. DCHost üzerinde Laravel projeleri için Nginx, PHP‑FPM, queue’lar ve zero‑downtime dağıtımın nasıl kurgulanacağını ayrıntılı Laravel yayınlama rehberimizde adım adım anlattık.

Küçük SaaS ürünleri ve mikroservis yapıları

Küçük bir SaaS ürünü için genellikle şu akışla başlıyoruz:

• Başlangıçta tek VPS: Monolitik uygulama + veritabanı + basit dev/staging dizinleri
• Trafik artınca: Prod’u ayrı VPS’e taşıyıp eski sunucuyu dev/staging’e dönüştürmek
• Daha da büyüyünce: Veritabanını ve cache’i ayrı sunuculara bölmek, arka plan işler için ek worker VPS’leri eklemek

Mikroservis ve çok kiracılı mimariler için ileri seviye seçenekler (örneğin Kubernetes, çoklu bölgeli dağıtımlar) mümkün olsa da, çoğu KOBİ ve SaaS için iyi tasarlanmış klasik VPS mimarisi daha sade ve maliyet açısından daha öngörülebilirdir.

DCHost Üzerinde Örnek Mimariler

Ajans veya freelancer için tek VPS’te çoklu ortam

5–10 arası WordPress sitesi yöneten bir ajans için sık kullandığımız senaryo şu:

• NVMe diskli, orta seviye kaynaklara sahip bir DCHost VPS,
• Her müşteri sitesi için ayrı kullanıcı ve alt alan adları,
• Her proje için basit bir staging alt alan adı (stg.musteri1.com gibi),
• Git tabanlı deploy ve otomatik yedekleme.

Böyle bir mimariyle hem maliyeti kontrol edebilir, hem de tek VPS’in avantajlarını en iyi şekilde kullanabilirsiniz. Zamanla trafiği artan projeleri ayrı VPS veya dedicated sunucuya taşıyarak kademeli bir büyüme stratejisi uygulamak da mümkündür.

Büyüyen e-ticaret sitesi için kademeli ayrıştırma

Yeni açılmış bir WooCommerce mağazası için başlangıçta tek güçlü VPS yeterli olabilir. Ancak kampanyalar, reklam yatırımları ve trafiğin artmasıyla birlikte:

1. Önce staging’i ayrı bir VPS’e taşıyıp canlı ortamı izole etmek,
2. Ardından veritabanını ayrı bir VPS veya dedicated sunucuya bölmek,
3. Son aşamada, arka plan işlemleri (queue, raporlama, entegrasyonlar) için ek worker VPS’leri eklemek

çoğu projede işe yarayan kademeli bir yol haritasıdır. Bu süreçte hem performansı hem de SEO’yu nasıl koruyacağınızı, yeni web sitesi yayına alma kontrol listesi yazımızla birlikte planlayabilirsiniz.

Altyapıyı otomasyonla tekrar üretilebilir kılmak

Ortam sayısı arttıkça, “prod ile staging aynı mı?” sorusunun cevabını manuel olarak takip etmek zorlaşır. Bu noktada Infrastructure as Code (IaC) ve konfigürasyon yönetim araçları devreye girer. DCHost üzerinde Terraform ve Ansible ile çalışarak, aynı VPS veya sunucu kurulumunu tekrar tekrar otomatik şekilde oluşturabilirsiniz. Terraform ve Ansible ile VPS otomasyonu rehberimizde, tek tuşla yeniden kurulabilen VPS’lerin nasıl tasarlandığını pratiğe döküyoruz.

Sonuç ve Önerilen Yol Haritası

Geliştirme, test ve canlı ortamlar için hosting mimarisini doğru kurgulamak, projenin yaşam döngüsü boyunca size büyük rahatlık sağlar. Küçük bir projede tüm ortamları tek bir DCHost VPS üzerinde tutmak tamamen makul ve pratiktir; yeter ki kullanıcı/izin yapısı, veritabanı ayrımı, yedekleme ve temel güvenlik ayarlarını ihmal etmeyin. Proje büyüdükçe; önce canlı ortamı, ardından staging’i ve gerekirse veritabanı ile arka plan işçilerini ayrı VPS veya dedicated sunuculara taşımak, hem riskleri hem de performans problemlerini önemli ölçüde azaltır. Kararı verirken trafik hacmi, gelir seviyesi, regülasyon yükümlülükleri ve ekip yapınızı birlikte düşünmeniz gerekir.

Eğer hali hazırda tek sunucuda her şeyi taşıyor ve “acaba ne zaman bölmeliyim” diye düşünüyorsanız, DCHost ekibi olarak sizinle birlikte kısa bir kapasite ve risk analizi yapabiliriz. Mevcut sunucunuzu, yedekleme stratejinizi, veritabanı yapınızı ve büyüme planınızı inceleyip; tek VPS’te kalmanın mı, yoksa aşamalı olarak ayrı VPS’lere / dedicated sunuculara geçmenin mi daha doğru olduğuna birlikte karar verebiliriz. Böylece hem bütçenizi gereksiz yere şişirmeden hem de canlı ortamınızı riske atmadan, uzun vadede sürdürülebilir bir hosting mimarisi kurmuş olursunuz.