Template System Overview

AI Admin Panel includes a curated catalog of 45 templates for deploying services with a single click. Templates define everything needed to run a service: Docker Compose configuration, environment variables, health checks, resource requirements, and routing rules.

Categories

How Templates Work

Each template is a YAML specification stored in the panel's embedded catalog at internal/templates/catalog/{category}/. When you deploy a template, the panel:

1. Reads the YAML spec and presents configurable variables in the UI
2. Generates a Docker Compose file with your variable values substituted
3. Adds Traefik labels for automatic routing and SSL
4. Applies resource limits based on the template's minimum requirements
5. Starts the container and monitors the health check

Template YAML Structure

name: uptime-kuma
displayName: Uptime Kuma
description: Self-hosted monitoring tool
category: devtools
version: "1"
featured: false

logo: uptime-kuma.svg

compose:
  services:
    uptime-kuma:
      image: louislam/uptime-kuma:1
      volumes:
        - data:/app/data
      restart: unless-stopped

  volumes:
    data:

variables:
  - name: SERVICE_NAME
    label: Service Name
    type: string
    required: true

minResources:
  cpu: 0.5
  memoryMB: 256
  storageMB: 1024

healthcheck:
  path: /
  port: 3001
  interval: 30s
  timeout: 10s

expose:
  port: 3001
  protocol: http

securityProfile: secure

Key Fields

Variables

Templates define variables that users fill in during deployment. Variable types include:

Variables marked required: true must be provided before deployment. Optional variables use their default value if not set.

Security Profiles

Each template declares a security profile that controls container capabilities:

The panel displays the security profile in the template detail view so administrators can make informed decisions.

Baseline container hardening

Regardless of profile, every managed container is deployed with two hardening defaults applied directly to its Docker runtime configuration:

• no-new-privileges: true — the container can never gain additional privileges at runtime (e.g. via a setuid binary).
• A curated cap_drop set — dangerous Linux capabilities (SYS_ADMIN, SYS_PTRACE, NET_RAW, NET_ADMIN, SYS_MODULE, and others) are dropped so a container cannot tamper with the host kernel, spoof packets, or inspect other processes. The capabilities that ordinary workloads need — SETUID/SETGID/CHOWN (for images that drop to a non-root user via gosu/su-exec) and NET_BIND_SERVICE (for binding ports like 80/443) — are kept, so applications still run correctly. A template may declare its own cap_drop list to override this default.

These are applied at deploy time and re-applied on every restart; you do not need to configure anything.

Custom Templates

You can add custom templates by deploying via the Compose Deploy method with a raw Docker Compose file. The panel supports magic variables in compose files for dynamic value substitution:

• {{SERVICE_NAME}} — the service name
• {{DOMAIN}} — the auto-assigned subdomain
• {{PASSWORD}} — auto-generated secure password

For recurring custom deployments, you can save compose configurations as reusable templates through the API.

Template Logos

Each template includes an SVG logo displayed in the catalog. Featured templates appear in a highlighted section at the top of the catalog page with larger logo cards.

Resource Validation

Before deploying, the panel checks that the target server has sufficient resources for the template's minResources requirement. If resources are insufficient, the deploy is blocked with a clear error message showing what is needed versus what is available.