Template System Overview

Templates package service metadata, configuration variables, requirements, and a Compose or Git deployment definition. Open Templates, select an available card, then choose Deploy to configure and review it.

Categories and availability

Coming Soon cards describe planned integrations and do not offer deployment. A source manifest is not proof that a card is deployable, or that a deployment will work on your host. Review each card's requirements and post-deploy notes.

In this version, the unfiltered browser catalog requests only the first page from the API. Search for a missing template or select its category. GPU and other local filters act on the returned entries; they do not fetch the rest of the catalog. Consequently, the number of visible cards is not the size of the full catalog.

How templates work

Curated manifests live under internal/templates/catalog/{category}/ and are embedded into the panel. At startup, the loader validates and upserts them by name. The browser reads the database-backed catalog, including any custom entries. When deploying a Compose template, the panel substitutes variables, applies security settings, creates the service and deployment job, and starts its containers. Routing and health checks depend on the template and deployment configuration.

Manifest structure

This abridged example follows the shipped Uptime Kuma manifest. The compose field is a YAML string, not a nested object. It illustrates the format; use the full catalog manifest when authoring a template.

apiVersion: v2
kind: Template
metadata:
  name: uptime-kuma
  displayName: Uptime Kuma
  description: Self-hosted uptime monitoring
  category: devtools
spec:
  minResources:
    cpuCores: 1
    memoryMB: 128
  domains:
    - port: 3001
  variables:
    - name: VERSION
      displayName: Uptime Kuma Version
      type: string
      default: "1"
      required: false
      hidden: true
  compose: |
    services:
      uptime-kuma:
        image: louislam/uptime-kuma:${VERSION}
        expose:
          - "3001"
        volumes:
          - uptime_kuma_data:/app/data
        healthcheck:
          test: ["CMD-SHELL", "curl -sf -o /dev/null http://localhost:3001/ || exit 1"]
          interval: 30s
          timeout: 10s
          retries: 3
          start_period: 30s
    volumes:
      uptime_kuma_data:

Variables can be strings, passwords, integers, selects, or booleans. Required fields must be completed; defaults and locked values depend on the manifest and security mode. Generated secrets and deploy-time values use the panel's ${AAP_*} tokens. See Template Authoring for the full contract.

Security and resources

The deploy form offers Secure, Advanced, and Raw modes and shows their consequences. Keep Secure for normal deployments. The Compose validator still rejects privileged mode, host networking, published host ports and added capabilities regardless of the variable-editing mode. Runtime hardening is not a guarantee of complete tenant network isolation.

Review the resource requirements and selected limits before deploying. The form can block deployment when detected capacity is below the minimum, and customer quotas can also reject a request. Minimum resources are not a promise of performance.

Custom deployments

Use Compose Deploy for an existing Compose file, or the custom-template editor for reusable definitions. Custom entries and permissions can make an installation's catalog differ from the embedded curated inventory. For a first application, follow First Deploy.