VPS Üzerinde Docker ile ERPNext Kurulumu ve Yönetimi

Çalıştırmak için üstlendiğiniz sorumluluk

ERPNext uygulamasını bir VPS üzerinde kendi sunucunuzda barındırmak (self-hosting), tek komutla kurulumdan ziyade operasyonel bir süreçtir. Resmi Docker Compose yığını on bir adet container içerir ve genel muhasebe kayıtlarınız ile müşteri verilerinizi barındırır. Bu durum, aşağıda belirtilen her şey için standartları yükseltir: bir yedek, geri yüklemesi test edilmediği sürece yedek sayılmaz; sürümü sabitlenmemiş (unpinned) bir image etiketi ise her an gerçekleşebilecek bir şema migrasyonu riskidir.

Kılavuz boyunca birkaç isim öne çıkmaktadır. ERPNext iş uygulamasıdır. Frappe, onun altındaki Python çatısıdır. Bench, siteleri yöneten ve container'ların içinde halihazırda kurulu olan komut satırı aracıdır. Bir site, tek bir kiracıyı ifade eder: bir MariaDB veritabanı ve bir adet yüklenmiş dosyalar dizini. Buradaki neredeyse her komut, belirli bir site üzerinde bench aracılığıyla backend container'ı içerisinde çalıştırılır.

Bu kılavuz, projenin bizzat sürdürdüğü dağıtım olan frappe_docker deposunu kullanır. Aşağıdaki her komut, Ağustos 2026 itibarıyla bu depo üzerinde doğrulanmıştır. Eğer Docker Compose sizin için yeniyse, VPS üzerinde Docker Compose çalıştırma bölümü, bu kılavuzun temel aldığı ön bilgileri kapsamaktadır.

ERPNext ne kadar VPS kaynağına ihtiyaç duyar?

[
  {
    "label": "Evaluation",
    "vcpu": 2,
    "ram_gb": 4,
    "disk_gb": 40
  },
  {
    "label": "Small production",
    "vcpu": 4,
    "ram_gb": 8,
    "disk_gb": 100
  },
  {
    "label": "Room to grow",
    "vcpu": 4,
    "ram_gb": 16,
    "disk_gb": 160
  }
]

Yayınlanan kılavuzlar, tek bir kullanıcı sisteme giriş yapmadan önce 2 vCPU ve 4 GB RAM gereksinimini temel alır. Bu, değerlendirme seviyesidir. Bunlar başlangıç noktalarıdır, bu kılavuzdan alınan ölçümler değildir; gerçek ihtiyaç miktarı kendi belge hacminize göre belirlenir. Son satır yayınlanmış bir minimum değer değildir. Bu, bellek konusunun artık bir sorun olmaktan çıktığı yaklaşık seviyedir.

Küçük planlar konusunda kendinize karşı dürüst olun. 1 GB veya 2 GB kapasiteli bir VPS, yığını başlatır ancak ilk içe aktarma işleminde veya ilk uzun raporda çöker; çünkü dokuz adet uzun süreli çalışan container, MariaDB tampon havuzu ve rapor oluşturan bir Python işçisi bu belleğe sığmaz. Hata zarif bir şekilde gerçekleşmez. Çekirdeğin bellek yetersizliği öldürücüsü (OOM killer) bir container'ı durdurur ve üzerindeki docker inspect komutu, "OOMKilled": true çıktısını ve 137 çıkış kodunu gösterir. İşin ortasında öldürülen bir işçi, gönderilen bir belgeyi arka plan işlemleri yarım kalmış halde bırakır.

ERPNext'i her gün kullanan bir şirket için 8 GB RAM, 4 vCPU ve 100 GB SSD dürüst bir alt sınırdır. RAM ilk tükenen kaynaktır. Disk alanı, insanların beklediğinden daha hızlı dolar; çünkü her ek dosya ve her yerel yedekleme, veritabanı ile aynı birime kaydedilir.

On bir container ve her birinin işlevi

Stack ayağa kalktıktan ve dokuz container çalışır duruma geldikten sonra docker compose ps komutunu çalıştırın. configurator ve create-site adlı iki container daha görevlerini bir kez yapıp sonlanır; toplam on bir sayısına bu şekilde ulaşılır.

• backend, Frappe uygulamasını gunicorn altında çalıştırır. bench burada bulunur.
• frontend, nginx servisidir. Statik dosyaları sunar ve diğer tüm istekleri arka uca iletir.
• queue-short ve queue-long, RQ (Redis Queue) worker'larıdır. Giden e-postalar, içe aktarma işlemleri ve rapor oluşturma gibi arka plan görevlerini yürütürler.
• scheduler, zamanlanmış raporlar ve otomatik tekrarlanan belgeler dahil olmak üzere zamana dayalı görevleri tetikler.
• websocket, tarayıcıdaki canlı güncellemelerin arkasındaki socket.io sürecidir.
• db, MariaDB veritabanıdır.
• redis-cache ve redis-queue, biri önbellek diğeri ise görev kuyruğu için kullanılan iki ayrı Redis örneğidir.

Bu ayrımı öğrenmek önemlidir, çünkü hangi log dosyasını incelemeniz gerektiğini belirler. Takılan bir e-posta kuyruk worker'ı ile ilgili bir sorundur, bu yüzden doğru komut docker compose logs -f queue-short'tir. Yüklenen ancak bildirim rozetini güncellemeyen bir sayfa ise websocket ile ilgili bir sorundur. Her iki durum için de backend loglarını okumak zaman kaybına yol açar.

Demo yerine üretim compose dosyalarıyla kurulum yapın

Depo pwd.yml ile birlikte gelir ve README dosyası bu konuda nettir: "Bu kurulum yalnızca kısa süreli değerlendirme amaçlıdır. Bu kuruluma özel uygulamalar yükleyemezsiniz." Bunu ERPNext’i bir öğleden sonra incelemek için kullanın. Bir şirketi bunun üzerinde çalıştırmayın.

sudo apt update && sudo apt install -y git
curl -fsSL https://get.docker.com | bash
git clone https://github.com/frappe/frappe_docker
cd frappe_docker
mkdir -p ~/gitops
cp example.env ~/gitops/erpnext.env

~/gitops/erpnext.env dosyasını açın ve dört değeri değiştirin. ERPNEXT_VERSION, image etiketini sabitler. DB_PASSWORD, örnek dosyada 123 olarak gelir. SITES_RULE, Traefik yönlendirme kuralıdır ve LETSENCRYPT_EMAIL sertifika uyarılarını alır.

ERPNEXT_VERSION=v16.32.1
DB_PASSWORD=<a long random password>
SITES_RULE=Host(`erp.example.com`)
LETSENCRYPT_EMAIL=ops@example.com

Şimdi tek bir compose dosyası oluşturun ve ardından başlatın.

docker compose --project-name erpnext \
  --env-file ~/gitops/erpnext.env \
  -f compose.yaml \
  -f overrides/compose.mariadb.yaml \
  -f overrides/compose.redis.yaml \
  -f overrides/compose.https.yaml \
  config > ~/gitops/erpnext.yaml

docker compose --project-name erpnext -f ~/gitops/erpnext.yaml up -d

config hiçbir şeyi başlatmaz. Temel dosyayı geçersiz kılma (override) dosyalarıyla birleştirir ve tüm değişkenlerin yerine değerlerini koyarak sonucu yazdırır. Daha sonra bu oluşturulan dosyayı çalıştırırsınız. Bu fazladan adımın sağladığı fayda şudur: çalışan yığın, okuyabileceğiniz ve commit edebileceğiniz tek bir dosyadır; böylece birisi env dosyasını düzenlediğinde veya depoyu güncellediğinizde (pull) sizin bilginiz dışında değişemez. birden fazla Docker Compose dosyasının nasıl birleştiği konusu, geçersiz kılma kurallarını ayrıntılı olarak açıklar.

db servisinin başlamasını ve configurator servisinin çıkış yapmasını bekleyin; bu işlem birkaç saniye sürer, ardından siteyi oluşturun.

docker compose --project-name erpnext exec backend \
  bench new-site --mariadb-user-host-login-scope=% \
  --db-root-password '<your DB_PASSWORD>' \
  --install-app erpnext \
  --admin-password '<a strong admin password>' \
  erp.example.com

Kontrol edin:

docker compose --project-name erpnext ps
docker compose --project-name erpnext exec backend bench --site erp.example.com list-apps

list-apps, frappe ve erpnext sürümlerini yazdırmalıdır. Sağlıklı bir ps, dokuz servisi running durumunda ve hiçbirini restarting durumunda göstermemelidir.

Burada genellikle iki şey ters gider. --mariadb-user-host-login-scope=%, Docker altında isteğe bağlı değildir. Uygulama container'ı, MariaDB'ye Docker ağı üzerinden ulaşır; bu nedenle uzak bir ana makine (host) olarak gelir ve localhost ile sınırlandırılmış bir veritabanı kullanıcısı oradan giriş yapamaz. Site oluşturma işlemi, root kullanıcısını belirten bir MariaDB erişim reddedildi hatasıyla başarısız olur. % kapsamı, yeni sitenin kullanıcısına o özel ağdaki herhangi bir ana makineden erişim izni verir.

İkincisi ise site adıdır. Frontend, varsayılan olarak HTTP Host başlığından hangi siteye hizmet vereceğini seçer; bu nedenle erpnext olarak oluşturulan bir siteye, her ikisi de mevcut olsa bile erp.example.com üzerinden ulaşılamaz. Siteyi yukarıdaki gibi alan adıyla adlandırın veya env dosyasındaki FRAPPE_SITE_NAME_HEADER değerini site adına ayarlayıp compose dosyasını yeniden oluşturun.

HTTPS ve çalışması için gereken ön koşullar

compose.https.yaml geçersiz kılma işlemi, Traefik'i 443 numaralı portta çalıştırır, 80 numaralı portu buraya yönlendirir ve Let's Encrypt üzerinden sertifika talep eder. TLS (transport layer security), fatura ve oturum çerezlerinin ağ üzerinde düz metin olarak görünmesini engelleyen teknolojidir.

Sertifikanın düzenlenebilmesi için iki koşulun sağlanması gerekir. erp.example.com için tanımlanan DNS A kaydı, halihazırda VPS'i işaret etmelidir. 80 ve 443 numaralı portlar internetten erişilebilir olmalıdır; çünkü Let's Encrypt, alan adı üzerindeki kontrolünüzü 80 numaralı port üzerinden gerçekleştirilen HTTP-01 sınaması ile doğrular. Sunucu üzerindeki güvenlik duvarının yanı sıra servis sağlayıcınızın ağ güvenlik duvarını da kontrol edin. Bunlar birbirinden bağımsız denetim mekanizmalarıdır ve genellikle panel üzerindeki güvenlik duvarı gözden kaçırılır.

Sertifikalar, cert-data birimi içerisinde /letsencrypt/acme.json dizinine kaydedilir. Tarayıcı sizin sertifikanız yerine varsayılan bir sertifika gösteriyorsa, docker compose --project-name erpnext ps içerisinden proxy servis adını bulun ve ACME (automatic certificate management environment) hatalarını görmek için günlük kayıtlarını inceleyin. Aynı sunucuda başka web uygulamaları mı çalıştırıyorsunuz? birden fazla Docker Compose uygulamasının önünde tek bir Traefik örneği kullanmak, 443 numaralı port için çakışma yaşamadan proxy paylaşımının nasıl yapılacağını açıklar.

Giden e-posta veya faturaların sunucudan çıkmaması

Bu adım, çoğu ERPNext kılavuzunun atladığı ve sistemin kullanışlı olup olmayacağını belirleyen kısımdır. Giden e-posta servisi çalışmıyorsa müşteriye hiçbir fatura ulaşmaz, şifre sıfırlama e-postaları gelmez ve zamanlanmış raporlar iletilemez. Yığın içerisinde bir posta sunucusu bulunmaz.

E-postaları doğrudan VPS üzerinden 25 numaralı porttan göndermeye çalışmayın. Çoğu sağlayıcı yeni hesaplarda 25 numaralı giden portunu engeller; dışarı çıkanlar ise yeni bir VPS adresinin gönderim itibarı olmadığı için reddedilir veya spam olarak işaretlenir. 587 numaralı port üzerinden kimlik doğrulamalı bir aktarıcı (relay) kullanın.

Desteklenen yöntem, şifreyi şifreli olarak saklayan ERPNext arayüzündeki Email Account ekranıdır. Anahtarları site yapılandırma dosyasına da yazabilirsiniz:

docker compose --project-name erpnext exec backend \
  bench --site erp.example.com set-config mail_server smtp.example.com

docker compose --project-name erpnext exec backend \
  bench --site erp.example.com set-config mail_port 587 --parse

docker compose --project-name erpnext exec backend \
  bench --site erp.example.com set-config use_tls 1 --parse

docker compose --project-name erpnext exec backend \
  bench --site erp.example.com set-config mail_login 'erp@example.com'

docker compose --project-name erpnext exec backend \
  bench --site erp.example.com set-config auto_email_id 'erp@example.com'

--parse, 587 değerini "587" dizgesi yerine sayı olarak saklar. Dosyayı tekrar okuyun ve bu iki değerin etrafında tırnak işareti olmadığını doğrulayın:

docker compose --project-name erpnext exec backend \
  cat sites/erp.example.com/site_config.json

mail_password ayarını komut satırı yerine Email Account ekranı üzerinden yapın; böylece şifreli olarak saklanır ve hiçbir zaman shell geçmişinize girmez.

Ardından gerçek bir ileti gönderin. Bir Sales Invoice oluşturun, kontrol ettiğiniz bir adrese e-posta ile gönderin ve bu sırada kuyruğu izleyin:

docker compose --project-name erpnext logs -f queue-short

Giden e-posta bir arka plan işidir; bu nedenle ulaşmayan bir ileti genellikle tarayıcıda bir hata olarak değil, ilgili günlük kaydında başarısız bir iş olarak görünür. Gönderen alan adı için SPF (sender policy framework) ve DKIM (domainkeys identified mail) kayıtlarını yayınlayın, ardından bir DMARC politikası ekleyin. Bunlar olmadan teknik olarak doğru bir fatura bile müşterinin spam klasörüne düşer. Tüm süreci kendiniz yönetmek isterseniz, kendi barındırdığınız bir Mailcow posta sunucusu, ERP'den ayrı bir makinede kontrol edebileceğiniz bir aktarıcı sağlar.

Gerçekten geri yüklenebilir yedekler

Tek başına bir veritabanı dökümü, ERPNext için bir yedekleme sayılmaz. Ekler ve özel dosyalar MariaDB içinde değil, sites dizininde bulunur. Yalnızca veritabanını geri yüklerseniz, yüklenmiş tüm satın alma siparişleri bozuk bağlantı olarak geri döner.

docker compose --project-name erpnext exec backend \
  bench --site erp.example.com backup --with-files

Bu komut, sites birimi içindeki sites/erp.example.com/private/backups dizinine dört dosya yazar:

• bir -database.sql.gz dökümü
• genel dosyaların -files.tar arşivi
• özel dosyaların -private-files.tar arşivi
• site yapılandırmasının -site_config_backup.json bir kopyası

Dördüncü dosya, insanların genellikle göz ardı ettiği ancak eksikliği en çok sorun yaratan dosyadır. Bu dosya, Frappe'nin saklanan parolaları (e-posta hesabı kimlik bilgileri, ödeme geçidi anahtarları ve tüm entegrasyon sırları) şifrelemek için kullandığı anahtar olan encryption_key değerini tutar. Veritabanını eşleşen anahtar olmadan geri yüklerseniz site normal şekilde açılır, ancak e-posta gönderimi şu hata ile başarısız olur:

frappe.exceptions.ValidationError: Encryption key is invalid! Please check site_config.json

Dört dosyayı her zaman bir arada tutun.

Ardından bu dosyaları sunucudan dışarı çıkarın. Birim içindeki bir yedekleme, sunucu arızasında hayatta kalamaz; ayrıca bench zaten bu dizini temizler: varsayılan olarak 24 saatten eski yedekleri bu dizinden siler.

docker compose --project-name erpnext cp \
  backend:/home/frappe/frappe-bench/sites/erp.example.com/private/backups \
  ~/erpnext-backups

Bunu cron üzerinden çalıştırın ve ardından dizini yönetmediğiniz bir yere gönderin. sunucu dışı depolama alanına şifreli restic yedekleri bunun için doğru araçtır; çünkü veriyi yüklemeden önce şifreler ve restic check ile deponun hala okunabilir olduğunu doğrular. Bir ERP yedeği, tüm muhasebe kayıtlarınızın bir kopyasıdır; bu nedenle bu donanımdan farklı bir donanımda, şifrelenmiş halde saklanmalıdır.

Geri yükleme işlemini ihtiyaç duymadan önce test edin

Test edilmemiş bir yedekleme, sadece bir tahmindir. Yedeklemeyi canlı sistem üzerinde değil, aynı sunucu üzerindeki ikinci bir alanda test edin.

docker compose --project-name erpnext exec backend \
  bench new-site --mariadb-user-host-login-scope=% \
  --db-root-password '<your DB_PASSWORD>' \
  --admin-password '<a strong admin password>' \
  restore-test.example.com

docker compose --project-name erpnext exec backend \
  bench --site restore-test.example.com --force restore \
  sites/erp.example.com/private/backups/<stamp>-erp.example.com-database.sql.gz \
  --with-public-files sites/erp.example.com/private/backups/<stamp>-erp.example.com-files.tar \
  --with-private-files sites/erp.example.com/private/backups/<stamp>-erp.example.com-private-files.tar \
  --db-root-password '<your DB_PASSWORD>'

Şifreleme anahtarını yedeklenmiş yapılandırmadan alıp geri yüklenen siteye kopyalayın; aksi takdirde entegrasyonlar çalışmayacaktır:

docker compose --project-name erpnext exec backend \
  bench --site restore-test.example.com set-config encryption_key '<value from site_config_backup.json>'

Şimdi geri yükleme işlemini bir muhasebeci titizliğiyle kontrol edin. Alacak Hesapları raporunu açın ve kapanış bakiyesini canlı sitedekiyle karşılaştırın. Yakın tarihli bir satın alma faturasını açın ve ekini indirin. Sadece giriş sayfasının görüntülenmesi, sistemin çalıştığını kanıtlamaz.

İşleminiz bittiğinde test sitesini kaldırın:

docker compose --project-name erpnext exec backend \
  bench drop-site restore-test.example.com

ERPNext için sürüm sabitlemenin önemi

Statik bir sitede sabitlenmemiş bir imaj etiketi sürpriz bir yeniden başlatma anlamına gelir. ERPNext tarafında ise bu, bir şema migrasyonu demektir. bench migrate veritabanı tablolarını yeniden yazar ve belge verilerini değiştirebilir; bunun bir geri alma işlemi yoktur. Geri dönüş, bir docker compose down ile değil, yedekten geri yükleme ile yapılır.

Bu nedenle etiketi sabitleyin. ERPNEXT_VERSION=v16.32.1, Ağustos 2026 itibarıyla deponun kendi pwd.yml dosyasında sabitlenmiş sürümdü. Bu numarayı kontrol etmeden bir sonraki sürüme taşımayın. Güncel sürümler frappe/erpnext releases sayfası üzerinde listelenir ve mevcut imaj etiketleri Docker Hub üzerinde bulunur. Geçiş yapmadan önce geçeceğiniz sürüme ait notları okuyun.

Yükseltme işleminin kendisi bir yedekleme ve bakım modu ile başlar.

docker compose --project-name erpnext exec backend \
  bench --site erp.example.com backup --with-files

docker compose --project-name erpnext exec backend \
  bench --site erp.example.com set-maintenance-mode on

~/gitops/erpnext.env içindeki ERPNEXT_VERSION dosyasını düzenleyin, ardından render, pull ve migrate işlemlerini gerçekleştirin.

docker compose --project-name erpnext \
  --env-file ~/gitops/erpnext.env \
  -f compose.yaml \
  -f overrides/compose.mariadb.yaml \
  -f overrides/compose.redis.yaml \
  -f overrides/compose.https.yaml \
  config > ~/gitops/erpnext.yaml

docker compose --project-name erpnext -f ~/gitops/erpnext.yaml pull
docker compose --project-name erpnext -f ~/gitops/erpnext.yaml up -d

docker compose --project-name erpnext exec backend \
  bench --site erp.example.com migrate

docker compose --project-name erpnext exec backend \
  bench --site erp.example.com set-maintenance-mode off

Bakım modu önemlidir çünkü migrate çalışırken şemayı değiştirir. Bir kullanıcının yarı migrasyon yapılmış bir tabloya belge göndermesi, kayıtları elle onarmak zorunda kalmanıza neden olur.

Her adım arasında yedek alarak, her seferinde bir ana sürüm olacak şekilde ilerleyin. Bir sürümdeki migrasyon kodu, kendisinden önceki sürümden yükseltme yapacak şekilde yazılmıştır; bu nedenle ana sürümleri atlamak, kimsenin test etmediği bir migrasyon kombinasyonuna yol açar.

Depo ayrıca, her başlatmada bench --site all migrate çalıştıran bir container ekleyen overrides/compose.migrator.yaml dosyasını da sunar. Bu kullanışlıdır. Ancak bu durum, etiketi değiştirilmiş bir docker compose up işleminin, siz izlemiyorken üretim veritabanınızı migrasyona sokması anlamına gelir. Bir iş sisteminde, migrate işlemini o sabah verdiğiniz bir karar doğrultusunda çalıştırın.

Müşteri kayıtlarını barındıran bir sunucunun güvenliğini sağlama

İlk girişte Yönetici parolasını değiştirin. Değerlendirme amaçlı compose dosyası, parola olarak admin değerini kullanır ve bu alışkanlık üretim ortamına da taşınır.

DB_PASSWORD değerini example.env içindeki 123 değerinden farklı bir değerle değiştirin. Bu değer, oluşturulan ~/gitops/erpnext.yaml dosyasında düz metin olarak yer alır; bu nedenle dosyayı chmod 600 ve herhangi bir git deposuna eklemeyin. Daha güçlü bir yöntem için overrides/compose.mariadb-secrets.yaml, parolayı bir ortam değişkeni yerine Docker secret dosyasından okur. Docker Compose'da ortam dosyaları ve secret yönetimi konusu, bu yöntemlerin avantaj ve dezavantajlarını ele alır.

Yalnızca ihtiyacınız olanı dış dünyaya açın. HTTPS geçersiz kılma (override) ile yalnızca 80 ve 443 numaralı portlar dışarıya açılır. Veritabanı istemcisinin bağlantısını kolaylaştırmak için db servisine bir ports eşlemesi eklemeyin; bu işlem MariaDB'yi genel internete açık hale getirir. Bunun yerine docker compose --project-name erpnext exec backend bench mariadb kullanın. Ana makinede 22, 80 ve 443 numaralı portlara izin verin, geri kalanını engelleyin ve ayrıca servis sağlayıcınızın sunduğu ağ güvenlik duvarını da kontrol edin.

Sistem Yöneticisi rolüne sahip her hesap için Sistem Ayarları üzerinden iki faktörlü kimlik doğrulamayı etkinleştirin. Bu rol, her belgeyi okuyabilir ve her tabloyu dışa aktarabilir; bu nedenle bu hesabı bir kolaylık aracı olarak değil, bir yönetici hesabı olarak değerlendirin. Birden fazla self-hosted uygulama çalıştırıyorsanız, her uygulama için ayrı bir parola yerine Self-hosted tek oturum açma sağlayıcısı olarak Authentik kullanımı daha uygundur.

Ana makineyi güncelleyin ve çekirdek (kernel) güncellemeleri için yeniden başlatın. Yığının (stack) yeniden ayağa kalkacağına güvenmeden önce, oluşturulan dosyada her servis için bir restart politikası olup olmadığını kontrol edin; çünkü bu politika olmadan yığın, yeniden başlatma sonrasında kapalı kalır. Docker Compose yığınının yeniden başlatma sonrası otomatik çalışması konusu, systemd tarafındaki yapılandırmayı ele alır.

ERPNext tek bir VPS üzerinde yetersiz kaldığında

Bir VPS, küçük bir şirketin ihtiyaçlarını uzun süre karşılayabilir. Ancak artık yetersiz kaldığını gösteren belirtiler şunlardır:

• Arka plan işleri birikir; bu nedenle e-postalar ve içe aktarma işlemleri dakikalar veya saatler sonra ulaşır.
• docker inspect, "OOMKilled": true veya 137 çıkış koduyla hata veren container'ları raporlar.
• İki saniye süren raporlar otuz saniye sürmeye başlar ve CPU kullanımında MariaDB süreci öne çıkar.
• Yedekleme işlemleri o kadar uzun sürer ki, bir sonraki yedekleme zamanı geldiğinde bir önceki hala devam etmektedir.

İşe, MariaDB'ye paylaşmadığı kaynakları ayırarak başlayın; çünkü veritabanı ve Python işçileri aynı bellek için rekabet eder ve buffer pool, daha fazla bellek talep eden kısımdır. Daha büyük bir uygulama sunucusu, genellikle beklenenden daha az fayda sağlar. Veritabanını Docker içinde veya host üzerinde çalıştırmak bu kararı nasıl uygulayacağınızı açıklar; Docker Compose içinde bellek sınırlarını belirlemek ise siz yapılandırmayı yaparken bir container'ın diğerlerini kaynak açlığına sürüklemesini engeller.

Bunun ardından, web kapasitesini artırmak yerine kuyruk işçilerini (queue workers) çoğaltın. ERPNext'teki yavaşlık genellikle arka plan işlerinden kaynaklanır: rapor oluşturma ve toplu içe aktarma işlemleri. Daha fazla işçi container'ı çalıştırmak, daha büyük bir sunucu kiralamaktan daha düşük maliyetlidir ve kullanıcıların asıl şikayet ettiği sorunları doğrudan çözer.

FAQ

ERPNext bir VPS üzerinde ne kadar RAM'e ihtiyaç duyar?

Yayınlanan kılavuzlar 4 GB RAM ve 2 vCPU ile başlamaktadır; ancak bu seviye yalnızca değerlendirme amaçlıdır. Günlük kullanım yapan bir şirket için 8 GB RAM, 4 vCPU ve 100 GB SSD planlanmalıdır. Bu değerlerin altında, kernel out of memory killer yük altındaki container'ları durdurur; bu durum docker inspect tarafından 137 çıkış kodu ile "OOMKilled": true olarak raporlanır. Bunlar kesin ölçümlerden ziyade başlangıç noktalarıdır; bu nedenle ilk ay boyunca kendi bellek kullanımınızı izleyin.

pwd.yml dosyasını üretim ortamında çalıştırabilir miyim?

Hayır. Projenin README dosyası, bu dosyanın yalnızca kısa süreli değerlendirme amaçlı olduğunu belirtir ve içine özel uygulamalar yükleyemeyeceğinizi vurgular. MariaDB, Redis ve HTTPS geçersiz kılmaları (overrides) ile compose.yaml kullanın, bunları docker compose config ile tek bir dosyada birleştirin ve bu dosyayı çalıştırın.

ERPNext sitemi oluşturduktan hemen sonra neden erişilemez durumda?

Ön uç (frontend), varsayılan olarak hangi sitenin sunulacağını HTTP Host başlığına göre seçer; bu nedenle site adı tarayıcıdaki alan adı ile eşleşmelidir. erpnext olarak oluşturulan bir site, erp.example.com adresinde sunulmaz. Siteyi alan adını kullanarak oluşturun veya env dosyasında FRAPPE_SITE_NAME_HEADER değerini site adına göre ayarlayın, compose dosyasını yeniden oluşturun ve stack'i yeniden başlatın.

Bir ERPNext yedeğinde neler bulunmalıdır?

Birlikte tutulan dört dosya: -database.sql.gz dökümü, -files.tar ve -private-files.tar arşivleri ve -site_config_backup.json yapılandırma kopyası. bench --site erp.example.com backup --with-files komutunu çalıştırmak bu dört dosyayı da oluşturur. Yapılandırma kopyası encryption_key değerini tutar; bu nedenle bu kopya olmadan yapılan bir geri yükleme, kayıtlı entegrasyon parolalarının şifresinin çözülememesine neden olur ve bu durum Encryption key is invalid! Please check site_config.json hatası olarak ortaya çıkar.

Verilerimi bozmadan ERPNext'i nasıl yükseltebilirim?

--with-files ile yedek alın, bakım modunu açın, env dosyanızdaki ERPNEXT_VERSION değerini değiştirin, compose dosyasını yeniden oluşturun, pull işlemini gerçekleştirin, stack'i ayağa kaldırın, ardından bench --site erp.example.com migrate komutunu çalıştırın ve bakım modunu kapatın. Her seferinde bir ana sürüm yükseltin ve önce sürüm notlarını okuyun; çünkü migrate şema ve belge verilerini geri alınamaz şekilde yeniden yazar. Geri dönmek, başlangıçta aldığınız yedeği geri yüklemek anlamına gelir.