lissy93/portainer-templates: 500+ One-Click Apps for the Portainer App Templates List

The gap between Portainer's built-in templates and a real app catalog

Portainer ships with a set of default app templates, and the project's README points at portainer/templates as that baseline. For a homelab or a small server, that set runs out quickly. The moment you want Activepieces, or a finance app like Actual, or any of the several hundred other self-hosted services, you are back to writing docker run commands by hand or pasting compose files from a README.

Portainer does allow you to point its App Templates setting at an external URL. That is the hook this repository uses. Instead of maintaining your own JSON, you paste one URL and the catalog expands. The audience is narrow and specific: people who already run Portainer, already trust the one-click deploy flow, and want more entries in it. If you deploy with plain docker compose and never open the Portainer UI, nothing here applies to you.

How templates.json is assembled from sources.csv and sources/local

The repository is a build pipeline, not a hand-edited file. The README states that templates.json is generated by the scripts in lib, run through GitHub Actions. The Makefile makes the stages explicit: install_requirements installs from lib/requirements.txt, download runs lib/download.py, combine runs lib/combine.py, validate runs lib/validate.py, and list runs lib/list.py. The all target chains them in that order.

The data flow is: URLs listed in sources.csv are downloaded, parsed, and merged with any template files dropped into sources/local/, producing a single templates.json in Portainer's v3 format. The README notes that v3 is compatible with all Portainer versions. A Schema.json at the repository root defines the shape a template must have, and make validate checks conformance against Portainer's app template specification.

Two consequences follow from this design. First, editing is indirect: you change sources.csv or add files under sources/local/, then rebuild. Second, quality is inherited. If an upstream template in sources.csv is stale or points at an image tag that moved, that problem lands in your catalog. The repository does not vendor the images; it only aggregates the definitions.

Pointing Portainer at the templates URL

The README's TL;DR is the whole install for the hosted path. Log into the Portainer web UI, go to Settings then App Templates, and replace the template URL with the raw GitHub URL for templates.json.

https://raw.githubusercontent.com/Lissy93/portainer-templates/main/templates.json

After saving, the README says the apps appear under Home then App Templates, where clicking one starts a deploy. There is a second route mentioned in the same section: when you start Portainer you can append the --templates flag pointing at the templates URL. The README does not spell out the flag's full syntax beyond that, so check your Portainer version's startup options before scripting it.

If you would rather not depend on GitHub raw being reachable from your host, the self-hosting path is a prebuilt NGINX image. The README gives this command, with 8080 as the host port you can change:

docker run -p 8080:80 lissy93/portainer-templates

The Dockerfile confirms what is inside: an nginx:stable-alpine base with templates.json and index.html copied into /usr/share/nginx/html, exposing port 80. You then hand Portainer the URL http://[host]:[port]/templates.json. To build it yourself instead, the README gives these commands, noting you should swap lissy93 for your username if you are working from a fork:

git clone https://github.com/Lissy93/portainer-templates.git
cd portainer-templates
docker build -t portainer-templates .
docker run -d -p "8080:80" portainer-templates

There is also a volume trick for keeping your own file without forking: pass your templates.json into the container with -v "${PWD}/templates.json:/usr/share/nginx/html/templates.json". That is the cleanest middle path if you want the container plumbing but your own catalog contents.

Where this catalog model breaks down

The aggregation approach has a real failure mode, and the README is honest about the shape of it without calling it a risk. Because sources.csv lists other people's template files, a broken or abandoned upstream is a broken entry in your catalog. The README's own supported-apps list links some entries to other repositories for issue reporting, which tells you maintenance is distributed across maintainers you did not choose.

There is no documented rollback. If a new build of templates.json introduces a template that misbehaves, the README does not describe a versioned URL you can pin to, and releases are tagged at the repository level rather than exposing per-release template files. Your practical options are to fork and control the build, or to self-host a copy you have inspected. Neither is described as a supported downgrade path.

It is also the wrong tool if your deployment standards require pinned image digests, signed templates, or an auditable chain from template to upstream maintainer. The pipeline downloads and combines; the README does not describe signature verification or digest pinning as a step. And if you only ever deploy a handful of services, maintaining a small local sources/local/ file of your own is less machinery than pulling in 500 entries you will never click.

Compared with Portainer's default templates and a hand-rolled file

The obvious alternative is Portainer's own default template source, the portainer/templates repository the README references. The difference is scope and control. Portainer's set is curated by the vendor and small; this project's set is broad and assembled from contributors. Choosing the default means fewer entries but a single accountable maintainer. Choosing this project means more entries and a longer chain of custody.

The second alternative is writing your own templates.json and hosting it yourself. That is more work up front but removes every upstream dependency: you decide which apps exist, which image tags they use, and when they change. The repository actually supports this path rather than competing with it. You can fork, edit sources.csv to list only the sources you trust, drop your own definitions into sources/local/, and run make validate before publishing. The README explicitly describes using the repo as a base and swapping lissy93 for your username in the import URL.

So the honest framing is not this project versus a competitor. It is this project as a starting catalog versus this project as a build system for your own catalog. The second use is the one that ages well.

Licence, maintenance and the cost of staying current

The repository is MIT licensed, and the LICENSE file is at the root. That covers the template file and the build scripts. It does not relicense the applications the templates deploy, and it does not cover the upstream template files pulled from sources.csv, which carry their own terms. If you redistribute a combined templates.json, the MIT grant on this repository's own code is not the whole picture.

The last push to the repository was on 2026-09-04, and the most recent release is v1.2.0 from 2026-09-01, following v1.1.0 in August 2026 and v1.0.0 in July 2026. The repository is not archived. The upgrade cost is mostly your own: because templates.json is regenerated by GitHub Actions from the sources, staying current means either consuming the upstream raw URL and accepting whatever the latest build contains, or running the make pipeline yourself and reviewing the diff before you serve it. The second option costs a Python environment and the time to read a JSON diff, which for a catalog this size is not trivial.

Editorial conclusion

Adopt it if you run Portainer and want a broad app catalog without maintaining your own JSON, and especially if you are willing to fork it so the templates URL points at your own repository. Do not adopt it if you need per-template provenance guarantees, pinned image digests, or a catalog with no third-party maintainers in the chain, because the sources.csv model means the file is only as current as its upstreams. Before rolling it out, open templates.json and check that the apps you actually deploy are present, run make validate against your own additions, and confirm the raw URL resolves from the host running Portainer.

Frequently asked questions

Official sources

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