Koha packages or a source install: which one you want

Install from the community packages — koha-common on Debian or Ubuntu. A source install is for developing Koha, not for running a library on it: it gives up the whole koha-* command set, the packaged upgrade path, and most of the answers you will find when something breaks. The two exceptions are at the end of this page.

This is the part people underestimate. The commands in the manual, on the mailing list, in every guide and in this knowledge base are packaging, not part of Koha's Perl. On a source install none of them are there:

• koha-create / koha-remove — build and tear down an instance, including its database, user, ports and Apache site
• koha-dump / koha-restore — the backup that includes the configuration, not just the database
• koha-plack, koha-zebra, koha-es-indexer, koha-worker, koha-sip — start, stop and enable each service per instance
• koha-rebuild-zebra, koha-elasticsearch — reindex
• koha-passwd, koha-reset-passwd, koha-mysql, koha-shell, koha-list, koha-foreach — everything you do by hand on a normal day

Each one is replaceable by a longer manual procedure. The cost is not any single command — it is that every future instruction you are given has to be translated first, by somebody who understands both sides, usually while something is broken.

A packaged upgrade is two commands and a restart, and it knows what it replaced. A source upgrade re-runs the installer over the tree and leaves you to work out which of your hand edits survived — Apache config, cron entries, service units, file permissions, the search configuration. The first upgrade is manageable. The third one, done by somebody who did not do the first two, is where source installs are usually abandoned.

Scheduled jobs make the same point in miniature. The package ships Koha's cron entries and runs them per instance through koha-foreach; a source install has an empty crontab and no error when it stays empty — see which Koha cron jobs matter for what silently stops working.

1. 1You are developing Koha — writing patches, testing a bug fix, running the test suite. Upstream's own INSTALL file points developers at koha-testing-docker and KohaDevBox for exactly this, and points everyone else at the packages.
2. 2Your platform has no packages at all — RHEL, Rocky, AlmaLinux, openSUSE. Then a source install is not a preference, it is the only option, and the honest advice is usually to reconsider the platform instead: see which Ubuntu or Debian version to install Koha on.

The packaging is not a convenience wrapper somebody added later. It encodes the operational shape of a Koha server: where an instance's configuration lives, how a second library is added without a second copy of the code, which services exist per instance, how backups capture configuration as well as data, and how an upgrade is applied to twenty instances at once.

Choosing a source install does not skip those decisions — it moves them onto you, unwritten and undocumented, on one server. Most of the very hard Koha problems we are asked to look at start there: an install nobody can upgrade, whose backups turn out to contain the database and nothing else.

A source install is also not more "flexible" in the way it sounds. Customization — the OPAC's appearance, notices, MARC frameworks, circulation rules — is done through Koha itself and survives upgrades. Anything you do by editing the source is undone by the next upgrade regardless of how it was installed, which is a separate lesson entirely.

If you are on Windows, the question is different again — that one is answered here.