Her geliştiricinin bir kırılma noktası vardır. Yıllardır güvendiğiniz bir aracın, birden sizin aleyhinize çalışmaya başladığı o an. Bizim için bu an, yanlış giden geç gece bir dağıtım sırasında yaşandı – bir üretim sunucusu bozuk bir durumda bırakıldı, geri alma süreci SSH ile bir kutuya girmeyi ve dizinleri manuel olarak simgelemeyi gerektiriyordu ve bir izleme açığı nedeniyle, problemi ancak bir müşteri destek talebi geldiğinde, kırk dakika sonra fark ettik.
<p>Yıllardır Laravel uygulamalarını dağıtıyorduk. Her ana platformu kullandık. Ve sürekli aynı sorunlarla karşılaşıyorduk. İşte bu nedenle Deploynix'i inşa ettik.</p>
<h2>
<a name="the-pain-points-we-lived-with" href="#the-pain-points-we-lived-with"></a>
Yaşadığımız Sorunlar
</h2>
<p>Eğer profesyonel olarak Laravel uygulamaları dağıttıysanız, durumu biliyorsunuz. Bir sunucu yönetim platformu seçiyorsunuz, bulut sağlayıcınızı bağlıyorsunuz, bir sunucu açıyorsunuz ve dağıtım yapıyorsunuz. Çoğunlukla işe yarıyor. Ama "çoğunlukla" yeterli değil, çünkü gerçek işlerin bağımlı olduğu uygulamalardan sorumlusunuz.</p>
<p>Bizi sürekli rahatsız eden şeyler şunlardı:</p>
<h3>
<a name="zerodowntime-was-always-an-afterthought" href="#zerodowntime-was-always-an-afterthought"></a>
Sıfır Kesinti Her Zaman İkinci Plandaydı
</h3>
<p>Çoğu platform, sıfır kesinti dağıtımlarını bir premium özellik olarak ekliyor ya da bunu sizin yapılandırmanıza bırakıyordu. Ancak sıfır kesinti lüks değil, temel bir beklentidir. Her dağıtımda kullanıcılarınız bir kesinti yaşamamalıdır. Her kod itişinde geçiş sorunsuz olmalıdır. Atomic simge dağıtımlarını varsayılan hale getirmek istedik, satılık değil.</p>
<h3>
<a name="multicloud-was-painful" href="#multicloud-was-painful"></a>
Çoklu Bulut Zordu
</h3>
<p>DijitalOkyanus, Vultr, Hetzner, Linode ve AWS üzerinde uygulama yönetiyoruz. Bazı iş yükleri maliyet açısından Hetzner'de mantıklı. Bazıları uyum için AWS gerektiriyor. Bazı müşteriler DijitalOkyanus'da ısrar ediyor. Mevcut platformlar birkaç sağlayıcıyı destekliyordu ama deneyim hiçbir zaman tutarlı olmadı. Özel bir sunucu bağlamak her zaman ikincil bir deneyim gibi hissettirdi. Her sağlayıcının - özel bare-metal sunucular da dahil - birinci sınıf bir seçenek gibi hissettirdiği tek bir gösterge panosu istedik.</p>
<h3>
<a name="team-management-was-too-simple" href="#team-management-was-too-simple"></a>
Ekip Yönetimi Çok Basitti
</h3>
<p>Üretim ortamlarındaki Laravel uygulamaları tek başına projeler değildir. Arka uç geliştiriciler, ön uç mühendisleri, DevOps ekipleri ve proje yöneticileri vardır. Mevcut araçlar sadece "admin" veya "üye" ile sınırlı kalıyordu. Kesin izin sınırları olan ayrıntılı rollere ihtiyacımız vardı - Sahip, Yönetici, Müdür, Geliştirici ve Görüntüleyici - böylece bir junior geliştirici dağıtımı başlatabilirken, bir paydaş hiçbir şeye dokunmadan dağıtım durumunu görebilsin.</p>
<h3>
<a name="monitoring-was-bolted-on-or-missing" href="#monitoring-was-bolted-on-or-missing"></a>
İzleme Ya Eklenmişti Ya da Eksikti
</h3>
<p>Sunucu yönetimi ve sunucu izleme derinlemesine bağlantılıdır, fakat mevcut platformlar bunları ayrı endişeler olarak ele alıyordu. Sunucunuzu bir platformda kuruyordunuz, sonra tamamen ayrı bir izleme aracı yapılandırıyor, bir başka servis ile uyarılar kuruyordunuz. CPU, bellek ve disk izlemeyi doğrudan platforma entegre etmek, kullanıcılarınız bir şeyin yanlış olduğunu fark etmeden önce tetiklenecek uyarılarla birlikte istedik.</p>
<h3>
<a name="the-little-things-added-up" href="#the-little-things-added-up"></a>
Küçük Şeyler Birikti
</h3>
<p>Planlı dağıtımlar yoktu - gece geç saatlerde uyanık kalmak ya da kendi cron işinizi ayarlamak zorundaydınız. Aşamalı ortamlara yönelik özel alan adları yoktu. Entegre bir web terminali yoktu. WebSockets üzerinden gerçek zamanlı dağıtım günlükleri yoktu. Bireysel olarak bu küçük sıkıntılar olabilir. Toplamda, her hafta saatler süren zorluklara karşılık geliyordu.</p>
<h2>
<a name="what-we-set-out-to-build" href="#what-we-set-out-to-build"></a>
Ne Yapmayı Hedefledik
</h2>
<p>Deploynix, basit bir tezle başladı: ya bir sunucu yönetim platformu, 2026'da Laravel geliştiricilerinin çalıştığı şekilde inşa edilsin?</p>
<p>PHP'yi destekleyen genel bir platform değil. Önce WordPress için tasarlanmış ve ardından Laravel desteği eklenmiş bir araç değil. Her özelliğin, her iş akışının ve her varsayılanın Laravel uygulamaları ve etraflarındaki ekosistem için optimize edildiği bir platform.</p>
<h3>
<a name="laravelnative-defaults" href="#laravelnative-defaults"></a>
Laravel'e Özgü Varsayılanlar
</h3>
<p>Deploynix'te bir sunucu alırken, kutudan çıkar çıkmaz Laravel için yapılandırılır. PHP 8.4, Composer, Node.js, doğru dizin yapısı, uygun izinler, kuyruk işçiler, planlı görevler - her şey hazırdır. SSH ile bağlanmanıza ve yapılandırma dosyalarını düzeltmenize gerek yok. Hangi php.ini ayarlarının üretim için ayarlanması gerektiğini hatırlamak zorunda değilsiniz.</p>
<p>Octane'i FrankenPHP, Swoole ve RoadRunner ile birinci sınıf seçenekler olarak destekliyoruz. Kurulum sırasında sürücünüzü seçin ve sunucu buna göre yapılandırılır, dağıtımlar sırasında süreç yönetimi ve nazik yeniden başlatma dahil.</p>
<h3>
<a name="beyond-laravel-frontend-framework-support" href="#beyond-laravel-frontend-framework-support"></a>
Laravel'in Ötesinde: Ön Uç Çerçeve Desteği
</h3>
<p>Laravel bizim temelimiz olsa da, modern uygulamalar genellikle özel ön uç projelerini içerir. Deploynix, SPA çerçevelerini — React, Vue, Angular ve Svelte — ayrıca SSR çerçeveleri olan Next.js, Nuxt.js, SvelteKit ve Angular SSR'i dağıtmayı destekler. Her çerçeve, yapı komutları, çıktı dizinleri ve süreç yönetimi için makul varsayılanlar alır. İster Laravel API'nizin yanında bağımsız bir SPA çalıştırıyor olun, ister tam bir SSR uygulaması, Deploynix dağıtım hattını özel betikler yazmadan yönetir.</p>
<h3>
<a name="six-cloud-providers-one-experience" href="#six-cloud-providers-one-experience"></a>
Altı Bulut Sağlayıcısı, Tek Bir Deneyim
</h3>
<p>Deploynix, DijitalOkyanus, Vultr, Hetzner, Linode, AWS ve özel sunucularla entegre çalışmaktadır. Sağlayıcıdan bağımsız olarak, sağlama deneyimi aynıdır. Aynı izleme, aynı dağıtım hattı, aynı yönetim arayüzü. Kendi bare-metal sunucunuzu getirin ve yeni bir Hetzner kutusu ile aynı muameleyi görür.</p>
<p>Bu sadece bir kolaylık meselesi değil. Çoklu bulut mimarisi, dayanıklılık, maliyet optimizasyonu ve uyum için geçerli bir stratejidir. Bu stratejiyi her boyuttaki ekipler için erişilebilir hale getirmek istedik.</p>
<h3>
<a name="seven-purposebuilt-server-types" href="#seven-purposebuilt-server-types"></a>
Yedi Amaç İhtiyaçlarına Göre İnşa Edilmiş Sunucu Tipi
</h3>
<p>Her sunucu aynı şekilde yapılandırılmamalıdır. Bir veritabanı sunucusunun farklı optimizasyon ihtiyaçları vardır; bir işçi sunucusu web sunucusu çalıştırmamalıdır. Deploynix, belirli amacı için yapılandırılmış yedi farklı sunucu türü sunar — Uygulama, Web, Veritabanı, Önbellek, İşçi, Meilisearch ve Yük Dengeleyici.</p>
<p>Bu önemlidir çünkü iyi bir mimariyi teşvik eder. Her şeyi tek bir kutuda çalıştırmak yerine, amaçlarına göre farklı sunuculara yayabilirsiniz ve hepsini tek bir yerden yönetebilirsiniz. Kuyruk işleme işlemekte ölçeklendirme mi istiyorsunuz? Başka bir İşçi sunucusu ekleyin. Veritabanı yavaş mı geliyor? MySQL, MariaDB veya PostgreSQL ile henüz optimize edilmiş özel bir Veritabanı sunucusu açın.</p>
<h3>
<a name="zerodowntime-by-default" href="#zerodowntime-by-default"></a>
Varsayılan Olarak Sıfır Kesinti
</h3>
<p>Deploynix'teki her dağıtım atomic simge dağıtımları kullanır. Uygulamanız, belirli bir sürüm dizinine işaret eden bir <code>current</code> simgesinden çalışır. Yeni bir dağıtım tamamlandığında, simge atomik olarak değiştirilir. Eğer bir şey ters giderse, geri almak tek bir tıklama mesafesindedir - simge hemen önceki sürüme geri döner.</p>
<p>Paylaşılan depolama, çevre dosyaları ve kalıcı dizinler otomatik olarak yönetilir. PHP-FPM, mevcut talepler tamamlanmadan önce nazik bir şekilde yeniden yüklenir, böylece yeni işçiler taze kodu alır. Eski sürümler, sizin saklama politikanıza göre temizlenir.</p>
<p>Takvimsel bir tercih değil. Bir premium özellik değil. Her dağıtımın nasıl çalıştığı budur.</p>
<h3>
<a name="realtime-everything" href="#realtime-everything"></a>
Her Şey Gerçek Zamanlı
</h3>
<p>Deploynix, WebSocket iletişimi için Laravel Reverb üzerine inşa edilmiştir. Dağıtım günlükleri gerçek zamanlı olarak akmaktadır. Sunucu sağlık ölçümleri anlık olarak güncellenmektedir. Uyarı bildirimleri hemen gelmektedir. Dağıtımınızın bitip bitmediğini merak ederek sayfayı yenileyen biri olmayacaksınız.</p>
<p>Web terminali, tarayıcınızdan doğrudan SSH erişimi sağlar, doğru kimlik doğrulama ve audit kaydı ile birlikte. Takımınız boyunca SSH anahtarlarını yönetmek zorunda kalmazsınız - izinler platformun rol sistemi aracılığıyla yönetilir.</p>
<h3>
<a name="scheduled-deployments" href="#scheduled-deployments"></a>
Planlı Dağıtımlar
</h3>
<p>Bazen hemen dağıtım yapmak istemezsiniz. Belki de trafiğin en düşük olduğu saatlerde, 2 AM'de dağıtım yapmanız gerekiyor. Belki de bir dağıtımı bir pazarlama lansmanıyla koordine etmeniz gerekiyor. Deploynix, belirli bir zaman için dağıtımları planlamanıza olanak tanır ve dağıtımları yerine getirmeden önce iptal etme imkanı sunar. Gerçek bir iş akışı sorununu çözen basit bir özellik.</p>
<h3>
<a name="vanity-domains" href="#vanity-domains"></a>
Özel Alan Adları
</h3>
<p>Deploynix'teki her site, otomatik SSL ile ücretsiz bir <code>*.deploynix.cloud</code> alt alan adı alır. Bu, aşamalı ortamlar, müşteri ön izlemeleri ve geliştirme için mükemmeldir. DNS yapılandırmasına veya geçici ortamlar için sertifika provisionuna gerek yoktur. Üretim için hazır olduğunuzda, kendi alan adınızı getirin ve Deploynix, Let's Encrypt ile SSL'yi yönetir; Cloudflare, DigitalOcean, AWS Route 53 veya Vultr aracılığıyla wild card sertifikaları dahil.</p>
<h2>
<a name="the-technical-decisions-behind-deploynix" href="#the-technical-decisions-behind-deploynix"></a>
Deploynix'in Arkasındaki Teknik Kararlar
</h2>
<p>Deploynix'i inşa ederken, değerlerimizi yansıtan bilinçli teknik seçimler yaptık.</p>
<p>Faturalandırma için Paddle'ı seçtik çünkü global vergi uyumunu yönetiyor, böylece ürüne odaklanabiliyoruz. API'miz, Laravel Sanctum ile ayrıntılı token kapsamları kullanıyor, böylece panelin yaptığı her şeyi otomatikleştirebilir ve API tokenlarını sadece ihtiyaç duydukları izinlerle sınırlayabilirsiniz.</p>
<p>Yedeklemeler, AWS S3, DigitalOcean Spaces, Wasabi veya kendi Minio örneğinizi dahil olmak üzere S3 ile uyumlu tüm depolama alanlarını destekler. Çünkü yedekleme depolama, sizi belirli bir sağlayıcıya kilitlememelidir.</p>
<p>Yük dengeleme, Yığın Düşünebilir, En Az Bağlantılar ve IP Hash yöntemlerini destekler ve her yük dengeleyici için yapılandırılabilir. Çünkü farklı uygulamaların farklı trafik desenleri vardır.</p>
<p>Git entegrasyonu, GitHub, GitLab, Bitbucket ve özel Git depoları ile çalışır. Çünkü dağıtım platformunuz, kaynak kontrol tercihlerinizi dikte etmemelidir.</p>
<h2>
<a name="who-deploynix-is-for" href="#who-deploynix-is-for"></a>
Deploynix Kime Yönelik
</h2>
<p>Deploynix, dağıtım altyapısına ciddiyetle yaklaşan Laravel geliştiricileri ve ekipleri içindir. İster birkaç müşteri sitesini yöneten bir solo geliştirici olun, ister yirmi kişilik bir ekip olup bir SaaS ürünü gönderen bir grup olun ya da bir Laravel API'sinin yanında React veya Next.js uygulamalarını dağıtan bir ön yüz ekibi olun, Deploynix sizinle ölçeklenir.</p>
<p>Fiyatlandırmamız bunu yansıtmaktadır. Ücretsiz katman, başlamanızı ve platformu değerlendirmenizi sağlar. Başlangıç, bireysel geliştiriciler ve küçük projeler içindir. Profesyonel, büyüyen ekipler içindir. Kurumsal, karmaşık gereksinimlere sahip organizasyonlar içindir.</p>
<p>Her katman sıfır kesinti dağıtımları alır. Her katman gerçek zamanlı izlemeler alır. Her katman aynı dağıtım hattını alır. Temel güvenilirlik özelliklerini fiyatlandırma katmanları arkasında gizlemiyoruz.</p>
<h2>
<a name="the-road-ahead" href="#the-road-ahead"></a>
Gelecek Yol
</h2>
<p>Deploynix, varlığını gerektiği için başladık. Ama lansman sadece başlangıçtır. Yol haritamız, Laravel geliştiricilerinin gerçekten ihtiyaç duyduğu şeylerle yönlendirilmiş olup, sadece bir özellik karşılaştırma tablosunda etkileyici görünen şeylerle değil.</p>
<p>Her zaman kamuya açık bir şekilde inşa ediyoruz, geri bildirimleri dinliyoruz ve sürekli iyileştirmeler gönderiyoruz. Sunucu yönetim alanı çok uzun bir süre durağan kaldı. Mevcut platformlar, piyasaya sürüldüğünde devrim niteliğindeydi, ama Laravel ekosistemi o zamandan beri büyük ölçüde gelişti. Dağıtım uygulamaları, altyapı şemaları, ekip iş akışları - her şey değişti. Araçların da değişmesi gerek.</p>
<h2>
<a name="try-it-yourself" href="#try-it-yourself"></a>
Kendiniz Deneyin
</h2>
<p>Bu yazıdaki sorunlardan herhangi biri sizinle resonance oluşturuyorsa, Deploynix'i deneyin. Bulut sağlayıcınızı bağlayın, bir sunucu açın ve Laravel uygulamanızı dağıtın. Ücretsiz katman gerçekten ücretsizdir - kredi kartı gerektirmez, zaman limiti yoktur, temel özelliklerde yapay kısıtlamalar yoktur.</p>
<p>Deploynix'i, Laravel uygulamalarını dağıtmanın daha iyi bir yolunu istediğimiz için inşa ettik. Bizim de onu isteyeceğinizi düşünüyoruz.</p>
<p>Başlamak için [<a href="http://deploynix.io" target="_blank" rel="noopener noreferrer">deploynix.io</a>](<a href="https://deploynix.io" target="_blank" rel="noopener noreferrer">https://deploynix.io</a>) adresini ziyaret edin.</p>Kaynak: Orijinal Makale
