Templates Explained
This page will go over building a template. The templates are all compatible with portainer v1 templates so you can always check that documentation too. All of the keys (type, name, title, etc.) are optional and will simply be blank if left empty.
Single app templates will be surrounded by {}
as is standard for .json files. Multi app templates with consist of multiple {}
sections (separated with a ,
after the }
(ie. },
) surrounded in []
.
More info on writing JSON is available here
If you don't like writing in JSON another option is to use YAML. It's automatically converted into JSON in the backend so all of the options are the same.
- JSON
- YAML
#
This is what each section does:* = required
#
type*- JSON
- YAML
This currently isn't in use. It's just here to keep compatibility with portainer but is ignored.
#
title*- JSON
- YAML
This is what is displayed when in the apps list page. Punctuation is nice here and adds to the polish
#
name- JSON
- YAML
This is what the actual container is named. Information on this is here.
#
description- JSON
- YAML
This is the description that is shown in the app list. \n
is interpreted as a newline character
#
logo- JSON
- YAML
This is the logo that is show in the app list.
#
image*- JSON
- YAML
This is the image that's pulled from dockerhub. The tag (:latest
) is optional.
#
note- JSON
- YAML
This is shown when someone clicks on "VIEW" in the app list. It will render HTML appropriately.
#
categories- JSON
- YAML
- Single Line JSON
A list of categories associated with the application. This is optional but sorting/filtering by category will eventually be a feature.
#
platform*- JSON
- YAML
The platform the image will run on. Haven't tested anything but linux.
#
restart_policy- JSON
- YAML
Define your restart policy. Info here.
#
ports- JSON
- YAML
- Single Line JSON
Ports to be passed through. The host port is on the left of the :
and the container port is on the right. Protocol is after the /
. If no host port is specified a random one is used. I frequently leave out the host port on applications that use common ports.
#
Port Labels- JSON
- YAML
- Single Line JSON
You can label ports for the services that are on them if you would like. This will auto-fill the label field in the deploy form and give users a better understanding of the applications they're running.
#
network_mode- JSON
- YAML
You can set a certain network mode if you're using a legacy application that requires it.
any ports mapped will not be passed through if you choose host as your networking mode and you cannot change the ports
#
volumes- JSON
- YAML
- Single Line JSON
List of bind mounts. Container will mount inside of the container and bind will mount on the host. The bind section can utilize Template Variables in the users settings so if they're set they'll be replaced by what's there. You can use a named volume by using the name of the volume instead of a path (no /
at the beginning).
#
sysctls- JSON
- YAML
- Single Line JSON
Key value pair for sysctl options. More info available here
#
cap_add- JSON
- YAML
- Single Line JSON
Value of capabilities you want to add to a container. More info available here.
#
env- JSON
- YAML
- Single Line JSON
Env is used to set environment variables within the docker container. The description and default are both optional. Label currently isn't used but will be what is shown as the name of the field in the deploy form.
#
labels- JSON
- YAML
- Single Line JSON
Labels can be used for automating services like traefik automatically as well as store information about containers (this is where port descriptions are stored on containers). These will show up in the advanced section like sysctls and capabilities.
#
devices- JSON
- YAML
- Single Line JSON
Devices allow devices to be passed through containers for things like transcoding.