Packaging Koha for a Volunteer-Run Lending Library

TL;DR

• Setting up Koha, an integrated library system, for the Sterling Musical Instrument Lending Library.
• It’s Perl and Vue.js with several components including Elasticsearch on Docker.
• Goal is one-command development and deployment so volunteers can contribute.
• Terraform on AWS handles automated deploy and teardown to control costs.
• Blockers: passing script context into Docker containers, and Let’s Encrypt automation is untested.

Back on the Koha integration for the Sterling Musical Instrument Lending Library, after a nudge from James Reed, their main IT guy.

Koha is an integrated library system — Perl and Vue.js, with several components and libraries including Elasticsearch running on Docker. The task is configuring it as a Debian package that can be deployed and developed without much ceremony.

What matters here

The constraint shaping everything is that this is a volunteer-run library. Whatever I build has to be operable by people who aren’t me and may not be developers by trade. That’s a stronger requirement than it sounds, and it’s why “it works on my machine” isn’t an acceptable stopping point.

One-command development and deployment. Pull updates into a development environment, make hot-reloadable edits, deploy with minimal commands. Terraform and AWS handle automated deployment — and teardown, which matters because a charity shouldn’t pay for idle infrastructure.

Cross-platform setup. My setup is macOS-specific, which needs abstracting away so volunteers can contribute through Docker regardless of their machine. A centralised config.yaml keeps environment configuration consistent rather than living in everyone’s shell profile.

Where it’s stuck

Script context into Docker. Passing it into container instances isn’t working consistently. This is the main bottleneck and needs proper investigation rather than another workaround.

SSL automation. Let’s Encrypt is defined but untested. It needs exercising in staging before anyone relies on it — an expired certificate on a library’s public catalogue is exactly the kind of failure nobody notices until users complain.

Git and the build. The build depends on a clean git repository, and submodule interactions generate unwanted assets that dirty it. I need to understand that part properly rather than working around it, because a build that intermittently fails on repository state is the sort of thing that stops volunteers contributing entirely.

Each of these is load-bearing for the deployment being genuinely usable rather than technically functional.