When installing EspoCRM on Windows with IIS makes sense
Choose IIS on Windows Server when your organization already runs its web estate, identity and patching on Windows and must keep the CRM on servers it controls. EspoCRM's server configuration docs list IIS alongside Apache and Nginx as a supported web server, so the decision is about operations, not feasibility. The stack you would build is PHP 8.3 to 8.5, a database of MySQL 8.0 or newer, MariaDB 10.6 or newer, or PostgreSQL 15, and a scheduled task for background jobs, since cron does not exist on Windows. Confirm each version against the current EspoCRM server configuration docs before you order servers, because the supported matrix is the first thing an auditor or your change board will ask for.
The Docker Compose path and the Ubuntu, Debian and Linux Mint installation script do not apply to this build. Those routes deliver a Linux stack with Nginx and MariaDB, so a Windows mandate means you own every component the script would otherwise have configured: PHP extensions, the IIS site, URL Rewrite rules, file permissions, TLS certificates, backups and the upgrade procedure. Ask your team whether they can maintain PHP on IIS over several years, including the PHP runtime and FastCGI handler, and whether a Linux host with the same controls is an option that your policies would also accept. Windows is a sound choice when the operational skills exist in-house; without them, the lower-effort path is often a Linux VM inside the same Windows-governed data center.
Choosing between IIS, Nginx, Apache and Docker
If your team already runs Windows Server, patches through WSUS or Windows Update, and manages backups with Windows tools, IIS keeps EspoCRM inside a stack you already operate. The EspoCRM server configuration docs list IIS as a supported web server alongside Apache and Nginx, and they require PHP 8.3 to 8.5 and a database from the supported list. Background jobs run through a scheduled task instead of cron, so the operational model stays familiar to Windows administrators.
- Familiar tooling: Patching, group policy, certificate stores and monitoring stay on the platform your staff already know.
- PHP as an extra component: You install and maintain PHP for Windows and its extensions yourself, and each PHP upgrade is a change you must test.
- Database choice: Confirm whether your team will run MySQL, MariaDB or PostgreSQL on Windows or on a separate server, and who owns its backups.
- Scheduled task reliability: The job runner depends on a Windows scheduled task you must monitor, since a stopped task silently halts background work.
- Fewer packaged defaults: You assemble the server block, rewrite rules and permissions by hand rather than starting from a packaged stack.
Before you choose IIS, confirm that your team can maintain PHP versions and extensions on Windows and that someone owns the scheduled task and the backup routine.
Platform teams that already run Linux servers often prefer Nginx or Apache with PHP-FPM, because the configuration, service management and packaging match the rest of their estate. The EspoCRM server configuration docs list both as supported web servers, and background jobs use cron on Linux. Your team controls the PHP build, the modules and the update cadence directly, which makes version pinning and automated patching easier to design.
- Native cron: Background jobs run from cron, a model most Linux administrators already monitor.
- Server choice: Nginx and Apache each have their own configuration files, so pick the one your team can review and audit more easily.
- Patching control: Your team sets the PHP and database update windows, but it also owns the security response.
- Backup tooling: Database dumps and file backups use the tools already in your runbooks, so confirm they cover the upload directory and the configuration.
- Operating system support: Confirm the distribution and PHP packages your organization supports against the current EspoCRM requirements.
Before you choose a Linux stack, confirm the PHP version your distribution provides and whether it falls within the range the docs list.
Teams that want a working instance quickly, and that do not need to match a specific web server, can start from the Docker path or the installation script. The EspoCRM installation docs describe an installation script for Ubuntu, Debian and Linux Mint that deploys a Docker-based stack with Nginx and MariaDB, optional Let's Encrypt certificates and a command.sh utility for backups, restores and upgrades. Docker keeps the PHP, web server and database versions packaged together, which reduces the number of components your team assembles by hand.
- Packaged stack: The application, web server and database arrive as one tested combination, so there are fewer version choices to make.
- Built-in utilities: The command.sh helper covers backups, restores and upgrades, so confirm that its steps match your recovery objectives.
- Container skills: Your team must understand images, volumes and container upgrades, which is a different skill set from IIS administration.
- Host limits: The script targets specific Linux distributions, so a Windows-standard organization cannot use it.
- Storage planning: Volumes hold the database and uploads, so plan their placement and backup before go-live.
Before you choose this path, confirm that your hosting platform supports Docker and that your change process allows container-based upgrades.
Windows IIS configuration options and when each fits
This table compares the main configuration choices for running EspoCRM on IIS, from the PHP handler and database engine to the job runner. Read each row as a decision: the option that fits your server standards, and what to confirm with the vendor before you commit.
| Decision | Option | When it fits and what to confirm |
|---|---|---|
| PHP runtime | PHP 8.3 to 8.5 through the FastCGI handler | Fits most IIS estates. Confirm the exact PHP minor version and required extensions against the server configuration docs for your target EspoCRM release. |
| Database engine | MariaDB 10.6 or newer | Fits teams already running MariaDB. Confirm the PHP PDO driver build you install supports it on Windows. |
| Database engine | MySQL 8.0 or newer | Fits teams with existing MySQL standards and tooling. Confirm the Windows connector and PHP driver compatibility. |
| Database engine | PostgreSQL 15 | Fits organizations standardizing on PostgreSQL for backup and HA. Confirm the PHP PostgreSQL extension is available for your PHP build. |
| Site and document root | IIS site pointed at the public directory | Keeps application code outside the web root. Confirm that the site root does not expose internal folders. |
| URL Rewrite rules | Rewrite requests to the front controller | Required for clean EspoCRM routes. Confirm the rule set against the current EspoCRM rewrite example before go-live. |
| File permissions | Modify rights for data and custom folders only | Limits write access to runtime folders. Confirm the IIS application pool identity and the folders EspoCRM writes to in your release. |
| Job runner | Windows Task Scheduler running the EspoCRM cron entry | Replaces cron on Windows. Confirm the task runs as an account with access to the install folder and that the schedule matches your release docs. |
| Job runner | Cron-equivalent scripts on a Linux host | Fits organizations that prefer Linux for background jobs. Confirm network access to the database and file storage from that host. |
Setup sequence for EspoCRM on IIS with Task Scheduler
This sequence takes a Windows Server host from bare IIS to a working EspoCRM login page, with a scheduled task that runs background jobs in place of cron. Each step closes with a check so the team knows it can move on.
Prepare Windows Server roles and IIS
Confirm the server edition, patch level and time synchronization with your Windows administrators, then add the Web Server (IIS) role with CGI support, and install the URL Rewrite module from Microsoft. Create a dedicated service account for the application pool and a folder outside the web root for the EspoCRM files. Decide with your team how the server will be reached, including the internal DNS name and the TLS certificate source. Done means the default IIS site loads over HTTP on the server and the URL Rewrite module appears in IIS Manager.
Install a supported PHP version with extensions
Install a PHP version within the range listed in the EspoCRM server configuration documentation, which is PHP 8.3 to 8.5, using a build suited to IIS and FastCGI. Enable the PHP extensions that the server configuration page lists as required for your release, and confirm the php.ini values for memory, upload size and execution time with your application owner. Register PHP with IIS as a FastCGI handler for .php files. Done means a test page that calls phpinfo() loads through IIS and shows the expected version and extensions, and you then remove that test page.
Provision the database
Create an empty database and a dedicated database user with rights limited to that database. The documentation lists MySQL 8.0 or newer, MariaDB 10.6 or newer, or PostgreSQL 15 as supported choices, so pick one your database team already operates and confirm it matches the EspoCRM release you intend to install. Store the credentials in a location the service account can read but other local users cannot. Done means you can connect to the database from the web server host using the new account and the database is empty.
Deploy files with the public directory as site root
Copy the EspoCRM release files to the folder created in step one, and point the IIS site's physical path at the public subdirectory rather than the application root, so configuration, data and source files are not served directly. Confirm that the release package came from the official EspoCRM source and record its version for later upgrade planning. Done means the IIS site's physical path ends in the public folder and the folder listing is not reachable from a browser.
Configure URL Rewrite for EspoCRM routes
Add URL Rewrite rules at the site level so that requests for paths that are not existing files or folders are passed to the EspoCRM front controller, following the routing rules in the EspoCRM server configuration documentation for IIS. Block direct access to internal directories and sensitive file types with deny rules. Test the rules with one deep link, such as an entity record URL, after the installer runs. Done means the site root loads and a non-existent path returns the EspoCRM handling rather than a raw IIS 404 page.
Set folder permissions for the application
Grant the application pool identity modify rights only on the folders EspoCRM must write to, such as data, custom and upload locations, and keep read-only rights on the rest of the code. Keep the configuration file writable only during installation if your process requires it, then restrict it again. Ask your security team to confirm that the rights match your hardening baseline. Done means the application can write to its data folders in a test and cannot write to the code directories.
Run the installer and secure the first login
Open the site in a browser and run the web installer, entering the database details from step three and creating the first administrator. Immediately create a separate day-to-day administrator account, and plan to review the security settings recommended in the EspoCRM security documentation, including two-factor authentication and password policy. Done means the login page loads over HTTPS, the installer has completed, and you can sign in with the administrator account.
Create the scheduled task for background jobs
EspoCRM needs a recurring process for background jobs, and on Windows this is a scheduled task instead of cron. Create a task under the service account that runs the PHP executable against the EspoCRM daemon or cron script every minute, using the path and parameters in the EspoCRM server configuration documentation for your release. Confirm the task history shows successful runs, then check a queued job, such as a scheduled email, has been processed. Done means the task runs on schedule without errors and background jobs complete as expected.
How URL Rewrite and PHP handlers route EspoCRM requests
IIS terminates HTTPS for the EspoCRM site and decides, for every incoming request, whether it names a real file or should be handed to the application. Requests for files that exist on disk are served directly, and everything else is rewritten to the EspoCRM entry point. In practice, the URL Rewrite module checks whether the requested path matches a physical file or directory, and if not, rewrites it to index.php inside the public directory. The PHP handler then passes that request to PHP, which runs the application and returns the response through IIS. Each hop is a place where a misconfiguration can break routing, so the team should test the path after every change to the site, the handler mapping or the rewrite rules.
The document root must point at the public directory of the EspoCRM installation, not the folder that contains the application code. This matters because everything outside the public folder, including configuration, data, custom code and logs, is meant to be reached only by the application itself. If the site's physical path is set to the install root, a browser can request files such as configuration or internal folders directly. Deny rules for those folders are a second layer, but the safer design is to make them unreachable by construction. Confirm the exact public path for your release in the server configuration documentation before you set the site path, since the folder layout is the basis for every other rule in this setup.
Do not copy rewrite rules from a blog or an older guide. Confirm the exact rule set, the handler configuration for the PHP version you run, and the list of folders that must be denied against the current EspoCRM server configuration documentation for your release. Then verify the behavior yourself: a request for a missing path should reach the application, a request for a protected internal path should return a denial, and an upload should not be executed as a script. Record the results with the rule file version so that a later upgrade or PHP change can be checked against the same list.
Replacing cron with Windows Task Scheduler
EspoCRM relies on a recurring job runner for emails, scheduled jobs, and other background work. On Windows Server, that runner is a scheduled task instead of a cron entry, so its command, account, and failure behavior need the same care as the web server itself. The cards below cover the parts to configure and verify before the instance goes live.
The PHP command to schedule
The task runs PHP against EspoCRM's cron entry point in the installation directory, so the PHP executable path must point to the same PHP version IIS uses for the site. Use the full path to php.exe and the full path to cron.php, and set the start-in folder to the EspoCRM root. Mixing PHP versions between IIS and the task is a common cause of jobs that silently do nothing.
Trigger interval and job timing
Set a repeating trigger every minute, which matches how EspoCRM expects its job runner to be called. Confirm the interval against the current server configuration docs for your version. Consider whether the trigger starts at boot and whether repetition continues indefinitely, because a trigger that stops after a set duration will quietly halt email and scheduled jobs.
Service account and its rights
Run the task under a dedicated service account, not an administrator or a personal login. It needs read access to the EspoCRM files, write access to the data and custom directories, and permission to run PHP. Avoid storing a personal password on the task and confirm that a password change or account policy will not stop the task from running.
Failed runs, logs and overlap
Enable the option to stop a run that exceeds a time limit, and set the task to start only if the previous run has finished, so long jobs do not stack up. Check the Windows Task Scheduler history for exit codes, and review the EspoCRM log for PHP errors. Failures from a missing PHP module or a permission problem often appear only in these logs.
Large CSV imports depend on the task
EspoCRM's import documentation notes that large files are processed in the background through cron or a scheduled task. If the task is not running, a large import can appear stuck even though the upload succeeded. Test with a small import first, then with a file of realistic size, and confirm that records are created as expected before relying on the process for migration work.
Checks after a server restart
After a reboot, confirm that the task is still enabled, that its last run time updates, and that IIS and the application pool have started. Send a test email or trigger a scheduled job to prove the chain works end to end. Add this check to your maintenance runbook so it is repeated after patching windows and planned restarts.
Operating EspoCRM on Windows after go-live
How do I keep PHP and EspoCRM versions within supported ranges?
Check the supported PHP range for your target EspoCRM release before every upgrade, and keep PHP patched within that range. The EspoCRM server configuration docs list PHP 8.3 to 8.5 as the supported range for current releases, along with MySQL 8.0 or newer, MariaDB 10.6 or newer, or PostgreSQL 15. Confirm the matrix for the exact version you run, because a PHP update made for another site on the same server can move you out of range. Record the PHP version, the EspoCRM version and the database version in your change log so a later audit or upgrade starts from known facts. Track the EspoCRM release notes on the espocrm/espocrm releases page so you hear about new major versions early.
What should a backup of an EspoCRM on IIS include?
A usable backup needs both the database and the application files, taken at the same point in time. Back up the database with the tooling for your engine, and copy the EspoCRM directory, including the configuration file and the custom and data folders, plus any attachment storage if you keep uploads outside the install path. Store copies off the IIS server, encrypt them, and test a restore on a separate host at least after each upgrade. Confirm with your team how often backups run and who holds the keys. Restoring only one half, such as files without the matching database, is a common cause of broken instances.
How do I review scheduled task history for EspoCRM jobs?
Review the Windows Task Scheduler history for the EspoCRM job and the application's own job records, because either can show a failure first. Open Task Scheduler, select the task that runs the EspoCRM cron entry, and check its last run result, next run time and history tab. A non-zero result code means the PHP process failed to start or exited with an error. Compare this with the scheduled job list inside EspoCRM to see whether jobs are queuing or failing. Set a regular review, and ask whoever operates the host to confirm the task runs under an account with the right PHP and file permissions.
How do I troubleshoot email and background jobs that stop running?
Start with the scheduled task: if it has stopped, background jobs such as email sending will stop too. The EspoCRM server configuration docs state that background jobs need cron or a scheduled task, so a missing or disabled task is the first thing to check. Next, confirm the task runs the PHP binary with the EspoCRM cron script and that the account has rights to the install path. Then check EspoCRM's logs for mail transport errors, since a working job can still fail to send if outbound SMTP settings or credentials are wrong. Ask your team to confirm the log locations and retention for the version you run.
How should we plan an EspoCRM upgrade with the CLI process?
Plan the upgrade as a project: inventory extensions, customizations and PHP settings, then rehearse the change on a copy of production. The EspoCRM security docs note that upgrading through the UI is disabled by default as of version 10.0, so the command-line process is the path to plan around. Before the change, confirm the upgrade path, the PHP range and the database version for the exact target release in the official documentation, and check each installed extension for compatibility. Keep a verified backup, schedule a window, and define a rollback plan. Major releases such as 10.0.0, released on July 2, 2026, deserve a dedicated test cycle.
Can our own team run day-two operations, or do we need a partner?
Your own team can run day-two work if it has Windows Server, IIS, PHP and database skills, and a documented change process. Patching PHP, reviewing task history, maintaining backups and rehearsing upgrades are routine tasks that suit an internal operations group. A partner adds value where the team lacks PHP or IIS depth, needs a fixed-scope upgrade or wants a regular review. Engagements are usually fixed-scope with written deliverables, and ongoing support is available as a retainer. Ask any provider to state in writing what they operate, what you own and how changes are approved.
What drives the ongoing cost of running EspoCRM on Windows?
Ongoing cost depends on the staff time for patching, monitoring, backups and upgrades, plus the infrastructure and licenses you carry. The open-source edition can be downloaded and self-hosted for free, according to the EspoCRM pricing page, so the main recurring costs are Windows Server and database licensing where applicable, hardware or virtual machine capacity, and people time. Upgrade cost rises with the number of extensions and custom entities. Ask a provider for a quote that separates one-time setup from recurring operations, and confirm which tasks are included in a retainer.
Limits to confirm before choosing IIS
IIS is one of three web servers the EspoCRM server configuration docs list, and the support matrix rests on specific PHP and database pairs. The four cards below cover the items to confirm in your environment before you commit to a Windows build, since each one can change the architecture or the effort.
Exact PHP and database pairs
The docs list PHP 8.3 to 8.5 and MySQL 8.0 or newer, MariaDB 10.6 or newer, or PostgreSQL 15. Confirm which combination the exact release you plan to run supports, and check it against the release notes on the GitHub releases page before you install PHP on Windows. Record the PHP build, thread-safety setting and extensions you need, because a mismatch is the most common reason a Windows install fails at the first login.
OIDC or LDAP on IIS
Sign-in through OpenID Connect or LDAP is configured inside EspoCRM, but it depends on outbound network paths from the IIS host to your identity provider or directory. Confirm that the Windows host can reach the identity endpoints, certificate chains and LDAP ports your environment uses. Also confirm how fallback login and backchannel logout behave in your topology, and test both before cutover.
WebSocket support on IIS
Real-time updates depend on a separate WebSocket daemon and a proxy path to it. On IIS, that means confirming how the daemon runs as a Windows service or scheduled process and how requests are forwarded to it, since the supplied setup guidance centers on systemd, Nginx and Apache. Ask for a tested configuration rather than assuming the proxy and daemon work unchanged on Windows.
Advanced Pack on self-hosted installs
Workflows, Business Process Management and reports come from the Advanced Pack. The Advanced Pack page states that it is included in all EspoCRM Cloud plans, which is a separate offering from a self-hosted install. Confirm the licensing and entitlement for your self-hosted instance with EspoCRM before you design workflows or report-driven processes around it on Windows.
File storage location choices
Attachments are stored on local disk by default, so the IIS host needs enough free space, backup coverage and NTFS permissions for the storage path. If you plan to move uploads to S3 or an S3-compatible service, confirm that the chosen endpoint, credentials handling and path-style settings work from your Windows network before you go live. Decide this early, since migrating existing files later adds effort.
Questions buyers ask about EspoCRM on IIS
What does it cost to install EspoCRM on Windows with IIS?
The software is free to self-host under AGPL-3.0, so the cost is the work and the infrastructure around it. Expect a one-time cost for planning, installing and configuring PHP, IIS, URL Rewrite and the database, setting up TLS and scheduled jobs, and testing. Recurring costs are Windows Server licensing, the database, backups, monitoring and staff time for upgrades. The main cost drivers are the number of environments, whether you need identity integration such as SSO, the volume of data to migrate, and any custom entities or workflows. Ask any partner for a fixed-scope quote that lists each item separately, including what is excluded. If you compare against EspoCRM Cloud, the published price is 15 US dollars per user per month on the Basic plan (minimum 3 users), so count your user numbers over the period you plan to run the system.
How long does an EspoCRM on IIS installation take?
Duration depends on scope rather than on the base install. A single-instance installation with a standard database, TLS and scheduled jobs is the smallest case. Duration grows with PHP and database decisions, identity integration, data migration, custom entities and layouts, testing across environments and the handover to your operations team. No duration is fixed by the platform itself, so ask any provider for a timeline tied to a written scope, with milestones for environment build, data load, identity testing and go-live. Also confirm the availability of your Windows Server admins and your application owner, since waiting on access is one of the most common delays.
What must our team provide before an EspoCRM IIS build starts?
Before work starts, confirm five things. First, administrative access to the target Windows Server, or a documented build process your team will run with the provider. Second, a supported database server, such as MySQL 8.0 or newer, MariaDB 10.6 or newer, or PostgreSQL 15, with an account for EspoCRM. Third, DNS records and the certificate source for the public hostname, including whether you use an internal CA or a public one. Fourth, a named admin owner who makes decisions on roles, authentication and data. Fifth, a decision on whether the instance can reach external mail, identity and storage services. Missing any of these usually moves the start date rather than the scope.
Can an internal IT team install EspoCRM on IIS alone?
Yes, a competent Windows Server team can install EspoCRM on IIS using the official server configuration documentation, and many do. The work requires PHP installed and configured for IIS through FastCGI, URL Rewrite rules that route requests to the application, correct file permissions, a supported database, and a scheduled task that runs background jobs in place of cron. Your team should also be able to maintain PHP versions, which the documentation lists as 8.3 to 8.5, and to plan upgrades. If the team lacks PHP and IIS operations experience, or no one owns the instance after go-live, a partner can cover the gap, but the decision should rest on your staff's capacity.
When is it worth bringing in a partner for EspoCRM on Windows?
A partner is worth considering when the project carries more than a basic install. Common triggers include SSO through an identity provider, migration from another CRM, custom entities and formula-based logic, integrations with mail or telephony, and a requirement for documented controls for an assessment. A partner is also useful when you need a written scope and a repeatable build that your team can operate. DeployOpen implements, customizes, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own infrastructure, and works from a fixed scope agreed in writing. Ongoing support and upgrades are available as retainers.
What is the hardest part of running EspoCRM on IIS?
The hardest part is usually background processing and upgrades, not the first page load. EspoCRM needs scheduled jobs for background tasks, and on Windows these run through Task Scheduler rather than cron, so a missed or failing task can silently stop email, workflows and cleanup. Upgrades also need care: the newest major release, 10.0, disables upgrades through the UI by default, and PHP version changes can affect the application. Plan monitoring for the scheduled task, a tested upgrade procedure in a non-production environment, and a rollback path with verified database backups.
Should we secure EspoCRM with SSO and two-factor authentication on IIS?
For most regulated organizations, yes, but the two controls interact. EspoCRM supports OpenID Connect sign-in since version 7.3, with optional user creation on first login and mapping of identity provider groups to teams, and it also documents LDAP for Active Directory and OpenLDAP. EspoCRM's own two-factor authentication is not compatible with OIDC, so the identity provider must enforce MFA. Also restrict admin accounts to administrative tasks, enforce a password policy for local accounts, limit token lifetime, and consider IP allowlisting. Confirm the design with your security team before build, since these choices shape the access model.
How DeployOpen scopes and delivers an EspoCRM IIS installation
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including Windows Server hosts. For an EspoCRM installation on IIS, we agree the server layout, PHP configuration and scheduled job design in writing before any build work starts.
How we scope
- Engagements are fixed-scope, with the IIS sites, PHP version, database and task schedule agreed in writing first.
- The written scope names the Windows Server version, IIS modules, URL Rewrite rules and the database engine you run.
- We confirm which EspoCRM version and which extensions you need, so PHP and upgrade requirements are settled before installation.
How we build
- We configure the IIS site, FastCGI handler, PHP settings and URL Rewrite rules against the EspoCRM server requirements.
- Scheduled jobs replace cron through Windows Task Scheduler, with run accounts, triggers and logging set up and tested.
- We verify login, file permissions, background job execution and TLS on the published address before handing the system over.
How we hand over
- You receive written documentation of the IIS configuration, PHP settings, task definitions and database connection details.
- Runbooks cover backups, restores, service account rotation and the steps for applying an EspoCRM upgrade on IIS.
- Knowledge transfer sessions walk your Windows and application administrators through daily checks and troubleshooting.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the installation.
- Retainer work can cover PHP patch levels, EspoCRM version upgrades and changes to the scheduled job configuration.
- Confirm response expectations and the support hours in writing before you sign, since these are set per retainer.
