Both are correct in different situations, and the argument only gets heated because people compare them on the wrong axis.
A template is right when the app is a commodity to you. You want Uptime Kuma, you do not care how Uptime Kuma is packaged, and you will never edit its internals. The value of the template is not that it saves you typing — it is that somebody already found out that this image needs
There are 99 of these in the catalogue on this install, across databases, monitoring, developer tools, media, AI runtimes and 11 plain OS base images. Twenty-one of them are multi-service — the WordPress template brings its own MariaDB, Immich brings a vector-enabled Postgres — so what deploys is a working stack rather than a single container that then needs a database you have to wire up yourself.
Your own compose file is right when the topology is the thing you are designing. Custom application, non-obvious networking, an image you build yourself, anything where you will be editing the definition weekly. A template that you immediately have to unpick is worse than no template.
The middle path that most people end up on
Deploy from a template, then take the definition and own it. If your tooling can export a running container back to Compose you get the best of both — the packaged knowledge, and a file you control afterwards:
Panelica has this as
What to check before trusting any template, ours or anyone's
A template is right when the app is a commodity to you. You want Uptime Kuma, you do not care how Uptime Kuma is packaged, and you will never edit its internals. The value of the template is not that it saves you typing — it is that somebody already found out that this image needs
/var/lib/x persisted rather than /data, that this one refuses to start without a 64-character secret, and that this one binds to IPv6 first and needs an explicit override. That knowledge is invisible until it costs you an evening.There are 99 of these in the catalogue on this install, across databases, monitoring, developer tools, media, AI runtimes and 11 plain OS base images. Twenty-one of them are multi-service — the WordPress template brings its own MariaDB, Immich brings a vector-enabled Postgres — so what deploys is a working stack rather than a single container that then needs a database you have to wire up yourself.
Your own compose file is right when the topology is the thing you are designing. Custom application, non-obvious networking, an image you build yourself, anything where you will be editing the definition weekly. A template that you immediately have to unpick is worse than no template.
The middle path that most people end up on
Deploy from a template, then take the definition and own it. If your tooling can export a running container back to Compose you get the best of both — the packaged knowledge, and a file you control afterwards:
Code:
# what the panel exposes as an endpoint; the manual equivalent
docker inspect mycontainerPanelica has this as
GET /docker/containers/:id/compose, which reconstructs a Compose file from the running container including the resource limits it currently has. Useful for two things beyond editing: putting the definition in Git, and reproducing the same stack on a second server without re-deriving the environment variables by hand.What to check before trusting any template, ours or anyone's
- Which ports does it publish, and are any of them bound to
0.0.0.0when they should be on loopback? A database or an object store with a default password on a public port is the classic way people get owned in the first hour. - Does it pin a version or ride
:latest?:latestis fine for something stateless and a genuine risk for a database — a major version bump on restart can perform a one-way data directory upgrade. - Where is the persistent data, and is it a named volume or an anonymous one? Anonymous volumes survive a restart and disappear on a recreate.