Wavelog is a self-hosted PHP logbook for amateur radio operators

A Cloudlog fork with its own direction

Wavelog is a self-hosted PHP application that lets you log amateur radio contacts anywhere, and the README is direct that all you need is a web browser and an active internet connection. The lineage matters, because it explains the shape of the project. Wavelog is described as an enhanced fork of Cloudlog by MM9SQL, ex 2M0SQL, which is a PHP logbook that many hams already run. Forking rather than starting from scratch means the data model, the ADIF import and export and the general workflow of the application came from a working project, and the enhancements are the additions on top. The repository topics make the scope explicit: adif, cabrillo, clublog, eqsl, ham-radio, lotw, qrzcom, logbook, self-hosted and web-based-logger. The core dev team is listed by call sign, with DF2ET, DJ7NT, HB9HIL and LA8AJA, which is also a useful signal about the project's centre of gravity, since it is a European amateur community rather than a commercial product team.

The uploader integrations are the reason it exists

The feature set that distinguishes Wavelog from a spreadsheet of calls is its set of outbound integrations, and the topic tags name them. Clublog, eQSL, LoTW and QRZ.com all appear, along with cabrillo and adif. Each of these is a different kind of confirmation service, and connecting to them from a self-hosted application means the confirmation workflow is part of the logbook rather than a separate desktop tool. ADIF and Cabrillo are the file formats that let a logbook move data to and from contest and general software. There is also a separate WavelogGate repository, described as making easy CAT data transfer from a rig to Wavelog, which is the piece that addresses the other direction of the problem, getting data out of the radio and into the log. The primary language is PHP, the app is browser-based, and the point of the whole arrangement is that the operator logs from wherever they happen to be, which for a portable activity is the entire use case.

Running it: Docker or a LAMP stack

Two installation paths are documented, and the README is clear about which one it prefers. The Docker route is labelled easiest, using a prebuilt image and Docker Compose with a guide on the documentation site. The classic LAMP stack is labelled recommended, and comes with a requirement table.

The requirements are 64-bit Linux, which is highly recommended although Windows may work, with 32-bit no longer supported, a web server of either Apache2, which is recommended, or nginx, PHP from 8.2 to 8.5, and a database of MySQL 8 or newer or MariaDB 10.11 or newer.

The 32-bit line is the one to notice, since it says no longer supported rather than never supported, which means an old installation may exist that no longer upgrades cleanly. The PHP range of 8.2 to 8.5 is a wide window for a codebase this size, and the database requirement of MySQL 8 or MariaDB 10.11 tells you the schema uses modern features. The repository layout matches a classic PHP application rather than a modern framework: an `application/` directory, a `system/` directory, `src/`, an `index.php` at the root, an `install/` directory, `uploads/`, `userdata/`, `backup/` and `updates/` directories, and a `htaccess.sample` file that the Docker build renames into place. There is also an `update_wavelog.sh` script and a `po_gen.sh` script for translation file generation, with the translations themselves managed on a separate Weblate instance.

The Docker image shows how the app is actually wired

The Dockerfile is more instructive than the README, because it shows the moving parts. It starts from a PHP 8.5 Apache image on Trixie and sets a `CI_ENV=docker` environment variable, with a comment saying it is always needed or wavelog cannot work properly in a Docker environment. The PHP extensions installed are the useful list to know about, since they are the actual requirements of the application beyond the PHP version.

RUN install-php-extensions \
        curl \
        mysqli \
        mbstring \
        xml \
        zip \
        redis \
        memcached \
        apcu \
        gd

The image also creates a dedicated non-root user for files and the cron job, with the note that Apache itself keeps running as root, and it installs a cron entry that runs the application cron route once a minute through curl against localhost. That cron entry is not decoration. A logbook that uploads to ClubLog, eQSL, LoTW and QRZ.com has to do that on a schedule, and the image makes the schedule a first-class part of the deployment rather than something the operator wires up afterwards. The image then moves the sample `.htaccess` into place and adjusts the install config so the index page setting is empty, which is how the Docker deployment skips the web installer.

Where Wavelog is the wrong tool

There are two clear boundaries, and they are about hosting rather than features. The first is that Wavelog is a self-hosted application with a database, a cron job and a PHP runtime, so it needs a server you control and maintain. An operator who wants a logbook that opens in a browser with no server of their own is looking for a hosted service instead, and Wavelog is not that. The second boundary is the scope of a logbook. Wavelog is about contacts, confirmations and uploads. It does not do contest scoring, antenna modelling, or the rig control that the WavelogGate project handles on a separate piece of hardware. The stack requirement is a third practical limit for some people, since 64-bit Linux, Apache2 or nginx, PHP 8.2 to 8.5 and MySQL 8 or MariaDB 10.11 is more moving parts than a single-binary tool, and the Docker path is the sensible route for anyone who does not want to maintain a LAMP stack. For a Raspberry Pi or a shared host, the CPU and memory requirements are not stated in the documentation available here, so check them before you commit.

Community, translations and how to get help

Support is handled through GitHub issues, and the README asks for as much information as possible to reproduce a problem, which is the standard and reasonable request for a bug report. Contributions are credited by call sign, with a long list of named contributors, and translations are credited separately with a translator list, since the interface is translated through Weblate rather than by hand in the repository. The demo instance is published at demo.wavelog.org with the credentials demo and demo, and a live demo link sits in the header alongside links to setup, documentation and contributing. There is a SECURITY.md in the repository root, and the project is MIT licensed. The release cadence is steady rather than rapid, with 3.2.2 on 2026-09-14, 3.2.3 on 2026-09-23 and 3.2.4 on 2026-10-13, and the last push to the repository was on 2026-10-17, so this is a project that is being maintained on a schedule you can plan around rather than one that goes quiet for months.

Editorial conclusion

Adopt Wavelog if you want a browser-based ham radio logbook you host yourself, with the uploaders for ClubLog, eQSL, LoTW and QRZ.com already wired in, and you are comfortable running PHP and MySQL. Skip it if you want a hosted service with no server of your own, or if you only need a logger on a phone with no further integrations. Before you deploy, read the requirement table, because 32-bit systems are no longer supported and PHP 8.2 to 8.5 with MySQL 8 or MariaDB 10.11 is the actual floor, and change the demo account if you expose the instance to the internet.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. wavelog/wavelog on GitHub