Şunu fark ettim: Linux sunucuyla yeterince haşır neşir olduysanız, şu sahneyi muhtemelen yaşamışsınızdır: Bir tarafta PHP kuyruk işçisi koşuyor, öte tarafta Go ile yazılmış minicik bir API var, arka planda da Python’la çalışan bir bot… Hepsi ayakta gibi görünüyor ama aslında herkes kendi başına takılmış durumda. İşin kötü yani şu: biri tökezlediği an ortalık hemen karışıyor. Ben bu tabloyu ilk kez 2019’da İzmir’deki küçük bir ajansın VPS’inde gördüm; sabaha karşı “neden RAM doldu?” diye bakarken suçlu, adı bile unutulmuş bir Discord botuydu. Klasik.
İşte PQPM tam da bu dağınıklığa göz kırpan bir araç. “Herkes kendi prosesini yönetsin ama kimse başkasının alanına girmesin” fikriyle geliyor. Kulağa basit geliyor, evet. Ama pratikte baya işe yarayan tarafı şu: dil bağımsız çalışıyor —. Node.js dünyasına sıkışıp kalmıyorsun; PHP de olur, Go da olur, Python da olur, Rust da olur… hatta istersen saat başı çalan saçma bir bash script bile olur, kimse sormaz.
Neden böyle bir araca ihtiyaç var?
Lafı gevelemeden söyleyeyim: tek kullanıcıyla çalışan tertemiz makinelerde süreç yönetmek kolaydır. Ama iş paylaşımlı sunucuya ya da küçük ekiplerin ortak kullandığı VPS’lere gelince tablo değişiyor. Herkesin elinde nohup, screen, bazen de tmux var. Bunlar kötü araçlar değil; yıllardır hayat kurtarıyorlar zaten. Fakat ölçek büyüyünce aynı reçete biraz yamuluyor — kaçınılmaz olarak.
Benzer derdi geçen sene Ankara’daki bir müşteri projesinde de yaşadım. Üç farklı ekip aynı fiziksel sunucuyu kullanıyordu: biri Laravel queue worker çalıştırıyor, biri Go servis ayakta tutuyor, diğeri ise Python tabanlı veri çekme işi yapıyordu. Herkes “benim servis düştü” diye bana yazınca anladım ki mesele yalnızca prosesi başlatmak değil — onu güvenli biçimde, sınırlar belirli şekilde ayakta tutmak.
Çok konuştum, örnekle göstereyim.
PQPM’in burada hedeflediği şey de tam bu zaten. Root’a yalvarmadan kullanıcıların kendi süreçlerini yönetebilmesi ve bunun sınırlarının net olması. Mantıklı değil mi? Hani evde herkesin ayrı anahtarı olsun ama kimse komşunun kapısını açamasın gibi düşünün.
PQPM nasıl çalışıyor?
Yani, Sistemin omurgasında iki parça var gibi düşünebilirsiniz: daemon tarafı ve istemci tarafı. Daemon olan pqpmd, Linux üzerinde servis olarak duruyor ve Unix socket üzerinden gelen istekleri dinliyor. Kullanıcı ise CLI aracı olan pqpm ile komut veriyor. Bu kadar. Gerçekten bu kadar.
Bence, Beni en çok çeken detaylardan biri şu oldu: daemon root olarak başlıyor. Sonra işi yapan kişinin UID/GID bilgisine göre yetkileri indiriyor. Bu yaklaşım hoş çünkü “her şeyi root yapalım bitsin” kafasının tam tersi. Biraz sert gelebilir ama açık konuşayım — root yetkisini gereksiz yere etrafa saçmak çoğu zaman ileride ufak felaketler doğuruyor, bu konuda deneyimim var.
Bunu biraz açayım.
Kernel seviyesinde soket kimlik doğrulaması için SO_PEERCRED kullanılması da hoşuma gitti doğrusu. Çünkü burada olay sadece CLI’dan gelen isteğe güvenmek değil; isteğin gerçekten o kullanıcıdan geldiğini sistem düzeyinde doğrulamak. Güvenlik tarafında işte bu tip ayrıntılar fark yaratıyor — büyük laflar değil, küçük kararlar (bizzat test ettim)
Mimarinin kaba taslağı
# Basitleştirilmiş zihinsel model
Kullanıcı
└── pqpm start my-worker
└── Unix socket üzerinden pqpmd'ye bağlanır
└── SO_PEERCRED ile kullanıcı doğrulanır
└── Proses ilgili UID/GID altında başlatılır
└── Kaynak limitleri uygulanır| Bileşen | Görev | Neden önemli? |
|---|---|---|
pqpmd |
Daemon olarak çalışır | Tüm kontrol tek yerde toplanır |
pqpm |
Kullanıcı komut satırı aracı | Sudo olmadan kullanım sağlar |
.pqpm.toml |
Kullanıcı yapılandırmau | Sade ve okunabilir yapı verir |
TOML neden burada iyi duruyor?
Ne yalan söyleyeyim, Bence bu hikayenin gizli yıldızı TOML olabilir mi? Hmm, biraz abartılı söyledim belki ama haksız sayılmam da. YAML çoğu zaman insanı yoruyor; boşluk mu eksik kaldı, iki nokta üst üste mi kaydı… uğraştırıyor işte, sinir bozucu şekilde uğraştırıyor. JSON ise makine için rahat ama insan gözüne bazen soğuk geliyor, özellikle uzun konfigürasyon dosyalarında. TOML ise daha dengeli duruyor; hizmet tanımı gibi düz yapılarda gayet temiz okunuyor, en azından benim gözüme öyle görünüyor. Ajanlar Artık İş Yapıyor: API Kullanan Görev Motoru yazımızda bu konuya da değinmiştik.
Editör masasında bu örneği ilk gördüğümde aklıma direkt şu geldi: “Bu dosyayı beş dakika içinde ben de düzenlerim.” Bence araç tasarımında bu his çok kıymetli — gerçekten çok. 2024’ün Kasım ayında İstanbul’da yaptığım kısa testte de aynı şeyi yaşadım; config’e bakınca neyin nerede olduğu hemen anlaşılıyor, insan orada boğulmuyor.
Küçük startup için ayrı, enterprise için ayrı anlamı var mı?
- Küçük startup: Tek VPS üstünde birkaç servis koşuyorsa PQPM ciddi rahatlık sağlar.
- Büyüyen ekip: Kullanıcı bazlı izolasyon sayesinde operasyon yükü azalır.
- Kurumsal ortam: Burada eksik kalan kısım entegrasyon derinliği olabilir; yani mevcut orkestrasyon araçlarıyla ne kadar iyi konuşacağı önemli hale gelir.
- Melez senaryo: Bazı işler Kubernetes’e taşınmışken bazı yan servisler hala klasik Linux üzerinde kalabiliyor — işte tam orada PQPM tarzı çözümler hoş durur. — bunu es geçmeyin
Peki artıları nerede toparlanıyor?
Bana göre en güçlü taraf üçlü paket halinde geliyor: dil bağımsızlık, düşük sürtünme ve kullanıcı izolasyonu. Bu üçü birleşince özellikle paylaşımlı Linux sunucularında hayat kolaylaşıyor — fark edilir biçimde kolaylaşıyor. Mesela PHP artisan queue worker ile Go binary’nin aynı mantıkla yönetilmesi küçük görünen ama pratikte bayağı fark yaratan bir şey. Bir araç düşünün ki sizden önce “hangi dilde yazıldı?” diye sormasın… Bu konuyla ilgili Dyson’ın El Fanı Hamlesi: HushJet Mini Cool Ne Vadediyor? yazımıza da göz atmanızı tavsiye ederim. Daha fazla bilgi için Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımıza bakabilirsiniz.
Ama tabii her şey güllük gülistanlık değil. Benim ufak hayal kırıklığım şurada oldu diyeyim: böyle araçlarda genelde insanlar ilk anda bir UI bekliyor ya da merkezi panel görmek istiyor (buna dikkat edin). PQPM daha çok terminal — kendi adıma konuşayım — kafasında ilerleyen teknik kitleye sesleniyor. Bu kötü mü? Hayır. Ama pazarlama açısından biraz ham kalıyor şu an; biraz daha pişerse daha geniş kitleye yayılır gibi duruyor. Samsung Galaxy S25 Ultra’da Okyanus Modu: Neye Yarıyor? yazımızda bu konuya da değinmiştik.
PQPM’in asıl vaadi şudur: Sunucuya girip “hangi proses kimin” diye dedektifçilik yapmak yerine işleri önceden kurallara bağlamak!
Nerede zorlanabilir?
Neyse uzatmayayım… böyle sistemlerde ilk soru hep aynıdır: “Peki hata ayıklama nasıl olacak?” Çünkü prosesi ayağa kaldırmak başka şeydir, log’u anlamak başka şeydir, restart döngüsüne girince müdahale etmek bambaşka bir şeydir — bunlar gerçekten farklı problemler. Eğer izleme katmanı zayıfsa araç kağıt üstünde çok şık görünür ama pratikte can sıkmaya başlar. Bakın şimdi kritik nokta tam burada yatıyor (ben de ilk duyduğumda şaşırmıştım)
Eğer tek makinede çalışan birkaç servisiniz varsa PQPM bayağı yeterli olabilir. Ama yüzlerce konteynerlik mimariyi yönetiyorsanız zaten oyun alanınız değişmiş demektir. Orada systemd mi gerekir, Docker mı gerekir, yoksa doğrudan Kubernetes mi gerekir — bunu dürüstçe tartmak lazım. Her soruna yeni oyuncak almak çözüm değil; bazen doğru oyuncağı seçmek yeterli, o kadar.
Düşük seviyeli kontrol sevenlere iyi gelir mi?
Evet, özellikle sysadmin tadında çalışanlara iyi gelebilir bu. Ama terminalden uzak duran — kendi adıma konuşayım — ekipler için öğrenme eğrisi yine de var — o eğri çok dik değil gibi dursa da var sonuçta. İşletim sistemi mantığını az çok bilen biri hızla alışır; hiç bilmeyen kişi ise önce birkaç duvara çarpabilir, bu kaçınılmaz. PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımızda bu konuya da değinmiştik.
Bende bıraktığı his ne oldu?
Açıkçası böyle projeleri seviyorum çünkü gerçek hayattaki acıya dokunuyorlar. Teoride herkes modern orkestrasyon çözümlerinden bahsediyor; pratikteyse bazen tek istediğiniz şey şudur: “Şu PHP worker düşmesin, Go servisi yeniden başlasın, Python bot gece RAM’i yemesin.” Hepsi bu. Bu kadar basit aslında.
PQPM bana biraz eski usul Unix ruhunu hatırlattı: küçük parça, net görev, sade davranış… Gereksiz süs yok, gösterişli dashboard yok, abartılı bulut lafazanlığı yok. Bazen insan tam da buna ihtiyaç duyuyor; özellikle küçük ekiplerde. Kirlenmiş VPS düzenlerinde bu his çok tanıdık geliyor.
Araya gireyim: Ha bu arada, 2025’te eski mimari kararları anlatan yazılarda sıkça söylediğimiz şey burada da geçerli: her sorun için devasa platform kurmak zorunda değilsiniz. Siz hiç denediniz mi? 2025’te Eskiyen Mimari Kararları: 4 Sessiz Tuzak
Daha geniş resimde nereye oturuyor?
Aslında, PQPM’i ben en çok şu çizgide anlamlı buldum: Kubernetes öncesi dünyaya dönmek değil, aksine her şeyi konteynere taşımadan önce sağlamlaştırılmış ara katman sağlamak. Hele bir de paylaşımlı hosting geçmişi olan ekiplerde tanıdık gelecek bir sorunu çözüyor bu — inkar edemezsiniz, hepimiz o dönemi yaşadık. Bir de şu var: tamamen Node.js odaklı olmayan dünyalarda PM2 benzeri alışkanlıkların karşılığını vermeye çalışıyor.
Geçtiğimiz yıl Mart ayında Berlin’de birlikte çalıştığım küçük SaaS ekibi buna benzer şekilde sistemi sadeleştirmişti; önce üç farklı cron işi vardı, sonra bunları kontrollü proses yöneticisine taşıdılar. Operasyon çağrıları gözle görülür biçimde azaldı. Sihir değil tabii. Mesele disiplin.
Bir noktada şu bağlantıyı kurdum: bu tarz projeler aslında geliştiriciden çok operasyona kafa yoran insanlara sesleniyor. Cybersecurity Bitmiyor, Şekil Değiştiriyor: Asıl Hikaye
Sıkça Sorulan Sorular
PQPM hangi dilleri destekliyor?
Teknik olarak dili umursamadan çalışan uzun ömürlü süreçleri hedefliyor diyebiliriz.
PHP, Go ve Python örnekleri özellikle öne çıkıyor ama mantık bunlarla sınırlı değil.
PQPM systemd yerine geçer mi?
No tamamen yerine geçmesi gerekmiyor.
Daha dar kapsamda, kullanıcı bazlı süreç yönetimi için alternatif olarak düşünülebilir.
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.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
