Laravel Uygulamalarını VPS’te Nasıl Yayınlarım? Nginx, PHP‑FPM, Horizon ve Sıfır Kesinti Dağıtımın Sıcacık Yol Haritası

Ofiste Başlayan Küçük Bir Deploy Kaygısı: “Ya Site 1 Dakika Bile Düşerse?”

Hiç başınıza geldi mi? Tam herkese demo linkini atmışken, deploy tuşuna basarsınız ve o an içinizden kısacık bir endişe geçer: Ya site 1 dakika bile dursa? Geçen hafta benzer bir an yaşadım. Küçük bir kampanya sayfasıydı, ama zamanlaması hassastı. Kod hazır, testler iyi, ama üretimde işler bazen daha farklı akıyor. İşte o anda düşündüm: Bu süreci hem düzenli, hem güvenli, hem de mümkünse sıfır kesinti ile nasıl oturturuz?

Bu yazıda tam da bunu konuşacağız. Laravel uygulamalarını bir VPS üzerinde, Nginx ve PHP‑FPM ile sağlama alıp, arka planda Queue ve Horizon ikilisini akıllıca çalıştırmayı, üstüne bir de kesinti yaşatmadan dağıtımın nasıl yapılacağını adım adım anlatacağım. Kuru teknik anlatım değil; araya yaşanmış küçük deneyimler, pratik notlar ve “mesela şöyle düşünün” gibi ufak kıvrımlar koyacağım. Yazının sonunda, tek bir sunucuda başlayan bu düzeni, büyürken de taşıyabileceğiniz bir iskelete dönüştürmüş olacağız.

VPS’in Üzerine İnşa: Alan Adı, Nginx ve Temiz Bir Yapı Neden İşin Yarısıdır?

Alan Adı, DNS ve İlk Adımlar

VPS’i ilk kez ayağa kaldırırken herkesin içinden geçen o tatlı telaşı bilirsiniz. SSH ile bağlan, güncellemeleri yap, kullanıcı oluştur, anahtar ekle, ufak güvenlik dokunuşları… Bir de alan adını doğru yönlendirmek var. Eğer kendi DNS’inizi yönetmeyi seviyorsanız, özel ad sunucusu kurup Glue Record ile adı kendi yetkinize almak insana ayrı bir özgüven veriyor. Bu konu senin ilgini çekiyorsa, şuradaki adım adım anlatım epey iş görüyor: Özel ad sunucusu ve Glue Record kurulum rehberi.

DNS işini hallettikten sonra sıra, trafiği karşılayacak kapıya, yani Nginx’e geliyor. Nginx’i kurduğunuzda, ilk sayfa çok kolay gelir, ama asıl mesele Laravel’in public klasörüne doğru ve güvenli şekilde yönlendirmek, istemci ile sunucu arasındaki konuşmayı hızlı tutmak ve ileride oluşabilecek küçük sıkıntıları şimdiden çözmektir.

Nginx’i Laravel ile Arkadaş Etmek

Mesela şöyle düşünün: Uygulamanızın kök dizini /var/www/proje olsun. Nginx sunucu bloğu, kök olarak public klasörünü göstermeli. İsteklerin Laravel’in index.php’sine akması için temel kural budur. Üstüne bir de “güzelleştirme” dokunuşları gelir; sıkıştırma, doğru cache başlıkları, zaman aşımı değerleri gibi. Eğer HTTPS konusunda hız ve güven tarafını biraz daha şahlandırmak isterseniz, TLS 1.3, OCSP Stapling ve Brotli için ayrıntılı rehber fazlasıyla yardımcı olur. Küçük ayarlar, büyük farklar yaratır; özellikle ilk bayt süresinde ve tarayıcı tarafında hissedilir.

Konfigürasyonları düzenlerken, bir anda kendinizi dosyaların derinliklerinde kaybolmuş bulabilirsiniz. O anda akılda tutmak istediğim şey şu: Üretim ortamında okuması ve bakımı kolay bir yapı kurmak ileriye dönük en iyi yatırımdır. Sanal host dosyalarını kısa, isabetli ve tek sorumluluk ilkesine uygun tutun. Bir sorun çıktığında gece uykunuzdan kalkıp bakmanız gerekirse, o dosyaları kendinize teşekkür ettirecek şekilde bırakın.

SSL/HTTPS ve Zarif Yeniden Yüklemeler

SSL sertifikalarını yenilerken, Nginx’i komple yeniden başlatmak yerine yalnızca yeniden yüklemek (reload) ziyaretçinin gözünden ıskalanacak kadar yumuşak bir geçiş sağlar. Komutun tam adını ezberlemeye gerek yok; önemli olan “durdurup başlatma” gibi sert hamleler yerine “yeniden oku” demek. İlgisini çekenler için, Nginx’in kontrol sinyalleri üzerine kısa ama öz bir döküman var: Nginx process kontrolü ve reload davranışı. Ufak bir not: reload, aktif bağlantıları düşürmeden yeni konfigürasyonu devreye alır. İşte biz de dağıtımlarda hep bu inceliğin peşindeyiz.

PHP‑FPM’i Nazikçe Ayarlamak: Sessiz Kahraman

Neden PHP‑FPM ve Ne Zaman Takılır?

Laravel’in kalbi PHP‑FPM üzerinde atar. Fakat onu bir kez kurup unutmak çoğu zaman küçük tıkanıklıklara zemin hazırlar. Trafik arttıkça havuz ayarları, eşzamanlılık ve bellek kullanımı gibi konular hafifçe su yüzüne çıkar. Benim yaklaşımım basit: Önce sade bir yapı, sonra gözlem ve gerektiğinde minik rötuşlar. Aşırı büyük değerlerle başlamak yerine, gerçek trafiği görüp ona göre genişlemek çok daha sağlıklıdır.

Bir an için yoğun bir kampanya sayfasını düşünün. Kısa bir süre için istekler katlanıyor, ama kalıcı bir artış yok. Bu durumda PHP‑FPM’i kalıcı olarak şişirmek yerine, geçici olarak önbellekleme, statik dosya sunumu gibi alanlara yaslanmak daha akıllıca. Çünkü PHP süreçlerini büyütmek, belleği artırmakla kalmaz, işletim sisteminin planlayıcısını da daha fazla zorlar. Sakin ama kararlı adımlar burada işin sırrıdır.

OPcache ve Laravel’in Önbellekleri

Laravel tarafında rotaları, konfigürasyonu ve görünümleri önbelleğe almak, üretim ortamında inanılmaz rahatlatıcıdır. Ben genelde yayın öncesi şöyle bir sırayla ilerliyorum: Konfigürasyonu derlemek, rotaları derlemek, görünümleri önceden hazırlamak. Bu işlemler kodun daha derli toplu çalışmasını sağlar ve PHP‑FPM’in üzerindeki küçük baskıları azaltır. Bu arada OPcache’i akıllıca ayarlamak, opcache’in biriktirdiği derlenmiş kodları doğru şekilde taşımanız anlamına gelir. Kodu değiştirirken, FPM’e nazikçe yeniden yükleme yaptırmak çoğu zaman yeterlidir; sert bir yeniden başlatmaya pek gerek kalmaz.

Performans denince akla gelen temel taşları bir arada görmek istersen, şu pratik rehbere göz atmanı öneririm: Laravel prod ortam optimizasyonunu adım adım toparlayan yazı. Orada anlatılanlar burada kuracağımız iskeletle güzelce örtüşüyor.

Queue ve Horizon: Kulis Arkasını Sakin Tutmanın İnceliği

Arka Plan İşleri Neden Hayat Kurtarır?

Bir form dolduruluyor ve arka planda bir e‑posta tetikleniyor. Dosya yükleniyor, bir görüntü optimize ediliyor. Sipariş tamamlanıyor, bir web kancası çağrılıyor. Tüm bu işler anında, aynı istek içinde yapılmaya kalkarsa ziyaretçi bekler, tarayıcı bekler, ve bekleyiş uzadıkça hissedilen kalite düşer. İşte bu yüzden kuyruğa alışmak, uygulamanın nefes almasını sağlar. Ön yüz hızlı biter, ağır işler kuliste sakince hazırlanır.

Horizon, kuyruğu izlemek, işçileri dengelemek ve taşan durumları fark etmek için güzel bir yönetim paneli sunuyor. Bir keresinde gece yarısı gelen bir hata bildirimini Horizon’dan izleyip sorunu dakikalar içinde bulduğumu hatırlıyorum. Gösterge paneli, bekleyen iş sayısını, çalışır durumda olan işçi sayısını ve çeşitli kuyrukların sağlığını hızlıca gösteriyor. Bu görünürlük, üretimdeki rahatlığın yarısıdır.

Horizon’ı Dağıtımın Bir Parçası Yapmak

Horizon’ı sistemde bir hizmet gibi düşünün. Sunucu açıldığında ayağa kalksın, kapanırken nazikçe insin, dağıtımda yeni kodu görsün. Burada önemli olan iki küçük alışkanlık var. Birincisi, dağıtımın sonunda Horizon’a tekrar başla demek, yeni kodu ve yeni iş sınıflarını görmesini sağlar. İkincisi, kuyruk çalışanlarının sıkıştığı anlarda yumuşakça yeniden başlatmak işleri ferahlatır. Bu iki hareket, gecenin bir vakti sürpriz birikimleri engeller.

Resmi belgeler pratik ipuçlarıyla dolu. Göz atmak istersen, Laravel Horizon dokümantasyonu sade bir dille temel noktaları toparlıyor. Bir de şunu seviyorum: Horizon ile farklı öncelikte kuyruklar tanımlayıp, yoğun zamanı daha zarif yönetebiliyorsunuz. Önce hızlı dönüş isteyen işleri eritip, arkadan ağır işlere geçmek gibi.

Sıfır Kesinti Dağıtım: Kapanış Ekranı Göstermeden Kod Güncellemek

Mesela Şöyle Düşünün: Paralel Bir Sahne, Tek Bir Perde

Sahne hazırlığını iki ayrı yerde yaptığınızı düşünün. Birinde seyirciler var, ötekinde arka planda kostümler hazırlanıyor. Asıl olan, perde açıldığında her şeyin hazır olması. Laravel dağıtımında da benzer bir strateji kullanırız: releases adında bir klasör, içinde her dağıtım için ayrı bir dizin ve current adında, canlı olan sürümü gösteren küçük bir işaret. Kod yeni dizinde hazırlanır, bağımlılıklar yüklenir, önbellekler ısıtılır. Sonra yalnızca işareti yeni sürüme çevirirsiniz. Perde kalkar, sahne değişir, seyirci değişimi fark etmez.

Bu yöntemin güzelliği şu: Eski sürüm bir anda yok olmaz. Hatta birkaç dakika orada kalır, isterseniz geri dönmek için en hızlı can simididir. Bir problem görürseniz işareti tekrar bir önceki sürüme çevirirsiniz. Bu kadar basit. Kimse “Site biraz önce bozuldu” demez, hatta çoğu zaman hiçbir şey fark edilmez.

Dağıtımın Nazik Adımları

Kendi rutinimi anlatayım. Önce yeni sürüm dizinini oluşturup kodu oraya çekiyorum. Bağımlılıkları üretim modunda kuruyorum, sonra Laravel’in önbelleklerini ısıtıyorum. Eğer statik dosyalar, derlenen varlıklar varsa, onlar da yeni dizinde hazırlanıyor. .env gibi hassas dosyaları linkliyorum; böylece sırlar tek yerde duruyor ve sürüm dizinleri içinde gezmiyor. Depolama klasörlerini, günlükleri ve önbellek klasörlerini yine paylaşımlı tutuyorum ki sürüm değişirken veriler yerinde kalsın. Son adımda işareti yeni sürüme çeviriyorum ve yalnızca Nginx ile FPM’e “değişiklik oldu, bir bakar mısınız” diyen nazik bir yeniden yükleme yaptırıyorum.

Burada küçük ama çok önemli bir püf var: Veritabanı değişiklikleri. Dağıtım anında şema değiştiren komutlar riskli olabilir. Ben genelde iki aşamalı ilerliyorum: Önce uyumlu değişikliği ekliyorum (örneğin yeni bir sütunu boş geçilebilir şekilde eklemek), uygulamayı yeni sürüme alıyorum, sonra ikinci aşamada sıkılaştırmayı yapıyorum (boş geçilemez yapmak gibi). Eğer büyük veri taşıması varsa, bunu arka plana, kuyruklara bırakmak güneşli bir yol açar. Ziyaretçi hiçbir şey fark etmez, veriler güvenle hareket eder.

Bakım Modu mu, Sıfır Kesinti mi?

Bazen bakım moduna ihtiyaç olur. Özellikle büyük ve riskli dönüşümler sırasında kısa bir mola vermek en güvenli yoldur. Ama iyi yapılandırılmış bir sıfır kesinti şablonu çoğu dağıtımda bakım moduna ihtiyaç bırakmaz. Benim tercih sıram şöyle: Önce sıfır kesinti yöntemini denerim. Eğer şema değişiklikleri gerçekten tehlikeliyse, pencerem kısa da olsa bakım moduna geçer. İki yöntemi de elinizin altında tutmak, geceleri tatlı uyku verir.

Güvenlik, İzleme ve Yedek: Kırılgan Anlar Önceden Çözülürse Çok Rahat

HTTPS ve Saldırı Önlemleri

Canlı ortamda HTTPS zorunlu. Sertifikaların otomatik yenilenmesi, HTTP’den HTTPS’e nazikçe yönlendirme ve modern şifreleme kümeleri uygulamayı hem hızlı hem güvenli yapar. Bu kısımda Nginx’in küçük detayları çok iş görür. Eğer ayrıntı seviyorsan, TLS 1.3 ve OCSP Stapling ile hızlı ve güvenli HTTPS yazısı tam bir yol haritası sunuyor. Üstüne bir de uygulama seviyesinde oturum ve önbellek için güvenli çerez ayarları, çapraz site istekleri için korumalar derken, küçük taşlar bir araya gelip sağlam bir duvar örüyor.

İsterseniz bir katmanı daha ekleyebilirsiniz. Saldırı yüzeyini daraltmak için temel kurallar, hız sınırlamaları ve uygulama güvenlik duvarları hayat kurtarır. Statik dosyaları doğrudan Nginx’ten sunmak, büyük dosya indirmelerini php’nin üzerinden almak gibi ufak hileler, uygulama katmanını hafifletir ve beklenmedik yüklerde sakince kalmanızı sağlar.

İzlemezsen Göremezsin: Loglar, Paneller ve Sessiz Alarmlar

Gerçekten şöyle bir an yaşadığımı hatırlıyorum: Sunucu kaynakları idare eder görünüyor, ama kullanıcılar zaman zaman yavaşlıktan şikayetçi. Tek tek günlükleri karıştırırken ipucunu sonra buldum; belli bir saat aralığında bir kuyruk işi taşmaya başlıyor, sonra kendine geliyor. İzleme olmadan bu paterni fark etmek çok zor. O yüzden, sunucunu bir panelle gözlemlemek, belirli eşiklerde uyarı almak, uygulamanın içinden hata takip etmek dağıtım kadar önemli. İlgini çekiyorsa, VPS izleme ve alarm kurulumunu anlatan bu rehber iyi bir başlangıç sunuyor.

Horizon’un kendi göstergeleri de günlük akışını anlamak için güzel sinyaller verir. Bekleyen iş sayısı artınca, işçi sayısını geçici olarak artırmak bazen çözüm olur. Sürekli artıyorsa, kalıcı nedenleri araştırmak gerekir: Yavaş bir harici servis mi, beklenenden büyük dosyalar mı, veritabanında kilitlenmeler mi? İzleme, soruyu doğru sormanın en kısa yoludur.

Yedekleriniz Kibar Dursun, Geri Dönüşünüz Kolay Olsun

İç rahatlığı için yedekler kadar tatlı bir şey yok. Sürümleme, şifreleme ve uzak depolama alışkanlığı, kötü gün dostudur. Bir projede yalnızca veritabanını değil, yüklenen dosyaları ve kritik yapılandırmaları da kapsayan bir yedek planı kurduğumda omzumdan taş gibi bir yükün indiğini hissetmiştim. Bu konuyu sade ve anlaşılır şekilde toparlayan bir yazı var, göz atmanı öneririm: Restic ve Borg ile S3 uyumlu uzak yedekleme rehberi. İlk okumada bile işe yarayan bir çerçeve veriyor.

Uygulama Sıcak Kalırken Güncellemeler Nasıl Akacak?

Env, İzinler ve Paylaşımlı Klasörler

Uygulamanın sırları bir çantada dursun, sürümler ise çantanın etrafında dans etsin. Ben .env’i paylaşımlı bir yerde tutup, her sürümde ona nazik bir işaret (symbolic link) vermeyi seviyorum. Aynı şeyi storage ve bootstrap/cache gibi klasörler için de uyguluyorum. Böylece günlükler ve dosyalar sürüm geçişlerinde yerinden kıpırdamıyor, yalnızca kod değişiyor. İzinleri ayarlarken ölçülü davranmak önemli. “Hadi 777 olsun, bitsin” demek kısa yoldur ama risklidir. Uygulamanın yazacağı klasörlerde doğru kullanıcıya yazma izni vermek genellikle yeterlidir.

Bazı ekipler sürüm klasörlerinin adını tarih-saat ile verir, ben de seviyorum. Hem listesi okunaklı olur, hem de sorun çıktığında geri dönmek için net bir işaretiniz olur. Eski sürümleri belirli bir sayıda tutmak ve düzenli temizlemek, disk alanını sağlıklı yönetmenin küçük ama etkili bir yoludur.

Nginx ve FPM’e Kibarca Haber Vermek

İşaret yeni sürüme döndüğünde, Nginx’e “konfigürasyonu bir daha oku” demek ve PHP‑FPM’e “yeni dosyaları fark et” demek çoğu zaman yeter. Sert durdur-başlat yerine yeniden yükleme kullandığımızda aktif bağlantılar düşmeden hayat devam eder. Bu, sıfır kesinti yaklaşımının en tatlı tarafıdır. Dışarıda kimse değişimi fark etmez, içeride ise her şey yerli yerine oturur.

Bu sırada ufak bir alışkanlık daha: Horizon’u da dağıtımın sonunda nazikçe yeniden başlatmak. Böylece yeni iş tanımlarını, yeni kuyruk isimlerini hemen görür ve akış devam eder. Ziyaretçinin gözünde tek bir titreme bile olmaz.

Gerçek Hayatın Küçük Köşeleri: Sorun Çıktıysa Geri Dönüş ve İyileştirme

Geri Alma Planı (Rollback) Olmadan Dağıtım, Dağıtım Değildir

Ne kadar dikkat ederseniz edin, gerçek hayatta sürprizler olur. Bu yüzden geri alma planı dağıtımın ayrılmaz parçasıdır. İyi haber şu: Sembolik işaret yöntemiyle bu plan zahmetsizdir. Yeni sürümde istenmeyen bir davranış görürseniz, yalnızca işareti bir önceki sürüme döndürüp Nginx ve FPM’e yeniden yükleme yaptırırsınız. Günlükler daha sonra anlatır ne olduğunu; o anda önemli olan ziyaretçiyi rahat ettirmektir.

Bir keresinde yalnızca önbellek anahtarlarında ufak bir çakışma, canlıda beklenmedik bir göz yanılsaması yaratmıştı. Kod doğruydu, ama eski önbellek yeni yapıyla karışıyordu. Geri aldım, önbellek stratejisini düzelttim, sonra tekrar yayımladım. Eğer geri alma imkânım olmasaydı, gecenin kalanını panikle geçirirdim.

Belirtileri Okumak: Yavaşlık mı, Zıplamalar mı?

Gözlem araçları bazen şiir gibi konuşur. CPU uzun süre yüksek ama istek sayısı normalse, aklıma ağır bir kuyruk işi geliyor. Bellek birden zıplıyor ve duruluyorsa, büyük bir resim işleme ya da rapor üretimi olabilir. Zaman zaman ufak donmalar hissediliyorsa, veritabanında kilitlenmeler ya da dış servis beklemeleri masaya gelir. Bu belirtileri okumayı öğrendikçe, sorunlara yaklaşma süreniz kısalır ve özgüven artar. İşte tüm bu nedenlerle izleme ve alarm, dağıtım kadar önemlidir.

Laravel’in Kendi Araçlarıyla Şık Dokunuşlar

Resmi Rehberlere Minik Ziyaret

Altyapıyı kurduk, alışkanlıkları konuştuk. Bir de çerçevenin kendi önerilerine göz kırpmak iyi olur. Resmi Laravel dağıtım rehberi, önbellekleri derlemek, uygulamayı üretim moduna almak ve bakım modunu yönetmek gibi temel başlıklarda net bir çerçeve veriyor. Oradaki önerileri kendi sıfır kesinti planınıza eklemek, güçlü ve tutarlı bir yol açar.

Bir başka hoş detay da şu: Laravel’in komutları çoğu zaman dağıtım adımlarınızı öngörür şekilde tasarlanmıştır. Önce env’i hazırlamak, sonra cache’leri ısıtmak ve en sonda gelen trafiği yeni sürüme çevirmek… Kulağa masalsı gelse de, pratikte gerçekten böyle akıyor.

Ekstra Notlar: Trafik, Kaynaklar ve Büyüme Sevincine Hazırlık

Kaynak Seçimi ve Ufak Sürprizler

VPS seçerken CPU ve RAM’in yanında disk türü ve ağ trafiği de önemli. Özellikle dosya yazma-okuma yoğun uygulamalarda disk performansı hissedilir bir fark yaratır. Diski hızlı bir altyapıyla desteklediğinizde, kuyruk işleriniz, günlükleriniz ve önbellek hareketleriniz daha akıcı olur. Uygulamayı yayınladıktan sonra “niye zaman zaman boş alan azalıyor” sürprizi yaşamamak için eski sürümleri düzenli temizlemek ve günlük rotasyonlarını doğru ayarlamak iyi bir alışkanlıktır.

Uygulaman büyürken izleme panelleri ve alarm kuralları da seninle büyüsün. Dün önemsiz olan bir eşik, yarın kritik olabilir. İşte tam burada, VPS izleme ve uyarı için sessiz alarmları konuşturan rehber kafanı toplamana yardım eder; hangi metriklere bakmalı, hangilerine alarm kurmalı gibi sorular gün gibi belirir.

Kapanış: Sakin, Esnek ve Güvenli Bir Yayın Düzeni Mümkün

Toparlayalım ve Bir Sonraki Dağıtımda Neler Yapacağız?

Bugün bir VPS üzerinde Laravel’i yayımlarken, Nginx ve PHP‑FPM’i nazikçe ayarlayıp, Horizon ile kuyrukları sakin tutmayı ve sıfır kesinti dağıtımı bir alışkanlığa dönüştürmeyi konuştuk. Temel fikir şu: Değişimi arkada hazırlayıp, öne sadece bir işaretle çıkarmak. Bu yönteme bir kez alışınca geriye dönmek istemiyorsunuz. Çünkü ziyaretçi beklemiyor, siz de panik yapmıyorsunuz.

Bir sonraki dağıtımın için küçük bir eylem planı bırakayım. Önce dizin yapını netleştir: releases, current ve paylaşımlı klasörler. Sonra Nginx ve FPM’i sert yeniden başlatmalar yerine yeniden yüklemelerle yönetmeyi dene. Horizon’u dağıtımın doğal bir adımı haline getir. İyileştirme tarafında ise HTTPS ayarlarını gözden geçir, izleme panellerini tak ve yedek planını basitleştir. İstersen kaynak ve performans tarafını daha derli toplu ele almak için şu üretim optimizasyonu yazısına tekrar dönüp kontrol listesi gibi kullanabilirsin.

Umarım bu rehber yayın düzenini güçlendirir ve içini rahatlatır. Soruların, çekincelerin ve “şurada takıldım, nasıl aşarım” türünden küçük düğümler hep olur; hepsi normal. Paylaş, konuşalım, çözüm yolu her zaman var. Bir dahaki yazıda belki dağıtımı bir adım daha otomatikleştirmeyi, belki de logları konuşuruz. O zamana kadar sahnen sakin, perden pürüzsüz kalsın.