Why SuiteCRM high availability is more than adding a second web server
A second web server does not make SuiteCRM highly available by itself. High availability means every piece of state, every scheduled task and every database write can survive the loss of one node, and the sales or service teams using the instance keep working through that failure and through peak load. SuiteCRM is self-hosted, so your team owns the whole picture: the web tier, session and file state, database replication, the scheduler and the backups. None of these pieces is handled for you, and each one needs an explicit design decision before the load balancer is switched on.
The difficulty lies in three places. First, state that lives on one node: uploaded documents, generated files, cache directories and any session data stored locally will disappear with that node or make requests fail when they are routed elsewhere. Second, the scheduler must run on exactly one node at a time. If every web server runs the same cron-driven jobs, workflows, email sends and integration pulls will execute twice, which is harder to spot than an outage. Third, the database must be replicated and proven restorable. A replica that has never been promoted or restored in a test is an assumption, not a recovery plan.
Start by confirming the exact stack for your target release. The SuiteCRM 8.10 compatibility matrix lists PHP 8.2, 8.3 and 8.4, Apache 2.4, MariaDB 10.6, 10.11, 11.4 and 11.8, and MySQL 8.0 and 8.4, on Linux, Unix or macOS. Your load balancer, replication topology and failover method must be checked against that specific combination, not against a generic LAMP guide. Do not assume clustering features in the application. Ask how your SuiteCRM version stores sessions and files, whether it can run correctly with several web nodes sharing those locations, and what it expects from the scheduler in that setup.
Before any build work, produce a state map. List each location where SuiteCRM writes data or keeps session information, decide where each one lives in the shared design, and assign one node to the scheduler. Then set the test plan: a scheduled failover drill, a restore from backup into a separate environment, and a check that jobs run once. Plan to repeat these checks after each minor release, which SuiteCRM publishes roughly every eight weeks, because a change in the application or database schema can alter what the cluster depends on. Those checks, not the number of servers, are what show the system is available.
Which SuiteCRM components must be shared or singular across nodes
Each component below falls into one of three groups: duplicated freely, shared between nodes, or running on exactly one node at a time. SuiteCRM 8 core is licensed under AGPLv3, so your team can inspect and configure it, and that configuration lives in your instance under your control.
Web application nodes
Duplicated freely. Each SuiteCRM 8 web node runs the same code from the same release, so every node must match the others on PHP, Apache and build version. The compatibility matrix for 8.10 lists PHP 8.2, 8.3 and 8.4 and Apache 2.4, so confirm that every node uses one combination from that list. Deploy the instance configuration and any custom code identically to each node, because drift between nodes causes intermittent faults that are hard to trace. The number of nodes is a capacity decision that should be set by load tests on your own workload.
Shared session store
Must be shared. A user's session must be readable from whichever node receives the next request, or users are logged out or lose their place in a form when the load balancer moves them. Confirm how the instance stores sessions by default and whether it can use a shared backend that every node reaches. Sticky sessions at the load balancer can hide the problem for a while, but they keep users tied to one node, so use them only as a temporary measure. Test login, a long record edit and a single node failure in staging before go-live.
Shared file and upload storage
Must be shared. Uploaded documents, email attachments and generated files such as exports must be visible on every node, usually through a network file system or object storage that the instance is configured to use. List every directory the instance writes to, including upload, cache and generated-file paths, and confirm with the vendor which of them can stay local to a node without causing stale or inconsistent results. Ownership and permissions must match the web user on each node. Record the decision for each path in the runbook.
MariaDB or MySQL primary and replicas
One primary must accept all writes, so the write path is singular. Replicas copy from that primary and are useful for failover and possibly reporting. Keep the primary and replicas on one supported engine and version family from the compatibility matrix, which lists MariaDB 10.6, 10.11, 11.4 and 11.8 and MySQL 8.0 and 8.4 for SuiteCRM 8.10. Confirm whether the SuiteCRM build directs any reads to replicas before you rely on that. Replication lag, failover promotion and restore from backup all need a tested runbook.
Load balancer
Must run as one active entry point at a time, with a standby that takes over if the active one fails. Traffic reaches the web nodes only through this entry point, so its failure is a full outage unless the standby is tested. Configure TLS termination according to your security policy and pass the original client address to the nodes so that logs stay useful. Confirm the health check URL against the release you run, because a check that only tests the TCP port sends traffic to a node that returns errors.
Scheduler job runner
Must run on exactly one node at a time. Scheduled work such as email sending, workflow processing and campaign runs can duplicate records or messages if several web nodes execute it at once. Confirm how the SuiteCRM 8 scheduler is triggered in your release, then assign it to one designated node or to a single-run mechanism with failover. Check the job logs after a node restart to confirm that only one runner is active, and test in staging which jobs, if any, are safe to run concurrently.
Which high availability design fits your SuiteCRM load
This table compares three SuiteCRM deployment designs, then the decisions that apply across them: scheduler jobs, session handling and database hosting. Read each row against your own user count, downtime tolerance and team size, and set those thresholds from your requirements before choosing a design. The main takeaway is that each step up in availability adds nodes or database components that someone must patch, monitor and test.
| Design or decision | When it fits | Operational cost |
|---|---|---|
| Single node with fast backup and restore | Small teams that can accept a restore window after a failure and want the fewest moving parts. | One server to patch and monitor. Recurring work is restore tests and rebuilds from a known-good image. |
| Two or more web nodes behind a load balancer, one database primary | Web capacity or planned patch windows are the constraint, but the database can remain a single instance. | Every web node needs the same PHP, Apache and SuiteCRM version. Shared uploads, caches and sessions must be designed in. |
| Replicated database with automated or manual failover | Database loss would stop the business, and your team can run failover drills on a schedule. | Replica lag monitoring, a tested failover runbook, and extra database hosting or licensing for each replica. |
| Scheduler jobs on one designated node | Any design with more than one web node, so scheduled jobs do not run twice. | Someone must own the designated node and confirm the scheduler setup for your SuiteCRM version. |
| Sticky sessions at the load balancer | A short-term option when session data still lives on individual web nodes. | A node failure logs out its users. Draining a node for patching needs care and extra testing. |
| Stateless sessions in shared storage | Two or more web nodes, and any plan for rolling patches without user disruption. | A shared session store that all nodes can reach, with its own monitoring, backup and failure handling. |
| Self-run database | Teams with database administration skills that need to control maintenance windows and versions. | Your team pays for patching, backup verification, replica tuning and out-of-hours response. |
| Managed database service | Teams without database administrators, or where the provider offers the failover behavior you need. | Recurring hosting fees that rise with instance size and replica count. Confirm offered MariaDB or MySQL versions against the SuiteCRM 8 compatibility matrix. |
How to build a load-balanced SuiteCRM 8 cluster step by step
This sequence takes a single SuiteCRM 8 instance to a load-balanced setup with shared state, a replicated database, and one designated scheduler node. Each step ends with a check you can record before moving on. Run the sequence on staging first, and confirm every version against the compatibility matrix for your release.
Stand up a staging environment
Build a staging copy that matches production on SuiteCRM 8 release, PHP, web server and database versions. Check the SuiteCRM 8.10 compatibility matrix for supported PHP (8.2, 8.3, 8.4), Apache 2.4, and MariaDB or MySQL versions, and confirm your production versions appear in it. Load a recent copy of production data and customizations into staging, handling personal data under your privacy policy. Done when the staging login page loads, a test record can be created and edited, and the version figures in the admin console match production.
Back up files and database
Take a full backup of the SuiteCRM file system and the database from the current production instance, following the SuiteCRM migration guidance on backing up files and database before changes of this kind. Store the copies outside the servers being changed. Restore them into a separate test location and confirm the restored instance starts and that a sample of records in key modules matches the source. Ask your hosting or implementation partner to document the restore steps and who is authorized to run them. Done when a restored copy starts and the sample matches.
Build the replicated database layer
Configure a primary MariaDB or MySQL server and one or more replicas, using versions from the supported list in the compatibility matrix. Confirm in the SuiteCRM 8 database documentation whether the application can send reads to replicas, and do not assume a read split until you have verified it. Decide how a replica is promoted during failover and who performs it. Done when a record saved through the application appears on a replica, and a test failover promotes a replica while the application keeps saving records.
Move sessions and files to shared storage
Move uploaded documents, caches and any file-based session storage off each web server's local disk into storage that every node can reach. Confirm in the SuiteCRM 8 documentation which directories must be shared and which can stay local. Set the PHP session handler to a shared store so nodes do not depend on sticky routing alone. Set file permissions for the web server user on the shared paths. Done when a document uploaded through node A can be downloaded through node B, and a session started on node A continues after node A is restarted.
Deploy identical application nodes
Build two or more web nodes from the same image or build script, with the same SuiteCRM 8 release, PHP version, Apache 2.4 configuration, extensions and custom code. Keep environment-specific settings such as database host and file paths in shared configuration so each node reads the same values. Run a version check on every node as part of the build. Done when every node reports the same SuiteCRM and PHP versions and each node serves the same login page and records.
Place the load balancer with health checks
Put a load balancer in front of the web nodes and configure a health check against a page the application serves without a login. Mark a node out of rotation when the check fails. Use session affinity only if the shared session store from the earlier step is not yet proven in your environment. Decide where TLS terminates according to your certificate policy. Done when a stopped node is removed from rotation, users keep reaching SuiteCRM through the remaining node, and the stopped node returns to rotation after it recovers.
Designate one node for scheduler jobs
Choose exactly one node to run SuiteCRM scheduler jobs and disable the scheduler trigger on all other nodes, following the SuiteCRM 8 scheduler documentation for how jobs are started. Record the chosen node in your runbook and in the configuration so a replacement is a deliberate change. Create a test job that writes a log entry. Done when the test job runs once per scheduled interval and the log shows a single run from one host. Repeat this check after you fail the scheduler role over to another node.
Enable and test SSO login
If you use directory or SSO login, enable LDAP with AUTH_TYPE set to ldap, or SAML with AUTH_TYPE set to saml, using the SuiteCRM 8 LDAP reference or the SAML reference for 8.7.0 and later. Test sign-in on every node through the load balancer. Note the logout limitation: from SuiteCRM 8.7.0, SAML does not support IdP-initiated logout or POST binding to the logout service, so signing out at the identity provider does not end the SuiteCRM session. Tell users to sign out of SuiteCRM directly. Done when a user signs in through each node and a sign-out from SuiteCRM ends the session on that node.
How the high availability design changes by environment
A single node runs the web server, the SuiteCRM application, the scheduler and the database on one host, or with the database on a separate host. The goal here is recovery, not continuous service: the question is how quickly the team can rebuild the host and its data after a failure. Most of the choices below are simplifications that the other tabs reverse.
- Session storage: Sessions stay on the local disk of the one host, so no shared session store is needed. A restart signs users out.
- File storage: Uploads and generated files live on the local file system, so backups must cover that path as well as the database.
- Database replication: Usually replaced by scheduled backups with a restore test. A standby copy is optional and adds cost.
- Patch delivery: Patches are applied in place after a backup and a test on a staging instance.
- Scheduler placement: The scheduled job runs on the same host, so a host outage also stops scheduled work such as email and workflow runs.
Confirm that the recovery time the business expects can be met by restoring a backup onto a replacement host, and time that restore in a rehearsal before go-live.
A multi-node design places several web servers behind a load balancer, with the application files, uploads and database reached from every node. This is the model most often used when the business needs continuous access during a patch or a single host failure. The work shifts from recovering one host to keeping shared state consistent across several.
- Session storage: Either a shared session backend or sticky sessions at the load balancer. Confirm the choice with the platform team, because sticky sessions alone do not protect sessions when a node fails.
- File storage: A shared file system or equivalent storage mounted identically on every node. Confirm how file locking and write behavior are handled before the design is approved.
- Database replication: A primary with one or more replicas, plus a documented failover method. Use only database versions listed in the SuiteCRM compatibility matrix.
- Patch delivery: Rolling updates, one node at a time, with each node removed from the load balancer during its update and every node running the same package version.
- Scheduler placement: The scheduled job runs on exactly one node, or on a dedicated node, so that jobs do not run twice.
Check the failover path with a planned node failure and a planned database failover, and record how long users see errors during each test.
Container platforms change the unit of deployment from a host to an image, and most of the design questions move to how the image is built, where its state is kept and how many copies run. The team must confirm how SuiteCRM 8 is packaged, which paths the application writes to at runtime, and whether those paths sit on persistent storage. Until that is confirmed, the design for the other items cannot be finished.
- Session storage: A shared session backend, or session affinity at the ingress. Confirm which option the packaged application supports.
- File storage: A persistent volume for uploads and other writable paths. Replicas that read the same files need an access mode that the chosen storage class supports.
- Database replication: Run the database outside the application pods, as a managed service or an operator-managed cluster with its own backup policy.
- Patch delivery: Rebuild the image with a new version tag, test it in staging, then roll it out. Keep the previous image available for rollback.
- Scheduler placement: Run the scheduled job as a separate workload with a single replica, so it does not multiply when the web tier scales.
Before committing to a design, ask the vendor or the implementation partner to document the writable paths and the image build process for the exact release in use.
An air-gapped network has no route to public package repositories, so every patch, runtime package and database package must be brought in through an approved transfer route. The availability design inside the enclosure is often similar to the multi-node model, but the supply chain for updates and the reliance on internal services change how the team plans maintenance.
- Session storage: Use a shared backend that runs entirely inside the network. Confirm which options are approved by the security team.
- File storage: On-premises shared storage, sized and backed up under the same policy as the database.
- Database replication: Replicas stay inside the enclosure. Database packages for each version used must be transferred and verified like any other software.
- Patch delivery: Bring the SuiteCRM patch and the database packages through the approved route, verify checksums, and record each transfer in the change log before installation.
- Scheduler placement: Run the scheduled job on a designated node. Email relays, identity providers and any other service it calls must also be internal.
Confirm the transfer route, its approval steps and its lead time with the security and change teams before the first maintenance window is planned, since they determine how quickly a security patch can be applied.
What drives SuiteCRM high availability effort and cost
This table lists the factors that change how much design, build, testing and ongoing work a highly available SuiteCRM deployment needs. Read each row as a question to answer before requesting a quote, and use the last column to see which choices keep effort down. The main takeaway is that load, integrations and the number of environments matter more than the number of servers alone.
| Driver | Effect on effort and cost | One-time or recurring | How to keep it down |
|---|---|---|---|
| User count and concurrency | More concurrent users need more web nodes, sized database connections and session capacity, and load tests must reflect peak use such as month-end sales cycles. | One-time sizing and load tests, then recurring capacity review | Agree peak concurrency numbers in writing and test against them, not total headcount. |
| Data volume and attachment size | Large databases and attachment stores lengthen replication, backup and restore times and increase shared storage sizing. | One-time storage design, recurring growth and backup storage | Set attachment retention and archiving rules early and confirm backup window needs. |
| Integrations that write to SuiteCRM | ERP, marketing, telephony and web form feeds writing at the same time create contention, duplicate-record risk and failover questions for each job. | One-time integration design and failover tests, recurring monitoring | Limit writers, route feeds through one queue, and document which integration owns each field. |
| Number of environments | Development, staging, production and disaster recovery each need a matching build, data refresh and test cycle, multiplying configuration and patching work. | One-time environment build, recurring refresh and patching for each copy | Keep environments built from the same scripts and refresh staging from sanitized production data only when needed. |
| Depth of customization tested on every node | Custom modules, logic hooks and file overrides must behave the same on every web server, so each change requires cluster-wide testing. | One-time test scripts, recurring regression testing before each upgrade | Limit custom code, prefer supported configuration and keep customizations in version control. |
| Compliance evidence for backup and access controls | Auditors may ask for backup test records, restore timings, access reviews and change logs, which require evidence collection routines. | One-time evidence design, recurring evidence collection and restore tests | Agree the evidence list with your assessor before build and automate log and backup reports. |
| Team skills in database and load balancer operations | Teams without MariaDB or MySQL replication and load balancer experience need training or a partner to run failover, while experienced teams carry less onboarding effort. | One-time skills gap work and runbook writing, recurring on-call effort | Assess existing skills early, write runbooks for failover and restore, and rehearse them on staging. |
| Infrastructure ownership | Hosting, load balancers, storage and database servers may be paid to a cloud provider, a data center or a managed service, and each choice changes who patches and who pays. | Recurring infrastructure fees and one-time provisioning | Ask for a clear list of which party pays for and operates each component. |
How to prove a SuiteCRM cluster fails safely before go-live
Before go-live, prove that the SuiteCRM cluster fails in the ways its design promises. The proof is a short set of scripted failure tests, run against a staging copy that matches production in node count, load balancer, session handling, file storage and database topology. Run them in the order below, because later tests depend on the state earlier tests leave behind. Each test needs a named owner, an expected result agreed before the test starts, and evidence captured during the run. A test that only shows the system came back does not show what users and data experienced. Ask your implementation partner which of these tests they will run and which your team must run alongside them.
The first two tests cover the web and database tiers. Stop one web node while test users are logged in and submitting forms. Confirm that sessions served by the surviving nodes continue, that the load balancer removes the stopped node from rotation, and that any in-progress edit either saves or fails with a clear message, matching what your design says about shared session and file storage. Then fail the database primary and promote a replica using the runbook you wrote and reviewed. After SuiteCRM reconnects, compare records written just before the failure with the new primary. Count every write that was acknowledged to a user, and treat any missing one as a failed test. Confirm that the database connection settings point to the new primary as the runbook says they should.
Next, test the scheduler. Check that each scheduled job runs once per interval across all web nodes, that no job runs twice during the failover window, and that jobs resume once the new database primary is in service. Duplicate email sends and double-applied workflow actions are the failures to look for. Then restore a full backup to a clean environment, covering the file store and the database together. Check that the application starts, that a sample of records in each main module matches expected content, and that attachments open. Finally, test single sign-on. Sign out at the identity provider and confirm that the SuiteCRM session stays active. The SuiteCRM SAML configuration reference for version 8.7.0 and later explains that IdP-initiated logout is not supported, so the security team must either accept that behavior in writing or add a documented control for it.
Record every test in a log that shows the date, the build and component versions, the people involved, the expected result, the observed result, and links to logs or screenshots. A test passes only when every expected result is met. Partial success, such as sessions surviving while a scheduled job runs twice, is a failure to fix and retest. Set the acceptance thresholds from your own recovery requirements: the longest tolerable interruption, the largest acceptable data loss window, and the number of acknowledged writes you can lose, if any. Confirm those values with the business owners of the CRM before the test starts, so the results are judged against targets agreed in advance. Keep the signed log with your change records.
Restore testing continues after go-live. Schedule the restore test to repeat at an interval your recovery requirements justify, and run it against a clean environment each time so that it proves the backups can be used. Track restore duration and every manual step, because those determine how long recovery actually takes. Rerun the full failover sequence after any change to the web tier, database version, PHP or SSO configuration, and after SuiteCRM minor or patch upgrades, since those changes can shift the behavior you tested. Ask your partner to price the repeat testing and log review as a recurring item, separate from the one-time build of the test plan.
Securing sessions, file storage and database access in a cluster
When SuiteCRM runs on several web nodes, every shared path becomes a potential exposure: the database, session and file stores, configuration secrets and the login flow. The cards below cover the controls that keep those paths private and consistent across nodes. The full security review sits in the SuiteCRM security hardening topic.
Restrict replication and admin database access
Database replication traffic and administrative accounts should only be reachable from the private network segment where the SuiteCRM nodes and replicas sit. Confirm that replica connections use dedicated accounts with the minimum privileges needed for replication, and that no administrative account is reachable from a public address or a jump host without logging. Check the firewall and security group rules against the MariaDB or MySQL version you deploy, because the replication setup steps differ between them.
Keep sessions and files off public paths
Shared session and file storage must not be served directly by the web server. Review the public and legacy folders, because the SuiteCRM migration documentation warns that a migration may remove non-core files under the public/legacy folder, so customizations placed there need to be relocated and retested. Confirm that the web server denies direct requests to session, upload and cache directories and that any shared storage mount is reachable only from the application nodes.
Move secrets into a secrets manager
Database credentials, API keys and the application configuration values that hold them should be retrieved from a secrets manager at startup rather than copied into files on every node. Copies on each node multiply the places a secret can leak and make rotation a manual, error-prone task across the cluster. Ask your team to confirm which values are read from the environment, which are stored in configuration files, and how a rotated credential reaches all nodes without a restart outage.
Set load balancer TLS and forwarded headers
TLS is usually terminated at the load balancer, so the SuiteCRM nodes must be configured to trust the forwarded headers that carry the original client address and scheme. Without this, generated links, redirects and session cookie behavior can reference plain HTTP or the balancer's internal address. Restrict trust to the load balancer's own addresses so clients cannot spoof those headers, and test login, email links and file downloads through the balancer before go-live.
Apply one LDAP or SAML setting to all nodes
The authentication type is a single application setting, so LDAP (AUTH_TYPE=ldap) or SAML (AUTH_TYPE=saml) applies to every node in the cluster. Any drift between nodes will cause some users to be routed to a different login flow, so the setting and its identity provider metadata must be deployed from the same source. Confirm the attribute mapping, certificate rotation plan and test accounts with your identity team before enabling it in production.
Plan for SAML logout limits
The SuiteCRM 8.7.0+ SAML implementation does not support IdP-initiated logout or POST binding to the logout service, so signing out at the identity provider does not end the SuiteCRM session. In a cluster, this means sessions can remain active on a node after a user has been disabled upstream. Document this limitation for your security team, set session lifetimes that match your policy, and decide how disabled accounts are removed from SuiteCRM.
What to monitor, back up, patch and document after go-live
After go-live, the team needs to watch the signals that show whether the SuiteCRM cluster is still doing its job, not only whether the login page loads. Start with per-node response times and error rates from each web server, so that one node failing quietly behind the load balancer does not hide inside an average. Check what path the load balancer health check requests and confirm that it exercises the application, not just the web server process. Track replication lag on the MariaDB or MySQL replicas, along with database connection counts, and decide with the application owners how much lag users can tolerate before reads from a replica give them stale records. Watch the scheduler run history too, because SuiteCRM scheduled jobs that fail without notice stop email, workflows and campaigns. Finally, monitor disk use on the shared storage that holds uploads and files. Confirm alert thresholds against a baseline you record under normal load, not against figures copied from another deployment.
Backups for a clustered SuiteCRM instance cover two kinds of data: the database and the file store. Schedule both, and include the custom code, the configuration files and the uploaded documents, since the database alone cannot rebuild the application. Ask your backup tool how it keeps the database dump and the file snapshot consistent with each other, because a restore that pairs a database from one time with files from another can produce broken attachments and records. Restore tests matter more than the backup job itself. Restore into a clean environment on the same PHP and database versions as production, log in, run a scheduler job and open a sample of records. Record how long the restore took and update the runbook with what you learned. Set retention with your compliance lead, based on the record-keeping obligations that apply to your organization, and confirm the retention periods in writing.
SuiteCRM 8 minor releases arrive roughly every eight weeks, and patch releases carry only security and bug fixes with no new features and no database changes. That pattern makes rolling patches practical. Take one node out of the load balancer, patch it, run the health and smoke checks, return it to service, then move to the next node. Keep the cluster on one application version at a time once patching ends, and do not leave nodes on mixed versions longer than your test plan covers. Minor releases can differ from patch releases, so read each release note before scheduling the window. Before any change to PHP, Apache, or the database engine, check the SuiteCRM compatibility matrix for the supported versions. The matrix lists PHP 8.2, 8.3 and 8.4, Apache 2.4, MariaDB 10.6, 10.11, 11.4 and 11.8, and MySQL 8.0 and 8.4, but confirm the current matrix on the day you plan the change, since it is updated over time.
Documentation is what lets someone other than the original builder recover the cluster at 2 a.m. Write a runbook that covers four procedures: failover, which includes removing a failed web node and promoting or redirecting the database; restore, which links to the backup tool steps and the consistency rule you confirmed; scheduler recovery, which covers restarting the cron entries and deciding which missed jobs to rerun; and rollback, which states how to return to the previous application and database state. Pair the runbook with a configuration record for every node, listing the PHP and Apache versions, the enabled extensions, the session and file storage mounts, the cron entries, the environment settings, certificate details and any local changes. Assign an owner for each record and update both documents with every change. Run the runbook during each restore test so that gaps are found before an incident, not during one.
What buyers ask before they build SuiteCRM high availability
Is a single SuiteCRM server enough for our users?
A single node is enough when the business can accept downtime while one server is patched, repaired or restored, and when peak use stays within what one web and database host handles in load testing. Decide on three measures: the outage the business tolerates in hours, the peak number of concurrent users and scheduled jobs, and the time a full restore takes today. If an outage stops sales or service work, a second web node and a replicated database are worth scoping. If your team cannot yet restore a backup on a test machine, fix that first, because a cluster does not replace tested recovery. Run a load test on a staging copy before deciding, and record the results with the assumptions behind them.
How long does a SuiteCRM high availability build take?
The duration depends on your environments, your existing infrastructure and how many systems SuiteCRM must connect to, so no fixed timeline applies across organizations. The main drivers are whether you already run a load balancer, shared file storage and a managed database, which database replication method you choose, and how many identity provider connections (LDAP, SAML or both) must work. Integrations with ERP, marketing or telephony tools add design and test effort, as does the amount of load and failover testing the business requires. Cutover planning depends on a maintenance window the business approves. Ask for a written scope that lists each component, the environments included, the test cases and the acceptance steps, so estimates from different providers can be compared on the same basis.
Can our in-house team build SuiteCRM high availability without a partner?
Yes, if the team already runs these skills in production: Linux administration, Apache 2.4 and PHP configuration, MariaDB or MySQL replication and failover, load balancer health checks and session handling, shared file storage permissions, scheduled jobs, and backup and restore. Confirm the supported PHP, Apache and database versions in the SuiteCRM 8 compatibility matrix before choosing components. Most gaps appear in failover testing and scheduler setup, not in the initial install. Assign one named owner per layer, and plan a dry run on staging that includes stopping a web node and promoting a database replica. If one skill is missing, buy that piece as a fixed-scope task so the rest of the work stays with your own team.
What do we need to provide for a SuiteCRM high availability project?
Plan to provide infrastructure access, a staging environment close enough to production to test failover, and named owners who can decide quickly. Infrastructure access means accounts for the cloud, virtualization or data center, approved network changes, DNS and certificate control, and access to the existing database and file storage. Identity provider details are needed for LDAP or SAML, including the directory or metadata, attribute mapping and a test user for each role. You will also need a maintenance window for cutover, backup access, a rollback decision point and someone who can sign off acceptance tests. Name owners for the database, network, application, identity and business process. Missing owners are a common reason test dates slip, so confirm them before the scope is signed.
How is SuiteCRM high availability cost divided?
The cost splits into four groups because the SuiteCRM software is free to download and self-host under the GNU Affero General Public License version 3. Infrastructure is recurring: load balancers, web and database servers, shared storage, backups, monitoring, and any operating system or database licenses you choose. The build is one-time: design, configuration, session and file storage, replication, scheduler setup and documentation. Testing is partly one-time and partly repeated: load tests, failover drills and backup restore tests, which should run again after significant changes. Ongoing operations are recurring: patching on a minor release cycle that arrives roughly every eight weeks, monitoring, administration time and any support package such as SuiteASSURED. When requesting a quote, ask for each category as a separate line with its assumptions.
Does SuiteASSURED support cover SuiteCRM cluster problems?
Coverage for cluster issues is something to confirm in writing with SuiteCRM Ltd, not something to assume. SuiteASSURED is a paid support package from SuiteCRM Ltd, but this page cannot confirm how it treats multi-node or clustered deployments. Ask the vendor whether a load-balanced, multi-node topology with a replicated database is supported, which components they will troubleshoot, what they need from your environment to investigate, and how they handle issues involving your database, load balancer or identity provider. Get the answers in an email or contract schedule, then compare them with the responsibilities in your scope. Any gap between vendor support and your own support arrangements should have a named owner before go-live.
Is SuiteCRM Hosted a better option for high availability?
It is one alternative to self-hosting, and the choice depends on total cost of ownership, which the SuiteCRM cost of ownership topic covers in detail. SuiteCRM Hosted is a paid service from SuiteCRM Ltd. Check where the data is stored, who patches the platform, who runs failover and backups, what availability and recovery terms the contract states, and whether your integrations and custom modules can run on the hosted service. Self-hosting keeps the environment and network inside your own infrastructure, but your team carries the operating load. Ask SuiteCRM Ltd for the hosted service terms in writing before deciding.
What usually breaks first in a multi-node SuiteCRM setup?
The most common failures are configuration drift between web nodes, uploaded files stored on one node, sessions tied to a single server, scheduled jobs running on every node, and database replicas serving stale reads. Check that each web node has identical code, configuration and PHP settings, and that uploads and generated files sit on shared storage every node can read and write. Confirm the load balancer keeps sessions consistent, either through sticky sessions or shared session storage, and test what happens when a node is removed mid-request. Run scheduler jobs from one designated node so workflows and emails do not fire twice. Confirm LDAP or SAML settings match on every node, and record each failure mode in the runbook.
How DeployOpen scopes, builds and hands over a SuiteCRM cluster
DeployOpen plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and SuiteCRM high availability follows the same method. The work moves from a written scope to a tested cluster in your cloud account, data center or air-gapped network, with documentation and restore evidence handed to your team.
How we scope
- The written scope names the web nodes, load balancer, shared session and file storage, and database topology.
- Expected concurrent users, peak workflows and scheduler jobs are documented before any infrastructure is chosen.
- Engagements are fixed-scope, agreed in writing before work starts, with ongoing support available as a retainer.
How we build and test
- Build identical SuiteCRM 8 web nodes with pinned PHP and Apache versions behind a health-checked load balancer.
- Move sessions and uploaded files to shared storage so any node can serve any request.
- Configure the database as a replicated MariaDB or MySQL pair, checking the version against the compatibility matrix first.
How we hand over
- Deliver the architecture, runbooks and configuration documentation for the cluster in your environment.
- Document the failover steps, backup schedule and restore procedure that your operators will follow.
- Walk your administrators through the cluster and confirm they can run a restore without help.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Track SuiteCRM minor releases, roughly every eight weeks, and test each one on a staging cluster first.
- Re-check the load balancer, session storage and database versions whenever PHP or database support changes.
