Templates should not use docker-compose, but a custom format #147

New Issue

GiteaMirror · 2025-11-22T20:31:11-06:00

GiteaMirror commented

2025-11-22 20:31:11 -06:00

Originally created by @RDeluxe on GitHub (Nov 5, 2025).

I feel like using compose with Dokploy is kind of a hack : a lot of nice features are not working with compose (such as some volumes settings, backups, etc.) and it's way harder to debug and maintain.

We should probably create some kind of minimal templating system (extending the template.toml?) that would create the services in Dokploy (via it's API) and link them together nicely.

Sorry if this has already been pointed out, eager to know what you think about this.

Originally created by @RDeluxe on GitHub (Nov 5, 2025). I feel like using compose with Dokploy is kind of a hack : a lot of nice features are not working with compose (such as some volumes settings, backups, etc.) and it's way harder to debug and maintain. We should probably create some kind of minimal templating system (extending the template.toml?) that would create the services in Dokploy (via it's API) and link them together nicely. Sorry if this has already been pointed out, eager to know what you think about this.

GiteaMirror commented

2025-11-22 20:31:12 -06:00

@Siumauricio commented on GitHub (Nov 8, 2025):

Hello, could you explain in more detail?

I believe that using docker-compose makes it possible to implement any template without any hacks. The template.toml file is used to define the environment variables, domains, and mounts that the dokploy API expects, so we have

Some time ago, I had the idea of supporting templates but using applications, but this would be more work.

@Siumauricio commented on GitHub (Nov 8, 2025): Hello, could you explain in more detail? I believe that using docker-compose makes it possible to implement any template without any hacks. The template.toml file is used to define the environment variables, domains, and mounts that the dokploy API expects, so we have Some time ago, I had the idea of supporting templates but using applications, but this would be more work.

GiteaMirror commented

2025-11-22 20:31:12 -06:00

@RDeluxe commented on GitHub (Nov 14, 2025):

Hello there!

For me, the use of compose in Dokploy is — in itself — suboptimal. For most project, you should have separate services.

Why? Because the UI and UX of Dokploy are all about separate services: checking logs, deployments, volume and database backups... some templates are spinning a SQL DB in a docker-compose, for example.

There are also other features, like path mounting, which are not working as well with docker-compose (or are not documented correctly), see here.

So, while I understand the need for compose support (spinning a complete architecture quickly) Dokploy should probably advice against putting some services in a compose (e.g. databases) because of the lose of features it implies.

@RDeluxe commented on GitHub (Nov 14, 2025): Hello there! For me, the use of compose in Dokploy is — in itself — suboptimal. For most project, you **should** have separate services. Why? Because the UI and UX of Dokploy are all about separate services: checking logs, deployments, volume and database backups... some templates are spinning a SQL DB in a docker-compose, for example. There are also other features, like path mounting, which are not working as well with docker-compose (or are not documented correctly), see [here](https://github.com/Dokploy/templates/pull/318#issuecomment-3492443082). So, while I understand the need for compose support (spinning a complete architecture quickly) Dokploy should probably advice against putting some services in a compose (e.g. databases) because of the lose of features it implies.

GiteaMirror referenced this issue

2025-11-22 20:33:20 -06:00

[PR #147] [MERGED] feat: add Flagsmith Blueprint #244

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/templates#147