Odoo ve ERPNext İçin VPS Hosting Rehberi: CPU, RAM, Worker ve Reverse Proxy Ayarları

Odoo ve ERPNext İçin Doğru VPS Altyapısının Önemi

Odoo veya ERPNext ile kurumsal süreçlerinizi dijitalleştirirken, uygulamanın kendisi kadar önemli bir konu da arka plandaki VPS altyapısıdır. ERP ve CRM sistemleri; satış, stok, muhasebe, üretim, insan kaynakları gibi işlevleri tek bir yerde toplar ve çoğu zaman günün her saati aktif kullanıcı trafiği alır. Bu da CPU, RAM, disk ve ağ kaynaklarının rastgele değil, planlı şekilde tasarlanmasını zorunlu kılar.

Özellikle Odoo ve ERPNext gibi Python tabanlı, veritabanı ağırlıklı uygulamalarda yanlış seçilmiş bir VPS; yavaş açılan formlar, zaman aşımına düşen raporlar ve boşa giden çalışan zamanı olarak geri döner. Buna karşılık, iyi planlanmış bir VPS mimarisi; doğru CPU/RAM dengesi, makul worker sayıları ve sağlam bir reverse proxy ile yıllarca sessiz sedasız ve stabil çalışabilir.

DCHost olarak sahada gördüğümüz en büyük sorun, ERP geçişlerinde uygulama tarafına çok odaklanılıp altyapının son dakikaya bırakılması. Bu rehberde tam da bunu tersine çeviriyoruz: Odoo ve ERPNext için VPS seçerken hangi kaynaklara ihtiyaç duyduğunuzu, worker sayılarını nasıl hesaplayabileceğinizi ve Nginx reverse proxy ile üretim ortamını nasıl sağlamlaştırabileceğinizi adım adım netleştiriyoruz.

Eğer genel çerçeveyi de görmek isterseniz, bu yazıyı okuduktan sonra Odoo ve ERPNext için genel VPS hosting rehberimizi de incelemeniz faydalı olacaktır.

CPU, RAM ve Disk Kaynaklarını Planlamak

Odoo ve ERPNext için VPS seçerken ilk sorular neredeyse hep aynıdır: Kaç CPU, ne kadar RAM, ne kadar disk? Bu soruların tek bir sihirli cevabı yok; ama belli kullanıcı profilleri için oldukça isabetli aralıklar önermek mümkün.

Kaynak türlerini doğru okumak

Önce hangi kaynağın neye etki ettiğini netleştirelim:

• vCPU: Formların açılış hızı, raporların çalışması, import/export ve arka plan işler büyük ölçüde CPU gücüne bakar. Worker sayınızla doğrudan ilişkilidir.
• RAM: Odoo/ERPNext worker süreçleri, PostgreSQL veya MariaDB/PostgreSQL veritabanı ve Redis gibi servisler belleği paylaşır. Fazla worker açıp RAM’i yetiremeyince swap’e düşen sistem, kullanıcı deneyimini ciddi şekilde bozar.
• Disk (NVMe/SSD) ve IOPS: ERP uygulamalarında küçük ama sık I/O çoktur. Bu yüzden hızlı disk (tercihen NVMe) ve yeterli IOPS, özellikle raporlar ve toplu işlemlerde ciddi fark yaratır.
• Ağ ve gecikme: Uzak ofisler, VPN üzerinden bağlanan kullanıcılar veya entegrasyon servisleri varsa, network tarafındaki gecikme de hissedilir hale gelir; ancak çoğu senaryoda ana belirleyici CPU ve RAM’dir.

Kullanıcı sayısına göre temel boyutlandırma

Aşağıdaki yaklaşım, DCHost üzerinde gördüğümüz gerçek kurulumlardan süzülmüş pratik bir başlangıç noktasıdır (tek VPS, hem uygulama hem veritabanı aynı makinede):

• 5–15 eşzamanlı kullanıcı (küçük ekip):
  • 2 vCPU
  • 4–8 GB RAM (Odoo için 4 GB altına inmemenizi öneririz)
  • 80–120 GB NVMe disk (loglar ve yedekler için pay bırakın)
• 20–50 eşzamanlı kullanıcı (büyüyen KOBİ):
  • 4 vCPU
  • 8–16 GB RAM
  • 150–250 GB NVMe disk
• 50–150 eşzamanlı kullanıcı (çok departmanlı yapı):
  • 8 vCPU ve üzeri
  • 16–32 GB RAM
  • Uygulama ve veritabanını ayrı VPS’lere ayırmayı düşünmeye başlayın

Buradaki kullanıcı sayıları toplam kullanıcı değil, aynı anda aktif çalışan kullanıcı sayısıdır. Örneğin 80 lisanslı kullanıcı olup günde en fazla 15 kişinin eşzamanlı çalıştığı bir firmada, ilk kategori sizin için yeterli olabilir.

CPU ve worker ilişkisi

Odoo ve ERPNext, Python temelli olduğu için her worker süreci bir CPU çekirdeğini yük altına alır. Genel olarak:

• Toplam worker sayısını, vCPU sayınızın 2–3 katı civarında tutmak makuldür.
• Ancak her worker’ın bellek tüketimi de olduğundan, RAM tarafını mutlaka denkleme katmak gerekir.

Örneğin 4 vCPU ve 8 GB RAM’li bir VPS üzerinde 12–14 Odoo worker açmak teoride mümkün olsa da pratikte RAM yetmeyecek ve swap nedeniyle performans düşecektir. Aşağıda Odoo ve ERPNext için ayrı ayrı detaylı hesaplara gireceğiz.

Disk performansı ve noisy neighbor etkisi

ERP iş yüklerinde disk performansı özellikle raporlama ve toplu veri importlarında kritik hale gelir. DCHost üzerinde NVMe tabanlı VPS’lerde, klasik SATA SSD’lere göre hissedilir bir fark görürsünüz. Ayrıca paylaşımlı altyapılarda sık karşılaşılan noisy neighbor (komşu gürültüsü) problemleri, ERP gibi tutarlı performans gerektiren uygulamalarda daha da can sıkıcıdır.

VPS’inizde zaman zaman CPU steal oranlarının yükseldiğini görüyorsanız, bunun ERP performansına etkisini anlamak için noisy neighbor ve CPU steal sorunlarını tespit etmeye yönelik rehberimizi incelemenizi tavsiye ederiz.

Odoo İçin Worker, Cron ve Uzun Süreli İş Ayarları

Odoo’yu gerçek üretim ortamına alırken, en kritik adımlardan biri worker konfigürasyonudur. Geliştirme modunda (workers = 0) tek proses çalışır; bu mod küçük testler için uygun olsa da gerçek kullanıcı yükü altında dar boğaza girer. Üretimde mutlaka çoklu worker mimarisini kullanmalısınız.

Odoo worker sayısını hesaplamak

Odoo dokümantasyonunda sık geçen pratik formül şudur:

• web workers ≈ 2 × CPU çekirdeği
• cron threads (max_cron_threads) = 1–2

Ancak sahadaki tecrübeye göre sadece CPU değil, RAM’i de denkleme dahil etmek gerekiyor. Ortalama değerlerle konuşursak:

• Basit kurulumlar (az eklenti, az özelleştirme): worker başına 200–300 MB RAM
• Ağır kurulumlar (çok modül, rapor, gelişmiş özelleştirmeler): worker başına 400–500 MB RAM

Üzerine:

• PostgreSQL için en az 1–2 GB RAM
• İşletim sistemi, Nginx, Redis gibi hizmetler için 1–1.5 GB RAM

eklemeniz gerekir.

Örnek hesap: 4 vCPU, 8 GB RAM’li Odoo VPS

Orta seviyede özelleştirilmiş, 20–30 eşzamanlı kullanıcılı bir Odoo kurulumunu düşünelim:

• Toplam RAM: 8 GB
• OS + Nginx + diğer servisler: ~1.5 GB
• PostgreSQL: ~1.5 GB
• Geriye worker’lar için yaklaşık 5 GB kalıyor.

Kurulumunuzun orta ağırlıkta olduğunu varsayalım ve worker başına 350 MB desek:

• 5 GB / 0.35 GB ≈ 14 worker teorik üst sınır gibi görünebilir.
• Pratikte biraz tampon bırakıp 8–10 worker civarında kalmak çok daha güvenli olur.

CPU tarafında 4 vCPU’nuz olduğu için, 8–10 web worker + 1 cron thread iyi bir başlangıç konfigürasyonudur.

Temel odoo.conf örneği

Aşağıdaki örnek, 4 vCPU / 8 GB RAM’li bir VPS üzerinde Odoo 16 için makul bir üretim başlangıç ayarı olabilir:

[options]
; Performans
workers = 9
max_cron_threads = 1
longpolling_port = 8072

; Bellek sınırları (MB cinsinden)
limit_memory_soft = 268435456  ; 256 MB
limit_memory_hard = 536870912  ; 512 MB

; Zaman sınırları (saniye)
limit_time_cpu = 60
limit_time_real = 120

Burada:

• 9 worker: 4 vCPU için 2×CPU + 1 yaklaşımına yakındır.
• max_cron_threads = 1: Küçük ve orta ölçekli kurulumlarda genellikle yeterlidir.
• limit_memory_soft ve hard ile hatalı bir sorgu veya modülün tüm RAM’i yemesini engellersiniz.

İlerleyen dönemde kullanıcı sayısı arttıkça veya RAM yükselttiğinizde; önce RAM’i artırmak, sonra worker sayısını kademeli olarak yükseltmek en sağlıklı yaklaşımdır.

Uzun süren işlemler, import/export ve raporlar

Odoo’da büyük CSV importları, toplu fatura kesimleri veya geniş raporlar hem CPU hem de süre açısından ağır işlerdir. Bu noktada iki şey önemlidir:

• Nginx proxy_read_timeout değerini yeterince yüksek tutmak (örneğin 600 saniye),
• limit_time_cpu ve limit_time_real ayarlarını iş yüküne göre mantıklı seviyelerde belirlemek.

Çok ağır işlemleri mesai dışı saatlere kaydırmak da iyi bir operasyonsal pratiktir. İleride Nginx reverse proxy örneğinde bu timeout ayarlarını detaylandıracağız.

Longpolling ve canlı bildirimler

Canlı sohbet, bildirimler ve canlı durum güncellemeleri için Odoo, longpolling mekanizmasını kullanır. Bu trafiği ana HTTP portundan ayırmak, hem performans hem de hata ayıklama açısından faydalıdır. Genellikle:

• Uygulama portu: 8069
• Longpolling portu: 8072

ve Nginx üzerinde bu iki portu ayrı upstream bloklarıyla tanımlayıp; /longpolling yollarını 8072’ye, geri kalan istekleri 8069’a yönlendirmek iyi bir mimari örüntüdür.

ERPNext İçin Web Worker, Queue ve Scheduler Tasarımı

ERPNext, Frappe framework üzerinde çalışır ve tipik kurulumda aşağıdaki bileşenlerden oluşur:

• gunicorn tabanlı web worker’lar (HTTP istekleri karşılar)
• Redis kuyrukları (default, short, long)
• Queue worker süreçleri (kuyruklardaki işleri tüketir)
• Scheduler (zamanlanmış görevleri tetikler)

Bu mimari, iyi ayarlandığında hem esnek hem de ölçeklenebilirdir; ancak yanlış konfigürasyon, bekleyen kuyruklar ve zaman aşımı alan arayüz çağrıları olarak kullanıcıya yansır.

Gunicorn web worker sayısını belirlemek

ERPNext’te web tarafı için pratik formül, CPU çekirdeği başına 2–3 worker’dır. Örneğin:

• 2 vCPU için 3–4 web worker
• 4 vCPU için 6–8 web worker

Çok yüksek trafik yoksa 2×CPU ile başlamak, bellek tüketimini daha kontrollü tutmanızı sağlar. Web worker’lar tipik olarak daha kısa ömürlü, kullanıcı arayüzüne yönelik istekleri karşılar; uzun süren işlemlerin büyük kısmı arka plan kuyruklarına devredilir.

Queue worker’lar ve Redis kuyrukları

ERPNext’te üç ana Redis kuyruğu bulunur:

• default: Genel işler, e-posta gönderimleri, bir kısmı iş akışları
• short: Hızlı tamamlanması beklenen küçük işler
• long: Detaylı raporlar ve ağır arka plan görevleri

Her bir kuyruk için en az bir worker süreci çalıştırmanız, kuyrukların tıkanmamasını sağlar. Pratik bir başlangıç:

• default: 2 worker
• short: 1 worker
• long: 1 worker

Toplamda 4 queue worker eder. 4 vCPU / 8 GB RAM’li bir sunucuda, 6 web worker + 4 queue worker + scheduler ile genellikle 20–40 eşzamanlı kullanıcıyı rahatlıkla kaldırabilirsiniz.

Supervisor veya systemd ile süreç yönetimi

ERPNext üretim ortamında, web ve queue worker’ların supervisor veya systemd ile yönetilmesi en yaygın yaklaşımdır. Örneğin supervisor tarafında şu tür program tanımları görebilirsiniz:

[program:erpnext-web]
command=/usr/bin/bench serve --port 8000
numprocs=6

[program:erpnext-default-worker]
command=/usr/bin/bench worker --queue default
numprocs=2

[program:erpnext-short-worker]
command=/usr/bin/bench worker --queue short
numprocs=1

[program:erpnext-long-worker]
command=/usr/bin/bench worker --queue long
numprocs=1

Buradaki numprocs değerleri, az önce bahsettiğimiz web ve queue worker sayılarını temsil eder. Worker sayısını artırmadan önce mutlaka RAM kullanımını izleyip, gerekirse DCHost üzerindeki VPS’inizin RAM’ini bir üst pakete yükseltmek çok daha sağlıklıdır.

Genel olarak arka plan işlerinin ve kuyrukların nasıl yönetileceği konusunda daha geniş bir perspektif için, ERPNext’ten bağımsız olarak VPS üzerinde arka plan işleri ve kuyruk yönetimi rehberimizde anlattığımız desenleri de inceleyebilirsiniz.

Scheduler ve rapor yoğunluğu

ERPNext’te günlük, saatlik veya dakikalık tekrarlayan görevler scheduler üzerinden çalışır. Çok sayıda zamanlanmış rapor, toplu e-posta veya entegrasyon çağrısı tanımlıysa:

• Scheduler’ın CPU kullanımını izleyin,
• Gerekiyorsa scheduler interval’lerini daha seyrek hale getirin,
• Aşırı ağır işleri long kuyruğuna yönlendirip mesai dışına alın.

Bu sayede gündüz mesaisinde çalışanlar form doldururken, geceleri yoğun rapor ve entegrasyon işlerinin sistemi kilitlemesini önleyebilirsiniz.

Reverse Proxy (Nginx) Mimarisi ve Örnek Ayarlar

Odoo ve ERPNext’i doğrudan 8069/8000 portlarından internete açmak teoride mümkün olsa da üretim ortamında tavsiye edilmez. Ön tarafta bir reverse proxy (genelde Nginx) kullanmanın sağladığı avantajlar şunlardır:

• Tek noktadan SSL/TLS yönetimi
• HTTP/2 ve HTTP/3 gibi modern protokolleri etkinleştirebilme
• client_max_body_size, timeout ve buffer ayarlarını merkezi yönetme
• Statik dosyaları (CSS, JS, görseller) doğrudan sunarak uygulama yükünü azaltma
• Gerekirse aynı VPS üzerinde birden fazla ERP örneğini sanal host’larla ayırabilme

Nginx reverse proxy kurulumunun temel mantığını ve küçük projeler için basit load balancer senaryolarını, ERP dışındaki senaryolar için de olsa Nginx reverse proxy kurulum rehberimizde detaylı olarak anlattık. Burada Odoo/ERPNext’e özgü kritik ayarlara odaklanalım.

Temel Nginx server bloğu örneği (Odoo)

Aşağıdaki örnek, odoo.example.com alan adı üzerinden çalışan bir Odoo 16 için tipik bir Nginx konfigürasyonudur:

upstream odoo_web {
    server 127.0.0.1:8069;
}

upstream odoo_longpolling {
    server 127.0.0.1:8072;
}

server {
    listen 80;
    server_name odoo.example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    server_name odoo.example.com;

    # <a href="https://www.dchost.com/tr/ssl">SSL sertifikası</a> ve güvenlik ayarları burada

    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header X-Forwarded-Host  $host;
    proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;

    client_max_body_size 50m;
    proxy_read_timeout   600s;

    location /longpolling {
        proxy_pass http://odoo_longpolling;
    }

    location / {
        proxy_pass http://odoo_web;
    }
}

Burada dikkat etmeniz gereken ana noktalar:

• proxy_read_timeout 600s: Büyük raporlar veya import işlemlerinin zaman aşımına düşmemesi için 10 dakika gibi rahat bir süre.
• client_max_body_size 50m: Kullanıcıların yükleyeceği dosya boyutlarına göre bu değeri ayarlamalısınız.
• Uzun süreli bağlantılar için longpolling yolunu ayrı upstream’e yönlendirmek, chat ve canlı bildirimleri daha stabil hale getirir.

ERPNext için reverse proxy ve statik dosyalar

ERPNext’te bench komutları ile oluşturulan site yapısında, statik dosyalar genellikle public yollar altında tutulur. Nginx ile bu dizinleri ayrı location bloklarında doğrudan sunmak, Python tarafındaki yükü azaltır. Örneğin:

location /assets/ {
    root /opt/bench/sites;
    try_files $uri =404;
}

location /files/ {
    root /opt/bench/sites;
    try_files $uri =404;
}

location / {
    proxy_pass http://127.0.0.1:8000;
    proxy_read_timeout 600s;
}

Burada assets ve files dizinleri doğrudan Nginx tarafından sunulduğu için, özellikle çok sayıda kullanıcıya hizmet veren kurulumlarda CPU yükü belirgin biçimde azalır.

Keepalive, HTTP/2 ve sıkıştırma

ERP arayüzleri birçok JS ve CSS dosyası yükler. Bu nedenle:

• HTTP/2 kullanmak, çok sayıda eşzamanlı isteği tek bağlantıda toplamanıza yardım eder.
• gzip veya brotli sıkıştırma ile network trafiğini azaltabilirsiniz.
• keepalive ayarlarını mantıklı seviyede tutmak, her istek için yeni TCP bağlantısı açılmasını engeller.

Bunlar sadece ERP için değil, tüm web uygulamaları için iyi pratiklerdir; detaylarını farklı senaryolarla birlikte diğer makalelerimizde ele alıyoruz.

Güvenlik, Yedekleme ve İzleme: Üretim Ortamını Tamamlamak

CPU, RAM ve worker ayarlarını doğru yapmak ne kadar önemliyse; güvenlik, yedek ve izleme de en az o kadar kritik. ERP verisi, çoğu işletme için en hassas veri setlerinden biridir. Bu yüzden Odoo ve ERPNext VPS’inizi sadece performans açısından değil, bütünsel olarak tasarlamanız gerekir.

Temel VPS güvenlik sertleştirmesi

DCHost üzerindeki bir Linux VPS’te Odoo veya ERPNext kurarken, en azından şu adımları atmanızı öneririz:

• SSH için parola girişini kapatıp sadece anahtar ile erişim kullanın.
• sshd_config içinde root ile doğrudan girişi kapatın.
• UFW, firewalld veya benzeri bir güvenlik duvarı ile sadece gerekli portları (80/443, yönetim için 22 vb.) açın.
• fail2ban ile SSH brute force girişimlerine karşı koruma ekleyin.
• Veritabanı portlarını (PostgreSQL vb.) dış dünyaya tamamen kapatın, sadece localhost veya VPN üzerinden erişime izin verin.

Bu başlıkların her birini adım adım uygulamak için VPS güvenlik sertleştirme kontrol listesi rehberimizden yararlanabilirsiniz.

Yedekleme stratejisi: Veritabanı + dosya sistemi

Odoo ve ERPNext’te yedekler sadece veritabanından ibaret değildir. Odoo için filestore dizini, ERPNext için de site klasörleri içindeki dosyalar (ekler, yüklenen belgeler) en az veritabanı kadar kritiktir. Sağlam bir strateji için:

• Günlük veritabanı yedeği (PostgreSQL dump veya benzeri araçlarla)
• Günlük veya saatlik filestore/site dosya yedeği
• Yedeklerin düzenli olarak DCHost altyapısı dışında ikinci bir lokasyona da kopyalanması
• Periyodik geri yükleme testleri (restore denemeden yedek var sayılmaz)

Yedek sıklığını ve ne kadar geriye gidebilmek istediğinizi netleştirmek için, iş tarafında RPO ve RTO kavramlarının konuşulması çok faydalıdır. Bu konuda yol çizmek isterseniz, KOBİ’ler için RPO/RTO ve felaket kurtarma planı rehberimizi okumanızı tavsiye ederiz.

İzleme ve erken uyarı sistemleri

ERP sunucunuzun ne zaman zorlandığını, RAM’in ne zaman dolduğunu, disk alanının ne kadar kaldığını bilmezseniz; genellikle ilk uyarıyı kullanıcılar verir. Bu noktaya gelmeden önce:

• CPU, RAM, disk ve ağ kullanımını izleyen bir ajan kurun.
• PostgreSQL bağlantı sayısı, sorgu süreleri gibi metrikleri takip edin.
• Odoo/ERPNext loglarında hata patlaması olduğunda alarm üretecek mekanizmalar kurun.

VPS tarafında temel metrikleri nasıl takip edebileceğinizi ve hangi araçlarla görselleştirebileceğinizi, VPS kaynak kullanımı izleme rehberimizde somut örneklerle ele aldık. ERP sunucularında bu tür bir izleme, özellikle kapasite artışı gereksinimini önceden görmenizi sağlar.

Sonuç: Odoo ve ERPNext İçin Sağlam Bir VPS Mimarisi Nasıl Kurulur?

Odoo veya ERPNext için doğru VPS mimarisini kurmak, tek seferlik bir donanım seçimi değil; kapasite planlama, worker konfigürasyonu, reverse proxy ayarları ve operasyonel süreçleri birlikte düşünmeyi gerektiriyor. CPU ve RAM’i gerçek eşzamanlı kullanıcı sayısına göre boyutlayıp, Odoo ve ERPNext worker’larını bu kaynaklara uygun sayıda belirlemek; hem performans hem de maliyet tarafında sizi dengede tutar.

Ön tarafta Nginx reverse proxy ile SSL, timeout ve statik dosya sunumunu merkezi bir noktadan yönetmek; geri tarafta veritabanı ve dosya yedeklerini düzenli ve test edilmiş bir plana oturtmak, ERP projenizi uzun vadede sorunsuz taşımanın en güvenli yolu. Üzerine temel VPS güvenlik sertleştirmesi ve makul bir izleme/alarmlama katmanı koyduğunuzda, sisteminiz yıllarca istikrarlı şekilde hizmet verebilir.

DCHost olarak Odoo ve ERPNext projeleri için gerek NVMe tabanlı Linux VPS’ler, gerekse daha büyük kurulumlar için dedicated sunucu ve colocation altyapıları sunuyoruz. Mevcut veya planladığınız ERP yükünü, kullanıcı sayısını ve büyüme hedeflerinizi bizimle paylaşırsanız; CPU, RAM, worker ve reverse proxy ayarlarını da kapsayan uçtan uca bir mimari taslağını birlikte çıkarabiliriz. İhtiyacınız basit bir tek VPS kurulumu da olsa, çok şubeli ve yüksek erişilebilir bir mimari de olsa; ilk adımı doğru atmak, uzun vadede hem performans hem de maliyet açısından fark yaratacaktır.