Check your Domain Availability...
Free Domain Manager
Live Demo - lock option, edit Whois, edit name servers, custom DNS records, URL redirection, etc.
Enterprise-Class vTiger Web Hosting Solutions
vTiger™ is a trademark of Vtiger Systems India Private Limited and shares no connection with us.
100% vTiger-Compatible Web Hosting Servers
- An automated vTiger installation
- A 1-click vTiger script installation right at signup
- All vTiger hosting prerequisites are met and exceeded.
- The newest versions of Apache, MySQL and PHP
- 24/7/365 technical support
- A twenty-minute average trouble ticket response time
vTiger Hosting Solutions
| Economy | Regular | Deluxe | Ultimate |
|
Perfect for customers who only want a simple personal website or a blog.
|
A good choice for any online store or a fairly complex website.
|
A reasonably priced shared web hosting package, good for resource-heavy personal websites.
|
The right solution for high-profile websites with lots of visitors.
|
| Unlimited storage | Unlimited storage | Unlimited storage | Unlimited storage |
| Unlimited bandwidth | Unlimited bandwidth | Unlimited bandwidth | Unlimited bandwidth |
| 1 website hosted | 5 websites hosted | Unlimited websites hosted | Unlimited websites hosted |
| 24/7/365 support | 24/7/365 support | 24/7/365 support | 24/7/365 support |
|
30 Days Money Back Guarantee |
30 Days Money Back Guarantee |
30 Days Money Back Guarantee |
30 Days Money Back Guarantee |
|
30-Day Free Trial |
30-Day Free Trial |
30-Day Free Trial |
30-Day Free Trial |
| $4.95 / month | $8.75 / month | $17.50 / month | $25.00 / month |
| Compare All Hosting Plans | Compare All Hosting Plans | Compare All Hosting Plans | Compare All Hosting Plans |
Questions about vTiger web hosting? See our FAQ.
A narrative guide to vTiger web hosting.
The Beginning
There is a moment in the life of many businesses when keeping track of customers starts becoming harder than winning them.
At the beginning, everything seems manageable.
A few names are written down. A salesperson keeps notes in a spreadsheet. Customer conversations live in email. Someone has a calendar full of reminders. Important documents are stored in folders that everybody apparently knows how to find.
It works.
Until it does not.
The business grows. More customers arrive. More employees become involved. Leads have to be followed up. Sales opportunities move through different stages. Support requests start appearing. Important information becomes scattered across different computers, inboxes, spreadsheets, and people's memories.
Eventually somebody says the sentence that changes everything:
“We need a CRM.”
Vtiger can be that CRM. Its software brings customer and business information into a centralized application, with functionality covering areas such as sales, customer interactions, support, marketing, inventory, reporting, and other business processes depending on the edition and configuration.
There is another decision hiding immediately behind that one.
Where will the CRM live?
For a cloud service, that question is largely answered for you. Vtiger's cloud offering is operated as a managed service, so much of the server infrastructure is handled by Vtiger itself. With an open-source installation, the business can host the application on its own server and gains much more control over the environment.
That freedom can be attractive.
It also means the hosting environment becomes part of the project.
What Vtiger Actually Is
Vtiger is often introduced with a very simple description: CRM software.
That is true, but it does not really explain what the server is being asked to do.
A CRM is not just a collection of public web pages.
Inside a working Vtiger installation there can be leads, contacts, organizations, opportunities, activities, tickets, products, documents, emails, notes, calendars, reports, user accounts, custom fields, and relationships between all of those records.
Employees do not simply read that information.
They change it.
A sales representative creates a new lead. Another employee adds a note. Someone moves an opportunity forward. A support agent updates a ticket. A manager runs a report. A document is attached to a customer record. An email is connected to a conversation.
The system is constantly reading from and writing to its data.
That is one of the reasons hosting a CRM is different from hosting a small company website.
Vtiger's open-source documentation confirms that the application is designed to run in a PHP-based web environment with a relational database, and it provides the source code for organizations that want to operate the software themselves.
For businesses interested in the open-source edition, the Vtiger Open Source documentation is worth reading before choosing a server because the technical requirements depend on the application environment being deployed.
Once you understand what is actually happening inside the CRM, the hosting decision starts to look rather different.
Where the CRM Lives Matters
Imagine a company called Harbor Point Supplies.
It starts with six employees and a relatively small customer database.
The owner finds a cheap hosting package that appears to have everything the company needs.
There is plenty of disk space.
There is a control panel.
PHP is available.
A database can be created with a few clicks.
The price is low.
It looks perfect.
Then Vtiger is installed.
At first, everyone is happy.
The application opens. Records can be created. Employees can log in. The new CRM seems to be working exactly as expected.
Six months later, there are fifteen users.
The customer database has grown. More documents have been uploaded. Reports have become more complicated. Email activity has increased. Everyone is working in the system at roughly the same time.
And suddenly something that seemed perfectly adequate starts feeling slow.
Nothing magical happened.
The business simply changed the workload.
That is why Vtiger hosting should be evaluated according to how the CRM will actually be used rather than according to a hosting advertisement.
Storage space is useful.
Bandwidth is useful.
But CPU availability, RAM, database performance, process limits, PHP configuration, disk performance, and the overall quality of the server can have a much greater effect on how the application feels to the people using it every day.
The Server Behind It
Before installing Vtiger, it makes sense to stop thinking about the server as a generic box and start thinking about it as the application environment.
Vtiger's technical documentation identifies Apache as a recommended web server and describes the need for a compatible PHP installation. It also lists MySQL or MariaDB and PostgreSQL among the supported relational database systems, with Linux distributions such as Ubuntu, CentOS, and Debian among the operating environments that can be used.
There is a more detailed set of requirements for the open-source edition as well.
Vtiger's Open Source FAQ lists Apache, MySQL with InnoDB, PHP support, and PHP extensions including IMAP, cURL, and XML. It also specifies a minimum PHP memory limit of 256 MB and a minimum execution time of 60 seconds in its published requirements.
Those details matter because “our hosting supports PHP” is not a sufficiently precise answer.
It is the equivalent of saying that a car has an engine without mentioning whether the engine is actually compatible with the rest of the vehicle.
The Vtiger technical prerequisites provide a useful starting point for checking the environment.
There is also an important reason not to assume that the newest available software version is automatically the best choice.
Vtiger has ongoing compatibility work with newer PHP releases, and the project's public issue tracker contains reports concerning PHP 8.2 compatibility and warnings in Vtiger 8.4.0. That is not evidence that a particular PHP version can never be used, but it does demonstrate why the exact CRM version and its supported environment should be checked together.
In other words, compatibility should be established before installation rather than discovered by accident afterward.
The Database Is Always Working
The database is one of those parts of a CRM that nobody thinks about when everything is working.
It simply sits there doing its job.
But almost every meaningful action in Vtiger involves data.
Open a customer record and information has to be retrieved.
Create an opportunity and information has to be stored.
Search for a contact and the database has to find it.
Run a report and potentially thousands of records may have to be examined.
Open a related record and the application needs to follow the relationships between pieces of information.
The database is therefore much more than a place to store names and addresses.
It is the memory of the CRM.
Vtiger's open-source requirements specifically call for InnoDB when using MySQL. That is an important technical detail because database behavior and storage engines can affect reliability and performance.
The more the CRM grows, the more noticeable database performance can become.
A small installation with a few hundred records may appear fast almost anywhere.
A business with years of customer history, thousands of contacts, large numbers of activities, substantial product information, and many simultaneous users may expose database weaknesses very quickly.
That is why choosing hosting solely on the basis of storage capacity misses one of the most important parts of the system.
You are not simply storing data.
You are constantly asking the server to work with it.
When the Team Gets Busy
There is a simple test that often reveals whether a hosting environment is really suitable for business software.
Do not test it at eleven o'clock at night.
Test it when everybody is working.
At 9:00 AM, sales staff start checking their leads.
At 9:15, customer service starts working through support requests.
At 9:30, a manager opens a dashboard.
At 10:00, someone imports information.
At 10:15, another employee attaches documents to customer records.
At 10:30, people are creating new activities and updating opportunities.
Individually, none of those tasks is particularly dramatic.
Collectively, they create a workload.
This is where shared hosting limits can begin to matter.
If a hosting provider places tight restrictions on CPU usage, memory, concurrent processes, database activity, or other resources, users may experience slow responses even though the account technically has plenty of disk space.
That is why a CRM hosting plan should be judged during realistic working conditions rather than by looking only at the feature list displayed on the sales page.
For a business-critical application, consistency often matters more than an impressive peak-speed claim.
Employees want the CRM to respond normally at 10:00 AM on Tuesday just as much as they do at 11:00 PM on Sunday.
When Email Becomes Part of the CRM
Then Harbor Point decides to connect its email system to Vtiger.
That feels like a small improvement.
It is actually another step in turning the CRM into the center of the business.
Customer conversations can become part of the history associated with a contact or organization. Sales staff can work with messages alongside customer information instead of jumping constantly between unrelated systems.
Vtiger's open-source documentation describes Mail Manager configuration and the use of IMAP for connecting mailboxes. It also explains that an outgoing mail server must be configured when the CRM needs to send mail.
That means the hosting environment now needs to support more than ordinary web traffic.
Connections to mail services need to work.
Authentication needs to work.
SSL connections need to be handled correctly.
Firewall policies cannot interfere with legitimate communication.
And the hosting provider needs to be clear about any restrictions placed on outbound connections.
Vtiger is a business application, and business applications rarely live in isolation.
Once email becomes part of the workflow, the hosting environment becomes part of that workflow too.
The Work Happening in the Background
One of the easiest things to forget about a CRM is that not all of its work happens after somebody clicks a button.
There are tasks that may need to run automatically.
Scheduled activities can be processed. Data may need to be synchronized. Notifications can be generated. Other automated functions can require server-side execution.
This is where cron jobs and scheduled tasks become relevant.
The user may never see them.
That does not make them unimportant.
In fact, background processes can be among the easiest things to overlook when moving an application to a new server.
The CRM appears to work.
Users can log in.
Customer records open normally.
Then somebody eventually discovers that an automated task has stopped running.
A good hosting environment therefore needs to support the scheduled work required by the particular Vtiger installation.
And after a migration, those jobs should be checked rather than assumed to have followed the application automatically.
It is a small detail until it becomes a very large one.
Documents and Attachments
A CRM rarely stays a CRM for long.
It begins with customer records.
Then somebody attaches a quotation.
Another employee uploads a contract.
Someone adds a product brochure.
A support agent attaches a PDF.
A salesperson stores a presentation.
Six months later, the CRM is holding a substantial collection of business documents.
That changes the storage equation.
Vtiger's open-source documentation has included hardware guidance of 250 GB of disk space for file attachments. That figure should not be interpreted as an unavoidable requirement for every installation because actual storage needs vary widely, but it does illustrate an important point: attachments can become a major part of a CRM's footprint.
And once files are important to the business, storage performance and backup coverage matter as well.
A customer record without its associated document may not be particularly useful.
A restored database without the corresponding files may leave the company with an incomplete system.
This is why backups have to be designed around the whole installation rather than around only the database.
The files matter.
The database matters.
The customized configuration matters.
Everything that makes the CRM what the business actually uses needs to be considered.
Performance Is More Than a Fast Server
There is an understandable tendency to blame the server whenever an application is slow.
Sometimes the server is the problem.
Sometimes it is not.
Performance can be affected by database activity, PHP configuration, application customizations, inefficient processes, integrations, large amounts of data, storage performance, network latency, and the number of simultaneous users.
That means buying a bigger server is not always the first answer.
Imagine a Vtiger installation that becomes noticeably slower after several years.
The database has grown enormously.
There are more custom fields.
Several third-party integrations have been added.
Employees are generating more reports.
The document library has become much larger.
The business has also doubled its workforce.
The answer might involve more resources.
But it might also involve reviewing the application configuration and finding out what is actually taking the time.
This is one of the advantages of having a hosting provider that understands application hosting rather than simply selling disk space.
When something becomes slow, somebody should be able to help identify whether the bottleneck is the server, the database, the application, or the configuration.
Security Is Part of Hosting
Eventually Harbor Point realizes something else.
The CRM now contains information the company could not afford to lose.
Customer records.
Sales opportunities.
Documents.
Internal notes.
User credentials.
Business history.
That makes security part of the hosting decision.
Vtiger's technical prerequisites recommend securing the installation with an SSL certificate so that communication between the browser and server is encrypted.
But SSL is only the beginning.
The operating system must be maintained.
The web server must be maintained.
PHP must remain within a supported and secure environment.
The CRM itself must be updated carefully.
Passwords and access rights need to be handled responsibly.
And self-hosted installations require someone to take ownership of those responsibilities.
That last point is especially important because a self-hosted application is different from a SaaS service.
With Vtiger Cloud, Vtiger handles much of the infrastructure, maintenance, and service operation. With an open-source installation on your own server, those responsibilities are shared by the business and whoever manages the hosting environment.
There is another reason to take updates seriously.
Security advisories published in 2026 identify vulnerabilities affecting older Vtiger releases, including an authenticated remote code execution issue affecting versions through 8.4.0 and an authenticated file-upload issue affecting versions before 8.4.0.
That does not mean every installation is exposed in the same way, but it does make one principle very clear.
Self-hosted CRM software should not simply be installed and forgotten.
Current security information can be checked in the GitHub Advisory Database and in the Vtiger project itself.
Good hosting can provide the foundation.
Keeping the application secure still requires attention.
Backups and Recovery
There is a strange rule about backups.
People rarely care about them when they are working perfectly.
They become priceless the moment something goes wrong.
Imagine that an employee accidentally removes important records.
Imagine a failed update.
Imagine database corruption.
Imagine a serious server problem.
Imagine the worst version of the story: a security incident that requires the system to be rebuilt.
The question is no longer whether the company has a backup.
The question becomes whether it can actually restore the business.
For a self-hosted Vtiger installation, the database needs protection, but the database is not necessarily the whole story.
Application files matter.
Uploaded files matter.
Custom changes matter.
Configuration matters.
A fresh Vtiger installation may be easy to recreate, but recreating the exact environment that a business has developed over several years is a different problem.
That is why a good backup strategy should be designed around recovery rather than simply around the word “backup.”
How often are backups taken?
How long are they retained?
Where are they stored?
Can they be restored independently?
Has the restoration procedure actually been tested?
Those questions are much more useful than an advertisement that merely says “daily backups included.”
Customization Changes the Requirements
Northstar's original Vtiger installation eventually starts to look very different from the one it installed on the first day.
A developer has added custom fields.
The business has changed some workflows.
Additional modules have appeared.
The interface has been adjusted.
External systems have been connected.
Now the CRM is no longer just an application installed from a download.
It has become the company's version of that application.
This is where self-hosting can be particularly attractive.
The business has much more control over the environment.
Developers can work directly with the application files and database.
Custom code can be tested without waiting for a SaaS provider to expose every required capability.
But customization creates another responsibility.
Every major change makes future maintenance more important.
Before updating Vtiger, the business should know what customizations exist. Before changing PHP versions, compatibility should be checked. Before moving servers, custom configuration should be documented.
The more unique the installation becomes, the more valuable proper backups and a clear maintenance process become.
Flexibility is one of the strengths of self-hosting.
It is also one of the reasons self-hosting demands more careful management.
When Vtiger Talks to Other Systems
Eventually someone asks the question that almost always appears once a CRM has become important:
“Can we connect this to the rest of the business?”
That can mean many things.
Perhaps a website should send new leads into Vtiger.
Perhaps an accounting system should exchange information with it.
Perhaps a customer portal should communicate with the CRM.
Perhaps another internal application needs access to selected records.
Vtiger's open-source documentation confirms that third-party applications can connect through REST APIs.
That is useful, because modern businesses rarely operate with one application doing everything.
But integrations also create hosting dependencies.
The server may need to make outbound HTTP or HTTPS requests.
Certificates need to validate correctly.
Firewall rules must allow legitimate traffic.
DNS needs to resolve properly.
Timeouts need to be sensible.
And the external service needs to remain reachable.
At that point, the CRM is no longer just a website running on a server.
It is a participant in a larger business system.
That is why a hosting provider should be able to discuss networking and server configuration rather than treating every application problem as “something inside your software.”
Is Shared Hosting Enough?
This is probably the question most small businesses will ask first.
And there is no honest one-word answer.
A small Vtiger installation can run successfully on a capable shared hosting environment when the server meets the application's technical requirements and provides enough practical resources.
The problem is that not all shared hosting is alike.
One provider may place strict CPU restrictions on every account.
Another may offer more generous resources.
One may allow the required PHP extensions.
Another may not.
One may support scheduled tasks properly.
Another may heavily restrict them.
One may provide useful technical support.
Another may simply point at the application and say that it is not their problem.
So the right question is not:
“Is shared hosting good or bad?”
The better question is:
“Does this particular shared environment give Vtiger what it needs?”
For a small company with limited usage, the answer may be yes.
For a busy CRM with many concurrent users, extensive integrations, large databases, or substantial attachment storage, the answer may eventually become no.
The trick is to recognize that before the application becomes a bottleneck for the business.
When a VPS Makes More Sense
After a while, Harbor Point wants something different.
It does not necessarily need a giant server.
It wants predictability.
A VPS can provide that kind of environment by giving the business greater control and a more isolated set of resources than ordinary shared hosting.
For a growing CRM, that can be useful.
The company can plan around its resources and have more control over the software environment.
But the freedom comes with a price that is not measured in dollars.
Someone has to manage the server.
Operating-system updates have to be handled.
Security has to be monitored.
Services have to be configured.
Backups have to be checked.
When something unusual happens, someone has to know where to look.
That makes a managed VPS an interesting middle ground for some businesses.
The CRM can have its own environment and more predictable resources while the hosting company takes responsibility for part of the underlying server administration.
For a technical team, an unmanaged VPS can provide excellent freedom.
For a small company that simply wants the CRM to work, managed infrastructure may be far more sensible.
The best option depends less on technical fashion and more on who will be responsible when the server needs attention.
Moving an Existing Installation
Eventually a business may decide to move.
The current host might have become restrictive.
The company may need more resources.
Support might have become disappointing.
Or the business may simply want greater control.
Moving Vtiger is not quite like moving a simple HTML website.
The application files need to be transferred.
The database needs to be transferred.
Configuration must be checked.
PHP compatibility has to be verified.
Required extensions must be available.
Database credentials need to be correct.
Scheduled tasks need to be recreated or confirmed.
Email connections should be tested.
SSL has to work.
Uploaded documents need to be present.
Customizations need to survive the move.
External integrations should be checked one by one.
And the new installation should be tested before the old server is abandoned.
A proper migration is usually uneventful.
That is exactly what you want.
A successful migration should feel almost boring because the difficult work happened before the DNS change.
That preparation is especially valuable when employees rely on the CRM for their daily work.
Choosing a Hosting Provider
Suppose you are comparing several hosting companies.
One has the lowest price.
Another advertises enormous storage.
A third talks constantly about unlimited everything.
A fourth sells premium VPS servers.
The fifth does not have the most impressive advertising, but when you ask a technical question, somebody gives you a useful answer.
The fifth one may deserve serious consideration.
For Vtiger, the useful questions are not mysterious.
Which PHP versions are available?
Can the required extensions be enabled?
Which database systems and versions are supported?
What are the CPU and RAM limits?
How many concurrent processes are permitted?
Can scheduled tasks run normally?
Are outbound connections restricted?
How are backups handled?
What happens when the account reaches its resource limits?
Can the environment be upgraded?
Will the provider help investigate server-side problems?
These questions tell you much more than a giant number printed next to “storage.”
Vtiger provides a knowledge base with technical and product documentation, and it is worth using that documentation when comparing a hosting environment with the requirements of the version you intend to install.
A hosting company does not need to be a Vtiger specialist to be useful.
It does, however, need to understand that an application like this is different from a five-page brochure website.
Managed or Unmanaged?
There is one final question that often gets buried beneath the technical specifications.
Who is actually going to look after the server?
If the answer is a full-time system administrator, an unmanaged VPS may be perfectly reasonable.
If the answer is the business owner who also handles sales, accounting, customer service, and everything else, the answer may be very different.
Managed hosting can remove a considerable amount of day-to-day server administration.
But “managed” should never be accepted as a magic word.
Ask what it means.
Who handles operating-system updates?
Who watches for server problems?
Who deals with resource issues?
Who helps when the database becomes unhealthy?
Who restores a backup?
Who handles the web server?
What happens when the customer needs a specific PHP setting changed?
There is a huge difference between a provider that advertises managed hosting and one that actually manages the environment in a useful way.
For some businesses, managed hosting is worth paying for simply because it lets employees concentrate on the CRM rather than becoming reluctant server administrators.
Common Hosting Mistakes
The first mistake is choosing a hosting account because it offers an enormous amount of storage.
Storage is important, but storage is not the same thing as processing power.
The second mistake is assuming that PHP support automatically means Vtiger compatibility.
The exact PHP version, extensions, database environment, and configuration all matter.
The third mistake is ignoring the database.
The CRM's records do not magically appear from nowhere. Every customer, lead, opportunity, activity, and report depends on the database working properly.
The fourth mistake is forgetting scheduled processes.
The visible application may work while background jobs fail silently.
The fifth mistake is treating backups as a checkbox.
A backup that has never been tested is much less reassuring than a restoration procedure that is known to work.
The sixth mistake is ignoring future growth.
A hosting account that looks perfect for five users may become uncomfortable for thirty.
The seventh mistake is updating everything blindly.
A newer PHP version is not automatically compatible with every version of the application. Compatibility should be checked before changing the server environment.
And perhaps the biggest mistake of all is waiting until the CRM is already struggling before doing anything about the hosting.
Planning is much easier while the system is still healthy.
A Practical Setup
So what would a sensible setup look like?
Start with the specific Vtiger version.
Check the requirements for that version rather than relying on a generic statement that the host supports PHP and MySQL.
Then look at the business itself.
How many employees will use the CRM?
How large is the database expected to become?
How much document storage will be needed?
Will email be integrated?
Will external systems communicate with Vtiger?
Will developers create custom modules or code?
How critical is the application to day-to-day operations?
A small business may be perfectly comfortable on a capable shared hosting account.
A larger business may benefit from a VPS.
A highly demanding environment may eventually justify dedicated resources.
The important thing is not to buy the most expensive server simply because it exists.
The important thing is to leave enough room for the application to operate comfortably.
Vtiger's published open-source hardware guidance lists 4 GB of RAM and substantial disk capacity for attachments, but actual requirements vary with users, data, integrations, and usage. That is why those figures are best treated as a planning reference rather than a universal server specification.
Good hosting starts with compatibility and then adds sensible headroom.
When the Business Grows
Five years later, Harbor Point looks very different.
The company has more employees.
There are far more customer records.
The sales pipeline is larger.
The support department depends on the CRM.
Documents are exchanged every day.
Several integrations have become essential to the business.
And the server is larger than the one the company originally rented.
That is not a failure.
It is growth.
One of the most sensible ways to approach hosting is to stop treating the initial server as a permanent decision.
A business changes.
The CRM changes with it.
The hosting should be allowed to change too.
A small installation may need little infrastructure.
A growing company may need more RAM, more CPU capacity, faster storage, or a more isolated environment.
The important thing is to have a path forward.
The best host is not necessarily the one that gives you the biggest machine on the first day.
It may be the one that can comfortably support you now and make the next upgrade straightforward when the time comes.
The Ending Is Really a Beginning
It is late on a Friday afternoon.
The office is getting quiet.
The sales team has finished its work.
A support representative closes the last ticket.
The manager checks tomorrow's appointments.
A new customer record has been added.
A document has been attached.
The CRM is still doing its work.
Nobody is thinking about Apache.
Nobody is wondering how much RAM is available.
Nobody is checking database storage engines.
Nobody is worrying about PHP configuration.
And that is exactly how it should be.
Good hosting tends to disappear into the background.
People notice it when it is bad.
When it is good, they simply use the application.
That is the real point of Vtiger hosting.
Vtiger can become the place where a business remembers its customers, tracks its opportunities, manages its activities, organizes support work, stores documents, connects applications, and keeps years of valuable information together.
But all of that has to happen somewhere.
The server underneath the CRM does not need to be spectacular for the sake of being spectacular.
It needs to be compatible.
It needs to have enough resources.
It needs to be secure.
It needs reliable storage.
It needs dependable database performance.
It needs to support the required background processes and external connections.
And it needs to give the business somewhere to go when the CRM grows.
That is why choosing Vtiger hosting should not begin with the cheapest monthly price.
It should begin with a much more useful question:
“What does this business need its CRM to do, and what kind of server will let it keep doing that reliably?”
Once that question is answered, the hosting decision becomes much easier.
The CRM stops being something you are merely trying to install.
It becomes what it really is:
A piece of business infrastructure.
Practical takeaway: Before installing Vtiger on your own hosting account, check the requirements for the exact version you plan to run. Pay particular attention to PHP compatibility, required extensions, database support, memory, scheduled tasks, SSL, storage, CPU and RAM availability, backups, security maintenance, and the hosting provider's ability to scale the environment as your business grows. Self-hosting gives you greater control, but it also means taking responsibility for the environment in which the CRM operates.
FAQ
This FAQ covers running the open-source vTiger CRM on web hosting, including server requirements, installation, databases, email, security, backups, performance, updates, troubleshooting, and choosing a hosting setup that makes sense for a real working installation.
FAQ menu
- 1. Choosing the Right Hosting
- 2. Server Requirements and Compatibility
- 3. Installing and Configuring the Application
- 4. Database, Files, and Storage
- 5. Email and Scheduled Tasks
- 6. Security and Backups
- 7. Speed, Reliability, and Scaling
- 8. Updates, Maintenance, and Troubleshooting
1. Choosing the Right Hosting
1. What kind of hosting is suitable for vTiger?
A normal shared hosting account can sometimes handle a small installation, but CRM software is a little different from a basic WordPress site. You have a database that is constantly being used, users logging in, records being searched and updated, files being uploaded, and usually some scheduled jobs running in the background. For a small team, good shared hosting may be perfectly adequate, while a busy installation is usually happier on a VPS or dedicated server where you have more control over PHP, the database, memory, cron jobs, and server configuration.
2. Can I run it on ordinary web hosting?
Yes, provided the hosting environment actually meets the requirements of the particular vTiger version you are installing. The important point is not whether the host calls itself "web hosting," but whether you have the required PHP version and extensions, database support, appropriate file permissions, enough memory, and access to the settings and scheduled tasks the application needs. I would always check the requirements for your exact release before signing up rather than assuming that every Linux hosting account will work.
3. Is shared hosting a bad idea?
Not automatically. I've seen people choose expensive VPS hosting for an installation that hardly gets used, when a decent shared account would have been enough. The problem starts when the account is heavily restricted or packed with other sites and resources become tight. A small company with a handful of users may be perfectly comfortable on shared hosting, but once the CRM becomes something your staff depend on all day, having dedicated resources becomes much more attractive.
4. When does a VPS make more sense?
A VPS starts to make sense when you need predictable resources or more control than shared hosting gives you. It is particularly useful when several people are using the system at the same time, the database has grown large, reports take noticeable time, you have lots of attachments, or you want control over cron, PHP configuration, caching, and server security. You also gain the freedom to tune the environment instead of working within whatever limits the shared host happens to impose.
5. Does the operating system matter?
For a typical self-hosted installation, Linux is the natural choice because the application is designed around the usual PHP, web-server, and database stack used on Linux hosting. The exact distribution matters less than getting a supported combination of PHP, database, web server, extensions, permissions, and security updates. In other words, I would worry much more about the actual software versions and configuration than whether the server has one popular Linux distribution name or another.
6. Should I choose Apache or another web server?
Apache is the safest choice when you want to stay close to the officially documented deployment environment. Vtiger's own technical prerequisites identify Apache as the recommended web server, while the software can also be deployed in other PHP-capable environments when configured properly. :contentReference[oaicite:0]{index=0}
Back to FAQ menu2. Server Requirements and Compatibility
7. Which PHP version should I use?
This is one of the questions where you really need to check the release you are installing. Older vTiger documentation lists much older PHP versions, while vTiger 8.0 specifically introduced stable PHP 8.x support and was documented with PHP 8.2. :contentReference[oaicite:1]{index=1} Do not simply select the newest PHP version your hosting panel offers and hope for the best, because an older vTiger release and a very new PHP release can be a frustrating combination.
8. Does it support MySQL?
Yes. MySQL is one of the main database choices used with self-hosted installations, and the project documentation also references MariaDB and PostgreSQL support. The important bit is matching the database version to the application release you are running rather than treating "MySQL" as one single compatibility level. Vtiger 8.0, for example, documented support for MySQL 8.x and MariaDB 10.x. :contentReference[oaicite:2]{index=2}
9. Can I use MariaDB instead of MySQL?
Yes, provided the particular release supports the MariaDB version supplied by your host. MariaDB is explicitly mentioned in vTiger's deployment requirements, and current project materials show database handling that is not limited to a single MySQL installation. :contentReference[oaicite:3]{index=3}
10. What PHP extensions are important?
The exact list depends on the release, but the installation checks commonly involve extensions such as IMAP, cURL, and XML, along with other PHP functionality required by the application and its libraries. The older official administration documentation also calls out settings such as memory_limit and maximum execution time, which is a good reminder that having PHP installed is only the beginning. :contentReference[oaicite:4]{index=4}
11. How much memory does a server need?
There is no magic number that works for every installation because the requirement changes with the number of users, modules, imports, reports, extensions, and background jobs. Older official documentation listed 4 GB of server RAM as a hardware guideline and a 256 MB minimum PHP memory limit, but I would treat those as historical baseline guidance rather than a promise that every modern installation will perform well with exactly those figures. :contentReference[oaicite:5]{index=5}
12. Do I need SSL?
Yes, especially for a CRM containing customer names, addresses, communications, notes, documents, and other business information. Technically, an installation can be exposed without HTTPS, but there is little reason to do that today. Vtiger's own technical guidance describes SSL as optional but strongly recommended for protecting data traveling between the browser and server. :contentReference[oaicite:6]{index=6}
13. Can I use a subdomain for the installation?
Absolutely, and it is often a sensible arrangement. Something such as crm.example.com keeps the application separate from the public website and gives you a clean address for staff. The important thing is to configure the application's site URL correctly; the installer itself warns that using an exact hostname rather than "localhost" avoids problems with certain plugins. :contentReference[oaicite:7]{index=7}
Back to FAQ menu3. Installing and Configuring the Application
14. Is installing it difficult?
The basic installation is not particularly mysterious: upload the files, create a database and database user, make sure PHP has the required extensions and settings, open the installation page, and enter the database and site details. Where things usually become interesting is after the installer finishes, because permissions, email, cron jobs, PHP compatibility, SSL, and server limits all have to behave properly. The installer checks several of these items for you, which is useful because it catches problems before you are halfway through the setup. :contentReference[oaicite:8]{index=8}
15. Do I need a separate database?
You should give the installation its own database rather than putting unrelated applications into the same database unless you have a very good reason not to. A dedicated database makes backups, restores, troubleshooting, permissions, migrations, and eventual moves to another server much cleaner. It also keeps the CRM's data isolated from a WordPress site or other applications living on the same account.
16. What database information will I need during installation?
You normally need the database hostname, database name, database username, database password, and port when a non-default port is being used. The installer tests the connection, so if one of those values is wrong it should become obvious fairly quickly. The project's installer code specifically checks the database connection parameters and whether the supplied account can access the database. :contentReference[oaicite:9]{index=9}
17. Should the application be installed in the main domain or a subdirectory?
Either can work, so this is mostly about how you want people to reach it. A subdomain tends to make a business installation feel cleaner and avoids mixing the CRM's files with a public website. A subdirectory can be useful when you have one domain dedicated to several internal applications, but I would not put it inside an unrelated site's directory just because there happens to be space there.
18. Are file permissions important?
Very much so. The application needs to be able to read its files and write to certain locations, while you do not want the entire installation writable by the web server. The installer checks read and write access and can refuse to continue when required permissions are not available. :contentReference[oaicite:10]{index=10}
19. Can I install it with a hosting control panel?
Usually yes, but the control panel is only the convenience layer. You can use it to create the database, configure the domain or subdomain, select the PHP version, manage SSL, create email accounts, and sometimes create cron jobs. The application itself still needs a compatible environment underneath, so a one-click installer is helpful but does not magically solve compatibility problems.
20. Can I move an installation from one host to another?
Yes, and this is one reason it is worth keeping proper backups from the beginning. A typical migration involves copying the application files, moving the database, restoring the database on the new server, checking the configuration, correcting the site URL and file paths where necessary, and then testing everything before switching users over. The safest approach is to make the new server work while the old installation remains untouched until you know the migration is good.
Back to FAQ menu4. Database, Files, and Storage
21. Where is the CRM data stored?
It is split between the database and the files on the server. The database contains the structured information that makes the CRM useful, while the filesystem is also important for uploaded documents, attachments, application files, and other stored resources. That means backing up only the database is not enough if you want a genuine disaster-recovery copy of the whole installation.
22. Do attachments use much disk space?
They can, and this is one of those things people sometimes overlook until the disk starts filling up. A CRM can accumulate contracts, quotations, PDFs, scanned documents, images, email attachments, and other files for years. I would keep an eye on storage from day one and choose hosting with enough headroom rather than buying a plan that is just large enough for today's data.
23. Is the database usually the biggest part of the installation?
Not necessarily. The database can become substantial, especially with a large number of records, logs, and activity history, but attachments and other uploaded files can grow much faster. When you are estimating storage, think about the database, application files, attachments, backups, temporary files, and logs instead of looking at the database size alone.
24. Should the database use InnoDB?
For MySQL-based installations, InnoDB is the expected storage engine in the official documentation and schema materials. It is important because the application relies on database behavior and relationships that should not be casually changed by selecting a different storage engine. :contentReference[oaicite:11]{index=11}
25. Can I put the database on another server?
Yes, provided the network connection, permissions, firewall rules, latency, and database compatibility are all handled correctly. Separating the web application and database can be useful on larger deployments, but for a small installation it can also add complexity without giving you a meaningful benefit. I would not split them apart merely because it sounds more professional.
26. Should I optimize the database manually?
Not as a routine hobby. A healthy database benefits from sensible indexing, appropriate database settings, clean data, and keeping the software itself in good condition, but randomly changing tables or indexes can create problems that are much harder to diagnose later. Before doing database surgery, take a proper backup and understand exactly what the change is supposed to achieve.
Back to FAQ menu5. Email and Scheduled Tasks
27. Can it send email through my hosting account?
Usually yes, as long as your hosting provider allows the required outbound mail configuration. You can configure the application to use an SMTP server, and that is generally preferable to relying on a vague server-side mail function because SMTP gives you clearer control over authentication and delivery. If email is business-critical, I would use a reliable mail service rather than assuming that every shared host's default mail server will give you perfect delivery.
28. Why do CRM emails sometimes land in spam?
The problem is usually bigger than the CRM itself. Sender reputation, the sending domain, SPF, DKIM, DMARC, the SMTP service, message content, and recipient-side filtering can all affect delivery. A perfectly configured application can still have poor email delivery when the underlying mail setup is weak, so I would troubleshoot the entire sending chain instead of blaming the CRM immediately.
29. Does it need cron jobs?
Many useful CRM functions depend on scheduled tasks, so yes, you should treat cron as part of the installation rather than an optional extra. Scheduled tasks can handle background work that you do not want a user to trigger manually every time. Exactly which tasks need scheduling depends on the version and modules you are running, so check your installation's administration settings and documentation rather than blindly copying a cron command from an unrelated release.
30. Can shared hosting run those scheduled tasks?
Often it can, but shared hosts differ considerably in how much cron access they provide and how frequently jobs may run. Some give you full control, some limit the minimum interval, and some only offer a web-based scheduler. For a light installation that may be perfectly fine; for a busy system, proper system-level scheduling on a VPS is much more comfortable.
31. What happens if scheduled jobs stop running?
You may notice that something that used to happen automatically simply stops happening: email-related processing may be delayed, recurring tasks may not execute, or background maintenance may quietly fall behind. The annoying part is that the main interface can still appear perfectly healthy. When something seems mysteriously delayed, checking the scheduled jobs and the server's cron logs is one of the first things I would do.
Back to FAQ menu6. Security and Backups
32. Is it safe to host customer information in it?
It can be, but the responsibility is shared between the application and the server environment. You need HTTPS, strong administrator passwords, sensible user permissions, secure file permissions, current software, a properly protected database, and reliable backups. A CRM is a much more interesting target than a simple brochure website because it can contain a surprisingly complete picture of a company's customers.
33. Should I restrict access by IP address?
That can be an excellent extra layer for an internal system, especially when staff normally connect from known offices or through a VPN. It is not practical for every organization, particularly when employees work from changing locations, but limiting administrative access is worth considering. The important thing is not to create a restriction so strict that people start bypassing it in unsafe ways.
34. Should the admin area have its own security rules?
Yes. Administrators have considerably more power than ordinary users, so protecting those accounts deserves extra attention. Use strong unique passwords, restrict unnecessary administrator accounts, avoid sharing credentials, and consider additional server-side access controls. Also remember that changing the login password does not repair a compromised server or a vulnerable plugin, so security has to be approached as a whole rather than as one checkbox.
35. How should I back it up?
You should back up both the database and the relevant application files, including uploaded data. I strongly prefer automated backups stored separately from the production server, with more than one recovery point retained. A backup sitting on the same server as the CRM is not much comfort when the server's disk dies, the account gets corrupted, or somebody accidentally deletes the wrong thing.
36. How often should backups run?
The sensible frequency depends on how much data you can afford to lose. If people enter important records throughout the day, daily database backups are a reasonable baseline and more frequent backups may be justified. File backups can sometimes follow a different schedule, but the real test is simple: decide how much work your company could recreate after a disaster and set the backup frequency accordingly.
37. Do backups actually need to be tested?
Absolutely. A backup that has never been restored is a theory, not a proven recovery plan. Every so often, restore the database and files to a separate test environment and make sure the application actually starts and the important records and attachments are there. It is far better to discover a broken backup procedure on an ordinary Tuesday than during the worst day your server has ever had.
Back to FAQ menu7. Speed, Reliability, and Scaling
38. Why can the CRM feel slow when the website is fast?
A fast public website does not automatically mean a fast CRM. A typical website may mostly serve cached pages, while the CRM is doing live database queries, permission checks, searches, calculations, record updates, and other dynamic work for each user. When it feels slow, look at server CPU and memory, database performance, PHP configuration, disk performance, network latency, and the particular screen that is taking time rather than judging the host by another website running on the same account.
39. Is SSD storage useful?
Yes. CRM workloads involve a lot of database and filesystem activity, so faster storage can make a noticeable difference compared with slow traditional disks. That does not mean an SSD automatically fixes every performance problem, but when the server is busy doing database work, better disk performance can remove one of the more obvious bottlenecks.
40. Does more RAM make a difference?
It can, particularly when several users are active and the server is also running the database, PHP workers, cron jobs, and other services. When memory is genuinely the limiting factor, adding RAM can make the whole environment more stable. But adding RAM to a server with a badly configured database or an inefficient query is a bit like buying a larger garage because your car has a flat tire.
41. How many users can one server handle?
There is no honest universal number. Ten active users running light workloads are very different from ten users importing thousands of records, generating large reports, attaching documents, and working through several modules at once. The sensible way to judge capacity is to monitor real CPU, RAM, database load, PHP workers, disk activity, and response times as usage grows.
42. When should I upgrade from shared hosting to a VPS?
The best time is usually before the CRM becomes painful, not after users start complaining every afternoon. Consistently high resource usage, slow database queries, limited cron control, memory limits, lack of configuration access, or the need for stricter security are all good reasons to move. You do not need a huge server simply because it is a CRM; you need a server that has enough resources and enough control for the workload you actually have.
43. Can caching improve performance?
Caching can help, but CRM caching is not quite the same game as caching a public website. You have to be careful not to cache pages or data in a way that exposes one user's information to another user or shows stale information where live data matters. I would first make sure the database, PHP environment, storage, and scheduled tasks are healthy before reaching for aggressive caching.
Back to FAQ menu8. Updates, Maintenance, and Troubleshooting
44. Should I keep the software updated?
Yes, but do it deliberately rather than treating every update as a button you can press without preparation. Updates can contain security fixes, bug fixes, library changes, and compatibility changes, and the correct upgrade path depends on the version you are starting from. Make a tested backup first, check the release notes and server requirements, and ideally test the upgrade on a staging copy before touching the live CRM.
45. Can I update PHP without checking the CRM version?
I would not. This is one of the easiest ways to break an otherwise healthy installation. A PHP version can be perfectly supported by the server and still be incompatible with the particular vTiger release or a third-party extension you rely on. The project's own history shows why checking the actual application release matters: PHP 8.x support was specifically highlighted as a major part of the 8.0 release. :contentReference[oaicite:12]{index=12}
46. What should I check when the installer reports a PHP problem?
Start with the PHP version, required extensions, memory limit, maximum execution time, error reporting configuration, and file permissions. Those are not theoretical concerns: the official installation documentation lists them among the prerequisites and recommended settings. :contentReference[oaicite:13]{index=13} Also remember that hosting control panels sometimes let you select one PHP version for the account while command-line tools or cron jobs use another, which can create wonderfully confusing symptoms.
47. What if the database connection fails?
Check the database hostname, port, database name, username, password, and the user's privileges first. Then check whether the database server is reachable from the web server and whether the selected database type and version are supported. The installer itself distinguishes between invalid connection parameters, unauthorized database users, missing databases, and other connection problems, so those messages can narrow the problem down considerably. :contentReference[oaicite:14]{index=14}
48. Why does an upgrade sometimes work on one server but fail on another?
Because the application is only one part of the equation. Two servers can have different PHP versions, extensions, database versions, permissions, web-server behavior, PHP settings, cron configuration, or security restrictions. This is why cloning a working installation into a test environment that closely matches production is so useful: it lets you discover environmental differences before users discover them for you.
49. What should I check first when something suddenly stops working?
Resist the temptation to change ten things at once. Check what changed immediately before the problem appeared: a PHP upgrade, application update, server migration, expired certificate, database change, plugin modification, cron failure, storage issue, or permission change. Then look at the relevant application and server logs and reproduce the problem in a controlled way. In my experience, troubleshooting gets much easier once you stop guessing and start establishing exactly which layer is failing.
50. Is a managed server worth paying for?
For a company that needs the CRM but does not want to become its own server administrator, absolutely. With managed hosting, someone else can take care of operating-system maintenance, security updates, monitoring, backups, PHP configuration, and other server chores that otherwise land on your desk. If you already enjoy managing Linux servers and know exactly what you are doing, unmanaged hosting can save money, but there is no prize for spending your Saturday night diagnosing a PHP configuration problem when you could have paid somebody else to do it.
51. What is the biggest hosting mistake to avoid?
Choosing a host based only on the cheapest price or the number of websites it says you can host. For this kind of application, the important questions are whether the software version you need is supported, whether you get enough memory and CPU, whether the database is properly supported, whether cron is available, whether backups are reliable, and whether you can get sensible technical support when something breaks. A slightly more expensive environment that behaves predictably is often far cheaper than a bargain account that becomes unreliable once your business depends on it.
Back to FAQ menu