Laravel cPanel'e ve VPS'e Nasıl Kurulur? Adım Adım Rehber

Laravel cPanel'e nasıl kurarsınız?

Laravel'i cPanel'e kurmak, proje dosyalarını hosting hesabınıza taşımak, Composer ile bağımlılıkları yüklemek, .env dosyasını üretim değerleriyle doldurmak ve alan adının kökünü projenin public klasörüne yöneltmek demektir. Ardından göçleri çalıştırır, izinleri düzenler ve zaman ayarlı görevler için tek bir cron satırı tanımlarsınız.

Biz dijital pazarlama ve web ekibiyiz, hosting firması değiliz. Bu yazıdaki komutları ve ayar adlarını Laravel, Composer ve cPanel resmi dokümanlarına dayandırdık. Kendi sunucu işletme deneyimimizi anlatmıyoruz.

Peki bu rehber kime göre? Web sitesi ya da e-ticaret sahibiyseniz, yazılımcınızın ve hosting sağlayıcınızın ne yaptığını anlamanız için okuyabilirsiniz. Kendi VPS'inizi ya da cPanel hesabınızı yöneten bir yazılımcıysanız, komutları adım adım uygulayabilirsiniz. Sürüm numaralarını ve varsayılan değerleri burada sabitlemiyoruz, çünkü bunlar Laravel sürümünüze göre değişir.

Yazının sonunda iki bölüm bulacaksınız: sık görülen hatalar ve kurulumu ne zaman sağlayıcıya bırakmanız gerektiği. Çünkü doğru kararın bir kısmı komut yazmak, bir kısmı da komutu yazmamaktır. Laravel cPanel kurulumunu ilk kez yapanlar için en güvenli yol, her adımdan sonra sonucu kontrol etmektir.

Kuruluma başlamadan önce hangi gereksinimleri kontrol etmelisiniz?

Laravel'in resmi dağıtım dokümanı asgari PHP sürümünü ve gerekli eklentileri listeler. Dokümanın güncel sürümü PHP 8.3 ve üzerini istiyor. Ancak bu sayı Laravel sürümünüze göre değişir. Bu nedenle projenizin composer.json dosyasındaki php satırına ve dokümanın kendi sürümünüze ait sayfasına bakın.

cPanel tarafında PHP sürümünü seçtiğiniz bölümün adı sağlayıcıya göre değişir. Çoğu hostingde MultiPHP Manager ya da Select PHP Version gibi bir ekran bulursunuz. Sürümü seçtikten sonra eklentilerin açık olduğunu da doğrulayın. Dokümanın listesinde şu eklentiler var:

• Ctype, cURL, DOM ve Fileinfo.
• Filter, Hash, Mbstring ve OpenSSL.
• PCRE, PDO, Session, Tokenizer ve XML.

Ayrıca kullandığınız veritabanı için ilgili PDO sürücüsü gerekir. Örneğin MySQL kullanıyorsanız pdo_mysql açık olmalı. Son olarak terminal erişiminiz olup olmadığına bakın. Composer ve php artisan komutları terminal ister, paylaşımlı hostinglerin bir kısmı bunu kapalı tutar.

Paylaşımlı hosting, VPS ve yönetilen platform arasında nasıl karar verirsiniz?

Karar, ne kadar kontrol istediğinize ve bu kontrolün sorumluluğunu taşıyıp taşımayacağınıza bağlıdır. cPanel'li paylaşımlı hosting ucuz ve kolaydır, ama kuyruk işçisi gibi sürekli çalışan süreçler için sınırlıdır. VPS tam kontrol verir, fakat güvenlik ve güncellemeler size kalır.

Laravel'in kendi dokümanı iki yönetilen seçenekten söz eder. Laravel Cloud tam yönetilen bir dağıtım platformudur. Forge ise kendi sunucularınızı yönetmek isteyip tüm servisleri elle kurmak istemeyenler için bir VPS yönetim aracıdır. Aşağıdaki tablo genel bir çerçeve sunar.

Hosting seçiminin pazarlama ve performans yanını web sitesi için hosting seçimi yazımızda ele aldık. Burada yalnızca Laravel'e özgü farkları anlatıyoruz. Küçük bir kurumsal site ya da başlangıç aşamasındaki bir mağaza için Laravel cPanel düzeni çoğu zaman yeterlidir. Büyüyen trafikte ise VPS ya da yönetilen platforma geçiş konuşulur.

Proje dosyalarını sunucuya nasıl taşırsınız?

Üç yaygın yol vardır: Git ile çekmek, zip dosyasını File Manager'dan yüklemek ya da SFTP ile göndermek. Git en düzenli olanıdır, çünkü her dağıtımda hangi sürümün canlıda olduğunu bilirsiniz. Git'e yeni başlıyorsanız Git ve GitHub kullanım rehberimiz temel komutları anlatıyor.

Hangi yolu seçerseniz seçin, şu kurallar geçerlidir:

• Yerel .env dosyanızı sunucuya taşımayın. Üretim için ayrı bir dosya hazırlayacaksınız.
• node_modules klasörünü yüklemeyin. Sunucuda ön yüz derlemesi yapmayacaksanız, çıktı dosyalarını yerelde üretip yükleyin.
• vendor klasörünü tercihen sunucuda Composer ile oluşturun. Terminal yoksa yerelde üretip yüklemeniz gerekir.
• Projeyi alan adının herkese açık klasörünün dışına koyun. Gerekçesini public klasörü bölümünde anlatıyoruz.

Yani en güvenli düzen, uygulama klasörünün ayrı, yalnızca public içeriğinin web'e açık olduğu düzendir.

Dosya yüklemeden önce sürümü etiketlemek de işinize yarar. Bir sorun çıkarsa hangi sürüme dönebileceğinizi bilirsiniz. Ayrıca yüklemeyi trafiğin düşük olduğu bir saate koyun. Özellikle e-ticaret sitelerinde yoğun saatte yapılan bir dağıtım, sipariş kaybına yol açabilir.

Composer ile bağımlılıkları sunucuda nasıl yüklersiniz?

Proje klasörüne girip Composer'ın install komutunu üretim bayraklarıyla çalıştırırsınız. Composer'ın resmi komut dokümanına göre install, composer.lock dosyası varsa oradaki tam sürümleri kurar. Böylece yerelde test ettiğiniz paket sürümleri canlıya da gelir.

cd /path-to-your-project
composer install --no-dev --optimize-autoloader

no-dev bayrağı require-dev altındaki paketleri atlar. Yani test ve hata ayıklama araçları canlıya girmez. optimize-autoloader bayrağı ise sınıf yüklemeyi hızlandırmak için classmap üretir. Doküman bunu özellikle üretim için öneriyor.

Canlıda composer update çalıştırmayın. Çünkü update kilit dosyasını değiştirip test etmediğiniz sürümler getirebilir. Paylaşımlı hostingde bellek ya da süre sınırı yüzünden Composer hata verirse, vendor klasörünü yerelde aynı komutla üretip yüklemek geçici çözümdür.

Yerel makinenizdeki PHP sürümü ile sunucudakinin aynı olmasına dikkat edin. Sürümler farklıysa Composer, yerelde çalışan paketleri sunucuda reddedebilir. Hata mesajı genellikle hangi paketin hangi sürümü istediğini açıkça yazar. Bu mesajı okuyup sürümü eşitlemek, paketleri zorla kurmaktan çok daha güvenlidir.

.env dosyasını ve APP_KEY değerini nasıl hazırlarsınız?

Yeni bir Laravel kurulumunda .env.example dosyası vardır ve kurulum sırasında .env adıyla kopyalanır. Sunucuda da aynı mantıkla ilerlersiniz. Örnek dosyayı kopyalayıp üretim değerleriyle doldurursunuz, ardından uygulama anahtarını üretirsiniz.

cp .env.example .env
php artisan key:generate

Aşağıdaki değerler örnektir, kendi bilgilerinizle değiştirmelisiniz:

APP_ENV=production
APP_DEBUG=false
APP_URL=https://example.com
DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_DATABASE=hesapadi_laravel
DB_USERNAME=hesapadi_uygulama
DB_PASSWORD=guclu-bir-parola-yazin

Laravel yapılandırma dokümanı net konuşuyor: üretimde APP_DEBUG her zaman false olmalı. True kalırsa hata sayfaları hassas yapılandırma değerlerini son kullanıcıya gösterebilir. Ayrıca .env dosyası kaynak kontrolüne girmemeli, çünkü içindeki gizli bilgiler depoya erişen herkesin eline geçer.

Laravel şifreleme işlemlerinde APP_KEY değerini kullanır. Canlıda sonradan değiştirirseniz, eski anahtarla korunan veriler okunamaz hale gelebilir. Bu nedenle anahtarı bir parola yöneticisinde saklayın.

Veritabanını nasıl oluşturur ve migrate komutunu nasıl çalıştırırsınız?

cPanel'de MySQL Databases ya da MySQL Database Wizard bölümünden yeni bir veritabanı ve kullanıcı oluşturursunuz. Kullanıcıyı veritabanına tüm yetkilerle bağlamayı unutmayın. cPanel hesap adını ad önekine ekler. Bu yüzden .env içindeki DB_DATABASE ve DB_USERNAME değerlerine önekli adı yazmanız gerekir.

Bağlantıyı .env dosyasına girdikten sonra tabloları göçlerle oluşturursunuz:

php artisan migrate --force

Üretim ortamında Laravel, göçleri çalıştırmadan önce onay ister. Force bayrağı bu onayı atlar ve otomatik dağıtımlarda gereklidir. Ancak göçler tablo yapısını değiştirebildiği için, canlı veri varsa önce yedek alın. Yedekleme düzeni için web sitesi yedekleme stratejisi yazımıza bakabilirsiniz.

Sorgu mantığını ve veritabanı tasarımını daha iyi anlamak isterseniz SQL sorgu senaryoları yazımız iyi bir tamamlayıcıdır.

storage ve bootstrap/cache izinlerini nasıl düzenlersiniz?

Laravel dokümanına göre uygulama, bootstrap/cache ve storage klasörlerine yazabilmelidir. Yani web sunucusu sürecinin sahibi bu klasörlerde yazma iznine sahip olmalı. Çoğu cPanel kurulumunda PHP hesabınızın kullanıcısıyla çalışır, ancak bu sağlayıcıya göre değişebilir.

chmod -R ug+rwx storage bootstrap/cache

Bu komut sahibine ve gruba okuma, yazma ve çalıştırma izni verir. Klasörlere herkese açık tam yetki (777) vermeyin. Çünkü aynı sunucudaki başka hesaplar ya da bir güvenlik açığı bu izni kötüye kullanabilir.

Yüklenen dosyaları public diskten sunmak için storage:link komutunu çalıştırırsınız:

php artisan storage:link

Bazı paylaşımlı hostingler sembolik bağları kapatır. Bu durumda görseller 404 verir. Çözüm için sağlayıcınıza sorun ya da dosya sunum yöntemini değiştirin.

Kullanıcıların yüklediği dosyalar ayrı bir konudur. Bu dosyaların türünü ve boyutunu doğrulamayı unutmayın, çünkü kontrolsüz yükleme ciddi bir güvenlik riskidir. Yüklenen belgeleri çalıştırılabilir klasörlerde tutmayın. Doğrulama kurallarını uygulama kodunda yazarsınız, sunucu ayarı bunun yerini tutmaz.

Laravel cPanel kurulumunda alan adı kökünü public klasörüne nasıl yöneltirsiniz?

Laravel'in dağıtım dokümanı, web sunucusunun tüm istekleri uygulamanın public/index.php dosyasına yönlendirmesini ister. Dokümanın uyarısı açıktır: index.php dosyasını proje köküne taşımayın. Çünkü projeyi kökten sunarsanız, birçok hassas yapılandırma dosyası internete çıkar.

cPanel'de bunu Domains ekranından yaparsınız. cPanel dokümanına göre mevcut bir alan adının belge kökünü değiştirmek için alan adının yanındaki Manage düğmesine tıklarsınız. Ardından belge kökü alanına projenizin public klasörünün yolunu yazarsınız. Örneğin yol, hesap klasörünüzün altındaki uygulama klasörü ve onun içindeki public olur.

Alt alan adı ya da eklenti alan adı için bu işlem genellikle sorunsuzdur. Ana alan adında ise bazı sağlayıcılar belge kökünü sabit tutar. Bu durumda bir sonraki bölümdeki seçeneklere bakmanız gerekir.

Ana alan adının kökü değiştirilemiyorsa ne yaparsınız?

Öncelikle sağlayıcınıza sorun. Çoğu zaman belge kökünü değiştirmek tek bir destek talebiyle biter. Değilse ya projeyi bir alt alan adına kurarsınız ya da public içeriğini herkese açık klasöre taşıyan düzene geçersiniz.

İkinci yöntemde index.php içindeki autoload, bootstrap ve maintenance dosyalarına giden yolları yeni klasör düzenine göre güncellersiniz. Her Laravel güncellemesinde bu dosyayı kontrol etmek gerekir. Bu yüzden bu yöntem bakım yükü getirir.

Hangisini seçerseniz seçin, .env dosyasının genel klasörde olmadığından emin olun. Sonunda tarayıcıdan alan adınızın sonuna /.env yazıp deneyin. Dosya içeriği görünüyorsa kurulum güvensizdir ve hemen düzeltmeniz gerekir.

Üretim için hangi optimizasyon komutlarını çalıştırırsınız?

Laravel dokümanı, üretimde yapılandırma, olay, rota ve görünüm dosyalarının önbelleğe alınmasını önerir. Tek bir optimize komutu hepsini birlikte yapar ve dokümana göre dağıtım sürecinizin bir parçası olmalıdır. Ayrıntılı komutlar aşağıdaki tabloda.

Burada önemli bir tuzak var. Yapılandırmayı önbelleğe aldıktan sonra Laravel .env dosyasını okumaz ve env fonksiyonu null döner. Bu nedenle env çağrılarını yalnızca config klasöründeki dosyalarda yazın. Uygulama kodunuzda değerleri config fonksiyonuyla okuyun.

Önbellek mantığını daha geniş görmek için Redis ve Memcached önbellekleme yazımıza göz atın.

Laravel cPanel kurulumunda scheduler için cron'u nasıl tanımlarsınız?

Laravel'in zamanlayıcısı sunucuda yalnızca tek bir cron satırı ister. Bu satır her dakika schedule:run komutunu çalıştırır, komut da hangi görevin zamanı geldiğine kendisi karar verir. Görevleri routes/console.php dosyasında tanımlarsınız. Böylece zamanlama kodunuzla birlikte kaynak kontrolünde kalır.

Laravel dokümanındaki satır şöyledir. Yolu kendi projenizle değiştirin:

* * * * * cd /path-to-your-project && php artisan schedule:run >> /dev/null 2>&1

cPanel'de Cron Jobs ekranına gidin, aralığı her dakika olarak seçin ya da beş yıldızı elle girin. Komut kutusuna mutlak dosya yolunu yazın. Ayrıca php yolu sağlayıcıya göre değişir. Bu yüzden hosting panelindeki PHP bilgisine bakın ya da terminalde which php komutunu deneyin. Yanlış PHP sürümüyle çalışan bir cron, web sitesi sorunsuz açılsa bile görevlerin sessizce başarısız olmasına yol açar.

cPanel cron dokümanı iki uyarı veriyor. Birincisi, cron işleri arasında öncekinin bitmesine yetecek süre bırakın. İkincisi, çıktıyı sonuna /dev/null eklemezseniz e-posta bildirimi alırsınız. Kurulumdan sonra php artisan schedule:list komutuyla görevlerinizin göründüğünü doğrulayın. Örneğin günlük bir rapor görevi tanımladıysanız, listede bir sonraki çalışma zamanını görürsünüz. Canlıda schedule:work kullanmayın, çünkü doküman onu yerel geliştirme için gösteriyor.

Kuyruk işçilerini cPanel'de ve VPS'te nasıl çalıştırırsınız?

queue:work komutu sürekli çalışan bir süreçtir. Dokümana göre bu işçiler uygulama kodunu bellekte tutar. Yani yeni sürüm yayınladığınızda işçileri yeniden başlatmazsanız eski kod çalışmaya devam eder. Bunun için dağıtımda php artisan queue:restart komutunu çalıştırırsınız.

VPS'te işçileri ayakta tutmak için Supervisor gibi bir süreç yöneticisi kullanırsınız. Dokümandaki örneğin kısa hali şöyledir:

[program:laravel-worker]
process_name=%(program_name)s_%(process_num)02d
command=php /path/to/artisan queue:work
autostart=true
autorestart=true
numprocs=2
redirect_stderr=true
stdout_logfile=/path/to/worker.log
stopwaitsecs=3600

Paylaşımlı hostingde genellikle böyle bir süreç yöneticisi yoktur. Yaygın bir geçici çözüm, kuyruğu cron ile kısa aralıklarla boşaltmaktır. queue:work komutunun stop-when-empty ve max-time seçenekleri buna uygundur. Ancak bu yöntem işleri anında işlemez. Kuyruk işiniz kritikse VPS ya da yönetilen platform düşünün.

Örneğin sipariş onay e-postası ya da stok senkronizasyonu gibi işler gecikirse müşteri deneyimi bozulur. Bu tür işleri cron tabanlı çözüme emanet etmeyin. Her dağıtımdan sonra işçiyi yeniden başlatmayı da kontrol listenize yazın.

VPS'te Nginx için hangi ayarlar gerekir?

VPS kullanıyorsanız web sunucusu yapılandırmasını kendiniz yazarsınız. Laravel dokümanı Nginx için tam bir örnek verir. Başlangıç noktası olarak onu alın ve sunucunuza göre uyarlayın. Özellikle root satırı projenin public klasörünü göstermelidir.

server {
    listen 80;
    server_name example.com;
    root /srv/example.com/public;
    index index.php;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }
}

Bu kısa örnek yalnızca mantığı gösterir. Tam örnekte güvenlik başlıkları, PHP-FPM bağlantısı ve noktayla başlayan dosyaları engelleyen kural da yer alır. PHP-FPM soket yolu kurulu PHP sürümüne göre değiştiği için dokümandaki yolu olduğu gibi kopyalamayın.

HTTPS için sertifika da gerekir. cPanel'li hostinglerin çoğunda sertifika sağlayıcı tarafından otomatik gelir. VPS'te ise sertifikayı siz kurarsınız. Konuyu SSL sertifikası ve HTTPS güvenliği yazımızda anlattık.

Kurulumdan sonra Laravel cPanel dağıtımını nasıl test edersiniz?

Önce ana sayfayı, sonra ana sayfa dışındaki bir rotayı açın. Ana sayfa açılıp diğer rotalar 404 veriyorsa, belge kökü ya da yeniden yazma kuralları yanlıştır. Ardından şu kontrolleri yapın:

• /up adresini açın. Laravel'in sağlık rotası uygulama sorunsuz açıldıysa 200, aksi halde 500 döner.
• Alan adınızın sonuna /.env yazın. Dosya içeriğini görmüyorsanız doğru çalışıyor demektir.
• storage/logs klasöründe günlük dosyasının oluştuğunu ve yazılabildiğini doğrulayın.
• php artisan schedule:list çıktısında görevlerinizin göründüğünü kontrol edin.
• Sertifikayı ve DNS kayıtlarını araçlarla doğrulayın.

Sertifika ve DNS için SSL sorgulama aracımızı ve DNS sorgulama aracımızı kullanabilirsiniz. Ayrıca yayından sonra hız ölçmek için Lighthouse ile performans testi iyi bir adımdır. Hız ve sıralama ilişkisi için site hızı SEO'yu nasıl etkiler yazımıza bakın.

E-posta ve günlük (log) ayarlarını nasıl yaparsınız?

Uygulamanız bildirim, sipariş ya da şifre sıfırlama e-postası gönderiyorsa, .env dosyasındaki MAIL ile başlayan değerleri doldurmanız gerekir. cPanel'de e-posta hesabı oluşturup sağlayıcınızın verdiği SMTP bilgilerini kullanabilirsiniz. Parolaları yine yalnızca .env içinde tutun.

Günlükler de en az e-posta kadar önemlidir. Üretimde hata ayıklama ekranını kapattığınız için tek bilgi kaynağınız storage/logs klasörüdür. Bu klasörün zamanla büyüyebileceğini unutmayın. Disk kotası dolarsa uygulama yazma hatası verir.

Bu nedenle günlük dosyalarını düzenli kontrol edin. Ayrıca e-posta gönderimini canlıda gerçek bir adresle bir kez deneyin. Test mesajlarını gerçek müşterilere göndermeyin, kendi adresinizi kullanın. Kuyruk kullanıyorsanız e-postaların kuyruğa düştüğünü ve işçi tarafından işlendiğini de doğrulayın.

Laravel cPanel kurulumunda .htaccess dosyası ne işe yarar?

Laravel'in varsayılan iskeletinde public klasörü, Apache için hazır bir .htaccess dosyası içerir. Bu dosya, var olmayan adreslere gelen istekleri index.php'ye yönlendirir. Böylece /urunler gibi temiz adresler çalışır ve her rota için ayrı bir dosya gerekmez.

cPanel'li hostinglerin çoğu Apache ya da onunla uyumlu bir sunucu kullanır. Bu nedenle ek ayar yapmadan çalışması beklenir. Ancak belge kökünü yanlış klasöre yöneltirseniz, .htaccess dosyası devreye girmez ve yalnızca ana sayfa açılır. Dolayısıyla rotalar 404 veriyorsa önce belge kökünü kontrol edin.

Kendi .htaccess dosyanızı düzenlemeden önce yedek alın. Küçük bir yazım hatası bütün siteyi 500 hatasına düşürebilir. Emin değilseniz, bu dosyaya dokunmak yerine sağlayıcınızın desteğinden yardım isteyin.

Yerel geliştirme ile canlı ortam arasındaki farklar nelerdir?

Yerelde çalışan bir Laravel projesi canlıda aynı davranmayabilir. Çünkü iki ortamın hata gösterimi, önbelleği ve arka plan süreçleri farklıdır. Aşağıdaki tablo, dokümanlarda geçen başlıca farkları özetler.

Yani canlıya çıkmadan önce yerelde APP_ENV ve önbellek ayarlarını bir kez üretim gibi denemek iyi bir alışkanlıktır. Böylece env fonksiyonuyla ilgili sürprizleri erken yakalarsınız.

Laravel cPanel kurulumu SEO ve pazarlama açısından neden önemlidir?

Teknik kurulum, arama motoru görünürlüğünü doğrudan etkiler. Yanlış yapılandırılmış bir site 500 hatası verirse, Google'ın tarayıcısı sayfalarınıza ulaşamaz. HTTPS eksikse kullanıcılar tarayıcı uyarısı görür. Yavaş bir sunucu ise hem sıralamayı hem dönüşümü zayıflatır.

Bu nedenle Laravel cPanel kurulumu tamamlandığında şunları kontrol edin: tüm adresler HTTPS ile açılıyor mu, robots.txt dosyası erişilebilir mi, sayfalar gereksiz yönlendirme zinciri oluşturuyor mu? Robots dosyasını hazırlamak için robots.txt oluşturucumuzu kullanabilirsiniz.

E-ticaret sitelerinde hız ve satış ilişkisi daha da belirgindir. Konuyu e-ticarette sayfa hızı satışları etkiler mi yazımızda ele aldık. Dolayısıyla Laravel ile kurduğunuz bir mağazada önbellek ve sunucu seçimi pazarlama bütçenizin verimini de etkiler.

Laravel cPanel kurulumunda en sık hangi hatalarla karşılaşırsınız?

Hataların çoğu birkaç nedene dayanır: yanlış belge kökü, eksik anahtar, izinler ve eski önbellek. Her zaman önce storage/logs klasöründeki günlüğe bakın, çünkü APP_DEBUG kapalıyken ekranda ayrıntı görmezsiniz. Aşağıdaki tablo olası nedenleri özetler.

Hata mesajını arama motoruna olduğu gibi yapıştırmak çoğu zaman en hızlı yoldur. Mesajın tamamını, dosya adı ve satır numarasıyla birlikte kopyalayın. Böylece sorunun hangi dosyadan geldiğini daha çabuk bulursunuz. Ancak aldığınız komutları çalıştırmadan önce Laravel dokümanıyla karşılaştırın.

Hangi durumlarda kurulumu kendiniz yapmamalı, hosting sağlayıcınıza bırakmalısınız?

Her işi kendiniz yapmak zorunda değilsiniz. Bazı durumlarda sağlayıcıya ya da deneyimli bir sistem yöneticisine bırakmak daha güvenlidir. Biz de hosting firması olmadığımız için bu sınırı baştan söylüyoruz.

• Canlıda gerçek müşteri ya da sipariş verisi var ve yedeğiniz yok.
• SSH, güvenlik duvarı ve işletim sistemi güncellemelerini yönetecek birikiminiz yok.
• Hosting hesabınızda terminal kapalı ve kuyruk gibi kalıcı süreçlere ihtiyacınız var.
• Kesintisiz dağıtım ve yüksek erişilebilirlik gerekiyor.
• Ödeme ya da kişisel veri işleyen bir uygulamayı ilk kez canlıya alıyorsunuz.

Bu durumlarda kurulumu sağlayıcınıza yaptırın ve yalnızca doğrulayın. Güvenlik tarafında OWASP Top 10 yazımız hangi açıklara dikkat edeceğinizi gösterir. Dolayısıyla teknik ekibinizle konuşurken bu başlıkları kontrol listesi olarak kullanabilirsiniz.

Sağlayıcıdan şunları isteyebilirsiniz: otomatik yedek, PHP sürüm yönetimi, SSL sertifikası ve sorun anında hızlı destek. Bu hizmetleri sunan bir hostingde Laravel kurulumunun riskli kısımları sağlayıcıya geçer. Siz de işinizin pazarlama ve ürün tarafına odaklanırsınız.

Her dağıtımda hangi kontrol listesini izlemelisiniz?

Dağıtımı bir kez elle yaptıktan sonra aynı adımları her seferinde aynı sırayla çalıştırmak hataları azaltır. Aşağıdaki sıra, bu yazıda anlattığımız resmi komutların bir araya gelmiş halidir. Kendi projenize göre uyarlayın.

php artisan down
git pull
composer install --no-dev --optimize-autoloader
php artisan migrate --force
php artisan optimize
php artisan queue:restart
php artisan up

Doküman, down komutunun kısa bir kesinti yarattığını söyler. Kesintisiz dağıtım istiyorsanız yönetilen bir platformu düşünün. Ayrıca saniyeden kısa aralıklı görevler tanımladıysanız, dağıtımın sonuna schedule:interrupt komutunu eklersiniz.

Son olarak her dağıtımdan sonra sağlık rotasını ve ana sayfayı kontrol edin. Laravel cPanel dağıtımlarında en sık hata, bir adımı atlamaktan gelir; liste bu yüzden yazılı olmalı. Böylece sorunu kullanıcılar fark etmeden yakalarsınız. Ekibiniz büyüdüğünde bu adımları bir betiğe ya da otomatik dağıtım hattına çevirmek mantıklıdır.