When is the free EspoCRM core enough before buying the Advanced Pack?
The free self-hosted EspoCRM core is enough when the CRM's job is to hold account, contact and opportunity records, control who can see them, and let other systems sign in and connect. Records, role-based permissions and the REST API sit in the AGPL-3.0 core. Sign-in can run through OpenID Connect, which EspoCRM supports since version 7.3 with optional user creation on first login and mapping of identity provider groups to teams, or through LDAP, including Active Directory and OpenLDAP. Before you decide, map each requirement to a named core feature and test it on a staging instance. Note that EspoCRM's own two-factor authentication is not compatible with OIDC, so confirm where multi-factor checks will happen in your identity provider.
You need the Advanced Pack when the team needs reports, business process management or workflows. Sales teams that quote, invoice, track inventory, manage subscriptions or take payments need the Sales Pack as well. The Advanced Pack is included in all EspoCRM Cloud plans, so a team that wants these features without running the extension itself may compare the cloud route on the EspoCRM pricing page. Ask the vendor how each paid extension is licensed for a self-hosted instance, including the term, renewal and what happens to the features when a license lapses, and put those answers into the quote alongside the per-user cost.
A practical test is to write down the three most common automations your team expects, such as stage-change notifications, approval steps or follow-up tasks. If those need multi-step logic or approvals that span records, the paid packs are the likely path. Formula Script can handle before-save logic in the Entity Manager, but workflows and BPM are the paid features that run multi-step processes, so confirm which of your rules fall on each side. Whatever you choose, plan the cron or scheduled task that background jobs need, as EspoCRM's server configuration requires it. Ask any implementation partner to price the pack licenses and the testing of workflows as separate line items in a fixed-scope written proposal.
Which EspoCRM capabilities sit in the free core and which need the Advanced Pack or Sales Pack
This table maps each capability to the free self-hosted core, the Advanced Pack or the Sales Pack, based on EspoCRM's documented split. Use it to see which paid extension a planned process depends on, and treat the notes as the items to confirm with EspoCRM before you commit to a design.
| Capability | Free core (AGPL-3.0) | Advanced Pack | Sales Pack |
|---|---|---|---|
| Reports | Not in the documented free core split | Provides reports | Not in the documented Sales Pack split |
| Business process management and workflows | Not in the documented free core split | Provides BPM and workflows | Not in the documented Sales Pack split |
| Formula Script | Documented for before-save scripts in the Entity Manager; confirm which hooks ship in core | Used in workflows and BPM | Not documented as a Sales Pack feature |
| Quotes and invoices | Not in the documented free core split | Not in the documented Advanced Pack split | Adds quotes and invoices |
| Products and inventory | Not in the documented free core split | Not in the documented Advanced Pack split | Adds products and inventory |
| Purchases and subscriptions | Not in the documented free core split | Not in the documented Advanced Pack split | Adds purchases and subscriptions |
| Payments | Not in the documented free core split | Not in the documented Advanced Pack split | Adds payments; confirm the payment provider scope with EspoCRM |
| OIDC and LDAP sign-in | Documented; confirm no extension gates it for your version | Not listed as an Advanced Pack feature | Not listed as a Sales Pack feature |
| REST API (API key, HMAC, basic) | Documented with API users and role permissions; confirm any edition limits | No pack split documented; confirm with EspoCRM | No pack split documented; confirm with EspoCRM |
What reporting and workflow automation require from the Advanced Pack
The Advanced Pack is the paid extension that adds reports, Business Process Management (BPM) and workflows to EspoCRM. Before you budget for it, separate the automation your team needs from the automation the core already gives you. Formula Script is EspoCRM's built-in scripting language, and it runs in before-save scripts configured in the Entity Manager, in API before-save scripts, and inside workflows and BPM. Some of that scripting sits in the free core, so the question is which of the features that depend on it are reachable without the pack. Confirm this against the version you plan to deploy, because the boundary between core and paid extensions is set by the vendor and can change between releases.
The practical work usually falls into three groups: approval steps (for example, a discount above an agreed threshold routed to a sales manager), follow-up tasks created when a lead changes stage, and management reporting that a sales lead reviews each week. Approval routing and multi-step process flows are the parts most teams expect the pack to provide, so map each one to a concrete feature and check whether it is a workflow or a BPM flow in your version. Field-level logic that sets values on save, such as calculating a deal category, is a case to test on the core first, since before-save scripts are part of the free product. Illustratively, if a team only needs a single status change plus an email, it may find the core sufficient; a multi-branch approval chain with reporting dashboards is where the pack becomes the deciding factor.
Before you buy, run a short proof of concept on a test instance. Build one approval flow, one follow-up task and one report that management actually uses, then record which steps worked on the core alone. Ask the vendor or an implementation partner to confirm, in writing, which automation is included in your edition and version, and how the pack's licence is tied to the instance it is installed on. Also plan for the upkeep: workflows and scripts become part of your change process, so each one needs an owner, a test and a rollback path during upgrades.
How licensing, support and updates differ between the free core and paid packs
The free EspoCRM core and the paid packs sit under different terms, and those terms shape what you can run, how you get help and how upgrades reach you. The cards below cover the points to settle in writing before you commit to a pack for a self-hosted deployment.
AGPL-3.0 core license
The EspoCRM core is licensed under AGPL-3.0, according to the license metadata of the espocrm/espocrm repository. The license governs the free code you download and run. Before you modify the core for internal use or offer it to users over a network, have your legal team confirm which AGPL-3.0 obligations apply to your deployment, including whether any changes must be published.
Free self-hosted download
The open-source edition can be downloaded and self-hosted for free, according to the EspoCRM pricing page. Your costs are the infrastructure, the database, the people who install and patch the platform and any outside help you buy. Ask whether the free edition receives the same core releases as the cloud product, and which upgrade path your team will follow.
Official paid add-ons
The Advanced Pack adds reports, business process management and workflows, and the Sales Pack adds products, quotes, invoices, purchases, subscriptions, inventory and payments, per the EspoCRM features page. Both are paid extensions on top of the free core, not part of the AGPL-3.0 download. Map each feature your process needs to a pack before you budget.
Advanced Pack in cloud plans
The Advanced Pack is included in all EspoCRM Cloud plans, according to the EspoCRM pricing page. Buying a cloud plan therefore removes a separate pack purchase for reports and workflows, while the Sales Pack is not described as included. Compare the per-user cost of a cloud plan against the license and hosting cost of running the free core and packs yourself.
Term-limited, per-instance pack licenses
Paid extensions for self-hosted instances are tied to the instance they are installed on. Confirm in writing how long a self-hosted pack license runs, what happens when it expires, whether a staging or disaster recovery instance needs its own license and what your access to pack updates looks like during and after the term. Do not assume the cloud terms apply to self-hosting.
Vendor support terms to confirm
Ask EspoCRM, in writing, what support is included with a pack, what response is offered, which versions are covered, and whether support extends to self-hosted installs and to the Sales Pack as well as the Advanced Pack. Also confirm how pack compatibility is maintained across core major releases. DeployOpen does not provide vendor support for EspoCRM or its packs, and the terms must come from the vendor.
What enterprise sign-in and API access the free core already covers
The free self-hosted EspoCRM core already includes OpenID Connect sign-in, which has been supported since version 7.3. Administrators can enable optional user creation on first login, map identity provider groups to EspoCRM teams, configure backchannel logout and keep a fallback login method for break-glass access. LDAP authentication is also documented, covering both Active Directory and OpenLDAP. A team whose main requirement is single sign-on tied to an existing directory should first test these settings against its own identity provider before assuming a paid extension is needed. Confirm the group claim format, the team mapping rules and the fallback method against the EspoCRM OIDC documentation, because a misconfigured group mapping can grant the wrong teams to new users.
Plan for one limitation before rollout: EspoCRM's own two-factor authentication is not compatible with OIDC. If your policy requires a second factor, the control has to come from the identity provider, and you should document where that enforcement sits in your access review. Also decide whether the fallback login stays enabled. Keeping it helps when the identity provider is unavailable, but it is a second path into the application that needs its own password policy, monitoring and owner.
For integrations, the REST API supports API key, HMAC and basic authentication through dedicated API users whose access follows role-based permissions. The documentation describes HMAC as the most secure method and basic authentication as not recommended, so new integrations should use HMAC or a well-scoped API key, with a separate API user per integration. Create one API user for each system, give it only the roles it needs, and rotate its credentials on a schedule your security team can audit. Review the EspoCRM API documentation to confirm which method suits each consumer, since some client tools may only support basic authentication.
Which edition fits a sales team, an operations team or a compliance-led team
Consider a small illustrative sales team that mainly needs accounts, contacts, leads and activity history in one place. For this work the free self-hosted EspoCRM core is usually the starting point, since it is licensed under AGPL-3.0 and can be downloaded and self-hosted for free. The team may not need any paid extension at first.
- Core entities: Accounts, contacts, leads, opportunities and activity records sit in the free core and cover day-to-day pipeline tracking.
- Basic reporting: Simple list views and filters may be enough, but scheduled or cross-entity reports are part of the Advanced Pack, so check whether the team needs them.
- Email and calendar: Confirm which mail integrations the team needs, since Google, Outlook and other connectors are separate official extensions.
- Hosting effort: The team still needs a PHP web server, a supported database and cron for background jobs, so confirm who will run those.
Before committing, ask the team which reports leadership reads each week and whether they can be built from the core views, then confirm the required extensions with EspoCRM's current feature list.
Consider an illustrative operations team that needs approval steps, management reports and quotes that follow a fixed sequence. This team usually moves beyond the core. The Advanced Pack adds reports, Business Process Management and workflows, and the Sales Pack adds products, quotes and invoices.
- Approvals and routing: Workflows and BPM from the Advanced Pack handle multi-step approvals and automatic assignment.
- Scripted rules: Formula Script can drive before-save logic and workflow conditions, which helps with field validation and status changes.
- Quotes and invoices: The Sales Pack covers products, quotes and invoices, so check whether the team needs inventory or payments as well.
- Licensing model: Paid extensions are licensed per instance and are time-limited, so the team should confirm renewal terms and the cost of each pack.
- Upgrade planning: Extensions must match the core version, so test them against the release line before upgrading.
Before committing, have the team write down two or three approval flows and confirm with EspoCRM that each one runs in the Advanced Pack, then request a quote that includes pack licenses and the cost of testing upgrades.
Consider an illustrative regulated team that must show who signed in, how access was granted and which actions were recorded. The free core provides several identity options, but the team should confirm each control before relying on it for audit evidence.
- Single sign-on: EspoCRM supports OpenID Connect since version 7.3, with optional user creation on first login, group-to-team mapping and backchannel logout.
- Directory sign-in: The documentation describes LDAP authentication for Active Directory and OpenLDAP, which may suit teams with an existing directory.
- Two-factor limits: EspoCRM's own 2FA is not compatible with OIDC, so the team must confirm how the identity provider enforces multi-factor sign-in.
- API access: Dedicated API users with role-based permissions support API key, HMAC and basic authentication, and the docs describe HMAC as the most secure option and basic authentication as not recommended.
- Evidence: Confirm which access and change records the team can export and retain, and whether any paid extension is needed for them.
Before committing, ask the security team to test sign-in, deprovisioning and API access in a staging instance, and confirm with its assessor which records they will accept as evidence.
What each edition costs to run, and which costs are published
This table sets the free EspoCRM core against the Advanced and Sales Packs across license, cloud pricing, self-hosting effort and services. Only EspoCRM Cloud per-user prices are published, so read the self-hosted pack rows as questions to confirm with EspoCRM before you budget.
| Cost component | Free self-hosted core | Advanced and Sales Packs |
|---|---|---|
| Software license | AGPL-3.0, free to download and self-host per the EspoCRM pricing page | Official paid extensions on top of the free core, licensed separately from the AGPL core |
| EspoCRM Cloud price | Not applicable, the cloud service is a separate purchase | Cloud Basic 15, Enterprise 25 and Ultimate 69 US dollars per user per month (minimums 3, 5 and 10 users), Advanced Pack included in all plans |
| Self-hosted pack purchase | None required for the core | Not published. Confirm the price, term and per-instance scope with EspoCRM before purchase |
| Hosting and database | Your servers, PHP 8.3 to 8.5 and MySQL, MariaDB or PostgreSQL, plus cron for background jobs | Same stack, plus the extension must be supported on your installed EspoCRM version. Confirm this |
| Backups and upgrades | Your team runs backups and upgrades, or uses the install script utilities | Pack renewals or license changes may follow version upgrades. Confirm renewal rules and upgrade paths in writing |
| Implementation services | Quoted by DeployOpen from a written scope, covering hardening, integration and training | Quoted separately from the pack license. Include configuration of reports, workflows and BPM in the scope |
How to move from the free core to the Advanced Pack and back
This sequence moves an EspoCRM instance from the free AGPL core to the Advanced Pack, or back again, without losing records or breaking the workflows and reports the team depends on. The result is a tested change with a backup and a written rollback path.
Inventory workflows, reports and sales records
The CRM administrator and a sales operations lead list every workflow, report, dashboard and BPM-style approval the team uses today, along with the entities and fields they touch. Note which of these run without any extension and which depend on the Advanced Pack, since only the paid pack adds reports, business process management and workflows to the free core. The step is done when the list is agreed and each item is tagged as core or pack-dependent.
Confirm pack license terms and version compatibility
Before buying or activating anything, the instance owner asks EspoCRM which Advanced Pack license applies to the instance, how long it runs, and whether the pack build matches the EspoCRM 10.0 line your instance runs. Confirm the license is per instance, what happens at expiry, and whether a pack can be installed on a self-hosted core outside EspoCRM Cloud. The step is done when you hold written answers and a version match is confirmed.
Take a full backup before any change
The administrator takes a database dump and a copy of the EspoCRM files, including custom entity definitions, layouts and formula scripts, before installing anything. Store the copy outside the application host and confirm it can be read. The step is done when a restore test to a separate environment has succeeded, so the rollback point is proven rather than assumed.
Install and configure the pack in staging
A platform engineer installs the Advanced Pack in a staging copy built from the production backup, using the same PHP, database and web server versions as production. The administrator then recreates or imports the pack-dependent reports and workflows and checks that the Formula Script used in before-save scripts and workflows still runs. The step is done when the staging instance loads cleanly and the configuration matches the inventory.
Test workflows and BPM against real records
Sales operations runs each pack-dependent workflow and approval on copies of live records, including edge cases such as missing fields, reassigned owners and records already in a stage. Compare results with the expected outcome from the inventory and log every mismatch. The step is done when every workflow has a signed-off test result and the team agrees the reports match the figures they use today.
Apply the change to production in a window
The administrator schedules a maintenance window with the business owners, takes a fresh backup immediately before the change, and installs the pack in production using the same steps proven in staging. Confirm that the scheduled job for background tasks still runs, because workflows depend on it. The step is done when production passes the same smoke tests as staging and the change record is closed.
Plan the rollback for a lapsed or removed license
The team writes the rollback path before it is needed: which backup restores the instance, which workflows stop running if the pack license lapses, and who informs users that reports and approvals are unavailable. Ask EspoCRM what happens to pack data and configuration when a license ends, and decide whether to keep the pack entities in place or export them. The step is done when the runbook is approved and a restore has been rehearsed in staging.
What do buyers ask about EspoCRM editions, cost and effort before hiring help?
Can we run EspoCRM without buying any paid pack?
Yes. The open-source EspoCRM core is licensed under AGPL-3.0 and can be downloaded and self-hosted for free, according to the EspoCRM pricing page. The core covers contacts, accounts, leads, opportunities and the standard entity model. What the core does not include is the reporting, business process management and workflow functions of the Advanced Pack, or the products, quotes, invoices and inventory functions of the Sales Pack. If your sales process depends on those, plan for them from the start. Confirm with the vendor which features you need before you assume the core is sufficient.
What does an extension add to our monthly bill?
Self-hosted extensions are paid per instance and are time-limited licenses, so the cost is not a per-user monthly fee on your own servers. The EspoCRM pricing page lists the cloud alternative at 15 US dollars per user per month on the Basic plan (minimum 3 users), 25 dollars on Enterprise (minimum 5 users) and 69 dollars on Ultimate (minimum 10 users), with the Advanced Pack included in all cloud plans. To price a self-hosted setup, ask the vendor for the current license terms, renewal rules and what each pack costs for your instance. Add your own hosting, backup and staff time to that figure.
How long does it take to set up the Advanced Pack?
The supplied facts do not give a setup duration, so treat any number you hear as unverified. Effort depends on how many workflows, reports and business processes you need, how much of your data model you customize, and whether your team has already built Formula Script logic for before-save scripts, workflows or BPM. Simple reports and a few workflows are a small task. A full approval chain across several entities is a larger one. Ask any implementation partner for a fixed-scope written plan that lists the workflows and reports in scope before work starts.
What skills does our team need to run EspoCRM itself?
EspoCRM runs on PHP 8.3 to 8.5 with MySQL 8.0 or newer, MariaDB 10.6 or newer, or PostgreSQL 15, on Apache, Nginx or IIS. Background jobs need cron or a scheduled task. Your team needs people who can patch the PHP runtime, manage the database, configure the web server, schedule backups and apply upgrades, and who can run the Formula Script logic that customizations depend on. EspoCRM also provides an installation script for Ubuntu, Debian and Linux Mint that deploys a Docker-based stack with Nginx and MariaDB, plus a command.sh utility for backups, restores and upgrades. Confirm that the script fits your hosting policy before you rely on it.
Do we need a consultant for the first EspoCRM install?
Not always. A team with PHP, database and web server experience can install the free core from the documentation or with the installation script. A consultant adds the most value when the install must meet internal security standards, when identity integration is required, or when the data model and packs must be set up before go-live. Identity options include OpenID Connect since version 7.3 and LDAP, including Active Directory and OpenLDAP. Ask any provider for a written, fixed-scope deliverable list that names hardening, backup testing and handover documentation, so you can compare quotes on the same basis.
When does EspoCRM Cloud make more sense than self-hosting?
EspoCRM Cloud fits when you want to avoid running servers, patching PHP and managing backups, and when your user count is small enough that the per-user prices suit your budget. Using the figures on the EspoCRM pricing page, the cloud Basic plan starts at 15 US dollars per user per month with a minimum of 3 users. Self-hosting fits when data residency, network isolation or internal control rules require your own infrastructure, and when your team already runs PHP and database services. Compare the total cost of your own staff time against the cloud subscription, and check the plan limits and server locations before you decide.
What does the team need to change when upgrading EspoCRM?
Upgrades touch the core, your customizations and any installed packs, so the effort grows with the number of custom entities, workflows and Formula Script logic. Test each upgrade in a copy of production first, back up the database and files, and confirm that each installed extension supports the target version. EspoCRM's current line is 10.0, with 10.0.10 released on October 14, 2026, according to GitHub releases, so plan for the release you will actually run. Ask any provider how they schedule upgrades, test them and document the rollback path, and whether that work is covered by a retainer or a one-off scope.
How DeployOpen scopes, delivers and supports EspoCRM with or without the paid packs
DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For EspoCRM, that means first deciding with you whether the free AGPL-3.0 core covers your workflows, or whether the Advanced Pack, the Sales Pack or both belong in the written scope before any work starts.
How we scope
- Map each required workflow, report and quoting or invoicing need to either the free core or a named paid extension.
- Confirm the license terms, edition and per-instance scope of any paid pack you plan to use before committing.
- Agree deliverables, timelines and exclusions in writing, since most engagements are fixed-scope.
How we build
- Configure entities, layouts, roles and teams in the free core, and document where Formula Script or workflows are used.
- Connect OpenID Connect or LDAP sign-in to your identity provider, and test fallback login and group-to-team mapping.
- Test API access with dedicated API users and the authentication method your integrations need, checked against your permission model.
How we hand over
- Deliver a runbook covering the PHP, MariaDB or MySQL stack, cron jobs, backups and restores in your environment.
- Document which features depend on a paid extension, so licensing renewals and upgrades stay visible to your team.
- Walk your administrators through permissions, extension configuration and the upgrade steps they will repeat.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the build.
- Review EspoCRM release notes with you before upgrades, so pack compatibility is checked before anything changes in production.
- Ask us to confirm pack licensing terms and renewal dates with EspoCRM directly, since those sit outside our scope.
