# Cloudlog: a self-hosted amateur radio logger with a Docker path

> Cloudlog is a PHP and MySQL web application for logging amateur radio contacts, started by Peter Goodhall and now maintained with community contributions, and it covers everything from HF to microwave logging with integrations for CAT control and automation. The project ships a Docker Compose development environment, refuses pull requests outside the dev branch, and has a hosted option at four pounds a month.

**magicbug/Cloudlog** — Cloudlog is a web-based amateur radio logging application built with PHP and MySQL. It supports a wide range of station logging activities, from HF to microwave, and integrates with companion tools for CAT control and automation.

- Repository: https://github.com/magicbug/Cloudlog
- Website: http://www.cloudlog.co.uk
- Stars: 575 · Forks: 210
- Language: PHP
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/magicbug-cloudlog

## A logger you host, for people who log

Cloudlog is a self-hosted PHP application that allows you to log your amateur radio contacts anywhere, and the requirement is described in one line: all you need is a web browser and an active internet connection.

The scope is broad. The project description says it supports a wide range of station logging activities, from HF to microwave, and integrates with companion tools for CAT control and automation, which is the software that talks to a radio for frequency and mode control. The topic list adds the vocabulary of the hobby, with QSL and QSO for the confirmation cards and the contacts themselves, plus web-based-logger.

The origin and the governance are both worth knowing. Cloudlog was started by Peter Goodhall, MM9SQL, and has since received a lot of community code contributions. He is still the person who handles security reports, and he also runs the hosted offering through magicbug, priced at £4 a month at the moment, with the hosted service keeping itself updated.

The contribution rule is unusual enough to lead with. The readme says, in a note at the very top, that only pull requests on the dev branch are accepted. The pull request guidance repeats the spirit: include code that is commented, include one feature only, because multiple features or bug fixes will not be accepted, and include a description of what the pull request does and why it is needed.

One feature per pull request is a strict rule, and it is the kind that exists because a large contributor base makes a sprawling pull request hard to review. It also tells you something about the shape of the project: the main branch is stable and the dev branch is where change happens.

## The stack is CodeIgniter, Bootstrap and HTMX on PHP 7.4

The technology choices are conventional PHP, which is what you would expect for an application that has to be easy to run on a shared host or a small VPS.

The requirements list is short. A Linux based operating system, Apache, with the note that Nginx should work, PHP version 7.4, with PHP 8.2 noted as working, and MySQL at 5.7 or higher. Two notes follow: if you want to log microwave QSOs you will need a 64-bit operating system, and the project does not provide Docker support, though you are free to use it if you wish, with the caveat that they will not handle support for it.

That second note is the interesting one, and it is the reason the Docker section in the readme is framed as a development environment rather than a deployment option.

The application stack is CodeIgniter version 3 for the framework and Bootstrap 5 as the frontend toolkit, with HTMX for AJAX requests and jQuery for some of the frontend functionality, and Font Awesome for icons. End to end testing uses Cypress.

The repository layout matches a CodeIgniter application with a few extras. There is an application/ directory for the framework application code, a system/ directory for the framework itself, index.php as the front controller, an install/ directory for the setup wizard, src/, assets/, images/ and uploads/ for the content, a backup/ directory, an updates/ directory, a docs/ directory, and a script.sh plus a Dockerfile and a Dockerfile-db at the root for the containerised setup.

## The Docker development environment and its network gotcha

There is a Docker guide in the readme, and it opens with the caveat that this setup is not recommended for production use.

The configuration step is to copy the .env.sample file to .env and edit the values, and the environment sample shows the shape of that file, with the MySQL root password, database name, user, password, host set to db and port 3306, plus a BASE_LOCATOR, a WEBSITE_URL and a DIRECTORY.

The values from the .env file are used to populate the database connection details on the install page, and the readme says you should not need to change them unless your setup requires different values.

The one detail that will bite you is the service naming. Docker Compose creates a network for your application, and each service in the compose file can reach each other via the service name, so the DB_HOST value in the .env file and on the install page should match the service name of the database in the docker-compose.yml file. If the database service is defined as db, then DB_HOST should be set as db.

The compose file shows the two services. The web service builds from the repository root, reads the .env file, publishes port 80, mounts the current directory into /var/www/html read write, runs a startup script, depends on the database being healthy, and restarts on failure. The db service builds from a separate Dockerfile-db, mounts a named volume for the MySQL data, and has a health check with a 20 second timeout, 10 retries, a 10 second interval and a 40 second start period.

Starting it is one command:

```bash
docker-compose up
```

The environment sample itself shows the shape of the configuration, with the MySQL root password, database name, user, password, host set to db and port 3306, plus a BASE_LOCATOR, a WEBSITE_URL and a DIRECTORY.

## Cypress end to end tests and the PHP image behind them

The test story and the container story are both worth a look, because they show how the project expects itself to be worked on.

Running the Cypress tests locally takes five steps. Clone the repository, copy the sample .env file and adjust it, build and start the Docker services with docker-compose up -d, install Cypress with npm install cypress, and then run the suite with npx cypress run. The badge at the top of the readme tracks the same suite in continuous integration.

The Dockerfile for the web service starts from the official php:7.4-apache image and sets the working directory to /var/www/html. It installs the system dependencies, including the curl and libxml2 development packages, libzip, zlib, libpng, libonig and the default MySQL client, and then compiles the PHP extensions the application needs: pdo_mysql, mysqli, gd, mbstring, zip and xml, and enables the Apache rewrite module with a2enmod rewrite.

The rewrite module matters for a CodeIgniter application, since the front controller routing depends on it. The image also configures PHP for larger uploads by writing an uploads.ini with a 30M upload limit, a 35M post limit, a 64M memory limit and 300 second execution and input times, which is the kind of adjustment a logbook with uploaded images or exports needs.

Port 80 is exposed and the startup script is copied in and made executable, with a sed that strips the carriage returns from the line endings so the shell script runs under Linux.

The dependency list in the package manifest is minimal in the way you would expect from a project whose JavaScript is only test tooling. The cypress package is the only development dependency, and the test script is a stub, because the real suite is run with the Cypress binary rather than through npm test.

## Two support systems and a very long credits list

The support and reporting arrangements are simple and are split by the kind of problem.

There are two support systems. For code issues, use GitHub issues, and for general issues with setting up your server, use the general discussion forum on the project discussions page. That split is a sensible one, because a configuration question in an issue tracker buries the actual bugs.

Security vulnerabilities have their own route: send an e-mail to Peter Goodhall, MM9SQL, at the address given, and all security vulnerabilities will be promptly addressed. Reporting privately rather than in a public issue is the right practice, and having a named person to contact is a good sign for a project that handles call sign data.

The credits section is a good indicator of the community behind the project, and it is a long list of amateur radio calls and names: Andy, Gavin, Graham, Robert, Corby, Sarah, Tony, Kim, Michael, Andreas, Matthias, Thomas, Pat, Flo, Joerg and Fabian, and many more. The list of Patreon and PayPal donors is longer still, running to several dozen names with their call signs, and the readme says the donations exist to allow the maintainer to spend less time doing commercial work and more time coding Cloudlog.

That last sentence is the clearest statement of the project's economics, and it connects the donation page, the Patreon and the hosted offering. The hosted service at £4 a month and the sponsorship pages are two ends of the same arrangement, and the code remains MIT licensed in the repository with a LICENSE file at the root, which is a straightforward and open arrangement for a piece of software that many operators depend on daily.

## Conclusion

Cloudlog suits a licensed amateur radio operator who wants their QSO records in a database they control, and who wants to try the application before committing to running it on their own server. It does not suit someone who wants a mobile app or an offline logging workflow, and the Docker path is explicitly a development setup rather than a supported production deployment. Before setting it up, read the wiki installation pages, and if you want to contribute, target the dev branch, because pull requests elsewhere are not accepted.

## FAQ

### What is Cloudlog?

It is a self-hosted PHP and MySQL web application for logging amateur radio contacts anywhere, using only a web browser and an internet connection. It supports a wide range of station logging activities from HF to microwave and integrates with companion tools for CAT control and automation.

### What does Cloudlog need to run?

A Linux based operating system, Apache, with Nginx said to work, PHP version 7.4 with PHP 8.2 working, and MySQL 5.7 or higher. Logging microwave QSOs requires a 64-bit operating system, and the project does not provide Docker support even though you may use it yourself.

### How do I start the Cloudlog Docker development environment?

Copy the .env.sample file to .env, and make sure DB_HOST matches the database service name in docker-compose.yml, which is db, since services reach each other by service name on the compose network. Then run docker-compose up, and the compose file publishes the web service on port 80 with the database behind a health check.

### How do I contribute to Cloudlog?

Only pull requests on the dev branch are accepted. Each pull request should contain one feature only, since multiple features or bug fixes will not be accepted, with commented code and a description of what it does and why it is needed. The project was built with CodeIgniter 3 and Bootstrap 5, with HTMX and jQuery on the front end and Cypress for end to end testing.

## Sources

- [License: MIT](https://github.com/magicbug/Cloudlog/blob/master/LICENSE)
- [magicbug/Cloudlog on GitHub](https://github.com/magicbug/Cloudlog)
- [Project website](http://www.cloudlog.co.uk)
- [README](https://github.com/magicbug/Cloudlog/blob/master/README.md)
- [Releases](https://github.com/magicbug/Cloudlog/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/magicbug-cloudlog