Bu Laravel rehberi, sitedeki Laravel yazılarının merkezi. Yazıların çoğu paylaşımlı hosting üzerinde çalışan gerçek projelerden çıktı; yani buradaki sıra, “kurulum → geliştirme → yayına alma → bakım” şeklinde ilerliyor ve her adımda özellikle paylaşımlı sunucuda karşılaşılan tuzaklara yer veriyor.
Kurulum ve Temel Yapı
- Laravel 13 ile proje kurulumu — sıfırdan çalışan bir iskelet.
- .env dosyası — ortam ayrımının doğru yapılması; canlı ve yerel farkı buradan başlar.
- Blade şablon sistemi ve Vite + Tailwind kurulumu — arayüz katmanı.
- Eloquent ilişkileri, migration hataları ve seeder & factory — veri katmanı.
Uygulama Katmanı: İstek, Doğrulama, Yetki
- Middleware kullanımı — isteğin hangi noktada kesileceğini belirleyen katman.
- Validation — doğrulamayı controller içine yaymak yerine form request ile toplamak.
- Authentication sistemi ve admin panel kurulumu
- Dosya yükleme ve storage:link — paylaşımlı hostingde en sık kırılan iki nokta.
- Rate limiting ve API geliştirme pratikleri
- Localization — çok dilli yapıyı sonradan eklemek yerine baştan planlamak.
Arka Plan İşleri ve Zamanlama
Bir Laravel projesinin canlıdaki davranışını en çok bu üç şey belirler: kuyruk, zamanlanmış görevler ve önbellek. Paylaşımlı hostingde üçünün de kendine özgü kısıtları var — daemon çalıştıramamak bunların başında gelir.
- Queue sistemi nedir, ne zaman kullanılır, queue worker mantığı ve arka plan işlerinin kurgusu
- Task scheduling — tek bir cron satırıyla tüm zamanlanmış görevleri yönetmek.
- SMTP ile mail gönderimi — kuyrukla birleştirilmediğinde form gönderimlerini yavaşlatan klasik hata.
Yayına Alma ve Paylaşımlı Hosting
Laravel’i paylaşımlı hostingde yayına almak mümkün, ama varsayılan dizin yapısı buna göre tasarlanmamış. Aşağıdaki iki yazı, public klasörü sorununu ve dağıtım sonrası ilk kontrol listesini kapsıyor.
- Paylaşımlı hostingde yayına alma — dizin yapısı, izinler ve ilk çalıştırma.
- Route cache ve config cache hatası — dağıtımdan sonra “değişiklik görünmüyor” şikayetinin ana kaynağı.
- Log dosyalarını okumak — canlıda hata ayıklamada temel veri kaynaklarından biri.
- Güvenlik kontrol listesi — yayına almadan önce son geçiş.
Laravel’i Paylaşımlı Hostingde Çalıştırmanın Üç Yolu
Laravel’in dizin yapısı, web sunucusunun yalnızca public klasörünü göreceğini varsayar. Paylaşımlı hostingde ise sunucu genellikle doğrudan public_html içine bakar. Üç çözüm var ve üçünün de bedeli farklı:
| Yöntem | Nasıl | Riski |
|---|---|---|
| Alt alan adına bağlama | Panelden alt alan adının kök dizinini proje/public olarak gösterin | En temizi; panel bunu desteklemiyorsa uygulanamaz |
public içeriğini taşıma | index.php ve varlıkları public_html‘e alıp yolları düzeltin | Güncellemede yollar tekrar bozulabilir |
| .htaccess ile yönlendirme | Kök dizinde tüm istekleri public klasörüne yönlendirin | Yanlış kural, kaynak dosyaları dışarı açabilir |
Hangisini seçerseniz seçin, storage ve bootstrap/cache klasörlerinin yazılabilir olması ve .env dosyasının web kökünün dışında kalması şart. Bu iki kontrolü atlayan kurulumların büyük kısmı ya beyaz sayfa verir ya da yapılandırmasını internete açar.
Dağıtım Öncesi Kontrol Listesi
APP_ENV=productionveAPP_DEBUG=false— hata ayıklama açık kalırsa yığın izi ziyaretçiye görünür.APP_KEYüretilmiş mi — eksikse oturum ve şifreleme çalışmaz.- Veritabanı bilgileri canlı sunucununki mi, yerelde kalan değerler taşınmış mı.
- Önbellekler temizlendi mi: config, route ve view önbelleği eski değerleri saklar.
- Zamanlanmış görevler için sunucuda tek bir cron satırı tanımlandı mı.
- Kuyruk kullanılıyorsa işçinin nasıl tetikleneceği belirlendi mi (daemon yoksa cron ile).
- Loglar dönüyor mu — tek dosyaya yazan bir günlük, aylar içinde diski doldurabilir.
Bu Rehber Kimin İçin?
Yazıların hepsi, kurumsal bir sunucu ekibi olmayan geliştiriciler düşünülerek yazıldı: tek başına ya da küçük bir ekiple çalışan, projesini çoğunlukla paylaşımlı hosting ya da küçük bir VPS üzerinde yayınlayan kişiler. Bu yüzden her adımda “ideal yapılandırma” değil, o ortamda gerçekten uygulanabilir olan anlatılıyor. Sayfa yeni Laravel yazıları eklendikçe güncelleniyor.
Paylaşımlı Hostingde En Sık Üç Tuzak
1. Composer’ı sunucuda çalıştıramamak. Birçok paylaşımlı pakette SSH yok ya da bellek limiti composer install için yetersiz. Çözüm, bağımlılıkları yerelde kurup vendor klasörünü birlikte yüklemek.
2. Önbelleği temizlemeden dağıtmak. config:cache ve route:cache eski değerleri saklar; yeni .env yüklendiği halde uygulama eskisini okumaya devam eder.
3. Kuyruk işçisinin sürekli çalıştığını varsaymak. Daemon çalıştıramadığınız ortamlarda kuyruğu cron ile tetiklemek gerekir; aksi halde işler sessizce birikir.
Sık Sorulan Sorular
Laravel paylaşımlı hostingde gerçekten çalışır mı?
Çalışır, ama iki koşulla: PHP sürümü kullandığınız Laravel sürümünün istediği minimumu karşılamalı ve public klasörü sorununu yukarıdaki üç yöntemden biriyle çözmelisiniz. Kuyruk işçisi ve WebSocket gibi sürekli çalışan süreçler gerektiren özellikler ise paylaşımlı ortamda ya kısıtlı çalışır ya da hiç çalışmaz.
Yerelde çalışan proje canlıda neden 500 veriyor?
En sık üç sebep: storage ve bootstrap/cache klasörlerinin yazma izni olmaması, .env dosyasının yüklenmemiş olması ve eski config önbelleğinin canlıya taşınmış olması. Üçü de aynı belirtiyi verdiği için log dosyasına bakmadan tahmin yürütmek zaman kaybıdır.
Composer sunucuda çalışmıyorsa ne yapmalı?
Bağımlılıkları yerel makinenizde --no-dev --optimize-autoloader ile kurup vendor klasörünü projeyle birlikte yükleyin. Yerel PHP sürümünüzün sunucudakiyle uyumlu olmasına dikkat edin; aksi halde kurulan paketler sunucuda hata verir.
Değişiklik yaptım ama canlıda görünmüyor, neden?
Önbellek yalnız olası nedenlerden biridir; doğru release/alan adı, OPcache, CDN ve tarayıcı önbelleğini de kontrol edin. SSH yoksa hostingin güvenli terminal/görev aracı veya destek ekibini kullanın. İnternete açık artisan/bakım rotası eklemek sırları ifşa edebilir; önerilen dağıtım yolu değildir.
Resmî kaynak: Laravel 13.x dağıtım dokümantasyonu
Kaynaklar ve İleri Okuma
Resmî dokümantasyon
Sitedeki ilgili rehberler
Web kökü yalnız public içeriğini sunmalıdır. Bütün projeyi public_html içine koyup yalnız rewrite kuralına güvenmeyin; .env, vendor, storage/logs ve yedeklerin URL’den erişilemediğini doğrulayın. Vendor’ı hedef PHP sürümü ve uzantılarıyla uyumlu ortamda composer.lock üzerinden üretin; platform gereksinimlerini atlamayın. Mevcut APP_KEY’i her dağıtımda yeniden üretmek şifrelenmiş veriyi ve oturumları bozabilir. Cron ile queue çalıştırırken çakışmayı, tekrar deneme ve maksimum iş süresini sınırlayın.
