Portainer Templates: A Merged Template Feed for One-Click Docker Deploys

The Gap Between Portainer's Default Templates and a Working Catalogue

Portainer ships with a set of default app templates, and the README points to portainer/templates as that upstream set. For anyone running more than a handful of self-hosted services, the default list runs out quickly, and the usual workaround is to keep several template URLs and switch between them in the Portainer settings. This repository exists to remove that switching. It compiles templates from several sources listed in sources.csv into one templates.json, described in the README as a ready-to-go file containing all the apps you will ever need. The audience is narrow and identifiable: people who already run Portainer, who deploy Docker containers through its web UI, and who would rather click a template than write a compose file. The homepage at portainer-templates.as93.net is a browsing layer over the same data, showing stats, config options and stand-alone install commands per app. If you do not use Portainer, nothing here applies to you, because the output format is Portainer's own v3 template schema.

Merging Sources Instead of Authoring Templates

The mechanism is a build, not a runtime service. The README states that templates.json is generated by scripts in the lib directory, run through GitHub Actions. Running make downloads every source listed in sources.csv, parses each one, and combines the results with anything dropped into sources/local/, writing out templates.json. There are therefore two contribution paths and no third: either add a URL and a name to sources.csv, or place a template file in sources/local/. Each entry in the supported apps list carries a link back to the originating repository, which is how the merge keeps attribution visible. The output uses Portainer's v3 format, which the README says is compatible with all Portainer versions. That detail matters more than it looks: it means the file is a plain JSON document consumed by the Portainer front end, so the project carries no agent, no sidecar and no network dependency at deploy time beyond fetching the file. Validation is handled separately by Schema.json, a schema matching Portainer's App Template format, invoked with make validate. The pipeline is deliberately boring, and that is the correct shape for this kind of project.

Pointing Portainer at the Feed, or Hosting It Yourself

The shortest path is three steps from the README. Log into the Portainer web UI, go to Settings then App Templates, and set the URL to https://raw.githubusercontent.com/Lissy93/portainer-templates/main/templates.json. Then under Home and App Templates the full list appears, and clicking an entry starts a deployment. The README notes an alternative at container start: append the --templates flag pointing at the templates URL. If you would rather not depend on raw.githubusercontent.com, the project publishes a container image. docker run -p 8080:80 lissy93/portainer-templates serves the file over NGINX, and Portainer is then pointed at http://[host]:[port]/templates.json. Building it yourself is also documented: git clone the repository, cd into it, docker build -t portainer-templates ., then docker run -d -p "8080:80" portainer-templates. If you maintain your own templates.json but do not want to fork, the README gives a volume mount: -v "${PWD}/templates.json:/usr/share/nginx/html/templates.json". That last option is the one worth noticing, because it lets you keep the hosted image and swap only the data file.

What the Merge Model Does Not Give You

A merged feed inherits the quality of its sources. The README's app list links each entry back to the repository that contributed it, which is a reasonable attribution practice but also an honest signal: the maintainer of this repository is not the maintainer of those templates. Nothing in the supplied material describes per-image security review, digest pinning, or a schedule for re-checking upstream images. If an upstream template points at a tag that later moves, the merged file will reflect whatever the source said at build time. The GitHub Actions workflow regenerates the file, but the README does not state a cadence, so how stale a given entry can be is not something you can determine from the documentation alone. There is also a single point of failure in the default setup: the raw GitHub URL. If that host is unreachable from your Portainer host, or if you are running Portainer in an air-gapped network, the hosted option simply does not work, and the self-hosted container or a local file becomes mandatory rather than optional. Finally, this is the wrong tool if your requirement is a reviewed, versioned catalogue with a change history per application. The repository gives you one generated file, and a diff of that file is not the same as a changelog for each app.

Compared With Running Portainer's Own Template Repository

The obvious alternative is to leave Portainer pointed at its default template source and add individual templates by hand as you need them. The difference is one of control versus coverage. Portainer's default list is maintained by the Portainer project itself, which means a narrower set but a single upstream with its own release process. This repository takes the opposite approach: breadth through aggregation, with the maintenance burden pushed onto the sources.csv list and the build. A second alternative, and the one the README itself anticipates, is to fork the repository and point the import URL at your own username. That gives you the same pipeline and the same merge behaviour but with your own sources.csv, which is the sensible move for anyone who wants to add internal templates or exclude categories they will never deploy. The trade-off is that you now own the GitHub Actions runs and the resulting file. Neither alternative is better in the abstract; the default source is better if you deploy a small, stable set, and the merged feed is better if you frequently try new self-hosted software and find the manual template entry tedious.

Licence, Forking and the Cost of Staying Current

The repository is MIT licensed, which permits forking, modification and redistribution provided the licence terms are met. Note that the licence covers this repository's own code and generated output, not the applications the templates deploy; each of those carries its own licence, and the README's per-app links back to source repositories are where you would check. On maintenance cost, the design keeps it low for consumers and moderate for the maintainer. Consumers who use the hosted URL do nothing: the GitHub Actions build refreshes templates.json. Consumers who self-host the container need to pull a new image when they want updated templates, and the README's volume-mount example means anyone supplying their own file has taken on that update responsibility entirely. Contributors pay the real cost. Adding a source means editing sources.csv with a URL and a name, and adding a template means matching Portainer's App Template JSON Format and passing make validate against Schema.json. The releases listed in the repository metadata, v1.0.0 through v1.2.0, are spaced roughly a month apart, which suggests a periodic rather than continuous release rhythm, though the README does not commit to that cadence.

Who Should Point Portainer at This File

If you run Portainer on a home server or a small internal network and you regularly deploy community Docker images, this removes a repetitive step. The self-hosted container path is the one to prefer if your Portainer host has restricted outbound access, and the volume-mount flag is the cleanest way to keep your own additions without forking. If you maintain a template list of your own, contributing the URL to sources.csv is a low-effort way to have it merged, and the Schema.json validation gives you a way to check your file against Portainer's format before you do. Skip it if you need per-image provenance, pinned digests, or a reviewed catalogue, because the merge model does not provide those and the documentation does not claim it does. The first thing to verify is practical rather than architectural: confirm that your Portainer instance can reach whichever URL you choose, then run make validate after any local edits, and check the licence of each application you actually deploy rather than assuming the repository's MIT licence covers it.

Editorial conclusion

Adopt it if you run Portainer and want a broader App Templates catalogue without maintaining your own JSON, or if you already keep a template list and want a build pipeline that merges it with others. Do not adopt it if you need curated security review per image, pinned digests, or per-app version control, because the repository is a merge and validation layer, not a vetting service. Before pointing Portainer at the raw GitHub URL, check how your Portainer instance reaches the internet, decide between the hosted file and the self-hosted container, and run make validate against any local additions you make.

Official sources

1. License: MIT
2. lissy93/portainer-templates on GitHub
3. Project website
4. README
5. Releases