26 things to check on a self-hosted ERPNext— ERPNext security hardening checklist

Why it matters

Without HTTPS, passwords, session cookies and API secrets cross the network in the clear. An expired certificate does the opposite damage: browsers and webhook senders stop talking to the site until someone notices.

How to check

• From your computercurl -sI http://erp.example.com | head -n 3
• On the serversudo certbot certificates
• On the serversudo crontab -l | grep -i certbot
• From your computernmap --script ssl-enum-ciphers -p 443 erp.example.com

A good result. The first shows a 301 to https://. The second shows an expiry date in the future. The third shows a certbot renew line. The fourth lists TLS 1.2 and 1.3 and nothing older.

The setting or command

ssl_certificate and ssl_certificate_key in site_config.json, written by bench

• On the serverbench config dns_multitenant onbench setup lets-encrypt refuses to run without it.
• On the serversudo -H bench setup lets-encrypt erp.example.comThe domain must already point at the server, with port 80 open.

Where this comes from

• bench: bench/config/templates/nginx.confv5.31.0The nginx file bench writes allows TLS 1.2 and 1.3 only and redirects port 80 to HTTPS.
• bench: bench/config/lets_encrypt.pyv5.31.0bench setup lets-encrypt needs DNS multitenancy and adds a root cron job that runs certbot renew every day.
• bench: bench/commands/config.pyv5.31.0bench config dns_multitenant on|off exists.
• Frappe docs: Let's Encrypt SSL setupsudo -H bench setup lets-encrypt <site>; renewal by a root cron job; bench renew-lets-encrypt.

Why it matters

Bench and the Docker image both send a two-year HSTS header that covers every subdomain and carries the preload flag. After one visit, a browser refuses plain HTTP to your domain and to every subdomain of it. That is the aim. It bites when a subdomain has no certificate.

How to check

• From your computercurl -sI https://erp.example.com | grep -i strict-transport

• List the subdomains of your domain in DNS and open each one over https://.

A good result. The header is there, and every subdomain opens over HTTPS with no warning.

The setting or command

No Frappe setting: the header comes from the nginx file

• To change the header, set your own in the proxy in front of Frappe. bench setup nginx rewrites config/nginx.conf, so edits there are lost.

• Putting the domain on the browsers' preload list (hstspreload.org) is a separate step. Do not take it until every subdomain is on HTTPS for good: removal takes months.

Where this comes from

• bench: bench/config/templates/nginx.confv5.31.0The same file sends HSTS for two years, with includeSubDomains and preload.
• frappe_docker: resources/core/nginx/security_headers.confv4.0.1The Docker image's nginx sends the same HSTS header.
• OWASP: HTTP Strict Transport Security Cheat Sheetmax-age=63072000; includeSubDomains; preload, and the warning that includeSubDomains blocks subdomains served only over HTTP.
• hstspreload.orgSubmission needs a max-age of at least a year, includeSubDomains and preload, and every subdomain on HTTPS; removal is slow.

Why it matters

In bench's own files gunicorn (8000) and Redis (11000, 13000) bind to 127.0.0.1. The real-time service (9000) listens on every interface, and MariaDB (3306) listens wherever its config says. A firewall is what keeps all of them off the internet. In Docker, a published port skips ufw.

How to check

• From your computernmap -Pn -p 22,80,443,3306,6379,8000,9000,11000,13000 erp.example.com
• On the serversudo ss -ltnp

A good result. From outside, only 22, 80 and 443 are open. On the server, anything listening on 0.0.0.0 or :: besides those has a reason you can state.

The setting or command

A firewall, not a Frappe setting

• On the serversudo bench setup firewallDenies everything but 80, 443 and the SSH port: ufw on Ubuntu and Debian, firewalld on CentOS.

• Or close the same ports in your cloud provider's firewall, which sits outside the server and which Docker cannot bypass.

Where this comes from

• bench: bench/playbooks/roles/bench/tasks/setup_firewall.ymlv5.31.0bench setup firewall denies everything except 80, 443 and the SSH port (ufw; firewalld on CentOS).
• bench: bench/commands/setup.pyv5.31.0The command's own prompt says so.
• bench: bench/config/templates/redis_queue.confv5.31.0bench's Redis queue config binds to 127.0.0.1 (the cache config does the same).
• bench: bench/config/templates/supervisor.confv5.31.0gunicorn is started on 127.0.0.1.

Why it matters

MariaDB holds every ledger entry. Frappe gives each site its own database user, with rights on that site's database only and, typically, only from the same machine. The usual breaks: the server listens on the network, or a Docker install keeps the example root password, 123.

How to check

• On the serversudo ss -ltn | grep 3306
• On the serversudo mariadb -e "SELECT user, host FROM mysql.user"
• On the servergrep -c '^DB_PASSWORD=123$' .envDocker installs only, from the folder that holds .env.

A good result. 3306 is on 127.0.0.1, or on a private address if the database has its own machine. No user has host % unless it does. In Docker the count is 0.

The setting or command

bind-address in the MariaDB config; DB_PASSWORD in frappe_docker's .env

• In the MariaDB config set bind-address = 127.0.0.1 and restart MariaDB. The file's name depends on the distribution.

• For a database on another machine, create the site with --mariadb-user-host-login-scope set to that machine's address, not %, and keep 3306 closed to everything else.

• In Docker, set DB_PASSWORD in .env before the first start.

Where this comes from

• MariaDB: configuring for remote client accessbind-address controls which addresses MariaDB listens on; many packages set it to 127.0.0.1.
• frappe/database/mariadb/setup_db.pyv15v16.52.0Each site gets its own MariaDB user, granted rights on its own database only.
• frappe/commands/site.pyv15v16.52.0That user logs in from the local machine unless --mariadb-user-host-login-scope says otherwise.
• frappe_docker: example.envv4.0.1The example environment file sets the MariaDB root password to 123.

Why it matters

Frappe has no allowed-hosts list; we found none in the source. Without host_name, some links are built from the request's Host header. In July 2026 a high-severity advisory (CVE-2026-47194, fixed in v15.108.0 and v16.18.3) showed login links sent to a forged host. Setting host_name pins the address.

How to check

• In the benchbench --site erp.example.com execute frappe.utils.get_url

A good result. It prints your public address, starting https://. Not http://, not a bench port.

The setting or command

host_name in site_config.json

• In the benchbench --site erp.example.com set-config host_name https://erp.example.com

Where this comes from

• frappe/utils/data.pyv15v16.52.0Links are built from host_name when it is set, otherwise from the request's Host header.
• frappe/www/login.pyv15v16.52.0Login links are built without the Host header.
• frappe/core/doctype/user/user.pyv15v16.52.0So are password-reset links.
• frappe/utils/data.pyv15v16.52.0We found no allowed-hosts or trusted-hosts setting anywhere in the Python source.

Why it matters

With allow_cors set to "*", Frappe repeats any Origin back and says credentials are allowed. Frappe's own docs call the wildcard not recommended for production. The session cookie is SameSite=Lax, which limits what a hostile page can do, so this is a setting to remove, not an open door. Most sites need no cross-origin access at all.

How to check

• From your computercurl -sI -H "Origin: https://evil.example" https://erp.example.com/api/method/ping | grep -i access-control
• In the benchbench --site erp.example.com show-config | grep allow_corsshow-config prints every key, passwords included. Always filter it.

A good result. No Access-Control line from the first. No allow_cors line from the second, or only your own origins.

The setting or command

allow_cors in site_config.json

• In the benchbench --site erp.example.com set-config allow_cors NoneRemoves the key.
• In the benchbench --site erp.example.com set-config allow_cors '["https://portal.example.com"]' --parseOr a list of your own origins.

Where this comes from

• frappe/app.pyv15v16.52.0With allow_cors set to *, Frappe repeats the request's Origin and allows credentials.
• frappe/auth.pyv15v16.52.0The session cookie is HttpOnly and SameSite=Lax, and Secure when the request arrived over HTTPS.
• frappe/__init__.pyv15v16.52.0/api/method/ping answers a guest, so it is a safe place to look at response headers.
• frappe/commands/utils.pyv15v16.52.0bench show-config prints every key of the merged config, secrets included.

Why it matters

Frappe can add up the time all requests take and answer 429 to everyone once a window's budget is gone. That caps what a flood can cost the server, but one noisy client can also spend everyone's budget, and it is not a login lock-out. Set too low it blocks your own staff, so watch the headers first. Bench can also cap concurrent connections per site name in nginx.

How to check

• From your computercurl -sI https://erp.example.com/api/method/ping | grep -i x-ratelimit
• In the benchbench --site erp.example.com show-config | grep rate_limit

A good result. Either X-RateLimit headers come back and rate_limit.limit and rate_limit.window are set, or you decided against a budget and can say why.

The setting or command

rate_limit in site_config.json; allow_rate_limiting in common_site_config.json

• In the benchbench --site erp.example.com set-config rate_limit "{'limit': 600, 'window': 3600}" --parse600 and 3600 are the numbers in Frappe's docs: seconds of request time per window of seconds. Start from what your site uses.
• On the serverbench set-config -g allow_rate_limiting trueThen bench setup nginx and reload nginx: it adds a cap of 8 concurrent connections per site name.

Where this comes from

• frappe/rate_limiter.pyv15v16.52.0The site-wide rate_limit is {limit, window}: a budget of request time (seconds) per window (seconds), answered with 429.
• Frappe docs: rate limitingThe site_config rate_limit object, what it counts, and the 429.
• bench: bench/config/nginx.pyv5.31.0allow_rate_limiting is read from the bench config and is off by default.
• bench: bench/config/templates/nginx.confv5.31.0With allow_rate_limiting on, bench's nginx file caps concurrent connections at 8 per host name.

Why it matters

OWASP says a second factor is the main defence against most password attacks: brute force, credential stuffing, spraying. Turning on Enable Two Factor Auth in System Settings also ticks Two Factor Authentication on the role All, so it covers every user, Administrator included.

How to check

• In the benchbench --site erp.example.com execute frappe.db.get_single_value --args "['System Settings','enable_two_factor_auth']"Prints 1 when it is on and nothing when it is off.

• Sign in as an ordinary user in a private window.

A good result. The command prints 1 and the ordinary user is asked for a code.

The setting or command

enable_two_factor_auth and two_factor_method in System Settings

• System Settings → Two Factor Authentication: tick Enable Two Factor Auth and keep the method OTP App.

• Leave "Bypass Two Factor Auth for users who login from restricted IP Address" unticked unless a fixed-address rule is part of your plan.

• To limit it to some roles, untick Two Factor Authentication on the role All and tick it on those roles.

Where this comes from

• frappe/core/doctype/system_settings/system_settings.pyv15v16.52.0Turning on Enable Two Factor Auth ticks Two Factor Authentication on the role All.
• frappe/twofactor.pyv15v16.52.0A user is asked for a code when some role they hold has the box ticked; the switch is the System Settings field, not a bench config key.
• frappe/auth.pyv15v16.52.0The username-and-password login asks for the code.
• frappe/auth.pyv15v16.52.0A request with an API key is authenticated here and never reaches the 2FA code path.

Why it matters

Frappe scores a new password with zxcvbn and refuses one under the minimum score. It is on by default at 2, which resists online guessing but not a stolen database; 3 adds some protection against offline attacks. Forced rotation is your call: NIST says not to require periodic changes, unless a password is known to be compromised, and not to impose composition rules.

How to check

• In the benchbench --site erp.example.com execute frappe.db.get_single_value --args "['System Settings','minimum_password_score']"
• In the benchbench --site erp.example.com execute frappe.db.get_single_value --args "['System Settings','force_user_to_reset_password']"Prints nothing when it is empty.

A good result. The score is 3 or 4 (our suggestion; Frappe's default is 2). Reset-after-days is empty unless a rule of yours needs it.

The setting or command

enable_password_policy, minimum_password_score and force_user_to_reset_password in System Settings

• System Settings → Password: keep Enable Password Policy ticked and raise Minimum Password Score.

• Administrator and Guest are never forced to reset; change Administrator's password by hand (see Accounts and keys).

Where this comes from

• frappe/core/doctype/system_settings/system_settings.jsonv15v16.52.0Defaults of the System Settings fields this list names.
• frappe/core/doctype/system_settings/system_settings.jsonv16.52.0v16 spells out what each password score means.
• frappe/core/doctype/user/user.pyv15v16.52.0A new password is scored against the minimum score when the policy is on.
• frappe/utils/password.pyv15v16.52.0User passwords are stored hashed (pbkdf2_sha256, argon2), not encrypted.

Why it matters

Frappe counts failed sign-ins per account and per IP address and locks for a while after too many: 10 tries, then 60 seconds, by default. Zero tries switches lock-out off. A new site's idle timeout is 170 hours, about a week. Bench installs fail2ban, but its one jail watches for proxy abuse and scanner paths, not sign-ins.

How to check

• In the benchbench --site erp.example.com execute frappe.db.get_single_value --args "['System Settings','allow_consecutive_login_attempts']"
• In the benchbench --site erp.example.com execute frappe.db.get_single_value --args "['System Settings','session_expiry']"

A good result. Tries is above 0, the lock time is one you chose, and the idle timeout suits where your people sit.

The setting or command

allow_consecutive_login_attempts, allow_login_after_fail and session_expiry in System Settings

• System Settings → Brute Force Security: the number of tries and the lock time in seconds.

• System Settings → Session Expiry (idle timeout), written hours:minutes, such as 08:00.

• Allow only one session per user is off by default, and mobile devices are exempt from it.

Where this comes from

• frappe/core/doctype/system_settings/system_settings.jsonv15v16.52.0Defaults of the System Settings fields this list names.
• frappe/auth.pyv15v16.52.0Lock-out is tracked per user and per IP address, and is off when the number of tries is 0.
• frappe/sessions.pyv15v16.52.0A blank idle timeout falls back to 240 hours.
• bench: bench/config/production_setup.pyv5.31.0bench setup production installs nginx, supervisor and fail2ban, then fixes ownership of logs/ and config/.

Why it matters

Administrator exists on every site, and it is the account Frappe never forces to change its password. Frappe has no built-in default: the password is whatever was typed at install, or put in admin_password in a config file. A config file that still holds it is a plain-text copy.

How to check

• In the benchgrep -l admin_password sites/common_site_config.json sites/erp.example.com/site_config.json

A good result. No file is listed. Day-to-day work happens under named users, and you can say who knows the Administrator password.

The setting or command

The Administrator password; admin_password in config

• In the benchbench --site erp.example.com set-admin-password --logout-all-sessionsAsks for the password, so it stays out of your shell history.
• In the benchbench --site erp.example.com set-config admin_password None
• In the benchbench set-config -g admin_password None

Where this comes from

• frappe/commands/site.pyv15v16.52.0bench set-admin-password prompts for the password when it is not given, and can log everyone out.
• frappe/utils/install.pyv15v16.52.0A new site takes the Administrator password from admin_password in config, or asks.
• frappe/auth.pyv15v16.52.0Forced password reset skips the standard users, Administrator among them.
• frappe/__init__.pyv15v16.52.0Guest and Administrator are the standard users.

Why it matters

A System Manager can create API keys for any user and download backups. A person who has left can still sign in until their account is disabled. Review who holds the role, and who is still enabled, on a calendar.

How to check

• User list → filter Role is System Manager and Enabled is Yes. Then sort the enabled users by Last Active.

A good result. You can name every System Manager and each needs the role. No leaver is still enabled, and nobody has been unseen for months.

The setting or command

Enabled on the User form

• In the benchbench --site erp.example.com disable-user person@example.com

• Or untick Enabled on the User form.

Where this comes from

• frappe/core/doctype/user/user.pyv15v16.52.0Only a System Manager can create API keys, and each call makes a new secret.
• frappe/utils/response.pyv15v16.52.0Only System Manager or Administrator can download a backup, and the download is logged.
• frappe/commands/site.pyv15v16.52.0bench disable-user <email> disables an account.
• frappe/core/doctype/user/user.jsonv15v16.52.0On the User form the API secret is a Password field; Restrict IP and Last Active exist.

Why it matters

An API key and secret sign in with no password and no 2FA code, so the key's user is the whole gate. Until v15.120.0 and v16.33.0 a user's IP allow-list was not applied to key requests (advisory GHSA-h9jq-7pgf-hw8q, October 2026). Generating keys again makes a new secret and the old one stops working.

How to check

• User list → filter API Key is set. For each user, name the integration and read their roles.

• In the benchbench version

A good result. Every key maps to one named integration, with the fewest roles that work and an IP allow-list where its address is fixed. frappe is at v15.120.0 or later, or v16.33.0 or later.

The setting or command

API Access and Restrict IP on the User form

• One user per integration, with only the roles that integration needs.

• User → Restrict IP: the addresses it calls from.

• User → API Access → Generate Keys to rotate: copy the secret when it is shown.

• Disable the user when the integration ends.

Where this comes from

• frappe/auth.pyv15v16.52.0API-key requests are checked against the user's IP allow-list.
• frappe/auth.pyv15v16.52.0A request with an API key is authenticated here and never reaches the 2FA code path.
• frappe/core/doctype/user/user.pyv15v16.52.0Only a System Manager can create API keys, and each call makes a new secret.
• frappe/core/doctype/user/user.jsonv15v16.52.0On the User form the API secret is a Password field; Restrict IP and Last Active exist.

Why it matters

Allow Guests to Upload Files is off by default. If a public form needs it, narrow what can arrive: Frappe can limit guest uploads to named DocTypes, limit file extensions and cap the size. v16 can also restrict public uploads to System Managers.

How to check

• In the benchbench --site erp.example.com execute frappe.db.get_single_value --args "['System Settings','allow_guests_to_upload_files']"

A good result. It prints nothing (off), or you can name the web form that needs it and the DocType list and the extensions are filled in.

The setting or command

allow_guests_to_upload_files, allowed_doctypes_for_guest_uploads, allowed_file_extensions and max_file_size in System Settings; in v16 also only_allow_system_managers_to_upload_public_files

• System Settings → untick Allow Guests to Upload Files, or fill in Allowed Doctypes for Guest Uploads, Allowed File Extensions and Max File Size.

Where this comes from

• frappe/core/doctype/system_settings/system_settings.jsonv15v16.52.0Defaults of the System Settings fields this list names.
• frappe/core/doctype/system_settings/system_settings.jsonv16.52.0Only v16 has Only allow System Managers to upload public files.
• frappe/core/doctype/system_settings/system_settings.jsonv15.123.0v15.123.0 does not have that field.
• OWASP Top 10 (2021): A05 Security MisconfigurationUnnecessary features and ports, default accounts left on, settings not set securely.

Why it matters

bench init adds a cron job that backs up every site every six hours. It takes the database only: uploaded files need --with-files. Each run also deletes backup files older than 23 hours and the server keeps three sets, so what sits on it is about a day of history.

How to check

• On the servercrontab -l | grep backupRun as the user that owns the bench.
• In the benchls -lh sites/erp.example.com/private/backups

A good result. A cron line runs backup with --with-files, and the folder holds a fresh -database.sql.gz, -files.tar and -private-files.tar.

The setting or command

The cron job; keep_backups_for_hours in site_config.json; Number of Backups in System Settings

• On the servercd ~/frappe-bench && bench --verbose --site all backup --with-files >> logs/backup.log 2>&1The line to put in crontab -e, every six hours, in place of the one bench wrote.

• System Settings → Number of Backups (default 3) sets how many sets stay on the server.

Where this comes from

• bench: bench/bench.pyv5.31.0bench setup backups writes a cron job: backup all sites every 6 hours, no --with-files.
• bench: bench/utils/system.pyv5.31.0bench init sets that cron job up unless --no-backups is passed.
• frappe/commands/site.pyv15v16.52.0bench backup takes the database only unless --with-files is passed.
• frappe/utils/backups.pyv15v16.52.0Every backup run first deletes files in private/backups older than 23 hours, or keep_backups_for_hours.

Why it matters

Backups on the server die with it, and the server throws them away within about a day. A dead disk, a ransomware run or a deleted instance takes both. Keep copies somewhere the server can add to but not delete from (our advice, not Frappe's).

How to check

• Open the place the copies go (a bucket, a storage box) and sort by date.

A good result. The newest copy is from the last backup run, and older ones follow a retention rule you chose.

The setting or command

S3 Backup Settings, Dropbox Settings or Google Drive in v15; the offsite_backups app in v16

• v15: Integrations → S3 Backup Settings, Dropbox Settings or Google Drive. Each runs a daily job.

• On the serverbench get-app https://github.com/frappe/offsite_backups --branch version-16v16 moved those three out of Frappe core into this app.
• In the benchbench --site erp.example.com install-app offsite_backups

• Or copy sites/erp.example.com/private/backups yourself: frappe_docker documents restic and a push_backup.py script for S3-compatible storage. Copy the archives, not the site_config copy (next item).

Where this comes from

• frappe/utils/backups.pyv15v16.52.0Every backup run first deletes files in private/backups older than 23 hours, or keep_backups_for_hours.
• frappe/hooks.pyv15.123.0In v15 the S3, Dropbox and Google Drive backup jobs are in Frappe core.
• frappe/integrations/doctype/s3_backup_settings, frappe/integrations/doctype/dropbox_settings, frappe/integrations/doctype/google_drivev16.52.0In v16 those three are not in core any more.
• offsite_backups: offsite_backups/hooks.pyversion-16 @ 4764d43The offsite_backups app (branch version-16) carries the S3, Dropbox and Google Drive jobs.

Why it matters

Encrypt Backups is off by default. When on, Frappe encrypts the database and the file archives with gpg, using a separate key it creates in site_config.json. The copy of site_config.json that goes into each backup is not encrypted, though its name ends in -enc. It holds the database password, the encryption_key and, once encryption has run, the backup key.

How to check

• In the benchbench --site erp.example.com execute frappe.db.get_single_value --args "['System Settings','encrypt_backup']"
• On the servergpg --version | head -n 1
• In the benchfile sites/erp.example.com/private/backups/*Docker: run it through sh -c so the * expands.

A good result. encrypt_backup prints 1 and gpg is installed. The archives show as PGP encrypted data. The site_config copy shows as JSON text: that is the file to keep out of the off-box copy.

The setting or command

encrypt_backup in System Settings; backup_encryption_key in site_config.json

• System Settings → Backups → Encrypt Backups, with gpg installed.

• Save the key now: Download Backups → Get Encryption Key (System Manager), or the backup_encryption_key line in site_config.json.

• Keep the *_site_config_backup-enc.json files out of the off-box copy, or encrypt them with your own tool first.

• To restore an encrypted backup on another site, copy backup_encryption_key into that site's site_config.json first, then run bench restore with no key option (the restore item has the full steps). bench restore reads the key from the site it restores into. A passphrase typed on the command line stays in your shell history.

Where this comes from

• frappe/utils/backups.pyv15v16.52.0Encrypt Backups runs gpg with a separate key, backup_encryption_key, written into site_config.json on first use.
• frappe/utils/backups.pyv15v16.52.0The files gpg encrypts are the database and the two file archives. The site_config copy is a plain copy, though its name gets the -enc suffix.
• frappe/core/doctype/system_settings/system_settings.jsonv15v16.52.0Defaults of the System Settings fields this list names.
• frappe/commands/site.pyv15v16.52.0bench restore takes --with-public-files, --with-private-files and --encryption-key.

Why it matters

A backup you have never restored is a guess. A restore finds the quiet failures: files missing from the archive, a key nobody saved, an encrypted archive with no passphrase. Do it on a scratch bench, never on the live site.

How to check

• On the serverbench new-site restore-test.localAsks for the MariaDB root and Administrator passwords.

• Copy encryption_key (and backup_encryption_key, if the archives are encrypted) from the live site_config.json into restore-test.local's. bench restore reads the backup key from there, so no key goes on the command line.

• On the serverbench --site restore-test.local set-config mute_emails 1Before the restore. It stops the email queue sending, so the copy sends no real email, including mail an action on it sends straight away. A Send Now click on an Email Queue row still sends.
• On the serverbench --site restore-test.local restore PATH/…-database.sql.gz --with-public-files PATH/…-files.tar --with-private-files PATH/…-private-files.tar
• On the serverbench --site restore-test.local scheduler disableA second guard. A new site starts with the scheduler off and the restore keeps that setting, so it should already be off.
• On the serverbench --site restore-test.local execute frappe.utils.password.get_decrypted_password --args "['Email Account','NAME','password']" | wc -cPrints a count, not the password. NAME is an Email Account that has a password.

A good result. The site opens, a recent record and its attachment open, the last command prints a number above 1 (an 'Encryption key is invalid' error means the key is wrong), and you wrote down how long it took.

The setting or command

No setting: a habit

• Repeat it after every major upgrade, after any change to the backup tooling, and at least every quarter (our advice).

Where this comes from

• frappe/commands/site.pyv15v16.52.0bench restore takes --with-public-files, --with-private-files and --encryption-key.
• frappe/commands/site.pyv15v16.52.0With no --encryption-key, bench restore takes the key from get_or_generate_backup_encryption_key. The file has no --backup-encryption-key option, the name Frappe's how-to page uses.
• frappe/utils/password.pyv15v16.52.0encryption_key is created on first use, and Frappe's own error says to copy the original site_config.json after a restore.
• frappe/commands/scheduler.pyv15v16.52.0bench scheduler status|enable|disable|pause|resume.

Why it matters

Password-type fields (API secrets, email account passwords, integration credentials) are stored encrypted with encryption_key from site_config.json. Frappe creates the key the first time one is saved. A database restored without it keeps the rows but cannot read them, and Frappe's own error tells you to copy the original site_config.json. Changing the key breaks every one of them.

How to check

• In the benchgrep -c '"encryption_key"' sites/erp.example.com/site_config.jsonPrints a count, not the key.

• Ask where a copy of the key is kept, and whether that place is different from where the database backups are.

A good result. The count is 1, and a copy is in a password manager or secrets vault, not in the bucket that holds the database dumps. If the count is 0, nothing has been encrypted yet, but it will be.

The setting or command

No setting: keep a copy of encryption_key

• Read the value once as the bench user and store it in a password manager or secrets vault. Do not paste it into chat or a ticket.

• Never regenerate it. If it is lost, every stored password (email accounts, integrations, API secrets) has to be entered again.

Where this comes from

• frappe/utils/password.pyv15v16.52.0encryption_key is created on first use, and Frappe's own error says to copy the original site_config.json after a restore.
• frappe/utils/password.pyv15v16.52.0A wrong or new key fails decryption with that error.
• frappe/installer.pyv15v16.52.0A new site's site_config.json holds the database name and password; Frappe writes it with no file mode set.
• Frappe docs: site_config.jsonDocuments allow_cors (wildcard 'not recommended for production use'), host_name, encryption_key, backup_encryption_key, keep_backups_for_hours, server_script_enabled, developer_mode.

Why it matters

site_config.json holds the database password and the encryption keys in plain text; common_site_config.json holds the Redis addresses. Frappe never sets a file mode, so they get whatever the process umask gives, commonly readable by every local account. Backups in private/backups are the same.

How to check

• In the benchstat -c '%a %U:%G %n' sites/common_site_config.json sites/erp.example.com/site_config.json
• In the benchstat -c '%a %n' sites/erp.example.com/private/backups

A good result. Both config files show 600 or 640, owned by the bench user, with a group that nobody else shares.

The setting or command

File modes, not a Frappe setting

• On the serverchmod 600 sites/common_site_config.json sites/erp.example.com/site_config.jsonRun from the bench folder, as its owner.

• Leave sites/erp.example.com/private alone: nginx reads files there on Frappe's behalf, so a 700 mode breaks private downloads.

Where this comes from

• frappe/installer.pyv15v16.52.0A new site's site_config.json holds the database name and password; Frappe writes it with no file mode set.
• frappe/installer.pyv15v16.52.0Neither the installer nor the backup code sets a file mode.
• bench: bench/utils/system.pyv5.31.0The permission fix bench runs only changes the owner of logs/ and config/. It sets no file modes.
• bench: bench/config/templates/nginx.confv5.31.0nginx serves private files and backups through an internal /protected/ location, so it needs read access to them.

Why it matters

In developer mode Frappe allows changes to standard DocTypes and writes them to files; without it those changes are refused. A production site has no reason to allow that. Server Scripts run Python written in the desk, and they stay off unless server_script_enabled is set in common_site_config.json.

How to check

• In the benchbench --site erp.example.com show-config | grep -E 'developer_mode|server_script_enabled'

A good result. No developer_mode line, or 0. No server_script_enabled line unless you use Server Scripts.

The setting or command

developer_mode in site_config.json; server_script_enabled in common_site_config.json

• In the benchbench --site erp.example.com set-config developer_mode 0
• In the benchbench set-config -g server_script_enabled 0

Where this comes from

• frappe/core/doctype/doctype/doctype.pyv15v16.52.0Without developer_mode, Frappe refuses changes to standard DocTypes.
• frappe/utils/safe_exec.pyv15v16.52.0Server Scripts run only when server_script_enabled is set in common_site_config.json.
• Frappe docs: site_config.jsonDocuments allow_cors (wildcard 'not recommended for production use'), host_name, encryption_key, backup_encryption_key, keep_backups_for_hours, server_script_enabled, developer_mode.
• frappe/commands/utils.pyv15v16.52.0bench show-config prints every key of the merged config, secrets included.

Why it matters

Scheduled jobs are part of the clean-up: expired sessions, old logs, the 2FA QR-code images and old downloadable backups. With the scheduler off, in maintenance mode or paused, none of that happens. Frappe also runs jobs only once a day on a site nobody has opened for 4 days.

How to check

• In the benchbench --site erp.example.com scheduler status

A good result. It says the scheduler is enabled.

The setting or command

enable_scheduler in System Settings; pause_scheduler and maintenance_mode in site_config.json

• In the benchbench --site erp.example.com scheduler enable
• In the benchbench --site erp.example.com scheduler resume

Where this comes from

• frappe/commands/scheduler.pyv15v16.52.0bench scheduler status|enable|disable|pause|resume.
• frappe/utils/scheduler.pyv15v16.52.0Maintenance mode, a paused scheduler and the System Settings switch each stop it.
• frappe/hooks.pyv15v16.52.0Scheduled jobs clear expired sessions, delete 2FA QR-code images and clear old logs.
• frappe/core/doctype/system_settings/system_settings.jsonv15v16.52.0Defaults of the System Settings fields this list names.

Why it matters

Three layers keep logs, each with its own limit. The Activity Log, which holds sign-in history, is cleared after 90 days by default and the Error Log after 14. Frappe's own log files rotate at 100 KB, 20 files. Supervisor rotates its logs at 50 MB, 10 files; nginx's depend on your operating system.

How to check

• Log Settings → Logs to Clear: read the days against how long you need sign-in history.

• On the serverls -lh logs/ && du -sh /var/log/nginx

A good result. The days suit your needs, and no log is growing without a limit.

The setting or command

Logs to Clear in Log Settings

• Log Settings → change the days per log type. Export first anything you must keep longer than the default.

Where this comes from

• frappe/hooks.pyv15v16.52.0Default log retention: Error Log 14 days, Activity Log 90, Scheduled Job Log 7.
• frappe/utils/logger.pyv15v16.52.0Frappe's own log files rotate at 100,000 bytes, 20 files.
• frappe/hooks.pyv15v16.52.0Scheduled jobs clear expired sessions, delete 2FA QR-code images and clear old logs.
• Supervisor docs: configurationstdout_logfile_maxbytes defaults to 50MB and stdout_logfile_backups to 10.

Why it matters

Frappe sends security fixes to each supported version separately, and none to a version that has ended. On Frappe's support page, version 14 ended on 31 January 2026; version 15 is planned to end at the end of 2027 and version 16 at the end of 2029.

How to check

• In the benchbench version

A good result. frappe and erpnext are on version 15 or 16, and you know which release.

The setting or command

No setting: an upgrade plan

• If you are on 14 or older, plan the move to 16: follow Frappe's migration guides and rehearse it on a restored copy first (see the restore item).

Where this comes from

• Frappe: supported versionsVersion 14 ended 31 January 2026; version 15 is planned to end at the end of 2027 and version 16 at the end of 2029; fixes are sent to each supported version separately.
• Frappe forum: ERPNext v14 has reached end of lifeThe Frappe team's notice, posted 31 January 2026.
• bench: bench/commands/update.pyv5.31.0bench update backs up every site first unless --no-backup is passed.
• frappe/commands/utils.pyv15v16.52.0bench version lists the installed apps and their versions.

Why it matters

Frappe tagged 17 v16 and 14 v15 releases in the 90 days to 14 October 2026. It published 59 security advisories for the framework in the 12 months to the same day, 15 of them high or critical. More advisories can mean more reports handled in the open, not a worse product. Fixes that are public are fixes you may be missing.

How to check

• In the benchbench version

• Compare with the latest tag at github.com/frappe/frappe/releases. Subscribe to github.com/frappe/frappe/releases.atom in a feed reader, or watch the repository for releases.

A good result. You can say how old your release is, who applies updates, how often, and where they are tried first.

The setting or command

No setting: a calendar. Disable System Update Notification in System Settings should stay unticked

• In the benchbench updateBacks up every site first (unless --no-backup), pulls, migrates, builds and restarts. Try it on a restored copy first.

• Keep System Settings → Disable System Update Notification unticked so System Managers see new releases.

Where this comes from

• GitHub: frappe/frappe security advisoriesread 2026-10-14Published advisories for the framework, counted from the GitHub API on 2026-10-14.
• GitHub: frappe/frappe releasesread 2026-10-14Release tags for v15 and v16, counted from the GitHub API on 2026-10-14.
• bench: bench/commands/update.pyv5.31.0bench update backs up every site first unless --no-backup is passed.
• frappe/utils/change_log.pyv15v16.52.0System Managers get update notices unless Disable System Update Notification is ticked.

Why it matters

Frappe's fixes cover Frappe. The operating system, nginx, MariaDB, Redis and Node are patched by their own vendors, and OWASP lists unpatched components as a risk category of its own. Ubuntu Server installs unattended-upgrades and applies security updates by default; other systems need it set up.

How to check

• On the serversystemctl is-enabled unattended-upgrades
• On the serverapt list --upgradable 2>/dev/null | head -n 10
• On the serverls /var/run/reboot-required

A good result. The first says enabled, nothing security-related is waiting, and the third file is absent or a reboot is booked.

The setting or command

unattended-upgrades on Ubuntu and Debian

• Ubuntu: /etc/apt/apt.conf.d/20auto-upgrades turns it on and 50unattended-upgrades says what it installs and whether it reboots.

Where this comes from

• Ubuntu Server docs: automatic updatesunattended-upgrades is installed by default on Ubuntu and applies security updates.
• OWASP Top 10 (2021): A06 Vulnerable and Outdated ComponentsNot patching the platform and components is a risk category of its own.
• MithTech: how to self-host on HetznerThe server layer (SSH keys, firewall, Fail2ban, updates) this list does not repeat.