GitHub Pages Ücretsiz mi? Kurulum, Sınırlar ve Domain
Geçen ay bir arkadaşım aradı. “Ya Aşkın, ben şu portfolyo sitemi yayınlamak istiyorum ama hosting fiyatları ne öyle?” dedi. Ona GitHub Pages’i anlattım — 20 dakikada sitesi yayındaydı. Üstelik tek kuruş ödemeden. O gün dedim ki bu konuyu mutlaka yazmalıyım, çünkü hâlâ çok sayıda geliştirici bu özellikten bihaber geziyor.
- Browse all workflows‘a tıklayın
- Arama kutusuna “next.js” yazın (bu kritik)
- Çıkan Next.js workflow’ünün yanındaki Configure butonuna basın
- Workflow dosyasını inceleyin — genelde varsayılan ayarlar yeterli oluyor
- Commit changes butonuna basın
- Main branch’e commit yapıldığından emin olun ve onaylayın (bu kritik)
Commit yaptıktan sonra Actions sekmesine gidin, workflow’un tamamlanmasını bekleyin. Yeşil tık görünce — tebrikler, siteniz canlı.
Workflow Dosyası Neye Benziyor?
Vallahi, Merak edenler için tipik bir GitHub Pages workflow dosyasının iskeletini göstereyim:
name: Deploy Next.js to GitHub Pages
on:
push:
branches: ["main"]
workflow_dispatch:
permissions:
contents: read
pages: write
id-token: write
jobs:
build:
runs-on: ubuntu-latest
steps:
— name: Checkout
uses: actions/checkout@v4
— name: Setup Node
uses: actions/setup-node@v4
with:
node-version: "20"
— name: Install dependencies
run: npm ci
— name: Build
run: npm run build
— name: Upload artifact
uses: actions/upload-pages-artifact@v3
with:
path:./out
deploy:
runs-on: ubuntu-latest
needs: build
environment:
name: github-pages
url: ${{ steps.deployment.outputs.page_url }}
steps:
— name: Deploy to GitHub Pages
id: deployment
uses: actions/deploy-pages@v4
Bu dosyada dikkat edilmesi gereken birkaç nokta var. permissions kısmında pages: write ve id-token: write yetkilerinin verilmesi şart — bunları eksik bırakırsanız deploy başarısız oluyor. Hata mesajı da pek açıklayıcı olmuyor bu arada. Bunu deneyimlerimden söylüyorum: 2024 başında bir kere 40 dakika bu yüzden hata aradım. Sınır bozucu.
İki Yöntemin Karşılaştırması
Hangisini ne zaman kullanmalısınız? Şöyle bir tablo hazırladım:
| Kriter | Branch’ten Deploy | GitHub Actions |
|---|---|---|
| Kurulum kolaylığı | Çok kolay, 2 dakika | Orta, workflow bilgisi gerek |
| Build adımı desteği | Yok (sadece Jekyll) | Var, her framework desteklenir |
| Özelleştirme | Sınırlı | Tam kontrol |
| En uygun senaryo | Basit HTML/CSS/JS siteleri | Next.js, Hugo, Gatsby vb. |
| Hata ayıklama | Kolay (dosya var mı yok mu) | Actions loglarından takip |
Küçük bir startup için hızlıca landing page yayınlıyorsanız — branch yöntemi gayet yeterli, valla yeter. Ama enterprise seviyede bir dokümantasyon portalı ya da sürekli güncellenen bir site kuruyorsanız, GitHub Actions bana kalırsa daha mantıklı. Hem her push’ta otomatik deploy oluyor, hem build sürecini istediğiniz gibi şekillendirebiliyorsunuz. Ciddi fark var ikisi arasında.
Custom Domain ve HTTPS Ayarları
Ha bu arada önemli bir detay daha var. GitHub Pages varsayılan olarak kullaniciadi.github.io altında yayınlıyor. Kendi domain’ınızı de bağlayabilirsiniz (evet, doğru duydunuz). Bunun için Settings > Pages sayfasında “Custom domain” alanına domain adresinizi yazın. Sonra DNS sağlayıcınızda bir CNAME kaydı oluşturup kullaniciadi.github.io‘ya yönlendirin (ki bu çoğu kişinin gözünden kaçıyor). GitHub otomatik olarak Let’s Encrypt üzerinden SSL sertifikası sağlıyor. Ücretsiz.
Garip gelecek ama, Bu kısım beni açıkçası etkilemişti ilk keşfettiğimde —. SSL sertifikası derdi hosting’in en can sıkıcı parçalarından biriydi eskiden. “Enforce HTTPS” seçeneğini de mutlaka aktif edin. 2025’te HTTP üzerinden site yayınlamak (ciddiyim) — hmm, nasıl desem, pek hoş karşılanmıyor. — SEO açısından da güvenlik açısından da.
Sınırlamalar ve Dikkat Edilmesi Gerekenler
Şöyle söyleyeyim, Her şey güllük gülistanlık değil tabi. Açık konuşayım: GitHub Pages’in de eksikleri var ve bunları bilmek önemli.
Hani, Öncelikle repository boyutu için önerilen sınır 1 GB (ben de ilk duyduğumda şaşırmıştım). Site boyutu da (söylemesi ayıp) 1 GB’ı geçmemeli, aylık 100 GB bant genişliği sınırı var. Kişisel bir blog veya portfolyo için bunlar sorun olmaz ama yüksek trafikli bir site düşünüyorsanız — bu iş için uygun değil, başka bir çözüme bakmanız gerekiyor.
Bir de şu var. Özel (private) repository’lerden de Pages yayınlayabilirsiniz ama site kendisi her zaman public oluyor — yanı kodunuz private olsa bile sitenize herkes erişebilir (ben de ilk duyduğumda şaşırmıştım). Bu bazı kurumsal senaryolarda sorun olabiliyor (yanlış duymadınız). Logosoft’ta bir finans müşterimiz tam bu noktada “olmaz” demişti (ilk duyduğumda inanamadım). Haklıydı da, hassas içerik varsa dikkatli olmak lazım, tabiî ki.
Bakın, garip gelecek ama, Dinamik içerik yok. Sunucu tarafı işlem yok. Form gönderimi için Formspree veya Netlify Forms gibi üçüncü parti servislere ihtiyacınız var. Bu konuda beklediğim kadar esnek değil açıkçası. Ama statik site generator’lar artık o kadar gelişti ki çoğu ihtiyacı karşılıyorlar — bu biraz teselli edici.
Copilot entegrasyonu konusunda da bir şey söyleyeyim — workflow dosyası oluştururken commit mesajını Copilot’a yazdırabiliyorsunuz. Küçük ama hoş bir detay. Bu konuda GitHub Copilot CLI Nedir ve Nasıl Kurulur: İlk Adımlar yazımıza da göz atmanızı öneririm.
Pratik İpuçları ve Sahadan Notlar
Açıkçası, Yıllar içinde öğrendiğim birkaç şeyi paylaşayım. Kısa tutacağım.
Yanı, 404 sayfası oluşturun. Repository’nizin kök dizinine 404.html adında bir dosya koyun — GitHub Pages bunu otomatik olarak hata sayfası yapıyor (ki bu çoğu kişinin gözünden kaçıyor). Kullanıcı deneyimi açısından fark yaratıyor, küçücük bir dokunuş ama değer (evet, doğru duydunuz)
İlginç olan şu ki, Jekyll kullanmayacaksanız boş bir .nojekyll dosyası ekleyin. GitHub Pages varsayılan olarak Jekyll işleminden geçiriyor dosyaları. Alt çizgiyle başlayan klasörleriniz varsa — mesela _next — bu sorun yaratır. Boş bir .nojekyll dosyası bunu devre dışı bırakıyor. Bunu öğrenmek bana bir projede yaklaşık 2 saat mal olmuştu; 2021’de bir Next.js projesinde sayfalar düzgün yüklenmiyordu, sorun buymuş. Sız ne dersiniz? Neyse, sız aynı hatayı yapmayın.
Şunu söyleyeyim, Branch yönteminde /docs klasörünü kullanabilirsiniz. Root yerine /docs klasörünü kaynak olarak seçebilirsiniz — proje kodunuz ile site dosyalarınızı ayrı tutmanın güzel bir yolu bu.
Sıkça Sorulan Sorular
GitHub Pages tamamen ücretsiz mi?
Evet, kişisel hesaplar dahil tüm GitHub hesapları için ücretsiz (buna dikkat edin). Aylık 100 GB bant genişliği ve 1 GB site boyutu sınırı var ama çoğu proje için bu fazlasıyla yeterli. Custom domain bağlamak da ekstra ücret gerektirmiyor (yanlış duymadınız)
GitHub Pages’te dinamik bir uygulama (PHP, Python) çalıştırabilir mıyım?
Hayır, GitHub Pages sadece statik dosyaları (HTML, CSS, JavaScript) destekliyor. Bir bakıma, sunucu tarafı işlem yapamıyorsunuz. Dinamik bir uygulama istiyorsanız Azure App Service, Heroku veya Vercel gibi platformlara bakmanız gerekir.
Kendi domain adımı GitHub Pages’e nasıl bağlarım?
Settings > Pages’te “Custom domain” alanına domain adresinizi girin. DNS sağlayıcınızda bir CNAME kaydı oluşturup kullaniciadi.github.io‘ya yönlendirin. GitHub birkaç dakika içinde SSL sertifikasını otomatik sağlıyor. Daha açık söyleyeyim, “Enforce HTTPS” seçeneğini de aktif etmeyi unutmayın.
GitHub Pages sitemi private yapabilir mıyım?
Repository’niz private olsa bile GitHub Pages sitesi her zaman herkese açık yayınlanıyor (inanın bana). Eğer erişim kısıtlaması istiyorsanız GitHub Enterprise Cloud planında “access control” özelliği var. Bu ücretsiz planlarda mevcut değil.
Deploy ettikten sonra site neden görünmüyor?
İlk deploy’dan sonra birkaç dakika bekleyin — propagasyon süresi olabiliyor. Hâlâ görünmüyorsa Actions sekmesinden workflow loglarını kontrol edin. En sık karşılaşılan sorun .nojekyll dosyasının eksikliği veya yanlış branch seçimi oluyor.
Kaynaklar ve İleri Okuma
GitHub Pages Resmî Dokümantasyonu
GitHub Blog: Getting Started with GitHub Pages
Tuhaf ama, GitHub Actions ile Deploy Etme Kılavuzu
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
2 comments