Laravel 12'yi Tek Docker Konteynerinde (nginx + php-fpm + SQLite) Canlıya Almak: 5 Tuzak ve Çözümü

Laravel 12 projesini tek Docker konteynerinde, yani nginx + php-fpm + SQLite ile ayrı veritabanı sunucusu olmadan canlıya almak mümkün ve küçük-orta ölçekli siteler için gayet rahat. Synorq'ta son haftalarda yazdığımız birkaç Laravel projesini bu düzenle yayına aldım. Aşağıda yolda takıldığım 5 yeri ve çözümlerini yazıyorum.

Kullandığım düzen

• İmaj: serversideup/php (nginx + php-fpm tek imajda), port 8080
• Veritabanı: SQLite
• Tek kalıcı birim: /var/www/html/storage (SQLite dosyası, yüklemeler, APP_KEY)
• Deploy: Coolify, GitHub'a push edince otomatik derleme
• Açılışta otomatik: migrate, yönetici hesabı, storage:link

1. APP_KEY kaybolursa şifreli veri okunamaz

Veritabanında şifreli alan tutuyorsanız (API anahtarı, stok bilgisi, EPP kodu gibi) bu veriyi yalnız o APP_KEY açar. Konteyner her deploy'da yeniden oluştuğu için anahtarı imajın içinde üretmek veriyi kaybetmek demek.
Çözüm: anahtar ilk açılışta bir kez üretilip kalıcı birime yazılsın, sonraki açılışlarda oradan okunsun. Ayrıca birimin dışında bir yedeği olsun.

2. Önbellek deploy'dan sağ çıkıyor

CACHE_STORE=database ve veritabanı kalıcı birimde olunca deploy önbelleği temizlemiyor. Ayarları "varsayılanlar + veritabanı" birleşimi olarak önbelleğe yazıyordum. Koda yeni bir ayar anahtarı eklediğimde eski önbellekte o anahtar olmadığı için canlı site 500 verdi.
Çözüm: önbelleğe yalnız veritabanı satırlarını yazmak, varsayılanları her istekte kodda birleştirmek.
public static function values(): array
{
$db = Cache::rememberForever('settings', fn () => static::pluck('value', 'key')->all());

return array_merge(static::DEFAULTS, $db);
}
Böylece yeni varsayılan eklemek önbelleği bozmaz.

3. Konteynerde cron yok

Laravel zamanlayıcısı için iki yol denedim:

• Panelin zamanlanmış görev özelliğiyle her dakika php artisan schedule:run
• İmajın içine s6 ile uzun süreli servis olarak php artisan schedule:work

İkincisi panelden bağımsız çalıştığı için daha taşınabilir. İmajı başka sunucuya götürdüğünüzde zamanlayıcı da beraber gelir.

4. Sunucu saati kayınca otomatik deploy sessizce durur

Sunucuda NTP çıkışı (UDP 123) kapalıysa saat kayıyor. 30-60 saniyelik farkta GitHub App imza doğrulaması "System time out of sync" hatası veriyor ve push sonrası deploy tetiklenmiyor.
Deploy tetiklenmiyorsa ilk bakılacak yer sunucu saati: timedatectl status

5. Windows'ta kopyalanan projede storage bağlantısı bozulur

Projeyi Windows'ta kopyalarken public/storage bağlantısı düz klasöre dönüşebiliyor. Görseller yükleniyor ama sitede görünmüyorsa sebep genelde bu. Kopyadan sonra public/storage klasörünü silip php artisan storage:link ile yeniden oluşturmak gerekiyor.

Kısa sorular

SQLite canlıda kullanılır mı? Tek sunucuda çalışan, yazma yükü düşük sitelerde evet. Aynı anda çok yazma varsa ya da birden fazla uygulama sunucusu gerekiyorsa MySQL ya da PostgreSQL'e geçmek gerekir. Laravel'de bu geçiş çoğu projede yalnız .env değişikliği.
Yedek nasıl alınır? Her şey tek birimde olduğu için o birimi yedeklemek yeterli. SQLite dosyasını çalışırken kopyalamak yerine sqlite3 database.sqlite ".backup yedek.sqlite" kullanmak daha güvenli.
Tek konteyner ne zaman yetmez? Kuyruk işçisi ağırlaştığında ya da yatay ölçekleme gerektiğinde. O noktada veritabanını ve işçiyi ayırmak gerekir.
SQLite'ı canlıda kullanan başka var mı? Hangi trafik seviyesinde MySQL'e geçtiniz, merak ediyorum.

Octane kullanıyor musunuz? Uygulama daha hızlı çalışıyor bellekte yüklü kaldığı için. Ama bellek sızıntısı ihtimaline karşı ne olur ne olmaz standart PHP-FPM veya FrankenPHP php_server kullanmak daha güvenli hissettiriyor. Siz şu anda ne kullanıyorsunuz?

Şu an geliştirdiğimiz Laravel projelerinde Octane kullanmıyoruz. Laravel 10 ve 12 tabanlı projelerimiz mevcut.
Octane’in özellikle yüksek trafik altında uygulamanın sürekli bellekte tutulması sayesinde performans avantajı sağlayabildiğinin farkındayız. Ancak sizin de belirttiğiniz gibi long-running worker mimarisinde singleton’lar, static değişkenler ve request-specific state doğru yönetilmediğinde memory leak ve state leakage riskleri oluşabiliyor.
Bu nedenle Octane’i varsayılan tercih olarak değil, ihtiyaç ve benchmark sonuçlarına göre değerlendirilmesi gereken bir optimizasyon olarak görüyoruz.
Özellikle uygulama katmanında ölçülebilir bir darboğaz oluşmadığı sürece standart PHP request lifecycle yaklaşımını daha öngörülebilir buluyoruz.
İleride Octane kullanmamız gerekirse worker recycling, memory monitoring, request-scoped dependency yönetimi ve load test süreçlerini birlikte ele almayı planlıyoruz.
Bu arada siz Octane tarafında doğrudan memory leak problemi yaşadınız mı, yoksa mimari tercih açısından mı PHP-FPM / FrankenPHP tarafını daha güvenli buluyorsunuz?