There are three ways to host Koha: on your own hardware, on a virtual server you manage, or on managed hosting where someone else does. The software is identical in all three. What differs is who is responsible when something breaks — which is the only question that really matters.
The three models at a glance
| On-premise | Self-managed VPS | Managed hosting | |
|---|---|---|---|
| Upfront cost | High (hardware) | None | None |
| Recurring cost | Power, cooling, replacement | Monthly rental | Monthly fee |
| Who patches the OS | You | You | Provider |
| Who upgrades Koha | You | You | Provider (verify this) |
| Who restores a failed backup | You | You | Provider |
| Realistic uptime | Depends on your building | Provider's, minus your mistakes | Provider's |
| Data location | Your control | Provider's region | Provider's region |
On-premise hosting
Genuinely wins when you have an existing data centre and staff, a legal requirement that data stays on institutional premises, or a requirement to keep circulating when the internet link is down.
What it demands is easy to underestimate: uninterruptible power, cooling, a real backup rotation with off-site copies, hardware replacement budget, and somebody reachable when the disk fails on a Saturday.
Self-managed VPS
The middle path, and the most common for technically capable libraries. You rent a virtual server and run everything on it.
You still own every software responsibility — OS patching, Koha upgrades, backups, monitoring, TLS renewal. What you have shed is the physical layer.
Managed Koha hosting
Someone else runs the infrastructure. The critical detail is that "managed" means very different things to different providers, so ask specifically.
Server requirements by library size
| Collection | vCPU | RAM | Storage |
|---|---|---|---|
| Under 20,000 items | 2 | 4 GB | 40 GB |
| 20,000–100,000 | 2–4 | 8 GB | 80 GB |
| 100,000–500,000 | 4–8 | 16 GB | 160 GB |
| 500,000+ or multi-branch | 8+ | 32 GB+ | 320 GB+ |
Starting points, not limits. Concurrent staff users and search volume matter as much as record count — a 50,000-item library with thirty simultaneous circulation desks works the server harder than a 200,000-item archive with two.
Backups — the part everyone gets wrong
An untested backup is not a backup. It is a file you hope is useful.
A complete backup includes the database, uploaded files and covers, and configuration. Keep copies somewhere other than the server itself, define retention, and restore one at least once a year to prove the process works. Full detail in our backup and restore guide.
Then the question libraries rarely ask a host: can I hold my own copy? A backup that exists only on the provider's storage is a dependency, not a safeguard. Backups delivered to storage you control — your own cloud drive, your inbox, a download — is what "your data" actually means in practice.
Notices and email deliverability
The part of hosting nobody calls hosting, and a frequent gap between what a library assumed and what it bought.
Overdue and hold notices need a mail server behind them, correct SPF and DKIM records, and templates somebody wrote and tested. Ask a prospective host who owns each of those. See why Koha notices stop arriving.
Scheduled jobs — who runs them, and can you see them?
Fines, overdues, the holds queue and notice generation all run on a schedule. Self-hosted that means crontab over SSH.
With a managed host, the question is not only whether they run but whether you can see that they ran. "It's fine" is not evidence. A readable per-library run history is the difference between trusting and knowing — see our guide to Koha cron jobs.
Security essentials
- HTTPS on both staff and OPAC hostnames
- A firewall exposing only what must be public
- Prompt OS and Koha patching
- Database bound to localhost unless remote access is genuinely required
- Staff accounts with appropriate permissions, not everyone as superlibrarian
Koha version upgrades
Two major releases a year. Falling behind compounds: database updates run in sequence, and the further back you start the more there is to go wrong. Establish who is responsible before you need them. Our upgrade guide covers doing it safely.
Data ownership and exit
The strongest argument for open source, and the question commercial vendors least enjoy. With Koha your data is in an open, documented schema, and you can take a full dump whenever you like.
Ask any host: can I export my complete database on demand, without asking permission? If the answer is qualified, you have found something important.
When something breaks, who do you talk to?
A mailing list, a ticket queue with a next-business-day target, or someone reachable quickly. Response time is a hosting feature, and it is worth more than most specification lines.
Which should you choose?
Work through this honestly:
- Is there a legal requirement that data stays on your premises? → on-premise.
- Do you have technical staff who will still be here in three years, with time allocated? → VPS is reasonable.
- Otherwise → managed, and check what "managed" includes.
If you land on managed, there is a further step worth knowing about. Managed hosting answers "who patches the server". A complete hosted setup also answers who installs it, who migrates the data, who writes the notice templates, who connects the copy-cataloging sources and who upgrades the application — because all of it is already set up and running before your library arrives.
We make server handling easy. You run the library; we run the server.
Not sure which model fits? Tell us your collection size, branches and what technical help you have. We will give you a straight recommendation — including telling you if self-hosting is the right answer.