When the EspoCRM install script fits and when a manual install does
The install script fits a team on Ubuntu, Debian or Linux Mint that wants a Docker-based stack with Nginx and MariaDB already assembled, plus a command.sh utility for backups, restores and upgrades. A manual install fits a team that already has web server, database and patching standards and needs EspoCRM to follow them. The deciding question is who will operate the stack after go-live. The script packages the components into one deployment that your team manages through one utility, which reduces setup work but ties day-to-day operations to the script's layout. Confirm that your distribution and hosting setup are covered before you commit.
The script's main advantage is a single, documented path for backups, restores and upgrades. That advantage matters most when your team has no standard tooling for a small CRM and wants routine tasks in one place. The conditions are real: you accept the container layout, and any change to Nginx, MariaDB or the Docker configuration needs to be checked against the script's assumptions before you make it. Optional Let's Encrypt certificates are available, but confirm how renewals are handled. Before go-live, run a restore from a backup into a separate host and record each command in your runbook. Also confirm with EspoCRM which data and files the backup covers, since the installation documentation is the source for that detail. The installation by script documentation is the next read.
A manual install fits when your organization already requires specific components, such as Apache, Nginx or IIS, and specific database versions. The server configuration documentation lists PHP 8.3 to 8.5, MySQL 8.0 or newer, MariaDB 10.6 or newer or PostgreSQL 15. Your team will also need to configure cron or a scheduled task for background jobs and monitor it, because the script's Docker setup will not do that for you. Ongoing work includes patching PHP, the database and the web server on your own cycle, applying EspoCRM upgrades, and running backups with your existing tools. If you use an implementation partner for a manual build, ask for a written scope that names each component, the backup method and the restore test, and who maintains each of them after handover.
Install script and manual install compared factor by factor
This table compares the bundled installation script with a manual install on your own web server and database across control, platform support, certificates, upgrades, backups and skills. Read each row against your own operating system standard and team skills, because the script trades configuration freedom for a packaged stack. The main takeaway is that the script suits teams that accept its Docker, Nginx and MariaDB defaults, while manual installs suit teams that must match an existing server standard.
| Factor | Installation script | Manual install |
|---|---|---|
| Operating systems | Documented for Ubuntu, Debian and Linux Mint | Any platform that meets the server requirements; confirm support with your own OS standard |
| Web server | Nginx, deployed in the Docker-based stack | Apache, Nginx or IIS, chosen by your team |
| PHP runtime | Set by the packaged stack; confirm the PHP version against the documented 8.3 to 8.5 range | You choose and tune PHP within the documented 8.3 to 8.5 range |
| Database | MariaDB, deployed in the Docker-based stack | MySQL 8.0 or newer, MariaDB 10.6 or newer, or PostgreSQL 15 |
| Background jobs | Handled by the packaged stack; confirm how it runs scheduled jobs | You must configure cron or a scheduled task yourself |
| Certificates | Optional Let's Encrypt certificates during install | You issue, install and renew certificates with your own tooling or internal CA |
| Upgrades | Performed with the command.sh utility | Performed by your team, following the upgrade steps for your own stack |
| Backups and restores | Built into command.sh for backups and restores | Built with your existing database and file backup tooling; you define restore tests |
| Skills required | Docker administration plus basic Linux operations | Linux, web server, PHP and database administration, plus backup and patch processes |
| Fit | Teams that accept the packaged stack and want a faster first deployment | Teams with an existing server standard, custom hardening or a database platform they already run |
What the install script deploys on your server
The EspoCRM installation script is a turnkey path for Ubuntu, Debian and Linux Mint hosts. It deploys a Docker-based stack with Nginx as the web front end and MariaDB as the database, and it can request Let's Encrypt certificates if you opt in. Before you run it, confirm the exact OS release you are on against the EspoCRM installation by script documentation, because the supported list and the script's behavior are defined there, not by the distribution family alone. Ask your platform team whether a Docker engine is already approved on that host, since the script's footprint and its Docker dependency both affect your patch and change process.
The script also installs a command.sh utility that handles backups, restores and upgrades. Treat these as the operational contract of the deployment. Before go-live, test a full restore into a separate host, confirm where the backup archives are written, and confirm that those archives include both the database and the uploaded files. Check whether the Docker volumes holding database data and attachments sit on the disk you expect and whether they are covered by your host-level backup policy, since a volume on the root filesystem can fill it. Ask whether the utility's upgrade path matches the EspoCRM release line you intend to run, and rehearse it on a copy first.
Several items are yours to confirm, not the script's. Size the host for your user count and attachment volume, because the script does not replace capacity planning. Define firewall rules so only the intended ports reach Nginx and that MariaDB is not exposed beyond the Docker network. Verify DNS and certificate renewal if you use Let's Encrypt, and confirm that background jobs, which need cron or a scheduled task on the EspoCRM server configuration, are running in the stack you deploy. Write these checks down before you compare the script with a manual install, because they are the same work either way, only the owner changes.
What a manual install asks your team to own
A manual install moves every layer of the EspoCRM stack onto your team's runbooks. Each card below names one component, the documented requirement that comes with it, and the recurring task it creates, so you can compare that workload with what the installation script bundles for you.
Web server configuration
EspoCRM's server configuration documentation lists Apache, Nginx or IIS as supported web servers. In a manual install your team chooses one, writes the virtual host, sets the document root to the public directory, and keeps the rewrite rules intact through every server upgrade. Check that your chosen server's configuration survives OS package updates, since a silent change there can break routing without touching the application.
PHP runtime maintenance
The documentation lists PHP 8.3 to 8.5 as supported. A manual install means your team selects the PHP build, installs the required extensions, tunes memory and upload limits, and schedules moves to a new PHP line when the current one leaves the supported list. Confirm the extension set against the current docs before each upgrade, because a missing extension typically surfaces only when a specific feature is first used.
Database engine and its versions
EspoCRM supports MySQL 8.0 or later, MariaDB 10.6 or later and PostgreSQL 15. In a manual install your team picks the engine, creates the database and user, sets character collation, and owns patching and restores. The installation script instead deploys MariaDB inside its Docker stack. Ask who on your team already runs this engine in production, because that skill decides how safely you can operate it.
Cron jobs for background tasks
The server configuration docs state that a cron job or scheduled task must run EspoCRM's background work, such as scheduled jobs, email handling and workflows that depend on timed execution. A manual install leaves this to your team, who must add the entry under the correct web user, confirm it runs on every host in the deployment, and monitor it. A stopped cron job fails quietly, so alert on missed runs rather than waiting for users to report stale data.
TLS certificates and renewal
The installation script can configure optional Let's Encrypt certificates. In a manual install, your team issues certificates, installs them on the web server, enforces HTTPS redirects, and renews them before expiry. Decide whether you use a public certificate authority or an internal one, and document who receives expiry alerts. Expired certificates are one of the most common causes of a CRM outage that looks like an application fault.
Backups, restores and upgrades
The installation script ships a command.sh utility for backups, restores and upgrades. A manual install gives your team no equivalent, so you must script database dumps, file backups of uploaded attachments and configuration, restore tests, and the sequence for applying new EspoCRM releases. Test a restore on a separate host before go-live, and confirm the recovery steps with whoever owns your backup platform.
Which deployment path fits which team
A small team without dedicated web or database administration usually gets the most from the installation script. The script targets Ubuntu, Debian and Linux Mint and deploys a Docker-based stack with Nginx and MariaDB, so the team does not hand-assemble a web server, PHP runtime and database before it can run EspoCRM. The command.sh utility covers backups, restores and upgrades, which turns recurring tasks into documented commands rather than custom scripts. The fit depends on the team being willing to operate Docker and keep the host patched.
- Fewer moving parts to assemble: the script installs the web tier and database together, which removes the configuration steps most likely to stall a first deployment.
- Built-in lifecycle commands: backup, restore and upgrade run through one utility, so routine operations rely on the vendor's documented procedure.
- Optional Let's Encrypt: the script can request certificates, which helps a team without a certificate process get HTTPS in place on day one.
- Limited room for custom layout: the stack is opinionated, so unusual reverse proxy rules or a shared database server may require the manual path.
Before committing, confirm that your host OS is one the script supports, that someone on the team can run Docker in production, and who owns host patching and off-host backup copies.
A team that already runs a Linux standard and a supported database engine often prefers a manual install. Such a team can place EspoCRM on its existing web server and database, reuse its monitoring, backup tooling and change process, and avoid running a second container runtime just for one application. The EspoCRM server configuration documentation lists PHP 8.3 to 8.5, MySQL 8.0 or later, MariaDB 10.6 or later and PostgreSQL 15, on Apache, Nginx or IIS, with cron or a scheduled task required for background jobs.
- Reuse of existing database operations: the instance can join the replication, backup and access controls the team already runs for MySQL, MariaDB or PostgreSQL.
- Web server choice: Apache, Nginx or IIS are all listed, so the team can match its current standard.
- Scheduled jobs under your control: the cron or scheduled task that EspoCRM needs for background work is set up with the team's own scheduler tooling.
- More configuration ownership: PHP extensions, file permissions and upgrade steps become the team's responsibility, so the runbook must be written and tested.
Before committing, confirm which database engine and version your standard supports against the listed versions, and whether your upgrade process can follow the EspoCRM upgrade steps for the release line you plan to run.
A team that must align with an internal hardening baseline, or that runs in an air-gapped network, has to test whether the installation script fits its rules before choosing it. The script pulls and deploys a Docker-based stack and can request Let's Encrypt certificates, which assumes outbound access and an image source the organization accepts. A manual install puts every component under the baseline, which is often easier to document for an assessor, though it leaves the hardening work to the team.
- Image and package provenance: a script that deploys containers from external sources may conflict with an internal image approval process, so the team may need to mirror or rebuild components.
- Network access during install: an air-gapped deployment needs every package, image and certificate source to be available inside the enclosed network before work starts.
- Control mapping: a manual install lets the team map each component (web server, PHP, database, cron, TLS) to its own baseline controls and produce evidence directly.
- Authentication design: OpenID Connect and LDAP sign-in are documented, and both need to be wired to the organization's identity provider under its own standards.
Before committing, confirm with your security and platform teams whether container runtimes, Let's Encrypt and external image sources are permitted, and ask DeployOpen or the vendor to document the exact artifacts the chosen path pulls at install time.
Who runs upgrades, backups and monitoring in each model
This table compares who carries upgrades, backups, monitoring, patching and skills under the Docker-based install script and a manual install on your own web server and database. Read each row as a split of responsibility, then confirm the exact steps in the EspoCRM installation docs before production. The main takeaway: the script shifts routine stack work onto its tooling, while a manual install keeps every layer with your team.
| Area | Installation script | Manual install |
|---|---|---|
| Current release line | EspoCRM's current line is 10.0, with 10.0.10 released on October 14, 2026, per the GitHub releases | Same EspoCRM 10.0 line, but your team picks the version and timing for each upgrade |
| Application upgrades | The command.sh utility handles upgrades for the script's Docker stack; confirm the exact steps in the installation docs | Your team runs the EspoCRM upgrade procedure and checks file, permission and database changes itself |
| Web server, PHP and database upgrades | Stack components ship inside the Docker setup, so upgrade planning follows the script's packaging; confirm which components are covered | Your team plans and tests web server, PHP and MySQL, MariaDB or PostgreSQL upgrades against EspoCRM's supported versions |
| Backups | command.sh provides backup and restore commands; confirm what the backup scope includes, such as files and database | Your team designs backup scope, schedule, encryption and restore tests for web root, files and database |
| Background jobs and health checks | Confirm how the script schedules background jobs and what health checks it runs by default | Your team must configure cron or a scheduled task for background jobs and monitor it directly |
| Patching the host and stack | The script's host is Ubuntu, Debian or Linux Mint; patching of the host OS stays with your team | Your team patches the OS, web server, PHP and database on its own schedule |
| Skills required | Docker, Linux administration and basic Nginx and MariaDB operation | Linux administration, web server and PHP tuning, database administration and cron or scheduler management |
How to run an upgrade safely under each model
This sequence gives the team the same safe path whether the install came from the script or was built by hand, so each upgrade starts from a verified backup and ends with confirmed logins and background jobs. The split between the two models lies in which steps the script automates and which ones the team still checks itself.
Take a full backup before anything changes
Before touching the running instance, take a backup of the application files and the database together, so the two stay consistent. Under the installation script, the command.sh utility covers backups, restores and upgrades, so the backup runs through that tool. Under a manual install, the team runs its own database dump and copies the EspoCRM directory, following its existing backup routine. The step is done when the backup file exists in a separate location and a restore has been rehearsed on a copy at least once, not just assumed to work.
Confirm the target version on the releases page
Check the EspoCRM releases page on GitHub to identify the exact version you plan to move to, and read the release notes for changes that affect your customizations, extensions or integrations. Note whether the target is within the same major line or crosses a major version, since major changes need more testing. The output is a written target version and a short list of release notes the team has reviewed. Ask your DeployOpen contact or the vendor to confirm any extension compatibility you depend on, such as paid packs.
Verify web server and database versions against the supported list
Compare the installed PHP, database and web server versions with the EspoCRM server configuration documentation before upgrading. The script deploys Nginx and MariaDB as part of its Docker-based stack, so the team should confirm the versions the script pulled. On a manual install, the team owns this check entirely, including Apache or Nginx and the MySQL, MariaDB or PostgreSQL version. If a component falls outside the listed range, upgrade it first in a separate change so you can tell which change caused any later fault.
Rehearse the upgrade in a non-production copy
Restore the backup into a separate environment with the same versions, then run the upgrade there. Under the script, this means running the upgrade command on a copy built with the same installation method. On a manual install, it means applying the same file and database steps by hand on the copy. Record every command or manual step you ran, because that record becomes the runbook for production. The step is complete when the copy runs on the target version and the team has a written list of any errors and how it resolved them.
Apply the upgrade to production in a planned window
Schedule the change with users informed and with the backup and rollback path confirmed. Under the installation script, the upgrade runs through command.sh, which replaces the file copy, configuration and migration steps that a manual process needs. Under a manual install, the team runs each step from the runbook in order and checks each one before moving on. Keep the previous backup available until the verification step is complete. The output is a production instance reporting the target version.
Verify background jobs and sign-in
Confirm that the scheduled job that drives background tasks still runs after the upgrade, because EspoCRM requires cron or a scheduled task for background jobs and a stopped scheduler can fail silently. Then test sign-in with a standard user, an administrator and, if you use it, an OIDC or LDAP login, and confirm API users still authenticate. Review the application logs for new errors. The step is done when a test record can be created, a scheduled job has run and every sign-in method in use has succeeded on the new version.
Document the outcome and the rollback decision
Record the versions before and after, the backup identifier, the time of the change, the tests run and any issues found. Name the person who signed off the result and the conditions under which the team would roll back. Store this record with the runbook so the next upgrade starts from the same evidence. The output is a change record that a future auditor or new team member can follow without asking the original operator.
Questions buyers ask before choosing an EspoCRM install path
What drives the cost and effort of each EspoCRM install path?
The main difference is who does the work and who carries it afterward. With the installation script, the stack is pre-assembled as a Docker-based setup with Nginx and MariaDB, so the effort shifts toward configuration, hardening, Let's Encrypt decisions and running the command.sh utility for backups, restores and upgrades. With a manual install, your administrators build and maintain the web server, PHP, database, cron jobs and backup routines themselves. Costs recur in both cases: staff time for patching, upgrades and monitoring, plus hosting. Ask any partner to split a quote into one-time setup, hardening, backup design and recurring support so you can compare the two paths on the same basis.
Can our team run the EspoCRM install script ourselves?
Your team can run it if the target host is one of the supported Linux distributions the installation documentation names, which include Ubuntu, Debian and Linux Mint, and if someone is comfortable operating Docker containers, a reverse proxy and a database inside them. The script is designed to deploy a working stack quickly, but it does not remove the need for judgment about DNS, TLS, firewall rules, network placement and backup storage. Confirm the current supported distributions and script prerequisites in the EspoCRM installation documentation before you plan the host build, and check that your change process allows a container-based stack on that host.
What does a manual EspoCRM install require from administrators?
A manual install asks administrators to build the platform layer themselves. According to the EspoCRM server configuration docs, the application runs on PHP 8.3 to 8.5 with MySQL 8.0 or newer, MariaDB 10.6 or newer, or PostgreSQL 15, and on Apache, Nginx or IIS. Cron or a scheduled task must run background jobs. Administrators also own PHP extension tuning, file permissions, database users, TLS, log rotation, backup scheduling and restore testing. Before committing, check that your team already runs this stack in production and that someone is accountable for each of these items after go-live.
How long does an EspoCRM installation take, and what sets the time?
No duration is supplied for either path, so treat any timeline you see as unverified until it is written down. The time depends on the number of environments (development, test and production), whether you need single sign-on or LDAP wired in at install time, how many custom entities and integrations are in scope, data migration from an existing CRM, hardening requirements from your security team, and change approval cycles in your organization. A manual install on a host you already manage can be quicker to start but slower to make repeatable. Request a written scope with milestones and acceptance criteria before work starts, as DeployOpen engagements are typically fixed-scope.
What should we ask for in a quote for an EspoCRM install?
Ask for a quote built from a written scope that names the install path, the target hosts and operating system, the database choice, and the authentication method. The quote should list the deliverables explicitly, such as the installed stack, backup configuration, a tested restore, upgrade runbook, documentation and handover, and it should state what is excluded, such as data migration, custom development or user training. Ask how recurring work is handled, including patching, EspoCRM upgrades and monitoring, and whether that is a separate retainer. DeployOpen does not publish a price list, so the quote follows from the agreed scope. Confirm acceptance criteria in writing before signing.
Does the Advanced Pack or Sales Pack change the install choice?
The paid extensions do not change whether you use the script or a manual install, but they add steps that your scope must cover. According to the EspoCRM Advanced Pack page, the Advanced Pack provides reports, Business Process Management and workflows, and it is included in all EspoCRM Cloud plans. The Sales Pack adds products, quotes, invoices, purchases, subscriptions, inventory and payments, per the EspoCRM features page. Extensions are installed into an existing instance, so plan for licensing checks, extension upgrades alongside core upgrades, and the backup scope. Confirm the license terms for self-hosted extensions with EspoCRM before you budget for them, since the licensing model is a separate decision from the install path.
When should we bring in an implementation partner for EspoCRM?
Bring in a partner when the internal skills, time or change capacity do not match the install path you need. Common triggers include no team member who already operates PHP, MariaDB or Docker in production, a security requirement that needs documented hardening and evidence, a need for OIDC or LDAP sign-in configured correctly on day one, or a backup and restore process that must be proven before go-live. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with agreed deliverables. It does not issue audit reports or certifications, so compliance evidence still comes from independent assessors.
What to confirm with your team and the vendor before you decide
Start with the operating system. The install script targets Ubuntu, Debian and Linux Mint, so confirm that your exact release is on that list in the EspoCRM installation script documentation before you plan a host build. If your standard image is a different distribution or release, the manual path is the realistic option, and that changes who builds and patches the stack. Then check the PHP, MySQL, MariaDB and PostgreSQL versions you intend to use against the EspoCRM server configuration documentation, and confirm which web server you will run. Do not assume the script's bundled versions match the current supported list. Ask EspoCRM to confirm the matrix for the release you plan to deploy.
Next, decide who owns the scheduled jobs and the certificate process. EspoCRM needs cron or a scheduled task for background jobs, and a missing or misowned job tends to show up later as stalled workflows or stale emails rather than as an obvious outage. Name the team that owns that schedule, the account it runs under and the monitoring that will alert on it. Also confirm how TLS will be issued: the script can request optional Let's Encrypt certificates, but your security team may require an internal CA or a managed certificate, and that decision belongs on the list before installation, not after.
Finally, agree on backup retention, restore testing and upgrade approval. A backup taken by command.sh is only useful if you have restored it into a separate environment and timed the result, so schedule that test and record who signs it off. Write down how many restore points you keep, where they are stored, and whether they sit outside the host that runs the CRM. For upgrades, name the approver, the staging environment that must pass first and the rollback plan. Confirm each of these specifics in the EspoCRM documentation or with the vendor directly, and record the answers in your change records, so the decision rests on your environment rather than on assumptions about the defaults.
How DeployOpen scopes, delivers and supports EspoCRM deployments
DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms inside your own cloud accounts, data centers or air-gapped networks. For EspoCRM, that means deciding with your team whether the installation script or a manual build fits your standards, then delivering it with written scope, tested backups and handover documentation.
How we scope
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
- The written scope states which hosts, database engine, web server and identity method your EspoCRM instance will use.
- Scope also records which paid extensions, if any, are in play and who owns their licenses.
How we build
- We install EspoCRM either through the installation script or by hand, based on the scope you approved.
- Configuration covers database, web server, cron jobs for background tasks and any OIDC or LDAP sign-in.
- Backup and restore steps are tested against your own environment before the system is handed over.
How we hand over
- Handover documentation describes the deployed stack, configuration files, credentials ownership and upgrade steps.
- We document how backups, restores and upgrades run, so your own staff can operate the system afterward.
- Compliance-related controls and evidence are prepared for your independent assessor, though DeployOpen does not issue audit reports.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers outside the initial fixed scope.
- Retainer terms, including response expectations, are written into the agreement, so confirm them before signing.
- Upgrade work follows the EspoCRM release notes for your version, and we confirm them against your environment first.
