Every few weeks someone asks us to size a server for "our company wiki" as if that's one thing. It isn't. A documentation wiki that a handful of people update once a week and a real-time collaborative wiki that fifty engineers hammer on simultaneously have almost nothing in common under the hood. This post is our honest attempt at mapping a self-hosted company wiki VPS to the actual workload, tier by tier, without rounding everyone up to the same expensive box "just to be safe."
Two wikis that get lumped together and shouldn't be
"Company wiki" covers two very different pieces of software in practice. On one end you have a flat-file or lightly-databased documentation tool — think static pages, a search index, maybe version history — read far more often than it's written. On the other end you have a real-time collaborative wiki with concurrent editing, websocket connections, a proper relational database, a cache layer, and file attachments that need to live somewhere durable. Sizing both the same way wastes money on the small one and starves the big one. We'd rather tell you which is which than sell you the same tier twice.
The lightweight documentation wiki: smaller than you think
If your wiki is closer to a knowledge base — internal runbooks, onboarding docs, SOPs, a searchable archive that a small team edits occasionally — the resource profile is genuinely light. PHP or Node rendering a handful of pages per second, a SQLite or small MySQL database, and static assets served from disk. This is squarely BookStack hosting requirements territory: BookStack's own guidance targets a low-single-digit-GB memory footprint and modest CPU, because it's built around simple CRUD operations and server-rendered pages rather than persistent connections.
For that workload, our VPS I at EUR4/mo (2GB RAM, 1 vCPU, 40GB NVMe) is a reasonable starting point for a small team with light, occasional edits — not a hard ceiling, just enough headroom for typical docs-wiki traffic. If you want room for a reverse proxy, automated backups running alongside the app, and general growth, step up to VPS II at EUR6/mo (4GB RAM, 2 vCPU, 80GB NVMe) — it's our most-picked tier for exactly this reason, and it leaves real slack instead of running uncomfortably close to its memory ceiling on day one.
The heavier collaborative wiki: where the sizing actually changes
Real-time collaborative wikis — the Outline-style tools with live cursors, websocket sync, rich embeds, and a proper database backing every keystroke — are a different animal entirely. Outline wiki VPS requirements look more like a small web application stack: Postgres for structured data, Redis for job queues and session/socket state, and S3-compatible object storage for uploaded images, PDFs, and attachments (which Outline expects natively, not as an afterthought). Concurrent editing sessions hold connections open, and search indexing across a growing document set adds sustained CPU and memory pressure that a docs-only wiki never sees.
This is where sizing has to move up a real tier, not just a little. A small-to-mid team running Postgres, Redis, and moderate attachment volume together is a reasonable starting point for VPS III (8GB RAM, 2 vCPU, 120GB NVMe, EUR10/mo) — again, a starting point rather than a guarantee, since actual headroom depends on your attachment volume and how many people edit concurrently. If you're running Postgres, Redis, and the app on the same box with heavier concurrent editing load, VPS IV — the same 8GB/2 vCPU/120GB specs at EUR16/mo — gives you the same footprint with more bandwidth allowance for a busier install. Larger organizations, heavier attachment libraries, or wikis that double as a lightweight intranet should plan for VPS V (16GB RAM, 4 vCPU, 200GB NVMe, EUR30/mo), which gives Postgres and Redis dedicated memory instead of fighting the app process for the same few gigabytes.
Self-hosted company wiki VPS sizing: the straight table, no upsell
These are starting points based on typical resource footprints for each workload, not guarantees — actual headroom always depends on your attachment volume, plugin choices, and how many people edit at once. That's exactly why hourly billing (more on that below) is useful: it lets you check the assumption against real usage before committing to a monthly plan.
| Wiki type | Typical profile | Recommended tier | Price |
|---|---|---|---|
| Docs-only (BookStack, DokuWiki-style) | Small team, light/occasional edits | VPS I | EUR4/mo |
| Docs-only, growing team or backups running alongside | Growing team, some concurrent traffic | VPS II | EUR6/mo |
| Real-time collaborative (Outline-style), Postgres+Redis+object storage | Moderate concurrent editing | VPS III | EUR10/mo |
| Same stack, busier install / more attachments | Heavier concurrent editing | VPS IV | EUR16/mo |
| Large team or wiki-as-intranet, dedicated headroom for DB+cache | Larger org, heavier attachment library | VPS V | EUR30/mo |
Notice what's missing: we're not telling everyone to buy VPS V "to be safe." A documentation wiki on VPS V is paying for RAM it will never touch. A collaborative wiki crammed onto VPS I will swap and stall under concurrent load the first time a few people edit the same document tree at once. The honest answer is that these are different jobs, and the full six-tier lineup (up to VPS VI at EUR58/mo for 32GB/6 vCPU/400GB, if you're running the wiki alongside other internal tools) exists so you can match the tier to the job instead of the other way around.
Object storage and the database, not just RAM
One thing that trips people up when they size for a collaborative wiki: it's not just about RAM for the app process. Postgres wants its own memory for shared buffers and connection overhead, Redis wants enough to hold session and job-queue data without eviction pressure, and attachments need NVMe I/O that won't choke when someone uploads a batch of screenshots into a doc. All our tiers run on NVMe storage with root SSH access and hourly billing to the second, so you can provision a tier, watch actual memory and disk I/O under your real usage pattern for a week, and step up or down without being locked into a monthly contract you guessed wrong on.
Why this matters for internal company documentation specifically
Company wikis are usually the single most sensitive internal system a business runs — HR policies, incident postmortems, client notes, credentials rotation logs, architecture decisions. For teams inside the EU, or those serving EU customers, keeping that data on EU-based infrastructure isn't a nice-to-have, it's often a straightforward requirement from a data protection officer or a client's own procurement checklist. That's also the reasoning behind the gdpr knowledge base hosting question we get asked repeatedly: it's less about a single certification and more about keeping data residency, backups, and processing all inside the EU, with a data processor you can name in an audit. As X Zone IT SRL, based in Romania and running our own network under AS60982, that's simply where your wiki's data sits by default when you host with us — no separate configuration required.
How Noded Can Help
We're X Zone IT SRL, based in Romania, running our own network under AS60982 — not reselling someone else's capacity. For a self-hosted company wiki, that means EU-resident infrastructure by default, root access so you control the stack end to end, and hourly billing so you can size correctly on day one and adjust as your wiki actually grows instead of guessing twelve months out. Our entry VPS I starts at EUR4/mo for the lightweight docs case, and the lineup scales cleanly up to VPS VI for teams running a heavier collaborative stack alongside other internal tools — see the current specs and pricing on our VPS hosting page. If your internal tooling footprint eventually outgrows a single VPS, our dedicated servers are there too. If you're not sure which tier fits your specific wiki software and team size, tell us your user count and whether you need real-time editing — we'll give you a straight answer, not the biggest box we sell. You can reach us any time at noded.cloud.
FAQ
How much RAM does a self-hosted company wiki actually need?
For a documentation-only wiki (BookStack, DokuWiki-style) with a small team and light edits, 2-4GB is typically enough as a starting point. For a real-time collaborative wiki running Postgres, Redis, and object storage together, plan for 8GB minimum and 16GB or more once concurrent editing gets heavier.
What are BookStack's hosting requirements?
BookStack is a lightweight PHP application with a small database backend (MySQL or SQLite) and modest memory needs — it's built for server-rendered documentation pages rather than persistent real-time connections, so a 2GB/1 vCPU tier is usually sufficient for a small team.
Does Outline need object storage to run?
Yes. Outline expects S3-compatible object storage for image and file uploads rather than storing them on local disk by default, alongside Postgres for structured data and Redis for background jobs and real-time sync — which is why its VPS requirements are meaningfully higher than a docs-only wiki.
Can I start small and upgrade later without downtime disruption?
Yes — with hourly billing to the second, you can provision a smaller tier, observe real memory and disk usage under your actual traffic, and resize up as your wiki's user count or attachment volume grows.
Why does EU hosting matter for an internal company wiki?
Company wikis often hold sensitive internal data — HR records, incident logs, client notes — so keeping the hosting, backups, and data processing within the EU simplifies data residency requirements for teams operating under GDPR or serving EU clients.