VPS Üzerinde Docker ile ERPNext Kurulumu

Çalıştırmayı taahhüt ettiğiniz sistem

ERPNext uygulamasını bir VPS üzerinde kendi sunucunuzda barındırmak (self-hosting), tek komutla kurulumdan ziyade bir operasyonel yönetim işidir. 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ükleme testi yapılmadığı sürece yedek sayılmaz; sabitlenmemiş bir image etiketi ise gerçekleşmeyi bekleyen 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 adet MariaDB veritabanı ve bir adet yüklenen dosyalar dizini. Buradaki neredeyse her komut, bench içinde, backend container'ı üzerinde, belirli bir site için çalıştırılır.

Bu kılavuz, projenin 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, bir VPS üzerinde Docker Compose çalıştırma başlıklı içerik, bu kılavuzun temel aldığı 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 ile başlamayı önerir. Bu, değerlendirme seviyesidir. Bunlar başlangıç noktalarıdır, bu kılavuzdan elde edilen ölçümler değildir; gerçek ihtiyaç duyulan kaynak miktarı, kendi belge hacminize göre belirlenir. Son satır ise yayınlanmış bir minimum değer değildir. Bu, bellek konusunun artık bir sorun teşkil etmediği seviyeyi kabaca ifade eder.

Küçük planlar konusunda kendinize karşı dürüst olun. 1 GB veya 2 GB RAM'e sahip 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'nin tampon havuzu ve rapor oluşturan bir Python işçisi (worker) bu belleğe sığmaz. Hata, kontrollü 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. İşlem ortasında öldürülen bir işçi, gönderilmiş bir belgeyi arka plan çalışması yarım kalmış şekilde 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ı birim (volume) üzerine yazılır.

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. Diğer iki container olan configurator ve create-site, görevlerini bir kez yapıp sonlanırlar; toplam on bir sayısına bu şekilde ulaşılır.

• backend, Frappe uygulamasını gunicorn altında çalıştırır. bench burada barınır.
• frontend, nginx servisidir. Statik varlıkları sunar ve diğer tüm istekleri arka uca iletir.
• queue-short ve queue-long, RQ (Redis Queue) çalışanları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 faydalıdır, çünkü hangi günlüğün (log) okunması gerektiğini belirler. Takılan bir e-posta kuyruk çalışanıyla ilgili bir sorundur, bu nedenle docker compose logs -f queue-short doğru komuttur. Yüklenen ancak bildirim rozetini güncellemeyen bir sayfa ise bir websocket sorunudur. Her iki durum için de backend günlüklerini okumak zaman kaybına yol açar.

Demo değil, üretim ortamı 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, imaj 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 değerlerini sürümleriyle birlikte 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 kapsamındaki 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. Ön uç (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ına göre 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 ayarı, 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 verilerinin ve oturum çerezlerinin ağ üzerinden düz metin olarak iletilmesini engelleyen mekanizmadır.

Sertifikanın düzenlenebilmesi için iki koşulun sağlanması gerekir. erp.example.com için tanımlanan DNS A kaydı, VPS adresini işaret etmelidir. 80 ve 443 numaralı portlar internete açık olmalıdır; çünkü Let's Encrypt, alan adı üzerindeki kontrolünüzü 80 numaralı port üzerinden HTTP-01 challenge 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 kontrollerdir ve genellikle panel üzerindeki güvenlik duvarı gözden kaçırılır.

Sertifikalar cert-data birimi içerisinde /letsencrypt/acme.json yoluna 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 log 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 rehberi, 443 numaralı port için çakışma yaşamadan proxy'nin nasıl paylaşılacağını gösterir. Bu tür bir sunucuda barındırılan ikinci uygulama genellikle müşteri odaklıdır ve self-hosted Chatwoot destek masası aynı proxy arkasında çalışarak fatura işlemleriyle ilgilenen personelin müşteri e-postalarını ve sohbetlerini tek bir noktadan yönetmesine olanak tanır.

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

Bu adım, çoğu ERPNext kılavuzunun atladığı ve sistemin işlevselliğini belirleyen en kritik aşamadır. Giden e-posta servisi çalışmadığı sürece hiçbir fatura müşteriye ulaşmaz, şifre sıfırlama e-postaları gelmez ve planlanmış raporlar gönderilemez. ERPNext yığını içerisinde bir posta sunucusu bulunmaz.

E-postaları doğrudan VPS üzerinden 25 numaralı portu kullanarak göndermeye çalışmayın. Çoğu sağlayıcı yeni hesaplarda 25 numaralı porttan çıkışı engeller; dışarı çıkmayı başaran e-postalar ise yeni bir VPS IP 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 şifrelenmiş 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" dizgisi yerine sayı olarak saklar. Dosyayı tekrar okuyun ve bu iki değerin etrafında tırnak işareti bulunmadığı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 değer şifrelenmiş 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ünüzdeki 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-postalar arka plan işi olarak yürütülür; 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 yapılandırılmış bir fatura bile müşterinin spam klasörüne düşer. Sürecin tamamını kontrol etmek isterseniz, kendi kendine barındırılan bir Mailcow posta sunucusu, ERP'den ayrı bir sunucuda kontrol edebileceğiniz bir aktarıcı sağlar.

Gerçekten geri yüklenebilen yedekler

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

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 hissedilen dosyadır. Bu dosya, Frappe'nin saklanan parolaları şifrelemek için kullandığı anahtar olan encryption_key değerini tutar: e-posta hesabı kimlik bilgileri, ödeme geçidi anahtarları ve tüm entegrasyon sırları. Eşleşen anahtar olmadan veritabanını 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ından sağ çıkamaz; ayrıca bench zaten bu dosyaları temizler: varsayılan olarak, o dizindeki 24 saatten eski yedekleri siler.

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

Bu işlemi cron üzerinden çalıştırın ve ardından dizini yönetmediğiniz başka bir yere aktarın. sunucu dışı depolama alanına şifreli restic yedekleri bu iş için en 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ş olarak saklanmalıdır.

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

Test edilmemiş bir yedekleme, sadece bir tahmindir. Yedeklemeyi aynı sunucu üzerinde ikinci bir dizine geri yükleyerek test edin; asla canlı sistem üzerinde işlem yapmayın.

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ırma dosyasından kopyalayıp geri yüklenen siteye aktarı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 denetleyin. Alacak Hesapları raporunu açın ve dönem sonu bakiyesini canlı siteyle 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 beklenmedik 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 sürümler sayfasında listelenmiştir; mevcut imaj etiketleri ise Docker Hub üzerinde görülebilir. Geçiş yapmadan önce geçeceğiniz sürüme ait notları okuyun.

Yükseltme işleminin kendisi, 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 yükseltmesi yapın. 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 içerir. Bu kullanışlıdır. Ancak bu durum, etiketi değiştirilmiş bir docker compose up işleminin, siz izlemeden üretim veritabanınızı migrasyona tabi tutması 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 Administrator parolasını değiştirin. Değerlendirme amaçlı compose dosyası, bu 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 edin ve herhangi bir git deposuna eklemeyin. Daha güçlü bir yöntem için, overrides/compose.mariadb-secrets.yaml parolasını bir ortam değişkeni yerine Docker secret dosyasından okur. Docker Compose'da ortam dosyalarını ve secret'ları yönetme 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, MariaDB'yi genel internete açık hale getirir. Bunun yerine docker compose --project-name erpnext exec backend bench mariadb kullanın. Sunucu tarafında 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.

System Manager rolüne sahip her hesap için System Settings üzerinden iki faktörlü kimlik doğrulamayı etkinleştirin. Bu rol her belgeyi okuyabilir ve her tabloyu dışa aktarabilir; bu nedenle bu rolü 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 kullanmak daha iyi bir seçenektir.

Sunucuyu yamalayın ve çekirdek (kernel) güncellemeleri için yeniden başlatın. Stack'in yeniden ayağa kalkacağına güvenmeden önce, her servis için oluşturulan dosyada bir restart politikası olup olmadığını kontrol edin; çünkü bu politika olmadan stack, yeniden başlatma sonrasında kapalı kalır. Docker Compose stack'ini yeniden başlatma sonrası otomatik çalıştırma konusu systemd tarafını ele alır.

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

Tek bir VPS, küçük bir şirketi uzun süre idare edebilir. Artık yetersiz kaldığının işaretleri ş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ış kodu ile konteyner hatalarını raporlar.
• İki saniye süren raporlar otuz saniye sürer ve CPU'yu meşgul eden süreç MariaDB'dir.
• Yedeklemeler o kadar uzun sürer ki, bir sonraki planlanmış yedekleme ile çakışır.

İşe MariaDB'ye paylaşmadığı kaynakları ayırarak başlayın; çünkü veritabanı ve Python işçileri aynı bellek için rekabet eder ve daha fazlasına ihtiyaç duyan kısım buffer pool'dur. Daha büyük bir uygulama sunucusu, insanların beklediğinden daha az fayda sağlar. veritabanını Docker içinde veya ana makinede çalıştırmak bu kararı kapsar ve Docker Compose içinde bellek sınırlarını ayarlamak, siz düzenlemeleri yaparken bir konteynerin diğerlerini aç bırakmasını engeller.

Bundan sonra, web kapasitesinden ziyade kuyruk işçileri (queue workers) ekleyin. ERPNext'in yavaş çalışması arka plan işlerinden kaynaklanır: rapor oluşturma ve toplu içe aktarma işlemleri. Daha fazla işçi konteyneri, daha büyük bir sunucudan daha az maliyetlidir ve kullanıcıların aslında şikayet ettiği sorunu çö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, çekirdeğin "out of memory" (OOM) katili, yük altındaki container'ları durdurur; bu durum docker inspect içerisinde 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çerisine özel uygulamalar yükleyemeyeceğinizi vurgular. MariaDB, Redis ve HTTPS geçersiz kılmaları (override) 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?

Önyüz (frontend), hangi sitenin sunulacağını varsayılan olarak 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 ayarlayın, compose dosyasını yeniden oluşturun ve stack'i yeniden başlatın.

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

Birlikte saklanan 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 üretir. Yapılandırma kopyası encryption_key verisini tutar; bu dosya olmadan yapılan bir geri yükleme, depolanan 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 yapın, 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 şemayı 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.