Koha hosting: managed cloud or your own server?

What Koha hosting should include

When a proposal says "hosting included", it should cover seven things. If any of them is missing, the cost simply moves to your internal team:

• Server and operating system: the virtual machine, its sizing and the operating system's security patches.
• The Koha stack: Perl and its dependencies, MariaDB or MySQL, the web server and the indexing engine (Zebra or Elasticsearch).
• Domain and TLS certificate: the OPAC and the staff interface served over HTTPS, with automatic certificate renewal.
• Backups: copies of the database and configuration files, with defined retention and, above all, tested restores.
• Monitoring: alerts for downtime, full disks and stalled indexing processes.
• Updates: monthly maintenance releases applied and major-version upgrades planned.
• Outgoing email: Koha sends overdue notices, hold-available messages and password resets; if email is not configured properly, those features do not exist in practice.

Outgoing email is the most underestimated item. A freshly built server almost always lands in the institutional domain's spam folder until the sender-authentication DNS records are configured.

Koha hosting models compared: managed cloud or your own server

Neither model is better in the abstract. The answer depends on whether your institution has an infrastructure team with real capacity to run another service, and on how strict its data policies are.

There is a middle ground that works well for universities with strict data policies: the server belongs to the institution, physical or in its own cloud account, and the provider administers Koha remotely. Data never leaves the institutional perimeter, and operations stay with people who know the system. BiblioLabTech uses this model when an IT department requires the machine to stay under its control. If your institution is subject to data-protection laws such as the GDPR, or a national equivalent, data location is often the criterion that settles the choice.

Koha server requirements by collection size

Koha is a Perl application on MariaDB or MySQL with a separate indexing engine, so you are sizing two memory consumers, not one. These are sizes that work in real operation, not the absolute installation minimums:

Two notes on storage. The database of a typical academic catalog takes only a few gigabytes; what consumes space is the indexes, accumulated backups and attachments such as cover images or PDFs. And use SSD storage: a full reindex of a large catalog on a mechanical disk can go from minutes to hours.

Zebra or Elasticsearch

Koha ships with Zebra as its default search engine, and Zebra works well for the vast majority of academic libraries. Elasticsearch is the alternative: it improves faceting, relevance and typo-tolerant search, but it raises the hardware floor noticeably, because it is a Java service that should get at least 8 GB of memory for itself, on top of what Koha and the database already use.

The practical recommendation: if your collection is under 100,000 records and nobody complains about search, stay with Zebra. Elasticsearch is justified by a large catalog, many simultaneous searches or faceting requirements Zebra cannot meet. You can switch engines at any time by changing the configuration and reindexing; the decision is not irreversible, but it is not free either.

Backups, availability and SLAs

A backup that has never been restored is not a backup. These are the parameters worth writing into the contract:

• Frequency: a daily database copy at minimum; for libraries with intensive circulation, a daily copy plus incremental backups.
• Retention: 15 to 30 days is reasonable for a library; beyond that, storage costs grow without adding value.
• Location: off the production server. A backup stored on the same disk protects against nothing.
• Restore test: at least once a year, documented.
• RTO and RPO: how long the service can be down, and how many hours of data can be lost in the worst case. These are the two numbers that really matter.
• Committed availability: 99.5% a month equals about 3.6 hours of downtime a month; 99.9%, about 43 minutes. Choose the level according to how critical the OPAC is during exam periods.
• Maintenance windows: agreed outside academic hours and announced in advance.

Domain, TLS and access

The OPAC should live on a subdomain of your institution, such as catalog.university.edu, not on the provider's domain. It is a branding and continuity decision: if you ever change provider, the link printed in course guides and published on the institutional website keeps working. Technically, all it takes is for the institution to point a DNS record to the server.

The TLS certificate must renew itself. Publish the staff interface on a different subdomain from the OPAC and, where your security policy allows, restrict it by network or VPN. If your institution runs a corporate directory, Koha integrates with LDAP and Active Directory, as well as CAS, SAML and OpenID Connect providers, so staff and patrons do not need a second set of passwords.

Questions to ask a Koha hosting provider

1. Which version of Koha do you install, and how often do you apply maintenance releases?
2. Is the server dedicated to my instance or shared with other libraries?
3. What are the frequency, retention and location of backups, and when was the last restore test?
4. What monthly availability do you commit to, and what happens if you miss it?
5. What is the response time for a critical incident, such as the OPAC being down, compared with a normal request?
6. If I decide to leave, will you hand over the complete database dump and configuration files, how quickly and at what cost?
7. Are the domain and the certificate registered in the institution's name?
8. Does support cover questions about using the system, or only infrastructure incidents?

The sixth question is the most important and the least often asked. Koha is free software and your data is yours: any serious provider must be able to hand you a complete copy without argument. If the answer is vague, you are facing the same vendor lock-in that motivated leaving a proprietary system in the first place, as our guide to choosing an integrated library system explains.

When each model makes sense

Choose managed cloud hosting if your IT team has no capacity for another service, if the library needs the OPAC online continuously, if you want a predictable cost, or if you are coming from an instance that was never upgraded because nobody maintained it, a scenario covered in our guide to upgrading Koha.

Choose your own server if institutional policy requires data to stay on campus, if you already run virtualized infrastructure with formal backups and Linux staff, or if Koha must integrate with internal systems that are not exposed to the internet.

In both cases the software is exactly the same, and moving between models is feasible, because it comes down to moving one database and a set of configuration files. If you are also leaving another system at the same time, read how to migrate to Koha before choosing the server: the migration plan determines when production hosting must be ready.

What Koha hosting costs

There is no license in the price, so the cost of Koha hosting is infrastructure plus the people who run it. As a reference, BiblioLabTech's university projects place 12 months of managed hosting at USD 400 to 1,500, depending on three variables: the size of the server, the availability level committed in the contract and the backup policy.

Hosting is a recurring cost, unlike implementation and migration, which are paid once. That is why it should appear as a separate line in any proposal, and why our quotes come in two versions, with and without hosting. Keep in mind that hosting covers the infrastructure; questions from library staff about using the system belong in a support contract, described in what Koha support includes. The full budget picture, component by component, is in Koha implementation cost.

Koha hosting with BiblioLabTech

BiblioLabTech offers all three models. Managed hosting runs on Linux infrastructure with daily backups, HTTPS, uptime monitoring and security updates handled by our team. For institutions that must keep data on their own servers, we install Koha there and hand over a documented server with backups and monitoring configured, or administer it remotely. The Escuela Colombiana de Ingeniería Julio Garavito runs its Koha catalog, with BiblioScan AI cataloging, on a dedicated university server administered by BiblioLabTech; read the case study.

Our Koha service is quoted with and without hosting, precisely because the right answer depends on the institution, and every Koha project includes BiblioScan AI at no extra cost. We work remotely with libraries in any country from a UTC−5 base. Tell us about your library and we will size the server and the support your catalog actually needs.