The 2025 source thread never reached a confirmed working AdventureLog installation. The frontend loaded, but signup appeared to do nothing. Later logs showed two stronger clues: the frontend repeatedly reported fetch failed with connection timeouts, while the backend repeatedly said PostgreSQL is unavailable - sleeping. The database container itself eventually initialized and listened normally.
That evidence points to a multi-service connectivity/configuration problem rather than a simple “AdventureLog does not work on ZimaOS” conclusion. AdventureLog's current upstream deployment has also changed: its maintained Compose now uses an .env file, newer PostGIS, current frontend/backend images, and a dedicated installer that asks for the external frontend and backend URLs.
The Source Used a Three-Service Compose Stack
The 2025 Compose contained:
- a SvelteKit frontend called
web; - a Django/backend service called
server; - a PostGIS/PostgreSQL database called
db.
The frontend exposed host port 8015, the backend exposed another host port, and named Docker volumes stored database and media data.
The Visible Symptom Was a Signup Screen That Did Nothing
The application appeared to install successfully from ZimaOS Custom App, but the user could not progress through login/signup. That kind of frontend symptom can be caused by:
- the frontend failing to reach the backend;
- the backend failing to reach PostgreSQL;
- incorrect origin/CSRF URLs;
- service startup ordering or health;
- a reverse proxy changing the effective external URL.
The source logs contained evidence for the first two layers but did not establish one final root cause.
The Frontend Repeatedly Timed Out While Fetching
The frontend log reported TypeError: fetch failed and ETIMEDOUT. That means the frontend process could not complete a network request it expected to succeed.
The original Compose used PUBLIC_SERVER_URL=http://server:8000, which is conceptually correct for service-to-service communication inside one Compose project. However, changing other URL variables to LAN addresses or proxy domains can still create origin and browser/backend mismatches.
The Backend Initially Could Not Reach PostgreSQL
The backend log repeatedly printed PostgreSQL is unavailable - sleeping. Meanwhile, the database log showed PostGIS initializing and eventually becoming ready.
This is consistent with a backend starting before the database is ready, an incorrect DB connection setting, or a service-network problem. The source does not contain enough evidence to distinguish those possibilities conclusively.
Adding a Cloudflare Tunnel Did Not Fix the Source Problem
The user tried a Cloudflare Tunnel after the first failed install, but the application still did not work. This is expected if the underlying frontend ↔ backend ↔ database path is broken: a public tunnel can expose a service, but it does not repair internal Compose networking.
Current AdventureLog Uses a Simpler Maintained Compose Layout
AdventureLog's current upstream Compose now uses:
-
ghcr.io/seanmorley15/adventurelog-frontend:latest; -
ghcr.io/seanmorley15/adventurelog-backend:latest; -
postgis/postgis:16-3.5; - a shared
.envfile for service configuration; - persistent
postgres_dataandadventurelog_mediavolumes.
Review the current AdventureLog Compose definition instead of copying the 2025 forum YAML verbatim.
Configure Frontend and Backend URLs Deliberately
The current AdventureLog installer asks for the frontend URL and backend URL and derives the port configuration from them. That is a strong signal that URL/origin values are part of the application contract, not cosmetic labels.
For a LAN-only setup, use the actual ZimaOS IP/hostname and chosen ports consistently. For a reverse proxy, configure the public HTTPS URLs consistently and avoid mixing localhost, LAN addresses, and public domains without understanding which process sees each value.
Do Not Keep the Source Passwords and SECRET_KEY
The forum Compose included placeholder values such as changeme123 for PostgreSQL and Django secrets. Those are examples, not safe production credentials.
Generate unique database credentials and a strong application secret. If a real secret has ever been posted publicly, rotate it.
Persist Database and Media Before You Troubleshoot Reinstalls
Repeatedly uninstalling and reinstalling the stack can create confusing state if named volumes survive or if they are deleted unexpectedly. Decide whether the goal is:
- reuse the existing database/media;
- start with a completely clean test instance.
Back up anything important before deleting Docker volumes.
Current ZimaOS Handles Standard Compose More Directly
Current ZimaOS App Store 2.0 and Custom App workflows are built around standard Docker Compose plus ZimaOS metadata. Application runtime behavior—dependencies, environment variables, ports, volumes, health, networks—still belongs in Compose.
Use the current ZimaOS Compose model when adapting AdventureLog.
AdventureLog on ZimaOS FAQ
Did the 2025 source thread confirm a working fix?
No. The thread ended after the user posted frontend, backend, and database logs.
What were the strongest source clues?
Frontend fetch timeouts and a backend repeatedly waiting for PostgreSQL.
Should the old 2025 Compose be reused unchanged?
No. AdventureLog's maintained Compose, images, PostGIS version, and configuration model have changed.
