Deploying Traefik Overwrites docker-compose.yml file

Wappler General Bugs
1

Wappler Version : 6.7.3
Operating System : MacOS Sonoma 14.5
Server Model: Node.js, Docker
Database Type: MySQL
Hosting Type: local and remote

Expected behavior

I expected the installation and deployment of Traefik to not overwrite my web: services definitions or erase my volumes: definitions in my docker-compose.yml file. I have made changes to my production docker-compose.yml file to improve scalability of my production environment. Those changes were erased following Traefik install.

Actual behavior

The installation of Traefik services on my production machine, so I can use the Lets Encrypt SSL functionality, did not preserve my changes in my production target docker-compose.yml file.

How to reproduce

  • Make a change in your target's docker-compose.yml file to either the volumes: section within web: or the volumes: section at the same level as services:
  • Install Traefik following the How To here: Using Custom Domains and SSL with Let's Encrypt and Traefik
  • Deploy containers to that target, then inspect the docker-compose.yml file. It will have overwritten your changes if you changed any volume information, or removed the 'user_uploads: ~'
2

With all due respect, I saw this coming :melting_face:

Move away while you can. Wappler Docker is opinionated and I believe the Wappler team lacks the touch of real production environments. I suggest you use shared hosting, or if you don't like shared hosting you can setup CloudPanel on your VPS (this is what I did).

The SFTP deployment is insanely slow but they'll improve this in Wappler 7, or so I hope...

Edit:
Every time you change your target settings you're subject to this "bug"

3

Thanks Apple. I'm learning from trial by fire aren't I? :slight_smile: I understand your position on using shared hosting (managed services is what I think you meant?) and agree 100%.

Wappler has helped me rapidly develop an MVP, I can not deny that. There is a lot of truth behind your words about my experience however in Wappler's limited foresight on supporting more modern, scalable, and stable production architectures. It has led both you and HyperBytes as I understand, to reduce Wappler's role in the development and DevOps processes. Docker volumes are performant, and mounted block and object storage are proven, scalable storage solutions. Having to fight Wappler on maintaining these configurations in Docker is a pain, but at least now I know how and where Wappler fights me.

That's ok, as my longer-term plan is to move to managed services as I ramp up on Docker & Git. I guess taking the same path as you guys. I see Wappler being an IDE post-MVP and taking on less of the DevOps role if my MVP gains traction. Is that any different from other no/low code solutions however? I don't know, as that market and my experience with these solutions is just as new to me as my use of Wappler.

1 Like