We get some version of this question every week from teams migrating off a SaaS help desk: "what size VPS do I actually need?" The honest answer depends entirely on which self-hosted help desk you're running, and most sizing guides gloss over the one variable that matters most — whether your ticketing tool ships its own search engine. Picking a VPS for self-hosted help desk software without accounting for that is how teams end up swap-thrashing a 2GB box six weeks after go-live. Below is a practical resource floor for each type, mapped to specific tiers instead of "a few GB should do it."
Why "a help desk" isn't one workload
Self-hosted help desks split into two very different resource profiles. On one side you have lean, PHP/MySQL-style ticketing tools that store tickets as rows and search them with SQL LIKE queries or basic full-text indexes — cheap on RAM, cheap on CPU. On the other side you have modern platforms built around a real search index (usually Elasticsearch), a background job queue, and a separate cache layer. The second category is genuinely heavier, not because the vendor over-engineered it, but because full-text ticket search across years of history is an expensive feature to do well. If your sizing plan doesn't distinguish between these two, you'll either overpay for the lean tool or underprovision the search-backed one.
osTicket VPS hosting: the lightweight end
osTicket is the reference point for the lean category — PHP, MySQL/MariaDB, no bundled search daemon. For a small-to-mid support team (a handful of agents, a few hundred open tickets), it runs comfortably within 2GB of RAM with a single vCPU. That maps directly to our VPS I tier — 2GB RAM / 1 vCPU / 40GB NVMe at EUR4/mo (EUR0.0056/hr). If you're running osTicket alongside a couple of other lightweight services, or want headroom for PHP-FPM workers under a support-ticket spike, step up to VPS II (4GB / 2 vCPU / 80GB, EUR6/mo) — a sensible choice if you want that extra headroom, and it's usually overkill on day one, which is the point.
Zammad VPS requirements: budget for the search index, not just the app
Zammad is the clearest example of the search-backed category, and it's worth being specific about where the RAM actually goes. Zammad runs a Ruby on Rails application server, PostgreSQL, Redis for caching/sessions, and Elasticsearch for ticket search and reporting. Elasticsearch alone wants a dedicated JVM heap that doesn't shrink gracefully under memory pressure — pair that with Postgres buffers and the Rails workers and a 2GB box will swap the moment more than one agent is active. Given that stack, 4GB is a reasonable floor for a small team, and 8GB is where things stop feeling tight once attachments, custom fields, and reporting dashboards enter the picture.
That puts a genuine Zammad deployment at our VPS III tier (8GB / 2 vCPU / 120GB NVMe, EUR10/mo) as the minimum we'd recommend for production use, with VPS IV (8GB / 2 vCPU / 120GB, EUR16/mo) as the same footprint with more compute headroom if you're also running scheduled reports or SLA automation on the same box. Neither of these is "a few GB should do it" — they're roughly double what a lean ticketing tool needs, and that gap is Elasticsearch, not bloat.
Mapping a VPS for self-hosted help desk software to tiers
| Help desk profile | Recommended tier | Specs | Price |
|---|---|---|---|
| osTicket, small team | VPS I | 2GB / 1 vCPU / 40GB NVMe | EUR4/mo |
| osTicket with headroom, or 2-3 lightweight services | VPS II | 4GB / 2 vCPU / 80GB NVMe | EUR6/mo |
| Zammad, small-to-mid team (production floor) | VPS III | 8GB / 2 vCPU / 120GB NVMe | EUR10/mo |
| Zammad with reporting/automation, or growing ticket volume | VPS IV | 8GB / 2 vCPU / 120GB NVMe | EUR16/mo |
| Multi-brand help desk, heavy attachment volume, larger agent count | VPS V | 16GB / 4 vCPU / 200GB NVMe | EUR30/mo |
| High-volume support operation, multiple integrations | VPS VI | 32GB / 6 vCPU / 400GB NVMe | EUR58/mo |
What actually pushes you up a tier over time
Sizing at launch is only half the job — help desks grow in ways that are easy to underestimate. Attachment storage compounds (screenshots, log files, PDFs attached to every ticket add up on NVMe faster than teams expect, which is why it's worth not skimping on storage even at the entry tier). Search index size grows with ticket history, and a search-backed tool's memory footprint tends to track that growth more than raw ticket count does. And integrations — Slack/Telegram notification bridges, CRM sync, SSO — each add a background worker that needs its own slice of RAM. If you're already close to your tier's ceiling at three months, it's worth moving up before performance degrades rather than after.
The EU network-ownership angle nobody skips past for a reason
Support tickets are one of the highest-PII-density workloads a lot of companies run — full names, emails, sometimes payment or account details pasted into a ticket body by a customer who didn't think twice about it. If you're self-hosting specifically to keep that data under control, where the VPS physically sits matters as much as the RAM sizing does. We're a Romanian company operating on our own network (AS60982) rather than reselling someone else's capacity, which matters if you need a straightforward answer about where your help desk's disk actually lives.
Test the stack before you commit to a monthly plan
Because the RAM difference between osTicket and Zammad is so tool-specific, we'd rather you test your actual stack than trust a table — including ours. All our VPS tiers are billed hourly to the second, so you can spin up a VPS III, install Zammad with your real ticket volume and attachment mix, watch memory under load for a day or two, and only then decide whether to commit monthly or resize. That's a fraction of a euro to find out for certain instead of guessing. If you outgrow the VPS lineup entirely — call-center-scale support operations with dozens of agents and heavy reporting — our dedicated servers start from EUR209/mo with dedicated cores and no noisy neighbors.
How Noded Can Help
We run six VPS tiers specifically so you're not stuck rounding up to a size that doesn't fit — from EUR4/mo for a lean osTicket instance up to EUR58/mo for a high-volume support operation, all on NVMe with root SSH and free 1 Tbps DDoS protection included by default. If you're not sure which tier your help desk needs, spin up the smallest plausible option on hourly billing, watch it under real load, and resize with a couple of clicks rather than a support ticket. Our full lineup, specs, and pricing are on the VPS hosting page.
FAQ
What are the minimum VPS requirements for Zammad?
4GB RAM is a reasonable floor for a small team, and 8GB is where Zammad stops feeling tight in production. The bulk of that requirement comes from Elasticsearch running alongside PostgreSQL, Redis, and the Rails application server — not from the ticket data itself.
Does osTicket need less RAM than Zammad?
Yes, significantly less. osTicket is a PHP/MySQL application without a bundled search engine, so it runs comfortably on 2GB RAM with a single vCPU for a small-to-mid support team, roughly half of what a production Zammad deployment needs.
Can I run a self-hosted help desk on a 2GB VPS?
For osTicket or similarly lightweight tools, yes. For Zammad or any help desk with a bundled search index, a 2GB VPS will swap under normal agent activity — plan for 4GB minimum and 8GB for production use.
Why does network ownership matter for a self-hosted help desk?
Support tickets routinely contain customer names, emails, and sometimes account or payment details pasted directly into the ticket body. If part of your reason for self-hosting is control over where that PII sits, the provider's physical location and network ownership matter as much as the specs.
Can I test a help desk VPS before committing to a monthly plan?
Yes — hourly billing to the second lets you provision a tier, install your help desk with real data and load, and observe actual RAM usage for a day or two before deciding whether to keep it monthly or resize.