Home / Blog / Business Applications and Automation / CRM Hosting Requirements and Deployment Checklist
A CRM is not just another web application. It holds the names, contact details, conversations, deals and histories of every customer your business has — the data that is hardest to reconstruct if it is lost, and the data whose exposure does the most damage if it leaks. Hosting a CRM therefore deserves more care than hosting a brochure site, and a deployment checklist is how that care becomes repeatable.
This guide uses SuiteCRM as the worked example, because it is a widely used self-hosted, open-source CRM, but the requirements and the checklist apply to most self-hosted CRMs. Always confirm the exact requirements for the CRM and version you deploy — versions change, and this guide is a starting point, not a substitute for the vendor’s documentation.
SuiteCRM’s compatibility matrix, as reflected in current installation guides, calls for:
mod_rewrite enabled, or Nginx with an equivalent configuration.A practical minimum server for a small team is 2 vCPU cores, 4 GB of RAM (8 GB recommended for production), and at least 20 GB of free disk — and that is a minimum, not a target. A CRM with several simultaneous users, email sync, workflows and reporting needs headroom, particularly in RAM. Set the PHP memory limit to at least 512 MB for larger deployments, and size uploads and post limits to the attachments your team actually sends (a common starting point is 100 MB for both, adjusted to your needs).
Shared hosting is generally not recommended for SuiteCRM: it needs more resources than a shared plan reliably provides, and the background jobs a CRM depends on do not run well there. A VPS or a dedicated server is the usual fit. See Self Hosted CRM vs SaaS CRM if you are still deciding whether to self-host at all.
Background jobs (cron/schedulers). A CRM does work when nobody is looking: it sends scheduled emails, runs workflows, updates campaigns, and processes inbound mail. In SuiteCRM these are Schedulers, and they only run if the server’s cron is configured to trigger them. A CRM installed without a working cron looks fine on day one and silently stops doing its background work. Configure the cron during deployment and verify that a scheduled job actually runs.
Email — inbound and outbound. A CRM is only useful if its email works both ways: outbound notifications and campaign mail through SMTP, and inbound mail for cases, leads and replies. Configure SMTP with authentication and TLS, test sending to an external address, and confirm SPF, DKIM and DMARC for the sending domain so CRM mail is not treated as spam. Test inbound mail as well — a mailbox that is configured but never polled is a silent failure.
File storage and attachments. Documents, email attachments and imported files accumulate. Size the disk with growth in mind, and include the CRM’s upload directory in the backup — it is not in the database, so a database-only backup will not restore it.
A CRM is a high-value target, because it concentrates personal data. Treat its security as a first-class requirement, not a post-launch task:
Back up the database and the application data. A SuiteCRM backup that covers only the database will not restore uploaded documents, custom modules, or configuration files. A practical routine is:
Decide your RPO and RTO before you deploy: how many hours of CRM activity can you afford to lose, and how long can the sales team be without the CRM? Those answers set the backup frequency.
Use this checklist for every deployment, and do not skip the staging step.
Planning
– [ ] CRM and version chosen, requirements checked against the vendor’s compatibility matrix.
– [ ] Server sized for the team and the data volume, with headroom for growth.
– [ ] Data-protection and retention requirements confirmed.
– [ ] RPO and RTO agreed, and the backup plan written down.
Server setup
– [ ] Current, patched Linux; firewall allowing only required ports.
– [ ] PHP version matching the CRM’s matrix, with required extensions installed.
– [ ] MySQL/MariaDB installed, with a dedicated database and a least-privilege user.
– [ ] Web server configured with mod_rewrite (Apache) or the equivalent, and HTTPS with a valid certificate.
– [ ] PHP memory, upload and post limits set to the planned values.
Installation
– [ ] CRM installed on staging first, from the official release.
– [ ] Admin account created with a strong, unique password; no default credentials left in place.
– [ ] Company information, currencies, and system settings configured.
– [ ] SMTP configured and tested (send and receive); SPF, DKIM and DMARC checked.
– [ ] Cron/schedulers configured and verified running.
– [ ] Roles and user accounts created; access reviewed per role.
Data
– [ ] Data import tested on staging with a sample file first — check for duplicates, encoding issues, and field mapping errors.
– [ ] Full import run on staging, verified, then repeated on production only after staging is approved.
– [ ] Duplicate-detection rules configured before the full import, not after.
Testing
– [ ] Core journeys tested on staging: create a contact, log a call, create a deal, send an email, run a workflow, generate a report.
– [ ] Backup taken and a restore tested on staging, timed.
– [ ] Performance checked with a realistic number of simultaneous users.
Go-live
– [ ] DNS and SSL confirmed on the production domain.
– [ ] Monitoring and backup-failure alerts in place.
– [ ] Team trained on the basics: login, contacts, deals, and how to ask for help.
– [ ] A named owner for patching, backups and user management, with a weekly check on the calendar.
A CRM deployment is not finished at launch. Put these on a recurring schedule: weekly patch checks and backup verification; monthly user and role reviews (remove access when people leave); quarterly restore tests and performance reviews; and a review of storage growth and database size every quarter. A CRM that is deployed and then ignored slowly becomes slow, insecure, and full of duplicate data — all of which are preventable with a small, regular routine.
Hosting a CRM well means getting the server, the database, the cron jobs and the email right, securing the personal data it holds, backing up both the database and the files, and testing the whole thing on staging before anyone’s real customer data goes in. The checklist above is the difference between a CRM the team trusts and one they work around.
For a VPS sized for a CRM, see our VPS hosting plans. [TO BE CONFIRMED: Offshore Hosting VPS specifications suitable for SuiteCRM, including RAM, storage and backup options.]
Email on your own domain looks professional and stays yours when you change providers. This guide explains what business email hosting involves, how it differs from free webmail, and the DNS and deliverability pieces that make it work.
Latency figures are widely quoted and widely misunderstood. This guide explains what ping measures, which hop actually matters, and the limits of what a VPS can do.
Webhooks, queue mode, and execution retention decide whether n8n stays fast or slowly fills its database. This guide explains each one and the settings that matter.