EspoCRM upgrade and extension upload lockdown

Why EspoCRM admins should not upgrade or upload extensions from the browser

In EspoCRM 10, upgrading through the UI is disabled by default, and regulated teams should treat that default as the starting point for their own lockdown. The EspoCRM security docs say so directly, and the change matters because an upgrade or extension upload from the browser is an administrator action that can change executable code on the server. Any admin account that can reach those functions is a path to running code of the attacker's choosing, so every admin session, every admin password and every admin workstation becomes part of the risk surface for the whole CRM. Holding upgrades and extension installs to a controlled process narrows that surface to the people who run the servers, not everyone who can sign in as an administrator.

The browser path is worth closing when the CRM holds regulated customer data, when the admin role is shared by more than a few people, or when change control requires a record of who changed the code and when. It is also worth closing when the team cannot yet prove that an extension package came from a source it trusts. Teams in those situations usually keep upgrades and extension changes on the command line, run during a planned maintenance window, and leave routine admin work in the UI. Before adopting this, confirm with your own change process which roles may approve a release, and confirm with EspoCRM's documentation how the 10.x UI setting is configured in your installed version.

Which lockdown options fit which operating model

This table compares the main ways to reduce admin attack surface in EspoCRM 10, from keeping the default UI block to restricting admin access by network or identity provider. Read each row against how often your team patches and how many people hold admin rights. The main takeaway is that stronger lockdown usually trades faster patch delivery for less exposure, so most teams combine two or three options.

Option	When it fits	Trade-off
Keep the default UI upgrade block	Stable deployments with a small admin group and a scheduled maintenance window for patches	Upgrades wait for a planned CLI run, so patch delivery depends on your change process
Disable extension upload	Teams that manage extensions through their own build and review pipeline and do not add packages from the admin screen	New extensions or updates need an operator with server access, which adds a handoff
Run upgrades from the CLI in maintenance mode	Regulated or multi-admin environments that need a logged, repeatable upgrade with a defined window	Requires shell access, a rollback plan and a maintenance notice to users
Restrict admin access by IP address	Administrators work from fixed office or VPN addresses and the reverse proxy passes the real client address	Travelling admins and support vendors need exceptions, and misconfigured proxies can lock out valid users
Route admin login through the identity provider	Organizations that already run central SSO with MFA and want one place to disable an administrator	Relies on OIDC or LDAP configuration, and EspoCRM's own two-factor authentication is not used with OIDC
Separate admin accounts from daily accounts	Any deployment where administrators also handle customer records or email	Adds accounts to manage, but limits what a phished daily account can change
Confirm the extension and upgrade settings in your own instance	Every deployment before go-live and after each major version change	Requires a test instance and a named owner to re-check settings after upgrades

How to disable extension uploads and move upgrades to the CLI

This sequence removes the browser route for upgrades and extension uploads, so changes to the running EspoCRM code happen through a controlled command-line process with a known backup and a recorded version check.

Confirm the installed version and backups
The administrator records the current EspoCRM version from the administration panel and the server, then confirms that a recent database backup and a copy of the files directory exist and can be restored. Your platform or DBA team usually owns this step. Done means you have the version string written down and a restore test plan you can run if the upgrade fails. Confirm the backup procedure against the EspoCRM docs for your version, since the supported backup and restore commands can differ between releases.
Review the admin account inventory
List every account with the admin role or equivalent administrative permissions, including API users and any shared or service accounts. Record who can sign in, whether each account has two-factor authentication enabled, and whether any administrator uses that account for daily work. Done means you have a short list with one owner per account and a decision on which accounts will remain. Reduce this list before you change upgrade or upload behavior, because the people on it are the ones who will be affected by the restriction.
Apply the extension upload restriction
Change the configuration setting that disables extension uploads through the administration interface, following the key name and location given in the EspoCRM security or server configuration docs for your version. Your platform engineer makes the change in the configuration file under change control, and a second person reviews it. Done means the setting is saved, the cache is cleared as the docs direct, and a test administrator sees the upload option unavailable or refused. Record the previous value so you can roll back.
Enter maintenance mode
Announce a window to users, then place the instance in maintenance mode using the command the docs describe for your version. Stop or pause scheduled jobs and background processing where the docs recommend it, so no records change during the upgrade. Done means a browser request to the instance shows the maintenance page and the cron or job queue has stopped processing new work. Confirm the exact command and whether jobs must be paused separately before you start.
Run the upgrade from the CLI
The platform engineer runs the upgrade from the server command line using the procedure in the EspoCRM upgrade documentation for the target release, including the PHP version check and any extension compatibility checks. Keep the command output in the change record. Done means the command finishes without errors and the output reports the new version. If it fails, stop, keep the instance in maintenance mode, and use the restore plan from the first step rather than retrying blindly.
Verify the version and core functions
Check the version reported by the instance against the release you planned, then exit maintenance mode and sign in with a test administrator and a standard user. Confirm login, record search, a saved layout, a workflow or scheduled job, and that the extension upload option stays disabled. Done means the version matches, the test checks pass, and the job queue runs again. Keep the instance in maintenance mode if any check fails.
Close the change and record the result
Restore the normal scheduled job and background processing settings, record the final version, the backup reference, the account review outcome and the configuration change in your change log, and set a reminder to repeat the account review at the next upgrade. Done means the change record is complete and the owner of each administrative account has confirmed their access. Ask your DeployOpen or internal team to confirm each configuration key and command against the EspoCRM documentation for the exact version you run.

How the approach differs for self-hosted and Docker installs

The installation script for Ubuntu, Debian and Linux Mint deploys a Docker-based stack with Nginx and MariaDB, and it includes the command.sh utility for backups, restores and upgrades. Because you control the host, the containers and the utility, the upgrade path runs from the command line, which fits EspoCRM 10 where upgrading through the UI is disabled by default. Your team decides who can reach that shell.

Host and shell access: You control the Linux host and the Docker daemon, so limit SSH and Docker socket access to the people who run upgrades.
`command.sh` as the upgrade path: Run upgrades inside a planned maintenance window, and take the backup with the same utility immediately before the change.
Extension files on disk: Blocking extension uploads in the admin panel does not stop a person with host access from placing files in the instance. Confirm which paths persist in volumes and which are rebuilt from the image.
Version pairing: Record which installation script and command.sh version built the stack, and check that they match the EspoCRM release you are moving to.
Host hardening: Firewall rules, OS patching and container image sources sit with your team, and they decide whether an admin account is the only way in.

Before relying on this model, confirm with the vendor which command.sh operations stop the application for maintenance and whether the upgrade steps for your target release match the ones the script runs.

Security and operational risks to plan for

Turning off UI upgrades and extension uploads removes two routes into the admin area, but the admin account, the backups, the change record and the patch schedule still decide how safe the instance is. Each card below is a risk that stays open after the settings change and needs an owner and a check.

Admin accounts used for daily work

An administrator who also reads email, browses the web and edits records gives every phishing lure and stolen session the admin role. EspoCRM's security guidance recommends keeping admin accounts out of daily work, so the upgrade and extension tasks run from a separate named account. Check that each admin has a second, non-admin account for daily use and that admin logins are limited to the people who perform maintenance.

Backup and rollback before maintenance mode

Maintenance mode stops users from working while the CLI upgrade runs, but it does not protect data if a migration step fails. Take a full database backup and a copy of the files directory and configuration before the window opens, and test a restore on a separate host. Confirm who can authorize a rollback and how long it would take to restore service, because that answer is what the window depends on.

Change control and approvals for upgrades

With UI upgrades disabled, the upgrade becomes a server-side change, so it should go through the same ticket, review and approval path as other production changes. Record the target version, the extensions and customizations affected, and the person who approved the window. Ask the implementation partner or your own team to confirm which extensions have versions compatible with the target release before approval.

Extension provenance and review

Disabling extension upload stops new packages from being pushed through the admin interface, but extensions already installed still run with full application privileges. Keep an inventory of every installed package with its source, version and reviewer, and review custom code in hooks and formula scripts the same way as application code. Any package that cannot be traced to a known source should be removed or quarantined.

Logging of admin actions

Settings changes, role edits and extension installs are the events an investigator will need after an incident. Confirm where EspoCRM writes its logs on your server, who can read them, and how long they are kept, then forward them to your central logging platform if you run one. Test that a sample admin change appears in the log before relying on it.

Delayed patching against reduced exposure

Locking the upgrade path reduces the number of people who can change the platform, but it also slows the moment a security fix reaches production. Agree in advance how quickly security releases must be applied, who decides when a window is opened outside the normal schedule, and how a version lag is reported. Compare the release history on the project's releases page with your own patch window before setting the policy.

Limits to confirm in your environment

Locking down the admin interface only works if the controls match your exact EspoCRM version, extension set and hosting model. The cards below list the items to confirm with your own environment and with the EspoCRM documentation before you change upgrade or extension settings.

Version-specific CLI commands and maintenance mode

Confirm the exact upgrade commands, maintenance mode switches and step order for the version you run. The UI upgrade default changed in version 10.0, so runbooks written for version 9 may not match. Test the full sequence on a copy of production, including the cron job and the backup taken before the upgrade. Record the commands as a versioned runbook that your on-call engineers can follow without guessing.

Extensions that still need UI upload

Inventory every installed extension and check whether its install path requires the admin upload screen. Extensions you rely on may be installed or updated only through a file or the CLI in your setup. Decide in advance whether you will allow any exceptions, who approves them, and how the package is checked before it reaches production.

Installing official extensions under the restriction

Confirm how each official extension, such as the Advanced Pack, is delivered and installed once extension upload is disabled. Check whether the vendor offers a package file or an alternative route, and whether license keys or activation steps depend on the admin UI. Plan the install and update path before you turn off uploads, so a required module cannot be blocked during a security fix.

PHP and database version requirements

Check the PHP, database and web server versions your target EspoCRM release supports, and compare them with what your servers run. Version requirements change between releases, so confirm them in the server configuration docs for the release you plan to install. Include these checks in the upgrade plan, because a PHP gap can block the CLI upgrade after you have already started maintenance mode.

CLI access under your hosting model

Verify that your hosting model gives the upgrade operator shell access to the EspoCRM directory, the PHP binary and the cron user. Managed hosts, some container platforms and shared environments may not allow this. Confirm who holds that access, how it is logged and whether the same operator can reach production data, since that access is what replaces the UI upgrade path.

Admin accounts and change approval

Confirm which accounts can run CLI upgrades and who approves a maintenance window. Admin users should not use daily work accounts for these tasks, so decide how privileged sessions are created and recorded. Write down the approval steps, rollback plan and communication to users before the window opens, and test that the rollback restores both files and the database.

Questions teams ask before locking down EspoCRM admin functions

Can our own admins lock down EspoCRM upgrades without a partner?

Yes, a team with Linux and PHP experience can make these changes, and the settings and CLI upgrade steps are described in EspoCRM's documentation. The lockdown itself is mostly configuration: UI upgrades stay off, extension upload is disabled, and upgrades run from the command line in a planned maintenance window. The harder part is the first run. Teams that have never upgraded from the CLI often discover untested extensions, custom code or scheduled jobs that depend on the old path. If your admins have not completed a CLI upgrade on a copy of production, that rehearsal is the step where outside help reduces the most risk. Confirm each step against the exact version you run before changing production.

What makes the effort for an EspoCRM upgrade lockdown go up or down?

Effort grows with the number of things an upgrade touches, so start by counting them. The main drivers are:

Installed extensions, each needing a compatibility check against the target version
Custom entities, layouts, formula scripts and hooks, which need retesting after every upgrade
Environments, from production through staging to any test copy used for rehearsal
PHP and database versions, which may need changing before the target release will run
Existing backup, restore and monitoring processes, which shorten the work when they are tested

Each extra environment repeats the checks, so ask for the count of each item before you agree a scope.

What does an EspoCRM admin lockdown need from our team?

Expect to provide server or shell access to the instance, a change window for the settings change and for the first CLI upgrade, and an inventory of the people and accounts involved. The inventory should list admin users, installed extensions, custom code and scheduled jobs. You also need a named approver for changes and staff who can confirm key business workflows after each step. Access should be limited to the EspoCRM host and its database, and documented. Ask the team who uses the admin UI today, because removing it changes their routine and they should hear about it before the change window.

Does disabling EspoCRM upgrades in the UI affect EspoCRM Cloud?

The lockdown in this topic applies to a self-hosted instance, where your team controls the server, the files and the command line. EspoCRM Cloud is run by the vendor, so confirm with EspoCRM which upgrade and extension settings Cloud customers can change before you plan. Cloud pricing is per user per month, according to the EspoCRM pricing page: 15 US dollars on Basic (minimum 3 users), 25 on Enterprise (minimum 5) and 69 on Ultimate (minimum 10), with the Advanced Pack included in all cloud plans. Those prices help you compare hosting models, but they do not show which admin controls each plan exposes, so check that directly with the vendor.

How long does a fixed-scope EspoCRM lockdown take?

The duration depends on the scope, so no fixed figure is given here. A lockdown of a single instance with few extensions is a different job from a change across several environments with custom code. The drivers are the number of instances, the number of extensions and customizations, whether a non-production copy exists for testing, and the target version. EspoCRM 10.0.0 was released on July 2, 2026 and 10.0.10 on October 14, 2026, so the version you target determines which release notes and compatibility checks apply. Most engagements are fixed-scope, with the timeline agreed in writing before work starts. Ask for the schedule to be tied to milestones you can verify.

What should we request in a fixed-scope EspoCRM quote?

A quote should follow from a written scope that lists exactly what changes and how each change is checked. Ask for:

An inventory of instances, EspoCRM versions, extensions and customizations in scope
The exact settings to change and the test that confirms each one
Whether the target version and the CLI upgrade rehearsal are included
Backup and restore steps, and who runs them
The change window, rollback plan and handover documentation
Which costs are one-time and which recur, such as ongoing support or upgrade retainers
The assumptions, and how a new extension or customization triggers a change request

Compare quotes line by line so the scopes match before you compare totals.

Will locking the admin UI stop routine EspoCRM administration?

Some routine tasks move to a controlled path. With UI upgrades off and extension upload disabled, admins install and upgrade through steps run by the team with server access. That adds a review step, but it leaves a clear change record. EspoCRM's security documentation also recommends avoiding admin accounts for daily work, so keep a separate admin account for these changes and use a standard account for day-to-day tasks. Confirm which admin tasks your team performs each month, so you can document the new steps for each one before the change takes effect.

How this connects to the rest of EspoCRM access control

Disabling UI upgrades and extension uploads is the last layer of admin control, and it only works if the roles behind it are already right. Role design decides who can change settings, install code and reach administration screens. Before you lock down those functions, review the roles described in *Designing EspoCRM roles and teams* and confirm that no sales, service or portal role carries administrative permissions. Then keep the people who run upgrades in a small admin group, separate from the accounts they use for daily work, as the EspoCRM security docs recommend. Upgrades are run from the command line in maintenance mode, so the people who can reach that command line are the real upgrade authority. Document that list and review it whenever staff change.

Authentication policy determines whether an admin account can be used by someone other than its owner. Enforce the password policy, require two-factor authentication for regular users and admins, and disable password recovery for admin accounts, following the recommendations in the EspoCRM security docs. Shorten auth token lifetime and idle time so a session left open on a shared workstation does not stay usable for administration. Work through *Enabling two-factor authentication in EspoCRM* and *EspoCRM password, recovery and session policy* together. If you sign in through OpenID Connect, EspoCRM's own two-factor method is not compatible, so confirm that your identity provider enforces MFA for the admin group before you rely on it.

Network placement and integration accounts complete the picture. Restrict admin sign-in to office or VPN addresses using the IP whitelist described in *Restricting EspoCRM access by IP address*, and confirm the REMOTE_ADDR handling if EspoCRM sits behind a reverse proxy, since an incorrect value can make the restriction ineffective. Integration traffic runs through API users, which are a separate path into the system. Keep API users out of the admin role, scope them as described in *EspoCRM API users and integration accounts*, and check any exceptions you grant them. Before go-live, test each path (web admin, command line upgrade, extension upload and API) and confirm that each one is blocked or limited as you intended.

How DeployOpen scopes and delivers EspoCRM hardening

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so the admin lockdown for EspoCRM runs in the environment you control. We scope the change in writing, build and test it against your deployment, then hand over the runbooks and support options your team needs to keep it in place.

How we scope

Inventory which admin accounts can reach the UI upgrade and extension upload paths today.
Confirm the EspoCRM version in use and whether it is on the 10.0 line before changing the upgrade process.
Agree the written scope, deliverables and timeline with you before any change is made to the system.

How we build

Disable extension upload and UI upgrades in your configuration, then verify the setting took effect for each admin role.
Document a maintenance-mode CLI upgrade procedure with backup, rollback and verification steps for your environment.
Test the lockdown in a non-production copy of your instance before applying it to production.

How we hand over

Deliver written configuration records, the maintenance-mode upgrade runbook and a list of who holds admin access.
Walk your platform, security and operations staff through the procedure and the evidence that it works.
Store the deliverables in your own repositories or document systems so your team owns them after handover.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer if your team wants DeployOpen to keep working on the platform.
Review the lockdown when a new EspoCRM release changes admin or upgrade behavior, as agreed in the scope.
Provide a quote for each follow-on change based on its written scope, since DeployOpen does not publish a price list.

Locking down EspoCRM upgrades and extension uploads