When to choose Apache for EspoCRM configuration
Choose Apache when your organization already runs Apache as its standard web server, or when your operations team holds the skills and monitoring to run it, and you need EspoCRM hosted on that estate. EspoCRM supports Apache, Nginx or IIS according to its server configuration documentation, so the web server is a platform decision you make against your existing standards rather than a requirement of the application. Apache is a sound fit when consistency with other internal services, existing certificate and logging processes, and staff familiarity outweigh the benefits of a dedicated proxy layer.
The Apache work is specific and bounded. It covers pointing the document root at the public directory rather than the application root, enabling mod_rewrite and allowing .htaccess overrides so that EspoCRM routes resolve, installing the PHP modules and version EspoCRM's server requirements list, and setting file ownership and permissions so the web user can write the directories the application needs. It also covers denying direct web access to internal directories and preparing the cron or scheduled task that runs background jobs, which Apache does not handle. Confirm each of these against the server configuration page for the EspoCRM release you intend to run, because module lists and PHP ranges change between releases.
Apache deployment options and when each fits
This table compares the main Apache choices for hosting EspoCRM: the virtual host layout, how PHP runs, and where rewrite rules live. Read each row against your server policy, since the right option depends on how your Apache estate is already managed. Confirm every setting against the EspoCRM server configuration documentation before you commit to a layout.
| Decision | Option | Trade-off | When it fits |
|---|---|---|---|
| Virtual host | Dedicated virtual host for EspoCRM | Clean document root and isolated TLS and logging, but one more host block to maintain | EspoCRM has its own hostname and the team wants clear separation from other apps |
| Virtual host | Shared host with other applications | Lower server footprint, but a misconfigured neighbor can affect rewrites, TLS or access rules | Small internal deployments where your Apache policy already governs shared hosts |
| PHP execution | mod_php inside Apache | Simple setup, but PHP runs with Apache's process model and is harder to isolate per site | Single-site servers with a small number of users and no strict isolation requirement |
| PHP execution | PHP-FPM through a proxy handler | Separate pool and user for EspoCRM, easier tuning, but needs extra service configuration | Shared servers, stricter isolation expectations or teams that already run PHP-FPM |
| Rewrite rules | .htaccess files in the application | Easy to change without reloading Apache, but AllowOverride must be enabled and the rules are spread across the file tree | Environments where application-level rules are allowed and changes are made by the EspoCRM administrator |
| Rewrite rules | Rewrite rules in the main server config | Rules are centralized and reviewed with the server, with no per-request file lookups, but changes need a reload | Teams that keep web server config under change control and prefer AllowOverride None |
| Document root | Public directory as document root | Keeps internal directories out of web reach, but the path must match the installed release layout | Default choice for production, confirmed against the server configuration docs |
| Ownership | Apache policy approval | Your security team may restrict modules, AllowOverride or PHP handlers, which narrows the valid options | Always confirm the chosen combination with your team's Apache policy before deployment |
How to configure the Apache virtual host for EspoCRM
This sequence takes a clean Apache server to a working EspoCRM virtual host, with PHP, the required modules, a document root on the public directory, rewrite handling, correct file ownership, a supported database and a scheduled job for background tasks. Each step ends with a check you can run before moving on.
Install Apache and a supported PHP version
Install Apache and PHP on the server, choosing a PHP version from the range the EspoCRM server configuration docs list (PHP 8.3 to 8.5). Your platform team or partner performs this step on a server you control. Confirm the PHP version with the command php -v and confirm Apache starts cleanly with apachectl configtest. The step is complete when both report success and the default Apache page loads from the server's address.
Enable the required PHP modules
Install and enable the PHP extensions EspoCRM needs, as listed in the EspoCRM server configuration docs for your PHP version. Check the current list in those docs before you install, because it can change between releases. Restart Apache after enabling modules. Confirm the result by running php -m and checking that every extension named in the docs appears in the output.
Enable mod_rewrite and the PHP handler
Enable the Apache rewrite module with a2enmod rewrite and confirm that the PHP handler is active for your PHP version. EspoCRM relies on rewrite rules to route requests to its front controller, so this module is required. Restart Apache and confirm the module is loaded with apachectl -M, which should list rewrite_module. The step is complete when the module appears in that list.
Set the document root to the public directory
Create a virtual host file for your EspoCRM hostname and point DocumentRoot at the public directory inside the EspoCRM installation, not at the installation root. This keeps configuration files, logs and internal directories out of the web root. Add a ServerName that matches your DNS record. Confirm the setup by running apachectl configtest, enabling the site and reloading Apache. The step is complete when the configuration test passes.
Allow overrides for rewrites
Inside the Directory block for the public path, set AllowOverride to All so that EspoCRM's .htaccess rules are read. Without this setting, rewrite rules are ignored and most routes return errors. Confirm the .htaccess file is present in the expected location and that requests to a non-existent path reach EspoCRM rather than returning a plain Apache 404. Reload Apache after the change.
Set file ownership and permissions for the web user
Assign ownership of the EspoCRM files that the application writes to, such as data, custom, client and upload directories, to the web server user (typically www-data on Debian and Ubuntu, or apache on RHEL-family systems). Keep the rest of the code readable but not writable by the web user where possible. Confirm the setup by checking ownership with ls -l and by loading the EspoCRM installer or login page without permission errors in the Apache error log.
Configure the database connection
Create an empty database and a dedicated database user, then configure the connection during EspoCRM installation. The server configuration docs list MySQL 8.0 or newer, MariaDB 10.6 or newer, or PostgreSQL 15 as supported options. Confirm the database version and that the application user can create tables. The step is complete when the installer finishes the schema setup and the administrator can sign in.
Add a cron job or scheduled task for background jobs
EspoCRM needs a scheduled job to run background tasks such as email processing and scheduled workflows. On Linux, add a cron entry for the web user that runs the EspoCRM daemon command every minute, as described in the server configuration docs. Confirm the job runs by checking the job log or the scheduled jobs view in the administration panel after a few minutes. Confirm the exact command for your version in the docs before you set it.
Why the document root must point at the public directory
The document root must point at the public directory of the EspoCRM installation, not at the application root. The application root holds configuration, source code, the vendor tree, and data directories that contain database credentials and uploaded files. If Apache serves that root directly, a request for a path such as /data/config.php or a file under /custom can be read by anyone who can reach the host, and the server has no reason to refuse it. Pointing the virtual host's DocumentRoot at the public directory keeps those files outside the web-visible tree, so the only entry point is the front controller that the application exposes. Confirm the exact DocumentRoot and Directory settings against the EspoCRM server configuration docs for your release before you go live.
Routing depends on mod_rewrite and the .htaccess file shipped with EspoCRM. Apache must load the rewrite module, and the directory block that serves EspoCRM must set AllowOverride to a value that lets .htaccess apply its rewrite rules. Without that, requests for application paths such as entity routes or API endpoints are not mapped to the front controller and return a 404, while the home page may still load. A common failure is a deep link (for example, a direct URL to a record) that works after navigation within the app but returns 404 when opened fresh or refreshed. When that happens, check three things in order: that the rewrite module is enabled, that AllowOverride is not set to None for the public directory, and that the .htaccess file exists and is readable by the Apache user.
Treat these checks as acceptance tests rather than one-time fixes. After any change to the virtual host, to the PHP version, or to the file layout during an upgrade, load a deep link in a private browser session, request an API endpoint, and request a file from the application root to confirm it is refused. Ask your implementation partner or your own administrators to record the expected results so a later change to the server image or a configuration management run can be checked against them.
PHP modules and permission settings that break EspoCRM
Most failed EspoCRM Apache deployments are not routing problems. They come from PHP extensions that are missing, directories that the web server cannot write, and cron jobs that run as a user with no rights to the application. Work through these items before you test the login page, because each one fails quietly or in ways that look like application bugs.
Missing PHP extensions
EspoCRM depends on a set of PHP extensions, and a missing one usually shows up as a blank page, a failed installer step or an error in the Apache log rather than a clear message. Check the PHP version against the supported range in the server configuration docs (PHP 8.3 to 8.5), then compare the loaded modules on the server with the list in those docs. Confirm the list with the docs for your release, because it changes between versions.
Wrong ownership of data and custom
The web server user must own or be able to write the data and custom directories inside the EspoCRM tree. When ownership stays with root or a deployment user, the installer, metadata changes and file uploads fail, and the error often appears only after an admin edits a layout or entity. Check ownership with a listing of the data and custom directories and confirm that the Apache user matches the user set in the virtual host configuration.
Writable cache and upload paths
Cache, upload and temporary paths must stay writable after every rebuild, and a rebuild that fails on one path can leave the instance half-updated. Test write access by running a rebuild from the admin interface and by uploading a small attachment to a record. Keep these paths outside the public document root where the configuration allows, and confirm the exact path list with the server configuration docs for your version.
Cron user lacking rights
Background jobs such as email sending, scheduled workflows and imports run from cron, and a cron entry set up for root or a different user creates files that the web server cannot later read or write. Symptoms include emails stuck in the queue and files created with the wrong owner. Run the cron entry as the same user as Apache, and check that the scheduled job creates no files that Apache then fails to modify.
Upload size and memory limits
PHP limits for upload size, post size, execution time and memory are set in php.ini or per-site overrides, and Apache may apply a separate request body limit. A limit that is too low makes large attachments and imports fail with a generic error, while the page itself loads normally. Check the effective values with a phpinfo page on the same host, remove that page afterward, and align the PHP and Apache limits before you test attachments.
Security settings to apply on the Apache layer
The Apache layer is the first control point for EspoCRM, so most of the hardening happens in the virtual host and the server itself. The cards below cover the web-facing settings to apply there, and they point to the application-side recommendations in the EspoCRM security docs that complement them.
Deny web access to internal directories
Only the public directory should be reachable from the web. Configuration, data, custom code, vendor libraries and logs sit beside it and must return a denied response. Confirm that requests for paths such as the configuration and data directories fail with a 403 or 404 on your own host, and that .htaccess files in those paths are not served as text. Test this after every upgrade, because new directories can appear between releases.
Restrict access by IP address
Where policy allows, limit the admin interface to known networks or a VPN using Require ip directives in the virtual host or a <Location> block. This reduces exposure of the login page to the open internet. Before you apply it, confirm how the load balancer or proxy passes client addresses, because a misconfigured RemoteIPHeader can make every user appear to come from one address and lock out the team.
Enforce HTTPS everywhere
Redirect all plain HTTP requests to HTTPS at the virtual host level, and send HSTS headers once you have confirmed that every subdomain and portal serves valid certificates. Session tokens and credentials travel with each request, so an HTTP fallback exposes them. Check that the EspoCRM site URL in the configuration uses ` otherwise generated links and callbacks can still point to HTTP.
Keep Apache and PHP patched
EspoCRM depends on the Apache and PHP versions in your environment, and the supported PHP range is listed in the EspoCRM server configuration docs. Schedule regular security updates for Apache, its modules and PHP, and remove modules you do not use. Confirm that the PHP version on the server still falls within the supported range after each update, since a version outside it can break the application without an obvious security warning.
Separate admin accounts from daily work
Administrators should sign in to a dedicated admin account only when they change configuration, and use a standard user account for sales and service work. The EspoCRM security docs advise against admin accounts for daily use. At the Apache layer, this supports restricting the admin path to the networks described above. Ask your team to document who holds admin rights and review that list on a fixed schedule.
Apply the application-level controls
Apache settings do not replace controls inside EspoCRM. Confirm that password policy, two-factor authentication, a limited auth token lifetime, and disabled password recovery for admins are configured in the application. These settings live in the EspoCRM administration area, so they need a separate review. Use the security docs as your checklist and record the settings you chose so auditors can trace them.
Questions teams ask about EspoCRM on Apache
How much effort does an EspoCRM Apache setup take for a small team?
For a single instance on one server, the work is mostly a bounded configuration task: a virtual host with the document root set to the public directory, mod_rewrite and .htaccess handling, the PHP modules EspoCRM requires, file permissions for the data and upload paths, and a cron entry for background jobs. The effort grows with the number of decisions you still need to make, such as TLS, database hardening and backups. A multi-site estate multiplies that work: each instance needs its own virtual host, database, storage and scheduled jobs, and each upgrade has to be repeated across them. Ask any partner to split the quote by instance and by shared component so you can see what is repeated and what is built once.
Can our team set up EspoCRM on Apache using only the documentation?
Often yes, if you already run PHP applications on Apache and have someone comfortable with Linux services, file permissions and certificates. The EspoCRM server configuration documentation lists the supported PHP versions, database engines and web servers, including Apache, and explains the cron requirement. What the documentation does not decide for you is how your environment fits together: your DNS names, your certificate process, your firewall rules, your backup schedule and your access model. Teams that go it alone usually underestimate the security settings, such as IP restrictions, admin account separation and the disabling of password recovery for admins, which the EspoCRM security documentation recommends. Confirm your team can own those after handover.
What does the work need from our side before it starts?
Plan for four inputs from your organization. Linux administration access to the target servers, with the ability to install Apache, PHP modules and cron jobs. DNS control so the hostname resolves to the server and so certificates can be issued for it. A certificate process that either uses an existing certificate authority or a free ACME-based service, and a person who can approve the choice. Database access, meaning a database server or permission to create one, with credentials stored outside the web root. You should also name an owner for the admin account, the backup target and the change window for upgrades. Ask the implementation partner to list these inputs in the written scope so gaps show up before the schedule is set.
Is Apache a better fit for EspoCRM than Nginx?
Neither is better in general. EspoCRM supports Apache, Nginx and IIS, so the choice should follow your standards. Apache is a reasonable fit when your organization already operates Apache, your team knows its module model and .htaccess-based rewrites, or you host several PHP applications that already rely on it. Nginx with PHP-FPM is a common choice when the team prefers a server block model and needs the extra control over upload size, timeouts and internal directory denial. The practical test is operational: which web server your staff can patch, monitor and troubleshoot at 2 a.m. Also check whether you need a WebSocket proxy or a customer portal on a separate domain, since both add configuration on either server.
How do EspoCRM upgrades change the Apache settings?
Upgrades can change the parts of Apache configuration that depend on the application version and its PHP requirements. A new major version may require a different PHP version or module set, which changes the packages and ini settings the virtual host depends on. Rewrite rules and the document root normally stay the same, but you should re-check them after each upgrade because a path or directory layout change will break routing silently. The EspoCRM server configuration documentation and release notes list the supported PHP range, so compare it against your current PHP before you schedule the change. Also note that the UI upgrade path is disabled by default as of version 10.0, so the upgrade itself runs through the command line process. Ask for a written upgrade runbook that covers Apache, PHP and the database together.
What drives the cost of a quote for EspoCRM on Apache?
A quote follows from the written scope, and the main drivers are the number of instances, the number of servers and environments (production, staging, recovery), and the state of the existing platform. Other drivers include whether TLS, SSO, LDAP, S3-compatible file storage, the WebSocket daemon or a separate customer portal domain are in scope, and whether hardening and documented evidence are required by your compliance team. Costs are one-time for the build and recur for ongoing support, upgrades and testing if you choose a retainer. EspoCRM itself is licensed under AGPL-3.0 and the open-source edition can be self-hosted for free, so the quote covers services and infrastructure you already pay for, not the software license. Ask for each line to state who does the work, what is delivered and what you must provide.
Which Apache settings need the most care for security?
Start by serving only the public directory as the document root, so that configuration files, logs and upload paths are not reachable by URL. Restrict write permissions to the directories EspoCRM needs, and confirm that data and storage paths deny direct web access. Enforce HTTPS, limit access by IP address for administrative paths where your policy allows it, and keep the PHP and Apache versions patched. The EspoCRM security documentation also recommends a password policy, two-factor authentication, limited token lifetime and avoiding admin accounts for daily work. Ask the partner to show how each of these is verified after the build, using a test checklist and the server's access logs, rather than relying on the configuration file alone.
What to confirm with your environment before go-live
Before you announce the Apache-hosted EspoCRM as live, run a short verification pass in the environment that will serve users, not only on a development host. Start with a smoke test of login and a deep link: sign in with a standard user account, open a record through a bookmarked URL that requires the router to pass the request to index.php, and confirm the page loads without a 404. Repeat the test with an admin account and a portal or API user if you use them. A deep link that works from the dashboard but fails when pasted directly usually points to a missing or unloaded rewrite rule in the virtual host or .htaccess handling.
Next, check that background jobs run on schedule. EspoCRM depends on cron (or an equivalent scheduler) for background work, so confirm that the job runs as the web server user, that its output is written somewhere you can read, and that queued items such as email sends or scheduled notifications move from pending to done. Also confirm the permission audit of the web root: the application should be able to write only to the directories it needs, such as cache, data, upload and log locations, and the public directory should be the only part exposed by the document root. Record the owner and mode of each writable path, and check that files such as configuration and internal source are not reachable by a browser request. Review the Apache error log and the EspoCRM log for errors raised during the smoke test and the first scheduled run, and keep a dated record of every result. Finally, confirm vendor-specific behavior with the EspoCRM docs and your own test instance, not with memory of an earlier version. Ask your implementation partner or your platform team to confirm the PHP version, the required Apache modules and the directives for your release against the server configuration page, and to rerun the checks after any change to the virtual host, PHP settings or permissions. Keep the signed-off results with the change record so that the next upgrade or hardening change has a known baseline to compare against.
How DeployOpen delivers EspoCRM hosting on Apache
DeployOpen plans, configures, hardens and documents EspoCRM on Apache inside your own infrastructure, from the document root and rewrite rules through to PHP settings and file permissions. Each step is agreed in writing before work starts, so you know what is delivered and how it will be checked.
How we scope
- Confirm the Apache version, PHP version and database engine your environment will run, against the EspoCRM server requirements.
- Agree the document root on the public directory and the hostnames, TLS approach and any portal domains in the written scope.
- Record which PHP modules, permission settings and cron or scheduled job method the deployment needs before build starts.
How we build
- Configure the virtual host, mod_rewrite and .htaccess handling so routing works and internal directories are not served.
- Set PHP modules, upload limits, timeouts and file ownership for the web user, then test each change in a non-production copy.
- Verify login, record pages, file upload, background jobs and access to protected paths against the agreed test list.
How we hand over
- Provide a configuration record with the virtual host, PHP settings, permissions and scheduled job setup as built.
- Document the steps to reapply Apache and PHP changes after an EspoCRM upgrade, so the next version does not undo them.
- Walk your platform and security team through the configuration and the verification results, and confirm ownership of each setting.
How we support
- Ongoing support, upgrades and continuous testing for the Apache configuration are available as a retainer, scoped in writing.
- Review Apache and PHP changes against the EspoCRM release notes before each planned upgrade of the application.
- Ask for the support boundary in writing, including who responds to server-side incidents and who owns the operating system patches.
