Nuxt Portföyümü Vercel’den Hetzner’e Taşıdım: Coolify ile Yaşadığım Deneyim

Neden kendi sunucuma geçmeye karar verdim?

Nuxt ile geliştirdiğim kişisel portföy sitem aleynaertin.com’u Vercel’de yayınlıyordum. Kendi sunucuma geçme kararımın arkasında iki hedef vardı: projelerimi tek bir sunucuda toplamak ve sunucu yönetimini öğrenmek.

Uygulama geliştirdikten sonra onu yayına alırken arka planda neler olduğunu da daha iyi anlamak istiyordum. Dağıtım süreci, alan adı ayarları, HTTPS ve yedekleme gibi konularda kendi projem üzerinden deneyim kazanmak, bunun için iyi bir başlangıçtı.

Bu hedeflerle Hetzner üzerinde bir sunucu kurup uygulamalarımı Coolify ile yönetmeye karar verdim. İlk adım olarak portföy sitemi taşıdım. Bu yazıda taşıma sürecini, karşılaştığım sorunları ve öğrendiklerimi paylaşacağım.

Kullandığım yapı ve sunucu seçimi

Sunucu seçerken başlangıç maliyetini düşük tutmak ve kendi projelerim üzerinden deneyim kazanabileceğim bir ortam oluşturmak istedim. Uygun maliyeti ve Almanya’daki sunucu lokasyonu nedeniyle Hetzner’i tercih ettim. Başlangıç için 2 GB RAM’li bir sunucuyla yola çıktım.

Hedefim, projelerimi tek sunucuda toplamanın yanında sunucu yönetimini ve Docker’ı öğrenmekti. Uygulamaların container içinde nasıl çalıştığını, sunucu kaynaklarını nasıl kullandığını ve dağıtım sırasında çıkan sorunlara nasıl müdahale edebileceğimi kendi projelerim üzerinden anlamak istiyordum. İleride küçük müşteri sitelerini de aynı yapı üzerinde barındırabilmek, bu tercihin bir diğer nedeniydi.

Kurduğum yapıda araçların görevleri şöyleydi:

- Nuxt: Kişisel portföy sitemi geliştirdiğim framework.

- Hetzner: Uygulamamın çalıştığı bulut sunucusu.

- Docker: Uygulamayı ve ihtiyaç duyduğu çalışma ortamını container içinde çalıştıran teknoloji.

- Coolify: Docker tabanlı uygulamalarımı ve dağıtım sürecini bir arayüz üzerinden yönetmemi sağlayan araç.

- GitHub: Kaynak kodumu tuttuğum ve Coolify üzerinden dağıtıma bağladığım platform.

Bu yapı sayesinde uygulamalarımı Coolify arayüzünden yönetirken arka plandaki Docker ve sunucu süreçlerini de adım adım öğrenebileceğim bir ortam oluşturdum. İlk uygulama olarak kişisel portföy sitem aleynaertin.com’u taşıyarak başladım.

İlk dağıtım ve karşılaştığım sorunlar

İlk adım olarak portföy sitemin GitHub reposunu Coolify’a bağladım ve dağıtım için `main` branch’ini seçtim. Ardından Nuxt uygulamasının build komutunu `npm run build`, çalıştırma komutunu ise `node .output/server/index.mjs` olarak ayarladım. Uygulamanın kullanacağı portu da `3000` olarak belirledim.

İlk dağıtım denemeleri sorunsuz ilerlemedi. Build kayıtlarını incelerken Node.js sürümü ve bağımlılıklarla ilgili hatalarla karşılaştım. Bu süreç, geliştirme ortamımda çalışan bir projenin sunucuda da aynı şekilde çalışabilmesi için çalışma ortamının doğru hazırlanması gerektiğini gösterdi.

Bu aşamayı geçtikten sonra build sırasında başka bir hata ortaya çıktı: `JavaScript heap out of memory`. Derleme işlemi, Node.js’in kullanabildiği heap belleğinin sınırına ulaşıyordu.

Sunucunun kaynaklarını kontrol ettiğimde yaklaşık 2 GB RAM ve mevcut 2 GB swap alanı olduğunu gördüm. Böylece fiziksel RAM, swap ve Node.js’in bellek sınırının ayrı ayrı değerlendirilmesi gerektiğini öğrenmeye başladım.

Bellek hatasının ardından Coolify’da şu ortam değişkenini tanımladım:

NODE_OPTIONS=--max-old-space-size=1536

Bu ayarla Node.js’in old-space bellek sınırını 1536 MB olarak belirledim. Değişkeni yalnızca build sırasında kullanılacak şekilde ayarladım; çalışan uygulamanın runtime ortamına eklemedim. Bu, sunucunun RAM’ini artırmak yerine derleme sürecindeki Node.js bellek sınırını düzenleyen bir değişiklikti.

Bu deneyim, sunucu yönetimini öğrenme hedefimin ilk somut adımlarından biri oldu. Coolify üzerinden dağıtımı başlatmanın yanında, hata kayıtlarını okuyup hangi aşamada sorun yaşandığını anlamam da gerekiyordu.

Alan adını yönlendirme ve HTTPS

Dağıtımın ardından sıra, aleynaertin.com alan adını yeni sunucuya yönlendirmeye geldi. DNS kayıtlarımı Cloudflare üzerinden yönetiyordum. Ana alan adının A kaydını Hetzner sunucumun IP adresine yönlendirdim. `www` için de ana alan adını işaret eden bir CNAME kaydı kullandım.

Bu aşamada yalnızca siteyi tarayıcıda açıp kontrol etmekle kalmadım. `dig` komutuyla hem `aleynaertin.com` hem de `www.aleynaertin.com` adreslerinin yeni sunucuya çözümlendiğini kontrol ettim. Böylece DNS tarafındaki değişikliğin sonucunu görebildim.

Ardından HTTPS erişimini kontrol ettim. `curl -I` ile yaptığım kontrollerde iki adres de `HTTP/2 200` yanıtı verdi. Yanıt başlıklarında Nuxt bilgisini de görmek, uygulamanın alan adı üzerinden erişilebilir olduğunu doğrulamama yardımcı oldu. Tarayıcıda ise `www` adresinin ana alan adına yönlendiğini kontrol ettim.

Bu süreçte dağıtım, DNS ve HTTPS’nin ayrı ayrı kontrol edilmesi gereken adımlar olduğunu öğrendim. Uygulamanın sunucuda çalışması ilk aşamaydı; ziyaretçilerin doğru alan adı üzerinden güvenli şekilde erişebilmesiyle taşımanın bu kısmı tamamlandı.

StudioAE için veritabanı yedekleme

Portföy sitemin taşıma işleminin ardından, studioae.com.tr projemde kullandığım Directus’un veritabanı yedeklerini düzenledim. Bu, aleynaertin.com’un dağıtımından ayrı olarak yaptığım bir çalışmaydı.

Coolify üzerinden Directus’un PostgreSQL veritabanı için günlük otomatik yedeklemeyi etkinleştirdim. Yedekleme saatini Türkiye saatiyle 05.00 olarak ayarladım. İlk yedeği kontrol ettiğimde yaklaşık 427 KB büyüklüğünde bir dosyanın oluştuğunu ve “Local Available” durumunda olduğunu gördüm. Bu, yedeğin sunucuya kaydedildiğini gösteriyordu.

Yedeklerin yalnızca uygulamanın çalıştığı sunucuda kalmasını istemedim. Sunucuya erişimi kaybedersem yedeklere başka bir yerden ulaşabilmek için Cloudflare R2’yi Coolify’a harici yedekleme alanı olarak bağladım ve veritabanı yedeklerini buraya da gönderdim.

Eski yedeklerin sürekli birikmesini önlemek için iki ayrı saklama süresi belirledim:

- Sunucuda, Coolify’ın yönettiği yerel yedekler: 7 gün.

- Sunucu dışında, Cloudflare R2’deki yedekler: 30 gün.

Böylece yakın tarihli yedekleri sunucuda tutarken daha uzun bir yedek geçmişini R2’de saklayabileceğim bir düzen oluşturdum.

Bu yedekleme PostgreSQL veritabanını kapsıyordu. Directus’a yüklenen görseller ve diğer dosyalar için ayrıca dosya yedeklemesi gerekiyordu. Geri yükleme testini ise henüz yapmadım; bir sonraki adımım, aldığım yedeği ayrı bir ortamda geri yükleyerek kullanılabilir olduğunu doğrulamak.

Bu süreçte öğrendiklerim ve sonraki adımlar

Başlamadan önce sunucuya taşıma işlemi gözümü korkutuyordu. Uygulamanın çalışması, Docker, DNS ayarları ve HTTPS gibi konuları bir arada düşününce süreç karmaşık görünüyordu. Ancak adımları tek tek ele alıp karşılaştığım hataları inceledikçe, düşündüğüm kadar göz korkutucu olmadığını gördüm.

Projelerimi aynı sunucuda toplamak da yönetim açısından rahatlık sağladı. Coolify üzerinden uygulamalarımı, dağıtım durumlarını ve hata kayıtlarını aynı yerden takip edebilmek, kurmak istediğim düzenin somut bir karşılığı oldu.

Bu süreçte benim için en önemli konulardan biri yedeklemeydi. Bir uygulamayı yayına almak kadar, bir sorun yaşandığında verilerini nasıl geri getireceğini düşünmek de gerekiyordu. Yedekleri sunucunun dışında da tutmak ve saklama sürelerini belirlemek, veri kaybına karşı hazırlıklı olmanın bir parçasıydı.

Henüz tamamlamadığım adımlar da var. Veritabanı yedeğini ayrı bir ortamda geri yükleyerek test etmek, Directus’a yüklenen dosyalar için yedekleme düzeni oluşturmak ve Render’daki Strapi uygulamamı taşımak sıradaki işlerim.

Portföy sitemi taşımak, sunucu yönetimini ve Docker’ı kendi projem üzerinden öğrenmek için iyi bir başlangıç oldu. Her şeyi tek seferde öğrenmem gerekmediğini; küçük adımlarla ilerleyip her adımın sonucunu kontrol ederek bu yapıyı yönetebileceğimi gördüm.