feat: add wallabag template

[NightVibes33]

/claim #152

Summary

Adds a wallabag Dokploy template as a separate focused PR:

• wallabag 2.6.14 web service exposed on port 80
• MariaDB 11.4 backend with generated root/app database passwords
• Redis cache service with persistent storage
• persistent image uploads volume
• domain, server name, and sender email wiring through template.toml
• metadata and SVG icon entry in meta.json

Review notes

• kept separate from feat: add 11 Dokploy templates #883 so the larger template PR stays focused and this one can be reviewed independently
• follows the official wallabag Docker MariaDB + Redis example while adapting it to Dokploy conventions: no container_name, no explicit networks, and no host port mappings
• official reference: https://github.com/wallabag/docker#docker-compose

Verification

• GitHub Actions validate-docker-compose: passing
• GitHub Actions validate: passing
• GitHub Actions build-preview: passing
• GitHub Actions validate-meta: passing
• node dedupe-and-sort-meta.js
• local TOML/YAML structural validation for this template: compose parses, configured domain service exists, domain port is valid, meta.json entry exists, and the template does not use container_name, explicit networks, or host port mappings
• git diff --check

[github-actions]

built with Refined Cloudflare Pages Action

⚡ Cloudflare Pages Deployment

Name	Status	Preview	Last Commit
templates	✅ Ready (View Log)	Visit Preview	65a9a0a

[Siumauricio]

Automated template check 🤖

This PR's template was imported into a test Dokploy instance (using the docker-compose.yml + template.toml from the PR head) and deployed, and its configured domains were then checked over HTTP.

Result: ❌ some issues need attention

wallabag

• Deploy: done (49s)
• Domain checks:
  • wallabag:80 → HTTP 500 ❌
• Container states at failure time: wallabag-1: running · wallabag-redis-1: running · wallabag-db-1: running
• Issues:
  • domain check failed for service wallabag:80 (path /): kept returning HTTP 500 for 3 minutes after the deploy finished

The test service is removed automatically after verification. Happy to re-test once the PR is updated.

[Siumauricio]

Automated template check 🤖

This PR's template was imported into a test Dokploy instance (using the docker-compose.yml + template.toml from the PR head) and deployed, and its configured domains were then checked over HTTP.

Result: ❌ some issues need attention

wallabag

• Deploy: done (49s)
• Domain checks:
  • wallabag:80 → HTTP 500 ❌
• Container states at failure time: wallabag-1: running · wallabag-redis-1: running · wallabag-db-1: running
• Issues:
  • domain check failed for service wallabag:80 (path /): kept returning HTTP 500 for 3 minutes after the deploy finished

The test service is removed automatically after verification. Happy to re-test once the PR is updated.

[Siumauricio]

Tested this template end-to-end on a Dokploy instance and pushed a fix.

What was broken: the deploy succeeded but the domain returned a persistent HTTP 500. Root cause: the compose set MARIADB_DATABASE=wallabag (plus MARIADB_USER/MARIADB_PASSWORD) on the db service, so MariaDB pre-created an empty wallabag database. The wallabag image entrypoint only runs bin/console wallabag:install when the database does not exist yet — it logged WARN: MySQL database is already configured and skipped the install, leaving an empty schema, so every request 500'd on missing tables.

Fix (65a9a0a):

• db service now only sets MARIADB_ROOT_PASSWORD; the wallabag entrypoint creates the database + user and runs the installer on first boot (this matches the official wallabag docker-compose).
• SYMFONY__ENV__DOMAIN_NAME is built from the generated domain with the http:// scheme so asset URLs/redirects match how the domain is actually served.
• Added SYMFONY__ENV__REDIS_HOST=wallabag-redis (the image default is redis, which doesn't resolve with this service name).
• Randomized SYMFONY__ENV__SECRET via the template instead of the image's hardcoded default.

Evidence: fresh deploy from this branch → all 3 containers running, first-boot log shows [OK] wallabag has been successfully installed., and the generated domain returns HTTP 200 with the wallabag login page (<title>Welcome to wallabag! – wallabag</title>) and correctly-schemed asset URLs.

[NightVibes33]

Hi, I’m following up on Algora bounty Dokploy/templates#152.

This PR and PR #883 were merged on July 8, 2026. I submitted that work under the bounty in the expectation that accepted work would be considered for reward processing.

As of July 25, 2026, I still do not see any public reward or payout confirmation for these merged contributions, and Dokploy’s Algora page still appears to show no completed payouts for this bounty.

Please confirm, in clear terms:

• whether PR feat: add 11 Dokploy templates #883 and PR feat: add wallabag template #900 were accepted for Algora reward processing,
• whether I am being paid for those merged contributions,
• if yes, the payout amount and expected payment date,
• if no, the reason those merged bounty submissions were not rewarded.

If there is any additional step required from my side, please specify it exactly.

If these merged bounty submissions were excluded from payment, I need a specific explanation for that decision.

Thanks.