How to Self-Host Wallos in 2026: Renewals, Notifications and SQLite

Most Wallos installation notes end at the first page load. That is too early: renewal dates shift because TZ is wrong or the SQLite directory is read-only. A useful production test is more demanding — create subscriptions in different billing cycles, set renewal dates, run the notification path and inspect totals in the selected currency.

Wallos's role is straightforward: subscription tracker with renewal dates and notifications. Its operational boundary includes more than the web process, so the dependency, stored state and public route all have to be named explicitly before real data arrives.

Map Wallos before touching Docker

Separate four concerns for Wallos: ingress, the listener on 80, durable state and supporting services or local capacity. The local runtime requirement is persistent database and logo-upload directories plus notification delivery. Size and monitor that resource with the container instead of exposing an unrelated network service.

Run the known-good transaction — create subscriptions in different billing cycles, set renewal dates, run the notification path and inspect totals in the selected currency — before calling that separation complete. Measure scheduled notification work, logo storage, SQLite writes and timezone correctness and keep the result with the deployment record. It provides both an acceptance criterion and the first capacity baseline.

Diagnose a healthy-looking Wallos

For Wallos, monitor a transaction rather than a process: create subscriptions in different billing cycles, set renewal dates, run the notification path and inspect totals in the selected currency. Combine its latency and error rate with scheduled notification work, logo storage, SQLite writes and timezone correctness so an alert identifies the constrained component.

The upgrade rehearsal must cover that Wallos database migrations should be tested with date and currency data before replacing the running image. Restore, migrate and run the transaction before production replacement. If renewal dates shift because TZ is wrong or the SQLite directory is read-only, do not erase data to make startup green; compare version, variables, mounts and dependency reachability in that order.

Turn the Wallos smoke test into a release check

The release record for Wallos needs facts, not “looks good.” Store the selected image digest, configuration checksum, public hostname and a timestamped result for: create subscriptions in different billing cycles, set renewal dates, run the notification path and inspect totals in the selected currency. Use non-production sample data so the check can run after every deployment.

Prove two lifecycle events separately. A container replacement must preserve normal operation; a clean recovery must show that subscriptions, categories, logos and notification settings return with unchanged renewal dates. While the checks run, measure scheduled notification work, logo storage, SQLite writes and timezone correctness and retain the result as the expected envelope for this version.

Test a denied or invalid condition as well: submit harmless input near the resource or format limit associated with this boundary: renewal dates shift because TZ is wrong or the SQLite directory is read-only. Wallos should fail in a diagnosable way and should not overwrite healthy state. Return the valid condition, rerun the sample and attach the relevant redacted logs. Those artifacts give a future rollback decision concrete evidence.

Make Wallos startup reproducible

A production-shaped launch is intentionally boring: named state, explicit port and no secret inside the image.

docker run -d \
  --name wallos \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  -v wallos-data:/var/www/html/db \
  -e TZ=UTC \
  bellamy/wallos:latest

The example is a baseline rather than a complete supporting stack. Confirm the local requirement before exposure: persistent database and logo-upload directories plus notification delivery. Check the effective mounts and listener, then try to create subscriptions in different billing cycles, set renewal dates, run the notification path and inspect totals in the selected currency. Pin the working image before the next restart.

Find every durable byte in Wallos

Inventory every durable artifact: subscription database, uploaded logos and notification settings. Mount /var/www/html/db before bootstrap, write harmless sample data and replace the container to prove that path is actually persistent. Include configuration that changes how stored data is interpreted, not only the largest directory.

Set retention, copy backups off-host and run a clean-room restore. The Wallos drill is complete when subscriptions, categories, logos and notification settings return with unchanged renewal dates. If snapshots are part of the plan, use PITR versus snapshot guidance to document what each mechanism can recover.

Give Wallos one canonical address

TLS issuance is only half of the Wallos route. Serve the application over HTTPS and set its timezone. Send traffic internally to 80 and forward the external scheme so generated URLs and secure cookies remain consistent.

Use the complete Wallos scenario from a clean network, not merely the root page. A 502 or certificate failure can be isolated with automatic domain and TLS setup. If traffic reaches the process and renewal dates shift because TZ is wrong or the SQLite directory is read-only, diagnose that condition where it occurs instead of stacking redirects.

Protect the valuable part of Wallos

After first login, review what an anonymous visitor, ordinary user and administrator can each do. The Wallos failure to avoid is leaving the first account weak on an internet-facing instance. The intended policy is to protect the account, keep notification tokens private and set TZ explicitly so renewals do not shift.

TZ controls behavior rather than confidentiality; validate its type and value, and store genuine Wallos credentials separately. Keep dependency accounts separate from human accounts, deny unused egress where practical and cap work influenced by scheduled notification work, logo storage, SQLite writes and timezone correctness.

Where Dockup removes work for Wallos

A Dockup template should encode the image, port 80, mounts, health timing, domain, TLS and secret delivery. Dockup should preserve the Wallos runtime settings while the operator confirms this local requirement: persistent database and logo-upload directories plus notification delivery. The same deployment can target Dockup servers or customer-attached capacity.

After the route is live, apply the public setting and try to create subscriptions in different billing cycles, set renewal dates, run the notification path and inspect totals in the selected currency. Back up subscription database, uploaded logos and notification settings and keep the restore exercise in the operating plan; those are Wallos responsibilities that remain visible after infrastructure provisioning.

Frequently asked questions

What does Wallos need for a production deployment?

Route the Wallos container on port 80 through one HTTPS origin. The local runtime requirement is persistent database and logo-upload directories plus notification delivery. Do not call Wallos ready until you can create subscriptions in different billing cycles, set renewal dates, run the notification path and inspect totals in the selected currency.

Which Wallos data belongs in a backup?

Persist /var/www/html/db and include subscription database, uploaded logos and notification settings in the same recovery manifest. A clean Wallos restore passes only when subscriptions, categories, logos and notification settings return with unchanged renewal dates.

Does Wallos require HTTPS behind a reverse proxy?

Use HTTPS for the public Wallos origin and keep port 80 on the internal route. Apply the Wallos setting correctly: serve the application over HTTPS and set its timezone. For Wallos, HTTPS protects credentials or user content in transit and keeps origin-sensitive client behavior consistent.

How should a Wallos upgrade be tested?

Restore current Wallos state into an isolated deployment, apply the candidate version and repeat its acceptance transaction. Pay particular attention because Wallos database migrations should be tested with date and currency data before replacing the running image. Keep the previous Wallos image until its data-migration and rollback boundary are understood.