Choosing and Operating a VPS for Odoo and ERPNext

When you decide to run Odoo, ERPNext or any self‑hosted CRM/ERP platform, your hosting choice stops being a simple “where do I put my website?” question. These applications are stateful, database‑heavy and business‑critical. A misconfigured server, slow disk or weak backup strategy does not just mean a minor performance issue; it can directly affect sales, invoicing, stock management and customer support. These requirements can justify choosing a properly sized VPS, dedicated server or colocation setup rather than shared hosting or a “one click” environment with limited administrative control.

In this guide we will walk through how to choose and configure VPS hosting specifically for Odoo, ERPNext and similar self‑hosted CRM/ERP stacks (Dolibarr, SuiteCRM, Yetiforce, etc.), along with supporting tools such as Metabase dashboards. We will look at illustrative sizing and how to validate it, database and storage choices, security, backups, monitoring and scaling paths. The guide is an operations overview: application-specific worker and reverse-proxy settings still need to follow the chosen release and deployment method.

Why VPS Hosting Fits Odoo, ERPNext and Other Self‑Hosted ERPs

ERP and CRM platforms are very different from a brochure website or small blog. They maintain thousands or millions of database rows, handle concurrent users and must stay responsive during working hours. Choosing the right hosting model is the first strategic decision.

Shared hosting vs VPS vs dedicated for ERP/CRM

The basic hosting models to compare are:

• Shared hosting: Great for classic PHP websites and small apps, but usually the wrong place for Odoo or ERPNext. You share CPU, RAM and I/O with many other customers, have limited process control and often cannot tune PostgreSQL or MariaDB the way an ERP needs.
• VPS hosting: Compare CPU allocation guarantees, RAM and storage limits, root access and firewall control for the chosen plan. Do not assume that a vCPU allocation means dedicated physical CPU capacity or that storage I/O is exclusive. A plan with sufficient administrative control lets you install and tune a compatible ERP stack. Compare the total cost and operating responsibility with the alternatives.
• Dedicated server or colocation: When measured resource needs, reporting, integrations or hardware-control requirements justify it, it can be worth moving to a physical server or even housing your own hardware via colocation services to host your own server (Turkish guide). You gain control over the physical server’s resources, but performance still depends on sizing and configuration, and operational responsibility increases.

A VPS is one possible starting point when the supported application stack, measured workload and acceptable downtime fit the plan. Evaluate service limits and management responsibility before deciding whether VPS, dedicated or another deployment model is appropriate.

What makes ERPs demanding on the server side?

Odoo, ERPNext and similar systems are not CPU monsters all the time, but they are sensitive to resource quality and consistency:

• Database‑heavy: Many application actions read or update several tables. Slow disk I/O or poorly tuned PostgreSQL/MariaDB shows up as sluggish forms and reports.
• Stateful sessions: Users stay logged in for hours. Timeouts or aggressive process killing immediately hurt usability.
• Background workers: Queues process emails, PDF generation, stock movements and scheduled jobs. Budget their peak RAM and CPU demand alongside interactive requests.
• Business‑critical data: Invoices, purchase orders, HR data, CRM pipelines. Backup and recovery planning is non‑negotiable.

Because of these characteristics, you want predictable vCPU, fast storage (ideally NVMe) and the ability to tune the database engine, web workers and caches. A VPS can meet these needs, but resource guarantees and measured performance matter more than the VPS label alone.

Choosing VPS Specs for Odoo, ERPNext and Other Self‑Hosted ERPs

Picking CPU, RAM, disk and bandwidth for an ERP is often where people either overspend or under‑provision. Start with three questions: how many users, what kind of workload and what kind of growth do you expect in the first 12–24 months?

CPU and RAM sizing by user count

You do not need a huge VPS for a small team, but you also should not shoehorn an ERP into minimal resources. Treat the following as illustrative starting configurations for one production instance (web + database on the same VPS), not measured user-capacity limits. Distinguish total accounts from simultaneously active users, and validate sizing with representative peak workloads for your application version, modules and worker count:

• Very small teams (up to ~10 users)
  Use case: micro business, single branch, light modules (Sales, CRM, basic stock).
  Suggested baseline: 2 vCPU, 4–8 GB RAM.
  Notes: Keep an eye on RAM usage with reporting modules and PDF generation.
• Small/medium teams (10–40 users)
  Use case: multiple departments, warehouse, accounting, more integrations.
  Suggested baseline: 4 vCPU, 8–16 GB RAM.
  Notes: Monitor background job contention and assess whether worker separation or application‑supported caching would help.
• Larger deployments (40–100+ users)
  Use case: many concurrent users, multi‑company, heavy reporting, APIs, BI tools.
  Suggested baseline: 8+ vCPU, 16–32 GB RAM (still can be VPS, or consider dedicated).
  Notes: Consider separate database and application tiers if monitoring shows resource contention that scaling this VPS cannot adequately resolve.

These are starting points, not strict rules. For example, an ERP used mostly for point‑of‑sale with many small transactions might be CPU‑light but I/O‑sensitive, while a team that runs complex financial consolidation reports might need more RAM and CPU but less disk.

Storage: capacity, performance and RAID

ERP databases grow steadily. Attachments (PDFs, scanned invoices, images) can grow even faster than transactional data. For production we recommend:

• Disk type: Prefer high‑performance SSD or NVMe‑based VPS plans. For an in‑depth look at why NVMe matters for databases, you can read our NVMe VPS hosting guide explaining IOPS and real‑world gains.
• Capacity planning: An illustrative starting allocation is 80–120 GB, not a universal minimum. Size it from the database, attachments, logs, temporary files and local backup staging, plus expected growth; document management can substantially increase storage needs.
• Headroom: A 30–40% free-space allowance can be an initial planning example. Validate it against database growth, temporary sorts, logs and the largest backup or restore staging requirement.

On a VPS, the provider manages the underlying storage; do not assume it uses RAID. Evaluate storage redundancy and consistent low‑latency I/O for the chosen plan. Redundancy does not replace backups. A dedicated server with an appropriate storage design is one possible later option; RAID or ZFS alone does not ensure backup, availability or application recovery.

Network and bandwidth considerations

Most ERP/CRM deployments are not bandwidth‑heavy compared to video streaming, but consistent, low‑latency connectivity to your main office(s) matters a lot. When choosing location and network:

• Pick a data center region close to your users and measure latency over the actual access path; distance alone does not determine network performance. Our article on how server location affects speed and user experience also applies to internal tools like ERPs.
• Consider VPN access if you need to expose the ERP only to internal staff. A site‑to‑site VPN from your office to the VPS is a common pattern.
• Plan bandwidth for remote branches and mobile users, especially if they upload or download large attachments.

Operating System, Database and Architecture Choices

Once you have a sense of size, the next step is choosing your OS, database and high‑level architecture. For a modest initial workload, a simple, well‑configured single VPS can avoid unnecessary complexity on day one, provided its downtime and recovery limits meet business needs.

Choosing a Linux distribution

Choose a Linux distribution and release supported by your target ERP version and installation method. The following are general distribution options, not a compatibility list for every Odoo or ERPNext release:

• Ubuntu LTS: Check the supported release and package versions in the ERP installation guide.
• Debian: Evaluate release support, package versions and the team’s maintenance process.
• AlmaLinux / Rocky Linux: RHEL-compatible options to evaluate where the application and installation method support them. The current Frappe installation page lists Debian/Ubuntu among officially supported systems; this is not a blanket ERPNext support list.

If you are unsure, consider an Ubuntu LTS release explicitly supported by your ERP version and installation method rather than assuming any LTS release will work. For a deeper comparison, see our article on choosing a Linux distro for your VPS, where we break down pros and cons for real‑world hosting workloads.

Databases: PostgreSQL vs MariaDB/MySQL

The ERP/CRM platform usually dictates the database engine:

• Odoo: Uses PostgreSQL. Odoo 19 documentation specifies PostgreSQL 13 or later; verify the requirements of the actual Odoo release being deployed.
• ERPNext: Use the documented ERPNext deployment path with MariaDB for this guide’s example, rather than treating MySQL as an interchangeable engine. For deployment planning in November 2026, the current Frappe installation requirements list MariaDB 10.6.6+ for v14/v15 and MariaDB 11.8 for v16/develop. Match the exact ERPNext and Frappe releases, database version and installed extensions before deployment; older installations need their own release-specific upgrade path. PostgreSQL work merged into ERPNext develop in June 2026, but that does not establish compatibility for every released stack, extension or migration path.
• Other CRMs/ERPs: Some support both PostgreSQL and MySQL/MariaDB; some are tied to one.

Whichever you use, review the database settings against your VPS resources and measured workload. Review shared buffers, work memory and connection limits on PostgreSQL, or buffer pool and log settings on MariaDB/MySQL; change them where measurements justify it. We have a detailed guide on PostgreSQL performance tuning on a VPS, which is directly relevant to Odoo. For the ERPNext/MariaDB example, review MariaDB-specific backup and tuning guidance for the selected version. For CRMs that support MySQL, our articles on MySQL backup strategies and WooCommerce/MySQL tuning offer background concepts, not an ERPNext compatibility or configuration recipe.

Single VPS vs multi‑VPS architecture

For an initial workload that meets the single-node resource and recovery limits, consider a single, well‑sized VPS that runs:

• Application server (Odoo/ERPNext, workers, background jobs)
• Database (PostgreSQL for Odoo; MariaDB for the ERPNext example; a supported engine and version for other apps)
• Reverse proxy (Nginx or Apache) terminating HTTPS

A single host reduces the number of network dependencies, but backups still need a consistent database/file recovery set and independent storage. The host is a shared failure and maintenance point. As usage grows, you can evolve towards:

• A separate database VPS or dedicated server
• A separate worker VPS (for background queues, reports, integrations)
• Load‑balanced application servers behind a reverse proxy or dedicated load balancer

Separating tiers adds network latency and access-control work. Multiple application nodes need the application’s supported design for sessions, attachments, queues and scheduler ownership. Load balancing alone does not add failover to the database or file store; test the complete recovery path.

Our article on when to separate database and application servers covers the decision points in detail and applies nicely to ERPs as soon as query load or maintenance windows start to impact users.

Containers vs classic installation

It is absolutely possible to run Odoo or ERPNext in Docker on a VPS, and in some teams this works very well. But containerization is not a requirement for a robust ERP deployment. Teams familiar with traditional hosting may prefer a classic “packages + virtualenv” setup because:

• It may fit the team’s existing service and package management experience.
• Database and file recovery can be documented explicitly with the application’s supported tools.
• Troubleshooting uses the team’s existing host-level tools, while still requiring ERP-specific knowledge.

Containers can support repeatable staging and deployment when the team can operate persistent storage, networking and secrets. Direct installation on a VPS is also an option when supported and documented. In either case, changing an image or package version back does not reverse a database migration; coordinate the application, database and files in the rollback plan.

VPS Setup Checklist for Odoo, ERPNext and Self‑Hosted ERPs

Once you have your VPS ready, prepare access, updates and recovery before business users start working. We have a general guide on what to do in the first 24 hours on a new VPS; here is how we adapt that playbook specifically for ERP and CRM workloads.

1. System updates, users and SSH hardening

• Apply supported security updates with a maintenance and rollback plan; decide which updates can be unattended and monitor their outcome.
• Create a non‑root sudo user and configure SSH keys. Verify key login and sudo access in a separate session before disabling direct root SSH logins or password authentication.
• If possible, restrict SSH to specific IPs or a VPN; verify that the allowed route works before closing your existing session.
• Enable a firewall (UFW, nftables) to allow only required SSH, HTTP/HTTPS and VPN access. For Docker deployments, review published ports separately: published container ports can bypass expected UFW filtering.

Our deeper dive on how to secure a VPS server against real‑world threats is worth following step‑by‑step for production ERPs.

2. Install and secure the database engine

For Odoo with PostgreSQL, or the documented ERPNext deployment path with MariaDB, first confirm the database version required by the chosen application and framework releases. For other CRMs, select their supported engine and version. Then apply the following checklist using that engine’s settings:

• Bind the database to 127.0.0.1 only when the application connects locally. If a separate application server needs database access, use a private network or VPN and restrict access to authorized application hosts with firewall rules and database authentication.
• Use separate, limited application credentials and protect administrative access. Remove only confirmed unnecessary test accounts/data; do not delete databases required by the ERP.
• Review the selected engine’s memory, logging and connection limits against measured concurrency; PostgreSQL and MariaDB setting names and semantics differ.
• Configure log rotation and slow‑query logging for later optimization.

This preparation can reduce configuration-related slowdowns and make later bottlenecks easier to diagnose.

3. Deploy the application and reverse proxy

Whether you use Odoo or ERPNext, a typical pattern is:

• Run the application with its own system user and virtual environment / app directory.
• Use the chosen distribution’s supported process manager, such as systemd or the ERP deployment’s supervisor, with explicit restart and startup policies for workers and queues.
• Place an Nginx (or Apache) reverse proxy in front to terminate HTTPS. Verify the release-specific routing for interactive, long-lived and attachment requests; compression requires supported modules and suitable content types.
• Configure strong TLS with modern ciphers and correct redirects; enable HSTS once HTTPS works reliably for the intended hostname scope. Review HTTP security headers such as HSTS and CSP as part of hardening the public interface; browse the DCHost blog for related guidance.

4. Timezone, locale and backups from day one

Few things confuse business users more than mismatched dates and times:

• Set the server timezone correctly (or keep it in UTC and configure timezone per user in the ERP, but be consistent).
• Ensure locales support your currency, number formats and language needs.

Then, before anyone enters real business data, put a backup strategy in place. Do not wait:

• Schedule regular database dumps (at least daily, or more frequently to meet your recovery point objective).
• Archive application files, attachments and required configuration. Use the ERP’s supported backup workflow or coordinate database and file backups so they form a consistent recovery set.
• Send an independent copy off-server (for example, S3-compatible storage or a separate backup server). For data-center loss, use a different location; another VPS in the same facility does not address that risk. Limit backup deletion/access separately from production.
• Test a full restore in an isolated environment before relying on the backups, and repeat restore checks regularly.

For Odoo, include the database and filestore. For ERPNext, include the database, public/private files, required site configuration and securely retained keys. The default Bench backup command creates a database dump; file backups need the supported file option. Record the matching application and extension versions.

If you want a structured approach, our article on how to design a backup strategy using RPO/RTO and the practical guide to the 3‑2‑1 backup rule on VPS environments provide planning principles; adapt the backup tool and consistency procedure to the selected ERP and database.

5. Monitoring, logs and alerting

Combine availability, resource and application checks, then test what they detect. Monitoring can help identify failures sooner, but it cannot guarantee notification before users notice. At a minimum:

• Monitor CPU, RAM, disk usage, disk I/O, network and database availability.
• Track key application metrics: worker queue length, background job failures, response times.
• Configure alerts for disk space thresholds, high load, backup failures and SSL expiry.

Our article on VPS monitoring and alerts with Prometheus, Grafana and Uptime Kuma describes the distinct roles of these tools. For more advanced centralized logging across multiple VPSes, evaluate a Loki or ELK design with the correct ERP log formats, permissions and retention. For new Loki collection, use a supported client such as Grafana Alloy: Promtail reached EOL on 2 March 2026. Test ingestion, a representative error, notification delivery and recovery separately.

Performance Tuning and Scaling Your ERP on a VPS

After the initial deployment, real‑world usage will uncover where your bottlenecks really are. Use those measurements to decide whether tuning, resource upgrades or architecture changes are appropriate before introducing complex clusters.

Application‑level optimizations

Start with the ERP configuration itself:

• Limit installed modules to what you actually use; every extra module can add fields, validations and menu items that cost CPU and RAM.
• Configure worker processes sensibly (number of Odoo workers, ERPNext queue workers) to match your CPU, RAM and measured workload rather than assuming the defaults fit your deployment.
• Use the application’s supported cache and queue services, such as Redis/Valkey where the chosen release calls for them. Session, cache and queue roles are different; adding Redis to Odoo does not automatically move sessions or make multiple nodes safe.

Database tuning as usage grows

Database bottlenecks are one possible cause of an ERP slowing down at particular hours. Use measurements to confirm whether queries, memory pressure or disk I/O are involved before changing settings. Some key actions:

• Enable slow query logging and review which reports or pages cause heavy queries.
• Test supported index changes against representative queries, write overhead and future ERP migrations before applying them.
• Increase memory parameters cautiously to reduce disk I/O while avoiding swapping.
• Configure rotation and retention without removing unread records; confirm the collector and backup process can handle the chosen rotation/compression timing.

For PostgreSQL‑backed Odoo, our friendly VPS playbook for PostgreSQL performance walks through shared_buffers, work_mem, WAL and connection pooling in detail. Capacity measurement is also useful for MariaDB, but PostgreSQL parameter names, WAL and PgBouncer are not MariaDB configuration instructions. Use the chosen engine’s supported settings and tools.

When to scale up vs scale out

There are two broad paths when you hit resource limits:

• Scale up (vertical): Increase VPS vCPU, RAM and disk. Check plan limits, cost, resize downtime and the measured bottleneck; no fixed extension of useful life is guaranteed.
• Scale out (horizontal): Add more VPSes: one for database, one or more for application, possibly a separate one for background workers and reporting. Introduce load balancing or replication only with the required state handling and tested failure behaviour.

Use measurements and recovery requirements to decide whether to remain on one VPS, separate tiers or change hosting models. Reasons to investigate a different design include:

• Database maintenance windows clash with business working hours.
• Backups on the same VPS significantly impact performance.
• You require high availability with failover across nodes or data centers.

A mixture of VPS, dedicated resources or colocation is an option, not a redundancy guarantee. Identify shared power, storage and network dependencies; define replication, failover, recovery ownership and tests before claiming high availability.

Staging, Upgrades and Safe Change Management

ERP systems evolve: new modules, version upgrades, integration changes. Doing all of this directly on production is asking for trouble. A safe workflow typically includes at least a staging environment and clear backup/rollback procedures.

Staging environments on a second VPS

A separate staging ERP instance can use a consistent, appropriately minimized and masked copy of production data. A smaller VPS can help functional testing, but it cannot prove production capacity. Use it to:

• Test version upgrades of Odoo, ERPNext or modules.
• Validate new workflows, fields and customizations with key users.
• Experiment with performance settings (workers, cache, database tuning) before applying to production.

Restore a coordinated database/file copy into an isolated staging environment. Disable real email, payment/e-invoicing endpoints and scheduled external effects before starting jobs; replace production credentials. Masking or neutralization is not proof that every sensitive value or custom integration is covered. Do not connect ordinary staging to live production replication by default.

Version upgrades and rollback strategy

Whether you are moving between minor releases or major versions, upgrades should be treated like small projects:

• Take a consistent recovery set: database, attachments, required configuration, keys and matching application/extension versions. Test restoring it.
• Rehearse the upgrade on staging and measure how long it takes.
• Communicate a maintenance window, even if you expect minimal downtime.
• Define rollback criteria and a write cutoff. If restoring the old version, restore its matching database and files and reconcile writes accepted since the backup; do not run old code against an upgraded schema. Frappe site downgrades are not supported.

Record the rehearsal time, validation results and rollback cutoff. During a migration, stop writes from users, workers and integrations before the final consistent transfer; do not leave old and new environments writable at the same time. DNS cache expiry alone does not make the transition loss-free or interruption-free.

When a VPS Is Not Enough: Dedicated and Colocation Options

Evaluate dedicated servers or colocation when measured hardware needs or specific operating requirements justify them. The following are example signals to investigate, not automatic thresholds:

• There are hundreds of concurrent users, multiple warehouses and regional offices using the system all day.
• The ERP is integrated with many external systems (e‑commerce, BI, payment gateways, legacy on‑prem software) and acts as a central data hub.
• Regulatory or internal IT policies require dedicated, auditable hardware or specific storage/network topologies.

In those situations, a dedicated server gives you direct access to all hardware resources, and colocation allows you to place your own servers into professional data centers with power, cooling, network and support responsibilities defined by the service contract. You can read more about choosing between dedicated server and VPS and how to use colocation to host your own servers (Turkish guide) when your ERP becomes truly enterprise‑critical.

Wrapping Up: A Practical Roadmap for Your ERP on a VPS

An ERP hosting decision should tie the supported software stack to the workload, access boundaries and recovery targets. Use this roadmap to produce a plan you can validate:

• Choose an initial VPS candidate; 2–4 vCPU and 4–16 GB RAM are illustrative test ranges, not a capacity promise. Measure representative peak jobs, disk headroom and user latency.
• Pick a supported OS release and the correct database engine/version: PostgreSQL for Odoo; MariaDB for this ERPNext example; the documented choice for other apps. Verify application, framework and extension compatibility.
• Harden the VPS, configure HTTPS, logging and monitoring/alerts before onboarding users.
• Implement a 3‑2‑1 backup strategy and regularly test restore procedures to measure actual recovery time and data completeness.
• As load grows, use measurements to choose among application changes, database tuning, vertical resources or tier separation. There is no mandatory upgrade order; recovery and isolation requirements may also justify a different design.

When comparing DCHost or another provider, confirm resource limits, backup scope, resize conditions and who operates the ERP software. Application upgrades, migrations and managed database support are not implied by a VPS plan. Before going live, validate login, business transactions, attachments, background jobs, restore and alert delivery, and retain the results with the operating plan.

Official Technical References

• Odoo 19 deployment guide
• Frappe backup scope
• Frappe restore limits
• Promtail lifecycle