Salesforce alternative that runs on premises or air-gapped

Why an air-gapped Salesforce alternative is a different problem

Salesforce Sales Cloud runs only as a cloud service, so a defense, government or critical-infrastructure team that must keep CRM data on its own servers or in a disconnected network has to start with a different question. SuiteCRM 8, EspoCRM and Odoo Community can all be hosted on your own infrastructure, but only after the team plans three things: offline installation, the transfer of updates and extensions into a host with no internet route, and identity integration with your directory. The constraint shapes the choice more than feature depth does, so this page is not a feature comparison with Salesforce.

Each candidate handles the constraint differently. EspoCRM ships an installation script built for Ubuntu, Debian and Linux Mint that deploys a Docker-based stack, which means your team must mirror the images, packages and PHP dependencies into the enclave before anything runs. SuiteCRM 8 has a documented compatibility matrix covering PHP, Apache, MariaDB and MySQL versions, so the offline build must match those exact components. Odoo Community is LGPLv3, but its upgrade service and standard support apply to on-premise Enterprise subscriptions, so your update path depends on which edition you run. Confirm with each vendor what artifacts they supply for disconnected builds, since public documentation alone does not settle that.

Plan the update and identity paths before you choose a product. Each security patch, minor release and extension has to be verified, signed off and carried across a transfer boundary, and the release cadence sets how often that happens. SuiteCRM 8 minor releases arrive roughly every eight weeks, while Odoo SaaS versions come every two to three months. Identity also needs early design: SuiteCRM 8 supports LDAP and SAML, EspoCRM supports OpenID Connect and LDAP, and Odoo documents LDAP. Ask each candidate how its sign-in flows behave when the identity provider is inside the same disconnected network, and test single logout before you rely on it.

What an on-premises or air-gapped CRM must support

A CRM that runs inside a disconnected boundary has to work without calling home, install from media you can verify, and keep its patch path under your control. The cards below set out the requirements that follow from that constraint, with the version and stack facts to check against your own host image before you commit to a product.

Every component inside the boundary

The web tier, the PHP or Python runtime and the database must all run on hosts you control, with no component reaching a vendor endpoint during normal operation. Map each process and its listening ports on a test host, then confirm that login, search, reporting and attachment handling still succeed with outbound traffic blocked. Pay attention to features that quietly fetch fonts, maps, license checks or telemetry from the internet.

Supported runtime and database versions

Each candidate publishes its own matrix of supported PHP, database and web server versions, and these change between releases. SuiteCRM 8.10 supports PHP 8.2, 8.3 and 8.4 with Apache 2.4 and MariaDB or MySQL versions listed in its compatibility matrix. EspoCRM lists PHP 8.3 to 8.5 with MySQL 8.0 or newer, MariaDB 10.6 or newer or PostgreSQL 15. Check these against the operating system packages your hardened image already ships, because a mismatch often forces a host rebuild.

Mirrored packages and offline install media

An air-gapped host cannot pull packages from public repositories, so the PHP extensions, Composer dependencies, container images and database packages must be mirrored into the network before installation. Ask each vendor which artifacts an offline install needs and whether they are published as archives. EspoCRM's install script deploys a Docker-based stack that pulls images at build time, so an offline variant needs its images staged in advance, and that work belongs in the project plan.

Controlled patch and release path

Updates arrive on a schedule you do not set, so an air-gapped team needs a repeatable way to bring signed releases across the gap, test them and promote them. SuiteCRM publishes minor 8.x releases roughly every eight weeks and patch releases with only security and bug fixes, which suits a monthly review cycle. Confirm how each vendor publishes checksums and whether security patches reach you without a commercial agreement.

Extensions and customizations reviewed offline

Add-ons, custom modules and scripts become part of your change record, so each one needs to be obtained, reviewed and installed through the same controlled path as core releases. EspoCRM's paid Advanced Pack and other official extensions are downloads that must be brought in from outside the boundary and checked. Keep a register of every extension with its source, version and approver, and retest it whenever the core platform changes.

Authentication that stays on your network

Sign-in should use directory services inside the boundary rather than a vendor-hosted identity service. SuiteCRM 8 supports LDAP and SAML, and EspoCRM supports LDAP for Active Directory and OpenLDAP along with OpenID Connect against an identity provider you run. Verify that your identity provider is reachable from the CRM subnet and that its logout behavior is understood, since at least one SuiteCRM SAML configuration does not end the application session when a user logs out at the identity provider.

Which open-source CRM fits which offline environment

A fully air-gapped host has no route to the internet, so every container image, operating system package, PHP library, database engine and update must be carried in and verified before use. The install method decides how much has to be mirrored, so compare the candidates on that point first.

SuiteCRM 8: The stack is a Symfony backend with an Angular frontend on Apache 2.4, PHP 8.2 to 8.4 and MariaDB or MySQL. Each layer needs an offline copy. Sign-in can use LDAP with AUTH_TYPE=ldap or SAML with AUTH_TYPE=saml, and the directory or identity provider must sit inside the enclave.
EspoCRM: The documented install script targets Ubuntu, Debian and Linux Mint and builds a Docker stack with Nginx and MariaDB. Its image pulls and package downloads must be redirected to local repositories, and the team should confirm the full list of fetches with EspoCRM first.
Odoo Community: It is licensed under LGPLv3 and can be installed from source, which makes the offline build easier to inspect. Enterprise needs a subscription code, and on-premise use with custom modules sits on the Custom plan. Enterprise source is not publicly available, so offline rebuilds depend on vendor access.
Updates by media: Patches enter the enclave as verified bundles on approved media. SuiteCRM patch releases carry only security and bug fixes, and minor 8.x releases arrive roughly every eight weeks. Set a defined intake schedule that tests each bundle on a staging host first.
Lost integrations: Cloud email, hosted e-signature and vendor telephony generally stop working inside the enclave, so connectors must point at services in the same network.

Before committing, ask each vendor in writing for every external host its installer, runtime and update checks contact, then rehearse the install on a disconnected staging host.

Open-source options compared for offline deployment

This table compares SuiteCRM 8, EspoCRM and Odoo on-premise against the offline constraint, showing how each installs, licenses and receives updates. Read each row for the trade-off that matters most to a disconnected host, since update paths and support windows decide how long an air-gapped instance stays current.

Option	How it meets the offline constraint	Trade-offs
SuiteCRM 8	Self-hosted on Linux with PHP 8.2 to 8.4, Apache 2.4 and MariaDB or MySQL; LDAP or SAML sign-in can use your internal directory	Licensed under AGPLv3; no SuiteCRM 8 extended support release has been nominated yet, so plan patch and minor release intake; SAML logout at the identity provider does not end the SuiteCRM session
EspoCRM	Installs on PHP 8.3 to 8.5 with MySQL, MariaDB or PostgreSQL; a script can deploy a Docker-based stack, and LDAP and OIDC are documented	Licensed under AGPL-3.0; major releases are infrequent, and the OIDC docs say EspoCRM's own 2FA is not compatible with OIDC; cron is required for background jobs
Odoo Community	Fully open source on Python and PostgreSQL, with no subscription needed to install and run it on your own servers	Licensed under LGPL-3.0; no access to the upgrade service and no paid extended support, so you own every version move and security patch
Odoo Enterprise on-premise	Installed on your own servers and activated with the subscription code; packaged installers and source installation are documented	Requires an Enterprise subscription and only the Custom plan allows on-premise hosting; standard support covers three years after a major release, and security patches come only during that window

How updates and extensions reach an air-gapped host

Every update reaches an air-gapped host through the same controlled path: release artifacts are downloaded on a connected system, checked against published checksums and signatures where the project provides them, carried across an approved media or data diode process, loaded into a staging mirror, tested there, and only then promoted to production. The staging copy should hold a restored snapshot of production data so that migrations run against realistic records. Keep a written record of each transfer, including the artifact version, hash and the person who approved the import, because that record becomes evidence during an assessment.

The release type determines how much testing the transfer needs. SuiteCRM 8 patch releases contain only security and bug fixes and make no database changes, so they are the simplest to stage. Minor 8.x releases arrive roughly every eight weeks and can change the database, so each one needs a full staging run. EspoCRM ships major versions such as 10.0.0 and point releases such as 10.0.10, and the upgrade path should be confirmed against the release notes for each. Odoo is different: its upgrade service moves a database to a newer supported version through an upgraded test database, and on-premise use requires an Enterprise subscription, so Community deployments have no vendor upgrade path and must plan migrations themselves.

Extensions follow the same path as the core. EspoCRM's Advanced Pack, which provides reports, Business Process Management and workflows, must be downloaded, transferred, installed and tested in staging alongside each core upgrade, and its compatibility with the target core version should be confirmed before the transfer. Moving from SuiteCRM 7 to 8 is a migration, not an upgrade: a new SuiteCRM 8 environment is built and the 7 data is moved into it, with the staging instance, file and database backups, and a review of customizations under the public/legacy folder that the migration docs call for. Budget that work as a project, not a patch window.

Which integrations you lose when the CRM leaves the cloud

Every integration your CRM depends on needs an owner, a route and a decision before the cutover. Salesforce integrations often sit on AppExchange apps, cloud email and calendar sync, and SaaS connectors that call vendor-hosted services over the internet. On a disconnected or tightly egress-filtered host, none of those calls will work. Start by listing every connector, plugin, scheduled job and inbound webhook, then classify each one as internal (runs entirely on your network), gateway-mediated (reaches an outside service only through a controlled proxy or relay you operate), or removed. Ask each vendor whether its extension needs outbound connectivity and whether it can run without a cloud account.

On the open-source side, EspoCRM's official Google, Outlook, MailChimp, Zoom and Stripe extensions are the clearest examples of outbound-dependent connectors. Each needs a route to the provider's service, so an air-gapped host either loses that feature or needs an internal substitute, such as a mail relay inside your network for outbound notifications or a local calendar service for scheduling. Confirm the exact network endpoints each extension calls before you approve it. Official extensions such as the Advanced Pack should be checked the same way, since reports and workflows are internal but licensing and update checks may not be.

Identity integrations carry the sharpest surprises. SuiteCRM 8.7.0 and later does not support IdP-initiated logout or POST binding to the logout service, so ending a session at your identity provider does not end the SuiteCRM session. Your runbook for leavers and shared workstations must include closing the CRM session directly and setting an appropriate session timeout. EspoCRM's own two-factor authentication is not compatible with OIDC sign-in, so decide where second factors are enforced (at the identity provider or through LDAP or OIDC policy) before you disable local 2FA. Test both flows against a staging instance, not production.

How to deploy a self-hosted CRM inside an air-gapped network

This sequence takes a CRM from a version check and offline mirror through staging, identity, restore testing and data migration to a cutover with a rollback path that your team has already rehearsed.

Confirm target versions against vendor matrices
Your architect and the application owner select the CRM and its release line, then check the operating system, PHP or Odoo runtime, and database versions against the vendor's published compatibility matrix. For SuiteCRM 8.10, that matrix lists PHP 8.2, 8.3 and 8.4, Apache 2.4, MariaDB 10.6 to 11.8 and MySQL 8.0 and 8.4. For EspoCRM, confirm PHP 8.3 to 8.5 and a supported database. Done means a signed version sheet that names every component and its exact release, reviewed by security before any download begins.
Mirror packages, images and dependencies into the enclave
The platform team builds an internal repository that holds OS packages, container images, PHP or Python dependencies, and the application release archive, all downloaded on a connected staging network and transferred through your approved media process. Record checksums for every artifact and keep the manifest with the change record. Installs should then resolve only against the internal mirror. Done means a test host inside the air-gapped segment installs the full stack with no outbound network calls, which you can confirm in firewall logs.
Install and harden on a staging host
The infrastructure team installs the application on an isolated staging host using the vendor's documented procedure. For EspoCRM, this may be the installation script, which deploys a Docker-based stack with Nginx and MariaDB, but confirm that the script's own package sources are replaced with your mirror before use. Apply your hardening baseline, TLS certificates from your internal CA, and restricted file permissions. Done means the application loads over your internal certificate and the administrator can complete first login.
Connect directory sign-in and test it
The identity team connects the staging instance to your internal directory. SuiteCRM 8 supports LDAP through AUTH_TYPE=ldap and SAML through AUTH_TYPE=saml, and EspoCRM supports LDAP, including Active Directory and OpenLDAP, as well as OpenID Connect. Test with a pilot group, confirm role mapping, and verify fallback access for administrators. Note that the SuiteCRM 8.7.0+ SAML implementation does not end the CRM session on identity provider logout, so document that gap for your security team. Done means each test account signs in with the expected role and the logout behavior is recorded.
Schedule jobs and prove a backup restore
The administrator configures scheduled tasks, such as cron for EspoCRM background jobs, and sets the backup routine for files and database. Then restore the most recent backup to a separate host inside the enclave and check record counts, attachments, users and scheduled jobs against the source. Confirm that the backup target sits inside the enclave and that retention meets your policy. Done means a restored copy opens, runs its background jobs, and matches the source on defined checks.
Migrate and validate data on staging
The data team extracts records from the legacy system and loads them into the staging instance. For SuiteCRM 7 to 8, the documented path is a migration, not an upgrade: bring the 7 instance to 7.14.x or later, back up files and the database, set up a new SuiteCRM 8 environment, and move the data across. Review customizations because the migration may remove non-core files under the public/legacy folder. Reconcile counts and sample records with business owners. Done means signed reconciliation reports show each object moved with agreed exceptions.
Cut over with a rehearsed rollback
The change board approves a cutover window, freezes the legacy data, runs the final migration, and switches users to the enclave instance. Keep the legacy environment readable until the new system passes acceptance checks, and rehearse the rollback steps on staging beforehand. Confirm that users can reach the system only from approved networks. Done means the business owner accepts the production system in writing, and the rollback runbook has been run once on staging.

Evidence assessors ask for under this constraint

An air-gapped CRM is judged on paper as much as on the server. The records below show what the system does, how software and data enter and leave, and how changes are controlled. DeployOpen prepares these artifacts, but independent auditors and accreditation bodies issue any assessment or accreditation decision.

Architecture and data-flow records

Assessors want diagrams and written descriptions showing every component of the CRM, its database, mail relay, identity source and backup target, and every path data can take. The key claim is no runtime egress: the host has no route to the internet, and any outbound connection is named and justified. Check that the record lists the PHP or Symfony services, the database and any SMTP or LDAP endpoints, and that network rules match the diagram.

Transfer and media-handling procedure

Because updates and extensions arrive on removable media or through a cross-domain transfer, the procedure must say who may bring media in, how files are scanned, hashed and logged, and how media is sanitized or destroyed afterward. Include the staging step where packages are checked on a disconnected test host before production. Confirm the procedure with your accreditor, since acceptable media rules vary by authority and classification level.

Signed package inventories and version records

Keep a current inventory of every package, library and container image the CRM runs, with versions and checksums, and check the publisher's signatures before installation. For SuiteCRM 8.10, record the release (8.10.2 is the latest stable version in the SuiteCRM-Core repository) and the PHP, Apache and MariaDB versions the compatibility matrix lists. Assessors will compare the inventory against vulnerability advisories when they review the system.

Backup and restore test results

A backup is only evidence once a restore has been tested. Keep dated records of restores to a separate test host, including the database and file store, the time taken, and the checks that confirmed records and attachments came back intact. Note that Zoho CRM's own backups exclude email, documents and integration data, which is a reminder to confirm what your chosen platform's backup covers. The SuiteCRM migration docs also advise backing up files and database before any change.

Identity and access configuration exports

Assessors check who can sign in, how, and with what rights. Export the LDAP or SAML settings (AUTH_TYPE=ldap or AUTH_TYPE=saml in SuiteCRM 8), the role and team mappings, and the list of service or API accounts. Record a known gap: the SuiteCRM 8.7.0+ SAML implementation does not end the CRM session on identity provider logout, so document the session timeout and the compensating control you chose.

Change records for each patch

Each security or bug fix needs a change record: the advisory or release notes that prompted it, the test run on staging, the approver, the install date and the rollback plan. SuiteCRM describes patch releases as containing only security and bug fixes with no database changes, which helps scope the review, but you still need to confirm that for each package you install. Keep the records with the inventory so the two can be matched during an assessment.

Questions buyers ask before choosing an offline CRM

Can SuiteCRM, EspoCRM or Odoo install fully offline?

All three are self-hostable, so each can be installed on a host with no route to the internet, provided the packages and dependencies are staged in advance. SuiteCRM 8 runs on PHP, Apache and MariaDB or MySQL on Linux, Unix or macOS, according to its compatibility matrix. EspoCRM needs PHP 8.3 to 8.5, MySQL 8.0 or newer, MariaDB 10.6 or newer or PostgreSQL 15, plus cron for background jobs. Odoo is built on Python and PostgreSQL, and its on-premise Enterprise databases are activated by entering a subscription code. Confirm with each vendor that the installer does not call external services at runtime, because some features, such as email delivery, maps or license checks, may need an outbound path. Your own test in an isolated network is the only reliable proof.

What drives the cost of an air-gapped CRM deployment?

Cost splits into components, each with a different payer. Software licenses are often zero for SuiteCRM and EspoCRM, while Odoo Community is free but Enterprise requires a subscription, and that subscription is what on-premise use of Enterprise features depends on. Hardware or virtual machines, database and backup storage, and the transfer process for packages and updates are recurring or one-time infrastructure costs. Identity integration with LDAP or SAML, admin time for patching, and staff time for a secure transfer workflow are ongoing. Ask any implementer for a written quote that lists each component separately, including who pays for media handling, staging and verification of each update bundle.

How long does an offline CRM migration take?

No duration can be stated here without a written scope, because it depends on data volume, custom objects, integrations, approval cycles and how many environments your network needs. A typical plan covers building the isolated environment, staging packages, mapping data, testing in a staging instance and a cutover window. SuiteCRM 7 to 8 is a migration rather than an upgrade, which adds steps for bringing the 7 instance to the latest 7.14.x or later first. Ask for each phase, its entry and exit criteria and its dependencies in the written scope, and confirm any timeline against that document rather than against a general estimate.

What does the work need from our team?

Expect input from four groups. Your security team approves the architecture, the transfer method, and the access model for the disconnected network. Infrastructure staff provide hosts, storage, and at least one non-production environment for staging and testing. Business owners sign off on the data model, pipeline stages, and reports. Identity administrators configure LDAP or SAML sign-in. Approvals for media transfer and change windows often take the longest, so confirm them before work starts. List the named roles, their time commitments, and the approval path in the written scope.

Can our internal team run an air-gapped CRM by itself?

It depends on existing skills and on how much customization you need. An internal team with Linux, database, PHP or Python, and identity administration experience can usually handle installation and routine operations, based on each vendor's documentation. The harder parts are a secure update workflow, backup and restore testing, hardening, and migration validation, which benefit from a second set of eyes. DeployOpen plans, implements, hardens, backs up, upgrades and documents self-hosted platforms inside your own infrastructure, including air-gapped networks, under fixed-scope agreements. Use a skills inventory to decide which parts to keep in-house and which to scope out.

How do we keep an air-gapped CRM updated?

Updates arrive as packages that you download on a connected system, verify, and carry across a controlled transfer path into the disconnected network. SuiteCRM 8 minor releases arrive roughly every eight weeks, and patch releases contain only security and bug fixes with no new features or database changes, which makes them easier to schedule. EspoCRM 10.0.0 was released on July 2, 2026, and its installation tooling includes a command.sh utility for backups, restores and upgrades. Odoo standard support covers the first three years after a major release for on-premise use, and security patches are only provided during standard support. Confirm the release calendar, the verification steps, and the rollback plan with each vendor before you commit.

Which integrations break when the CRM goes offline?

Anything that calls a cloud API stops working unless its endpoint is inside your network. Common casualties include cloud email sync, hosted telephony, third-party enrichment and SaaS marketing connectors. Inside the network, LDAP or SAML sign-in, the REST API that EspoCRM provides, and internal database links continue to work. The SAML implementation in SuiteCRM 8.7.0 and later does not support IdP-initiated logout, so logging out at the identity provider does not end the CRM session. Inventory every integration in the written scope and mark each as internal, replaced or retired.

What drives the cost of an offline CRM over the years

The cost of an air-gapped CRM is made of components, and most of them are people's time rather than licenses. Expect one-time costs for installation, hardening, the transfer tooling that moves packages across the air gap, data migration and identity integration, and recurring costs for patch cycles, backups, internal administration and any paid support. The open-source license itself, SuiteCRM under AGPLv3 or EspoCRM under AGPL-3.0, carries no fee. Before comparing options, ask each vendor or implementation partner to split its quote along these lines, and ask who performs each task: your staff, the partner, or a support contract.

The biggest variables are the number of integrated systems, the volume and quality of legacy data, and how often your environment can accept updates. Each system you connect to the CRM adds testing for identity and data flows. Each custom module or automation adds a rebuild on every upgrade. Mirroring and transfer work grows with the size of your release cadence, because every SuiteCRM minor release or EspoCRM major release has to be staged, verified and carried across the gap. Confirm which release is current and supported before quoting, and ask how the supplier handles security-only patch releases when they land on a disconnected host.

If you are on Odoo, the recurring line changes. Odoo Enterprise on-premise requires a subscription, and its upgrade service requires Enterprise as well, so the Community edition leaves you to plan major upgrades yourself. Ask for the subscription price for your user count and the support tier, then confirm the standard support window for the version you intend to run, since security patches are only provided during standard support. Do not carry over EspoCRM Cloud per-user prices into this estimate. Those prices pay for a hosted service and say nothing about the cost of running an on-premises install in your own network.

How DeployOpen deploys CRM platforms under air-gap constraints

DeployOpen plans, implements, hardens and documents self-hosted open-source CRM platforms inside your own infrastructure, including disconnected networks. For an air-gapped Salesforce replacement, the work starts with which CRM fits your offline requirements, then covers the install bundle, update path and integrations your network can actually support.

How we scope

Confirm which CRM candidates can install and run with no outbound internet access in your environment.
Map Salesforce objects, reports, integrations and users to the target platform in a written scope.
Agree in writing which update, extension and backup paths will cross the air gap, and who approves them.

How we build

Install the chosen CRM on your hardware or private cloud, with database, web tier and authentication configured.
Set up a staging instance that mirrors production so migrations and upgrades are tested before cutover.
Harden the stack, configure sign-in through your directory, and test access rules and data export paths.

How we hand over

Deliver installation, configuration and runbook documentation for offline updates, backups and restores.
Document the migration steps, data mapping and any customizations that must be re-checked on each upgrade.
Prepare control evidence for your own assessors. DeployOpen does not issue audit reports or certifications.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Review each new release package for security fixes and compatibility before it is moved into the network.
Confirm with your team the owner for patching, backup restore tests and integration changes.