Ubuntu 24.04 now pushing Docker 29.1.3 in general release cycle

[Cheese]

@George

there is no need to make a whole tool for it

Why am I not allowed to do that sort of thing? What is wrong with it? Why is it a bad thing?

You know what... Blaming me for bringing it up is fine. I don't mind.

[guptast]

Hi George,

@George

Well I don’t think the problem is that large and i wasn’t even able to reproduce it. Created numoof new servers on Hetzner with latest docker and deployed all fine to them.

We would be interested to know how the deployments of web applications with Docker v29.x.x have worked for you, whereas I and many other users have experienced 404 errors. Could you please explain the difference so that we can adjust the deployment method accordingly?

I'm happy to run tests if needed to assist the team to provide a permanent fix for this long standing issue.

[George]

@guptast

We would be interested to know how the deployments of web applications with Docker v29.x.x have worked for you, whereas I and many other users have experienced 404 errors.

Sorry I mis have missed your solution, there was some talks about pinning the docker to older version and others about updating Traefic.

So which exactly worked for you?

[George]

@Cheese

Why am I not allowed to do that sort of thing? What is wrong with it? Why is it a bad thing?

Well it is unclear to me exactly what are you fixing - I rather have a list of fixes instead of a tool to dissect.

Of course you can make as many tools as you wish but I rather have a clear list of what is wrong and how it can be fixed so we can apply that in Wappler.

[Cheese]

@George

Well it is unclear to me exactly what are you fixing

I fixed the deployment issue, initially as an internal tool, and then via requests (dozens of them) I was asked for a solution (and what I was using). Half the options in this tool were born out of internal needs, however they remain in the tool, which in itself is incredibly useful and has helped dozens of Users deploy without issue. It is not a dig at Wappler deployment being a problem, it just so happened it helped resolve the issue for others. It gives extended abilities to those deploying with Docker. Rather than running CLI commands. It allows for multiple options to install addons that the User may find helpful, etc, etc, yada-yada. It allows for security audits, and lots of other helpful features. It is a single unified tool with multiple options. It checks the host to see if Docker is installed, and if not it will install it for them (Digital Ocean Droplets do not install Docker by default). It is helpful in many ways. It runs health checks, allows users to connect to their remote terminal, it dissects Projects and creates useful files for use in AI cutting inference costs dramatically. It answer questions on your code-base, it sends you a text, the list goes on and is ever growing as requests come in, and feedback. It is not a replacement for Resource Manager or deployments in Wappler. It is an advanced set of tools for those who wish to do more than just deploy. Nothing is overwritten in Wappler Targets. All of its configurations remain within its own directory. It allows rolling back a deployment, on and on etc etc.

@George

I rather have a clear list of what is wrong and how it can be fixed so we can apply that in Wappler

I provided that back in November George. Nothing has changed in that regard. I've shared everything I know about that issue with Docker and Traefik, I really have...

[George]

Cheese,

Please provide me with exact list of bugs and the solution you have found. Preferably in separate topics with explanation.

[Cheese]

Differences are highlighted here in what I had to do prior to overcoming it with internal deployment solutions.

I did not like this method as was a real mess on subsequent deploys:

Docker and Traefik issues

My origianl config: services: web: restart: 'always' stdin_open: true tty: true logging: options: max-file: '5' max-size: '10m' build: context: '../../../' dockerfile: '.wappler/targets/DigitalOcean/web/Dockerfile' labels: - 'traefik.enable=true' - 'traefik.docker.network=wappler-compose_proxy' - 'traefik.http.routers.some-name__digitalocean_web.entrypoints=web' - 'traefik.http.routers.some-name__digitalocean_we…

That whole thread covers what I did.

Then there are @guptast's threads:

Docker and Traefik issues

Hi Cheese, I haven't come across this issue or any error in any of my projects that have been deployed via Docker and use Traefik v2.5 for SSL certificates. The VPS are running Ubuntu 24.04. You can check the traefik version installed on the server in the docker-compose.yml file. This is the file path in my project (under hidden folder) for a custom server. .wappler > providers > custom > servers > server_name > wappler-compose > docker-compose.yml

Docker 29.1.1 Issues explained (Traefik, Redis, MySQL containers) and work-arounds you can implement

I'm running Docker Desktop v4.55.0, Docker Engine v29.1.3 on MacOS. The projects have to be re-deployed everytime after restarting the Docker Desktop. Otherwise it keeps coming up with this error in the web server logs. [Screenshot 2026-01-08 at 10.05.34 am] The project stopped working with Docker Engine v29.x.x when I tried it on the remote server 2-3 weeks ago. I had to downgrade Docker to v28.x.x for the project to start working again.

Hope that helps.

[Cheese]

@George

I asked my chain of models (6 LLM's working in unity) to explain it in-depth. This may be far more useful. Rather than weaving in and out of posts.

Traefik + Docker Engine 29.x — bugs we hit and how we fixed them

DigitalOcean and many VPS images now ship Docker Engine 29.x. Stacks that worked before (Node app + Traefik + Compose, typical for Wappler Server Connect deploys) started failing in confusing ways: containers “up,” site dead.

Below is the list of issues we traced and the fixes that actually worked.

---

1. Traefik starts but every request returns 404

Symptom: Traefik listens on 80/443. App container is running. Browser shows 404 page not found. Traefik logs may include:

client version 1.24 is too old

Cause: Docker Engine 29+ requires Docker API ≥ 1.44. Older Traefik images (e.g. traefik:v3.0 through v3.5) still use API 1.24. Traefik starts but cannot talk to the Docker socket, so it discovers no backends and serves 404 for everything.

Fix:

• Use traefik:v3.6.1 or newer (we standardised on traefik:v3.6.7).
• After deploy, check Traefik logs for the API error above — if it’s there, upgrading the image is the fix, not debugging the app.

Upstream reference: github.com/traefik/traefik/issues/12253

---

2. App is running but Traefik still returns 404 (healthy container filtering)

Symptom: Correct Traefik version. App process is fine. Site still 404.

Cause: Traefik v3 does not route to containers whose Docker HEALTHCHECK is failing. Many Node/Wappler apps only serve /, not /health. A probe to /health fails → Docker marks the container unhealthy → Traefik drops all routes for that service.

Fix:

• Point HEALTHCHECK at something the app actually serves, e.g. http://localhost:3000/ (not /health).
• Add Traefik flag: --providers.docker.allowEmptyServices=true so routes don’t vanish during the container start-period while the app is still starting.

---

3. Compose fails: external network not found

Symptom: docker compose up errors because network traefik-public (or similar) doesn’t exist.

Cause: Docker 29.x does not auto-create external networks declared in compose. They must exist before up.

Fix: Create the network first:

docker network create traefik-public 2>/dev/null || true

Use whatever network name your compose file expects.

---

4. Redeploy fails: port already allocated (80 / 443)

Symptom: Second deploy fails with ports 80 or 443 already in use — common after a failed first attempt or a leftover Traefik container.

Cause: An old container still holds those host ports; Docker 29 won’t bind them again.

Fix:

• Redeploy with docker compose up -d --force-recreate.
• If that fails: docker compose down, stop any container still on 80/443, then retry.
• On shared staging (one Traefik for many apps): don’t try to start a second Traefik on 80/443 — only attach the app to the existing proxy network.

---

5. HTTPS / Let’s Encrypt fails silently

Symptom: HTTP may work briefly; HTTPS never gets a certificate; little obvious error in the app.

Cause: Usually one of:

• Cert resolver name in Docker labels doesn’t match Traefik static config (e.g. letsencrypt vs leresolver).
• Global HTTP→HTTPS redirect on port 80 runs before HTTP-01 ACME can complete.

Fix:

• Use the same cert resolver name in Traefik config and app labels.
• For HTTP-01: don’t redirect all of port 80 to HTTPS at the entrypoint; use per-router redirect after certs exist.
• If you route both apex and www, both need DNS (A or CNAME) pointing at the server.

---

6. Compose variables (${DOMAIN}, ${ACME_EMAIL}) empty or unresolved

Symptom: Traefik host rules blank; compose warns about unresolved variables.

Cause: Variables in the compose file itself (e.g. in Traefik labels) are resolved at compose parse time. Putting values only in a service env_file: does not substitute them in labels. Docker 29 is stricter about missing values.

Fix: Pass env file globally to compose:

docker compose --env-file .env.deploy -f docker-compose.yml up -d

Put DOMAIN, ACME_EMAIL, etc. in that file.

---

7. Multiple staging apps on one server

Symptom: Deploying one app breaks others on the same VPS, or port conflicts on every deploy.

Cause: Each project starting its own Traefik on 80/443.

Fix: Run one Traefik on the host. Per app, only add:

• Docker labels for routing
• Membership on the shared network (e.g. traefik-public or whatever Wappler’s local proxy uses)

Do not publish 80/443 again from each app stack.

---

Quick reference

Issue	Typical symptom	Fix
Traefik API too old for Docker 29	404; “client version 1.24 is too old”	traefik:v3.6.1+
Bad HEALTHCHECK	404 while app runs	Probe / on app port; allowEmptyServices=true
External network missing	Compose network error	docker network create … before up
Port conflict on redeploy	“port already allocated”	force-recreate, down + cleanup, retry
ACME / TLS	HTTPS never works	Matched resolver; no global :80→HTTPS for HTTP-01
${VAR} in compose	Blank hosts / compose errors	Global --env-file
Shared staging	Sites fight over 80/443	One Traefik; labels + shared network per app

---

Minimal checklist for a working Docker 29 + Traefik stack

1. traefik:v3.6.1 or newer
2. HEALTHCHECK → http://localhost:<app-port>/
3. --providers.docker.allowEmptyServices=true
4. Create external proxy network before compose up
5. docker compose --env-file … for label variables
6. One Traefik per host on shared servers

[George]

well great list maybe post it as troubleshoting list.

As for the traefik update to the new version 3 we will add it in the next update, but for now you can just do it manually, by opening the docker compose file in the editor from the services context menu " Open In Editor"

And just chang the traefik version to the latest v3.6

you can also add:

- '--providers.docker.network=proxy'

for the proxy issue.

Then just redeploy the server.

[Cheese]

@George

we will add it in the next update

That would be great. Thank you. So much better for the Users experiencing this issue than a hack/work-around if the fix is native.

[guptast]

Success!

The web project is now running correctly after updating the docker‑compose file.

Thank you @George for providing a reliable workaround while the permanent fix is on the way.

And thanks to @Cheese for the thorough investigation and clear guidance. Your consistent effort in helping the community, and the time you put into breaking down complex issues, is genuinely appreciated. The place feels more welcoming because of contributions like yours

[ben]

@ben

A quick fix: when using Docker version 29.5.3
In docker-compose.yml, change

image: 'traefik:v2.5'
to
image: 'traefik:v3.7.4'

Then re-deploy Traefik.

Similar to this.

[Cheese]

Thank you @guptast you are way too kind.

[Cheese]

This topic will close 2 days after the last reply.