Geçenlerde bu blog dahil, kendi yan projelerim için içerik üretme sürecimi otomatikleştirme hayaliyle yola çıktım. Amacım, benim manuel müdahalem olmadan, AI destekli bir içerik pipeline’ı kurmaktı. Yani yazıları oluşturan, düzenleyen, yayınlayan ve hatta SEO optimize eden bir sistem. Bu süreçte karşılaştığım teknik zorluklar, aldığım dersler ve sistemi ayağa kaldırırken edindiğim pratik bilgiler, tam da bir “indie hacker”ın başına gelebilecek cinstendi.
Bu yazıda, bu “kendi kendine çalışan içerik sistemi”ni kurarken adım adım neler yaşadığımı, hangi sorunlarla boğuştuğumu ve bunlara nasıl çözümler bulduğumu anlatacağım. Bir sistem mimarı olarak, bu tür projelerde beklentilerim yüksek olsa da, pratikte işlerin nasıl yürüdüğünü görmek her zaman farklı bir tecrübe oluyor.
Neden Kendi Kendime Çalışan Bir Sistem Kurdum?
Benim hesapciyiz.com, spamkalkani.com ve islistesi.com gibi birden fazla yan ürünüm var. Her birinin düzenli içeriğe ihtiyacı olduğunu biliyorum ama sınırlı zamanım var. Bu durum, sürekli “nasıl daha fazla iş yapabilirim?” sorusunu sormama neden oluyor. İşte tam da bu noktada, içerik üretimini ölçeklendirme ve tutarlılığı artırma ihtiyacı doğdu.
Elle içerik üretmek hem çok zaman alıcı hem de benim gibi tek kişilik bir operasyon için ciddi bir darboğaz. AI teknolojisinin geldiği noktayı görünce, bu yükü otomasyona devretme fikri cazip geldi. Böylece ben daha çok kod yazmaya ve sistemleri optimize etmeye odaklanabilecektim.
Pipeline’ın İlk Adımları ve İlk Hatalar
Sistemin temelini Astro ile kurdum, Node.js ile bazı backend işlerini hallediyorum, veritabanı olarak SQLite kullanıyorum ve Nginx ile yayın yapıyorum. systemd ile servisleri yönetiyor, GitHub Actions ile CI/CD süreçlerini otomatize ediyorum. Cloudflare ise caching ve güvenlik katmanını sağlıyor. Kağıt üzerinde her şey harika görünüyordu.
Ancak, ilk başta her şeyi kendi VPS’ime yığdığımda, performans sorunları hızla kendini gösterdi. Bir gün sabah 06:00’da, Pipeline-health monitor’ümden “DEGRADED” maili aldım. Sunucuya bağlandığımda kcompactd’nin CPU’yu %92’ye vurduğunu gördüm, sshd bile yeni bağlantıları kabul edemiyordu. Sanırım o an sleep 360 yazıp OOM-killed olduğum ve sistemin toparlanmaya çalıştığı zamana denk geldi. Swap’in fışkırdığını, belleğin son damlasına kadar kullanıldığını gözlemledim.
Bu olaydan sonra, bazı ağır iş yüklerini VPS’imden alıp GitHub Actions’a taşımaya karar verdim. Build ve AI çıkarım adımlarını orada çalıştırmak mantıklı gelmişti. Ancak, kısa sürede GitHub Actions’ın ücretsiz kotasını aşmaya başladım. Bu da beni self-hosted runner kullanmaya itti. Kendi VPS’imde GitHub Actions runner kurmak, kotayı delmemenin ekonomik bir yoluydu.
Self-hosted runner kurarken de kendi dertleriyle karşılaştım. Runner state bozuldu defalarca, özellikle _work/_temp içindeki dizinleri manuel olarak silmenin acısını yaşadım. Runner’lar bazen saçmalıyor, işleri almıyor ya da takılı kalıyordu. Bu, bir otomasyon sisteminde güvenilirliğin ne kadar kritik olduğunu gösterdi. Sürekli manuel müdahale gerektiren bir otomasyon, pek de otomasyon sayılmaz.
AI Entegrasyonu ve Beklenmedik “Quirk”ler
İçerik sisteminin kalbinde AI modelleri var. Bu modellerden gelen ham metinleri işleyip, MDX formatına dönüştürüp bloga entegre ediyorum. AI modelleri çoğu zaman harika sonuçlar verse de, bazen beklenmedik “quirk”ler ortaya çıkıyor.
Örneğin, AI’dan gelen çıktıdaki tags alanında slash (/) karakteri kullanması ya da publishDate alanını tırnaklı bir string olarak vermesi gibi. Astro’nun frontmatter parser’ı bu tür girdilerde hata veriyordu. Bir diğer ilginç sorun ise Türkçe i karakteriyle ilgiliydi; bazen düz i yerine farklı bir kodlama kullanılıyordu. Bu küçük detaylar, manuel düzeltme gerektirdi ve otomasyon akışımı kesintiye uğrattı.
# AI çıktısından gelen frontmatter'ı temizleme örneği
import re
def clean_frontmatter(frontmatter_str):
# Tag'lardaki slash'ı virgülle değiştir
frontmatter_str = re.sub(r'tags:\s*\[([^\]]+)\]',
lambda m: "tags: [" + m.group(1).replace('/', ', ') + "]",
frontmatter_str)
# publishDate'i tırnaklardan arındır
frontmatter_str = re.sub(r'publishDate:\s*"(\d{4}-\d{2}-\d{2})"', r'publishDate: \1', frontmatter_str)
# Dotted-i karakter sorununu düzelt (örneğin 'İ' yerine 'İ' gelirse)
frontmatter_str = frontmatter_str.replace('İ', 'İ').replace('i̇', 'i')
return frontmatter_str
# Örnek kullanım
# cleaned_fm = clean_frontmatter(ai_generated_frontmatter)Bu tür sorunlar için AI çıktısını işleyen bir “parser” katmanı geliştirmem gerekti. Bu parser, gelen metni standartlaştıran, hataları düzelten ve MDX uyumlu hale getiren bir dizi kural içeriyor. Bu sayede, AI’dan ne gelirse gelsin, sistemimin beklediği formatta işlenebiliyor. Güvenilirlik için preflight resource guard desenini uyguladım; yani bir işleme başlamadan önce gerekli tüm kaynakların (disk, bellek, API kredisi vb.) uygun olup olmadığını kontrol ediyorum. Ardından, hatalı durumlarda auto-fix mekanizmaları devreye giriyor ve dedup-alert pattern ile aynı hatadan birden fazla uyarı almamın önüne geçiyorum.
Disk Yönetimi ve Docker Deneyimleri
Kendi VPS’imde 13’ten fazla Docker container yönetiyorum. Postgres, Redis, Next.js uygulamaları ve bu blogun parçaları bu container’lar arasında. Eğer içlerinden bir tanesi sevimsiz davranırsa, tüm sistem swap’e iniyor ve performans yerle bir oluyor. Bu da benim için sürekli bir disk ve bellek izleme ihtiyacı anlamına geliyor.
Geçen 28 Nisan’da, sabah uyandığımda diskimin %100 dolu olduğunu gördüm. Root cause, Docker’ın biriken build cache’leri ve kullanılmayan image’larıydı. 33 GB’lık build cache ve 23 GB’lık unused image’lar diskte ciddi bir yer kaplıyordu. Bu durum, docker system prune -a komutunu düzenli olarak çalıştırmanın ne kadar önemli olduğunu bir kez daha hatırlattı. Bu komutu otomatikleştirerek, disk yangını senaryosunun önüne geçtim.
Aynı şekilde, Astro build sürecim de bazen beklenmedik bellek sorunlarına neden oluyordu. 7.6 GB RAM’e sahip bir VPS’te, Astro build’i 2.5 GB RAM yiyerek OOM (Out Of Memory) olabiliyordu. Bu da build pipeline’ımın güvenilirliğini etkiliyordu. Bu tür durumlar için build sürecini daha küçük adımlara bölmek ve kaynak kullanımını optimize etmek gerekti. Örneğin, resim optimizasyonunu ayrı bir adıma çekmek veya paralel işlem limitlerini ayarlamak gibi.
Güvenilirlik ve Cloudflare Stratejileri
Otomasyon, sadece işlerin yürümesi değil, aynı zamanda güvenilir bir şekilde yürümesi demek. Bu yüzden pipeline’ımın her adımında hata kontrolü ve tekrar deneme mekanizmaları kurdum. Bir şey ters giderse, sistemin kendi kendini onarması veya en azından beni doğru bir şekilde uyarması gerekiyor.
Cloudflare, bu sistemde önemli bir rol oynuyor. Blog trafiğini yönetiyor, DDoS koruması sağlıyor ve tabii ki caching yapıyor. Ancak, Astro’nun varsayılan olarak max-age=0 döndürmesi, Cloudflare’ın cache stratejileriyle çakışıyordu. Yani her istekte içeriği tekrar sunucudan istiyordu, bu da performans düşüşüne neden oluyordu. Bu sorunu, Nginx konfigürasyonumda Cache-Control header’ını manuel olarak override ederek çözdüm.
# Nginx ile Cloudflare cache kontrolünü override etme
location / {
# Astro'dan gelen max-age=0'ı ignore et ve kendi cache kurallarını uygula
add_header Cache-Control "public, max-age=3600, stale-while-revalidate=600";
# Diğer Nginx konfigürasyonları...
try_files $uri $uri/ /index.html;
}Bu tür ince ayarlar, otomasyon sistemlerinin sadece koddan ibaret olmadığını, aynı zamanda altyapı ve ağ katmanlarıyla da entegre bir şekilde düşünülmesi gerektiğini gösteriyor. Pipeline’ın her adımını izlemek ve proaktif olarak sorunları tespit etmek için Prometheus ve Grafana gibi araçlarla kendi monitoring sistemimi de kurdum. Bu sayede, “bir şeyler bozuldu” demek yerine, “X servisinde bellek kullanımı %80’in üzerine çıktı” gibi somut verilerle hareket edebiliyorum.
Sonuç
Kendi kendine çalışan bir içerik sistemi kurmak, beklediğimden çok daha fazla teknik detayı ve ince ayarı beraberinde getirdi. Bir “indie hacker” olarak bu süreçte edindiğim tecrübeler, sadece kod yazmakla bitmiyor; aynı zamanda sunucu yönetimi, ağ yapılandırması, otomasyon güvenilirliği ve hata ayıklama gibi geniş bir yelpazede bilgi birikimi gerektiriyor.
Her hatadan bir ders çıkardım ve sistemi adım adım daha sağlam hale getirdim. VPS’in OOM olması, Docker’ın diski doldurması, GitHub Actions runner’ının bozulması ya da AI’ın garip karakterler üretmesi… Bunların hepsi, bir sistemin ancak en zayıf halkası kadar güçlü olduğunu gösteren somut örnekler oldu. Şu sırada bende böyle bir süreç var ve hala optimize etmeye devam ediyorum. Belki bir sonraki yazıda bu sistemin finansal hesaplayıcıları nasıl güncellediğini de anlatırım.