Hosted ERP: The Difference From Cloud ERP, What It Costs to Run, and How to Self-Host One Without a Sysadmin

Hosted ERP means a single-tenant copy of an ERP system running on servers someone else operates, which is different from cloud ERP, where the vendor runs one multi-tenant application for everyone and upgrades it on their schedule, and from on-premise, where the servers are in your building. You get your own instance, your own database, your own upgrade timing and your own customisations, and you pay for the infrastructure and the people who keep it patched instead of a per-user subscription. For a small or mid-sized business the choice usually comes down to one question: do you need to modify the system, or do you need to stop thinking about it. Modify means hosted or self-hosted; stop thinking means cloud.

The three terms get blurred in vendor copy because every vendor wants to be described as cloud. The differences are concrete, they decide the bill and the upgrade path, and one of the options, running an open-source ERP on a container platform, has become straightforward enough that a business with no infrastructure staff can do it.

Table of contents

• The three models, precisely
• What hosted gives you that SaaS does not
• What the monthly cost is made of
• Self-hosting an open-source ERP on a container platform
• Sizing, in concrete terms
• Choosing in one sentence each
• How this fits the rest of the stack
• FAQ

The three models, precisely

• On-premise. The ERP runs on hardware you own, in a room you control. You buy the licence, the servers and the backup system, and you employ or contract whoever keeps it running. Total control, total responsibility, and a capital cost up front.
• Hosted. The same single-tenant installation, moved to a provider’s data centre or a cloud virtual machine. The licence model is often the same as on-premise. The provider handles the hardware, the network and usually the operating system; you or a partner handle the application, its upgrades and its backups. Reachable over a VPN, a remote desktop, or a browser depending on the product.
• Cloud, or SaaS. One version of the application, run by the vendor, shared by all customers, with your data isolated logically. Upgrades happen to everyone at once. You cannot modify the codebase, only configure within what the vendor exposes. Priced per user per month.

The word cloud in a product name does not tell you which of these you are buying. Ask whether you get your own database, whether you choose when upgrades happen, and whether you can change the code. Yes to all three is hosted; no to all three is SaaS.

What hosted gives you that SaaS does not

• Customisation without permission. Manufacturing, distribution and any regulated industry tend to need workflows the vendor did not anticipate. On a hosted instance you or a partner change the code or add modules; on SaaS you wait for the roadmap.
• Upgrade timing. A SaaS upgrade that breaks a report lands on the vendor’s schedule, often at quarter end. A hosted instance upgrades when you test and approve it.
• Data locality and access. The database is yours. You can back it up, query it directly, integrate it with anything, and move it if the provider disappoints you.
• Predictable cost at scale. Per-user SaaS pricing is cheap at five users and expensive at two hundred. Hosted cost tracks infrastructure size, not headcount.

What hosted does not give you is freedom from operations. Someone patches the application, tests the upgrades, monitors the backups and answers the page when it is down. If that someone is not on staff, it is a managed hosting partner, and their fee is part of the real cost.

What the monthly cost is made of

A hosted ERP bill has four parts, and the vendor quote usually shows one of them.

1. Compute. The application server and, for larger deployments, a separate worker for reports and background jobs. Most ERPs for a business of under fifty users run comfortably on a few vCPUs and a few gigabytes of memory.
2. Database. The relational database the ERP writes to, sized for the data and the concurrency. This is the component that must have backups you have tested, because it is the business.
3. Storage and bandwidth. Attachments, generated documents, exports. Usually small; occasionally, for a company that scans every delivery note, not.
4. People. The upgrade testing, the patching, the monitoring, the restore drills. Either an internal cost or a managed-services fee, and it is frequently larger than the other three combined.

Compared honestly, SaaS is not cheaper because the vendor is efficient. It is cheaper because item four is amortised across thousands of customers. Hosted wins on cost when the customisation and control are worth more than that amortisation, which for a business with specific processes is often the case.

Self-hosting an open-source ERP on a container platform

The option that has changed in the last few years is running an open-source ERP yourself without a server to administer. The major open-source systems ship official container images, and their architecture is the same shape: a web application, a Postgres or MySQL database, and sometimes a worker and a cache. That shape maps directly onto a platform that runs Docker services with a managed database beside them.

# the shape of a typical open-source ERP deployment
services:
  erp:
    image: vendor/erp:stable
    environment:
      DB_HOST: ${DB_HOST}
      DB_NAME: erp
      DB_USER: ${DB_USER}
      DB_PASSWORD: ${DB_PASSWORD}
    ports: ["8069:8069"]
    volumes:
      - erp-data:/var/lib/erp
  worker:
    image: vendor/erp:stable
    command: worker
    environment: *same-as-erp
volumes:
  erp-data:

On a platform, the compose file becomes a Docker service or two with the environment variables set in the dashboard, a managed database instead of a database container, and persistent storage attached for the attachments directory. The pieces that a sysadmin would otherwise own, TLS on the domain, restarts on crash, the deploy log, database backups and a private network between the app and the database, are the platform’s job.

The parts that remain yours are the ones that are genuinely about the ERP: choosing the version, testing upgrades on a copy before applying them, restoring a backup once a quarter to prove it works, and keeping the customisations in a repository so a redeploy reproduces them. That is a fraction of the work of operating the same system on a virtual machine, and it is the difference between needing a sysadmin and needing a careful person.

Sizing, in concrete terms

For a business with ten to thirty concurrent users on an open-source ERP, the application server is comfortable on a plan with one to two vCPUs and two to four gigabytes of memory, which on RunxBuild is the BasicPlus plan at $20 a month or the BasicMax at $65. The database on a similar plan beside it. Storage for attachments as needed. Below ten users, a Basic plan at $6 for the application is a reasonable starting point, with autoscaling set to move up when the month-end reporting run needs it.

The number to be suspicious of is a quote for hosted ERP that is many times that figure with no line for the people. Either the infrastructure is oversized, or the managed-services fee has been folded into the hosting line, and either way the question to ask is what exactly is being operated for the money.

Choosing in one sentence each

• Choose SaaS if you want to stop thinking about the system and your processes fit within its configuration.
• Choose hosted with a partner if you need customisation and have no one to operate it.
• Choose self-hosted on a container platform if you need customisation, have a careful technical person, and want the bill to be the infrastructure rather than a per-user fee.
• Choose on-premise only if a regulation names your building.

How this fits the rest of the stack

The self-hosted option is only honest if the total is visible before the decision. The RunxBuild hosting calculator puts the Docker service for the application, the managed Postgres or MySQL behind it, the persistent storage for attachments and the bandwidth on one screen with real plan prices, which is the four-part bill above minus the people. Database backups are part of the plan, which for an ERP is the line that matters most.

Useful related references:

• Self-Hosted GitLab: The Omnibus Install on Ubuntu
• Vercel Alternative: When the Hosted PaaS Stops Fitting and What to Move To
• Self-Hosted Mail Server: An Honest Account of What You Are Taking On
• Services on RunxBuild

FAQ

What is the difference between hosted ERP and cloud ERP?

Hosted ERP is a single-tenant installation of the software on a provider’s servers: your own database, your own upgrade timing, and the ability to customise the code. Cloud ERP, or SaaS, is one multi-tenant application run by the vendor, upgraded for everyone at once, configurable but not modifiable, and priced per user.

Is hosted ERP cheaper than SaaS ERP?

It depends on headcount and customisation. SaaS is cheaper at small user counts because operations are amortised across all customers. Hosted cost tracks infrastructure size rather than users, so it can be cheaper at scale, but only after including the cost of the people or partner who operate it.

Can a small business self-host an open-source ERP?

Yes, on a container platform. The major open-source ERPs ship Docker images, and their architecture is a web app plus a Postgres or MySQL database plus an optional worker. Run the app as a Docker service, the database as a managed instance, and attach storage for attachments. The platform handles TLS, restarts, logs and backups.

How much server capacity does a hosted ERP need?

For ten to thirty concurrent users on an open-source ERP, one to two vCPUs and two to four gigabytes of memory for the application, with a similar database plan beside it. Below ten users, a smaller plan with autoscaling for month-end load is enough. Larger or heavily customised systems scale from there.

What stays my responsibility on a hosted or self-hosted ERP?

Choosing and testing upgrades on a copy before applying them, keeping customisations in a repository, verifying backups by restoring them periodically, and managing users and permissions inside the application. Infrastructure, TLS, restarts and backup execution are the platform’s or provider’s job.