Wallabag: new service

[jackspiering]

Description

Adds a Wallabag stack: a read-it-later app that saves web pages as articles. It runs wallabag/wallabag:2.6.14 with MariaDB 11.8, as in the upstream Compose example, behind a Tailscale sidecar.

A sidecar is justified: the Wallabag image contains neither tailscale nor tailscaled, and Wallabag has no built-in Tailscale support. The upstream project is active (last commit 2026-10-13, latest release 2.6.14), and the image is the one the maintainers publish.

Deviations (all documented in the service README): an extra db container, no Redis, TAILNET_NAME for the base address SYMFONY__ENV__DOMAIN_NAME, and four required secrets.

Related Issues

• Closes 🏗️ New Service: Wallabag #341.

Verification

• docker compose config --quiet from services/wallabag, with dummy values for the required variables
• The stack started, Tailscale is healthy, and the service is reachable through the Tailnet. Tested from inside the namespace with --resolve, because the test node (tag:demo) cannot be reached from this host. Serve answered over TLS.
• The main function works and its data survives a restart. I logged in with the default account, saved http://example.com/, and the entry was still there after docker compose down and up -d. The wallabag, db, and (then still present) redis containers were all healthy. The image's own health check and healthcheck.sh in the db container ran inside the containers.
• rumdl check --config .markdownlint.yml . (0.2.78) on the whole repository, and git diff --check

Not tested:

• The optional LAN ports block.
• After review, Redis was removed. Wallabag uses it only for asynchronous imports, which also need a separate import worker that the stack did not run, and the option is off by default. The README now has a chown 65534:65534 step for ./wallabag-data/images. Retested live with the pushed files: wallabag and db became healthy without Redis, with "Enable Redis" and "Enable RabbitMQ" at their default 0. With "Download images locally" turned on and the folder given to 65534, saving a Wikipedia article stored 95 pictures owned by nobody. With the folder that Docker creates as root, the same test stored none, and the article's pictures returned 404.

Impact on existing users

• None.

Checklist

• I have performed a self-review of my code and followed the templates structure.
• I did not commit a working auth key, password, token, or other credential.
• The service README uses the headings of the template, in the same order, and is up to date.
• I added, removed, or renamed the service in the root README.md, in alphabetical order, or this PR does not change the list of services.

Additional Context

• Upstream Compose example and docs: https://github.com/wallabag/docker#docker-compose.
• Wallabag's default login is wallabag with the password wallabag. The README tells users to change it right away.