Custom ERP Hosting Requirements on a Saudi Server: Resources, Security, and National Access

The Direct Answer: What a Custom ERP Needs on a Saudi Server

A custom ERP for a mid-sized company, roughly 20 to 100 concurrent users, needs a practical minimum of 4 to 8 vCPU, 8 to 16 GB of RAM, and 40 to 100 GB of SSD storage, with the database separated from the application layer once your active load grows past a couple dozen users. But raw numbers do not settle the decision. The bigger questions in ERP hosting are where the data lives, how it is secured, who can reach it, and whether the system integrates with National Access and government entities. Those factors force a server inside Saudi Arabia, because government integrations often reject calls originating from foreign IP addresses, and because latency from a Riyadh server is around 8ms versus 100 to 120ms from a European one. That gap shows up directly on every database query, and a single page load in an ERP fires dozens of them.

This guide breaks down custom ERP hosting requirements point by point: sizing resources against real load, tuning the database, layering security, integrating with National Access, and building a backup and continuity plan. It is written for companies that built their system in-house or through a developer and want to move it onto Saudi infrastructure without performance or compliance surprises.

Sizing Resources: How Much vCPU, RAM, and SSD You Actually Need

The engineering rule is to start from load, not from guesswork. A concurrent user in an ERP is not a registered user, it is someone sending an actual request at that moment, and that is usually only 10% to 20% of your total users. A company with 200 staff on the system might peak at just 30 to 40 real concurrent users, and that is the number your resources should be built on.

For each active concurrent user in a typical ERP, budget roughly 150 to 250 MB of RAM for the application layer, and expect one CPU core to serve 8 to 12 concurrent users under normal load. Following that logic:

• Up to 20 concurrent users: a Growth plan with 2 vCPU and 4 GB RAM can work at first, but 4 vCPU and 8 GB is safer if your reports are heavy.
• 20 to 50 concurrent users: a Business plan with 4 vCPU and 8 GB RAM is the sensible starting point.
• 50 to 100 concurrent users: an Enterprise plan with 8 vCPU and 16 GB RAM, with the database moved onto its own instance.

For storage, do not look only at your current data size, look at its growth. An ERP database in an active company grows 20% to 40% per year, so provision at least double your current footprint. Insist on SSD only, because the difference between SSD and a spinning disk in random access time is more than 20 times, and random access is exactly the ERP pattern: many small, scattered queries. On Cloud every plan is SSD by default, and you can add storage in clearly priced 100 GB steps whenever you need it.

The Database: The Single Most Important Hosting Decision

The database is the bottleneck in 80% of the ERP performance problems we see during migration. The system may be well written, yet one query without a proper index is enough to drag the whole server down. That is why isolating and tuning the database is not optional.

Separating the Application and Database Layers

While concurrent users stay under 25, running the application and database on the same instance is safe. Above that, split them onto two instances, because they compete for memory and CPU in different ways: the application wants compute, the database wants memory and I/O. Separation can lift performance by up to 30% under load, and it lets you scale each layer independently of the other.

Tuning MySQL or PostgreSQL

Whatever your engine, these settings make the difference:

• Buffer cache: in MySQL, set innodb_buffer_pool_size to 60% to 70% of the RAM dedicated to the database, because that memory keeps indexes and hot data close without hitting the disk.
• Indexes: review slow queries through the slow query log with a one-second threshold, and add indexes on the columns used in conditions and joins. One correct index can cut a query from 4 seconds down to under 50ms.
• Connections: set max_connections to your real load rather than an inflated number, because every connection reserves memory, and an oversized value burns RAM for nothing.

Keep the database on the same Saudi server, close to the application, because even one extra millisecond per query adds up to a noticeable delay when a single page load issues dozens of queries.

Security: Layers, Not a Single Control

ERP security is built in layers, because any single layer will fail eventually. The data here is sensitive: salaries, contracts, invoices, and customer records governed by Saudi data protection rules. A serious minimum includes:

• Network isolation: the database is never exposed to the public internet. It sits behind a firewall that accepts connections only from the application layer. Close every port you do not use, and keep the database port, 3306 or 5432, fully closed externally.
• Encryption: SSL on every connection and disk encryption for data at rest. Cloud provides free Let's Encrypt certificates, which covers encryption in transit at no cost.
• Access control: never use the database root user inside the application, use a least-privilege user instead. Enable two-factor authentication on the control panel and SSH access, and restrict SSH to keys rather than passwords.
• Patching: one late security patch is enough for a breach. Around 60% of breaches exploit known vulnerabilities that already have a published fix, so patch the operating system and database engine on a schedule.

Add DDoS protection when the system serves external users or portals, since it is a clearly priced add-on on Cloud and saves you a costly outage.

National Access Integration and Why It Forces a Saudi Server

This is the core reason companies with custom systems look specifically for a Saudi server. Unified National Access integration and government interfaces often require calls to originate from infrastructure inside the Kingdom, and some of them block or throttle requests from foreign IP addresses for compliance and data sovereignty reasons.

When your server is in Riyadh, you are inside the digital boundary these systems expect, and reaching their gateways is measured in fractions of a hundred milliseconds instead of an international round trip. In practice, an integration that takes 250ms per call from a European server can drop below 20ms from a Saudi one, and that gap is decisive when a single login flow chains several sequential calls. On top of that, many data-residency compliance requirements are simply not met unless the data physically resides inside Saudi Arabia, which is an infrastructure condition, not a configuration one.

Backup and Business Continuity: RPO and RTO

Losing ERP data is not an inconvenience, it can be an operational disaster that halts invoicing, inventory, and payroll. That is why backup is measured by two figures: RPO, how much data you can afford to lose in time, and RTO, how long you can afford to be down before recovery.

• Low RPO: for an active ERP, target an RPO under one hour with database snapshots repeated through the day, not a single daily backup that costs you a full day of work on any failure.
• Multiple tiers: a daily backup for fast recovery, plus weekly and monthly for older rollbacks. Cloud provides daily, weekly, and monthly backups on all managed hosting plans at no extra cost.
• Restore testing: a backup whose restore was never tested is not a backup, it is an assumption. Test the restore at least quarterly so you know your real RTO before you need it on a failure day.

Keep a copy off the server itself, because a backup on the same disk dies with the disk. The well-known 3-2-1 rule means three copies on two different media with one copy off-site, and that is the level that actually protects you.

Checklist Before Migrating Your ERP to a Saudi Server

Before moving your custom system, review these items to avoid the most common migration problems:

• Resources: you sized against real concurrent users and left at least a 30% growth margin.
• Database: you separated it past 25 concurrent users and reviewed indexes and slow queries before migrating, not after.
• Security: you closed the database port externally and enabled SSL, two-factor authentication, and a least-privilege database user.
• National Access: you confirmed the server IP is Saudi and registered wherever the government integrations require it.
• Backup: you defined RPO and RTO, enabled multi-tier backups, and ran at least one full restore test.

Cloud does not migrate custom systems on behalf of your developer, but it provides the correct Saudi infrastructure and engineering support for your team through guidance sessions during migration. You choose resources freely through the VPS configurator, the server activates within seconds of payment, and you build your system on it at 8ms latency from Riyadh with compliance inside the Kingdom.