"Koha in the cloud" describes two completely different arrangements, and confusing them is the most common mistake in this decision. One leaves you running Koha; the other does not.
Two things people mean by "Koha in the cloud"
| Koha on a cloud server | Koha Cloud — set up and hosted for you | |
|---|---|---|
| Who installs it | You | Already done |
| Who patches and upgrades | You | Us |
| Who configures mail and notices | You | Already configured |
| Who runs backups | You | Automatic, daily |
| What you rent | A virtual machine | A working library service |
| Gets you | Someone else's hardware | No server at all |
Renting a virtual machine changes where the hardware lives and nothing else. Every software responsibility from our installation guide is still yours. That is a legitimate choice — just not the one most librarians think they are making when a vendor says "cloud".
Benefits of running Koha in the cloud
Elastic sizing
Outgrowing a server means changing a setting rather than buying hardware and scheduling a migration weekend.
Redundancy and snapshots
Cloud providers offer redundant storage and point-in-time snapshots that would be expensive to build yourself. Snapshots are a rollback tool, not a backup strategy — see below.
No datacentre, no on-call rota
No UPS, no cooling, no fan failure at 2am, no hardware replacement budget.
Access from any branch
Branches reach the same system over the internet, without a VPN back to a server in the main library.
The risks nobody mentions
Data residency
Public and government-funded institutions frequently have rules about where data physically sits. Confirm the region before you sign, not after. This is a genuine constraint and it disqualifies cloud hosting for some libraries entirely.
Egress and the cost of leaving
Getting data in is free. Getting large volumes out sometimes is not. Ask what a full export costs.
Bandwidth dependency
Your catalog is down when your building's internet is down — including for staff at the desk. A library with unreliable connectivity should weigh this seriously.
Shared-responsibility confusion
The most expensive misunderstanding in cloud hosting. Your provider backs up the virtual machine's disk. Nobody is backing up your Koha data unless somebody configured it. A snapshot restores yesterday's whole server; it does not restore one accidentally deleted patron record, and it is useless if the corruption happened three weeks ago.
And a backup you cannot hold a copy of is a dependency. Insist on daily backups delivered somewhere you control — your own cloud drive, your inbox, a download. See our backup guide.
The cloud does not configure your mail
SMTP, SPF, DKIM and notice templates are still yours to build unless somebody has already built them. Cloud hosting solves nothing here — see why Koha notices stop arriving.
Choosing a provider
- General VPS providers — cheapest, simple, entirely self-managed.
- Hyperscalers — the most capability and the most ways to misconfigure something. Usually overkill for one library.
- Koha specialists — more expensive per month, but they know what a holds queue is when you call.
Setting up Koha on a cloud VM
The installation itself is unchanged — follow our step-by-step guide. What is different is around it:
- Firewall rules that expose only ports 80 and 443 publicly
- A static IP or DNS that survives a rebuild
- A snapshot policy, and a real backup policy that is not the snapshot policy
- Backups copied off the instance, so losing it does not lose them
- Monitoring, so you learn about problems before a patron reports one
Cloud hosting cost
Broadly comparable to any virtual server; see our hosting cost guide. Remember to add backup storage and snapshot retention, which are billed separately and grow quietly.
But what about when the internet is down?
The strongest objection to anything cloud-hosted, and the one place on-premise genuinely wins. It deserves a straight answer rather than a dodge.
A desktop application that keeps circulation running offline and synchronises when the connection returns closes most of the gap — staff keep issuing and returning, and the records catch up. But if your connectivity is chronically unreliable rather than occasionally interrupted, weigh this carefully. Offline working is a draw between cloud and local, not a cloud advantage, and anyone who tells you otherwise is overselling.
Cloud versus on-premise: which fits
- Legal requirement that data stays on your premises? → on-premise.
- Chronically unreliable internet, and no offline capability offered? → on-premise.
- Technical staff with allocated time? → cloud VM is reasonable.
- Otherwise → a hosted service, where the server question does not arise.
If you land on the last one, that is what Koha Cloud is: no server to buy, nothing to install, your own catalog address, the mail and notices already working, backups arriving daily, upgrades handled without a window you have to schedule. Set up and hosted for you.
You look after your students and your collection. We look after the server.
Migrating an existing Koha to the cloud
Moving a running Koha is a database dump, a file copy, a configuration change and a DNS switch — plus testing. The care goes into the cutover: freeze circulation, take the final dump, restore, verify counts, switch DNS. Our migration guide covers the validation approach.
Considering a move to the cloud? Tell us where your Koha runs now and what you need from it. We will tell you what the move involves — and if staying put is the better answer, we will say so.