feat: add Trigger.dev v4 template

[digitalbase]

Summary

• add a new triggerdotdev-v4 blueprint with a full Trigger.dev v4 stack (Trigger app, Supervisor, PostgreSQL, Redis, ElectricSQL, ClickHouse, MinIO, registry, and docker socket proxy)
• add template.yml variables, domain wiring, and generated secrets needed for Dokploy setup
• include clickhouse/override.xml via template mounts and register the template in meta.json with a dedicated logo

Notes

• DOCKER_RUNNER_NETWORKS defaults to set-after-first-deploy; set it to your Dokploy network name after first deployment for managed worker runs

Greptile Summary

Adds a comprehensive Trigger.dev v4 self-hosting template with 10 services (Trigger app, Supervisor, PostgreSQL, Redis, ElectricSQL, ClickHouse, MinIO, Docker registry, registry-init, docker-socket-proxy). The template uses proper secret generation and domain wiring via template.yml.

• Missing version: "3.8" in docker-compose.yml — required by repository conventions (AGENTS.md)
• Unpinned Docker images — bitnamilegacy/clickhouse:latest, bitnamilegacy/minio:latest, tecnativa/docker-socket-proxy:latest, and httpd:alpine should be pinned to specific versions per security guidelines
• Redundant Docker socket mount on supervisor service — the direct /var/run/docker.sock mount bypasses the docker-proxy access controls, while DOCKER_HOST is already configured to use the proxy
• Template configuration (template.yml), meta.json entry, and SVG logo are well-structured and follow repository patterns

Confidence Score: 3/5

• Functional but has convention violations and a potential security concern with the redundant Docker socket mount
• Score of 3 reflects that while the template is comprehensive and mostly well-structured, it has a missing required version field, multiple unpinned :latest Docker images against security policy, and a redundant Docker socket mount that bypasses proxy access controls. These should be addressed before merging.
• Pay close attention to blueprints/triggerdotdev-v4/docker-compose.yml — it has the missing version field, unpinned images, and the redundant Docker socket mount on the supervisor service

_{Last reviewed commit: 6f774f0}

Greptile also left 3 inline comments on this PR.

_{(2/5) Greptile learns from your feedback when you react with thumbs up/down!}

Context used:

• Rule used - AGENTS.md (source)

[github-actions]

built with Refined Cloudflare Pages Action

⚡ Cloudflare Pages Deployment

Name	Status	Preview	Last Commit
templates	✅ Ready (View Log)	Visit Preview	4fd02b5

[dosubot]

Related Documentation

1 document(s) may need updating based on files changed in this PR:

Dokploy's Space

copilot-instructions /templates/blob/canary/.github/copilot-instructions.md

View Suggested Changes

@@ -6,7 +6,7 @@
 
 Key components:
 
-- **Blueprints**: Self-contained templates with `docker-compose.yml` (service definitions) and `template.toml` (Dokploy-specific configuration for domains, env vars, mounts).
+- **Blueprints**: Self-contained templates with `docker-compose.yml` (service definitions) and either `template.toml` or `template.yml` (Dokploy-specific configuration for domains, env vars, mounts).
 - **meta.json**: Centralized index of all templates, aggregated from blueprint metadata. Entries include `id`, `name`, `version`, `description`, `logo`, `links`, and `tags`.
 - **Scripts**: Node.js tools in root and `build-scripts/` for maintaining `meta.json` (deduplication, sorting, validation).
 
@@ -19,12 +19,12 @@
 - `meta.json`: Array of template objects. Always process after edits using `node dedupe-and-sort-meta.js` to remove duplicates (by `id`) and sort alphabetically.
 - `blueprints/<service>/`:
   - `docker-compose.yml`: Standard Docker Compose v3.8. **NEVER use `ports` with host port mappings**—use `expose` only. Avoid `container_name`, `networks`—Dokploy handles isolation via internal networks.
-  - `template.toml`: Defines variables (e.g., `${domain}`), domains (service:port → host), env vars, and mounts. Use helpers like `${password:32}`, `${uuid}`, `${jwt:secret_var}`.
+  - `template.toml` or `template.yml`: Defines variables (e.g., `${domain}`), domains (service:port → host), env vars, and mounts. Use helpers like `${password:32}`, `${uuid}`, `${jwt:secret_var}`.
   - `logo.svg/png`: Service icon, referenced in `meta.json`.
 - `dedupe-and-sort-meta.js`: Standalone script—reads `meta.json`, removes duplicate `id`s (keeps first), sorts by `id` (case-insensitive), creates timestamped backup.
 - `build-scripts/process-meta.js`: Advanced processor with CLI options (`--verbose`, `--no-backup`, `--input`/`--output`), JSON schema validation (required: `id`, `name`, `version`, `description`, `links.github`, `logo`, `tags` array).
 
-Exemplary blueprint: `blueprints/ghost/`—`docker-compose.yml` uses `expose: ["2368"]` for port exposure; `template.toml` maps domain to Ghost service; meta entry tags as ["blogging", "cms"].
+Exemplary blueprint: `blueprints/ghost/`—`docker-compose.yml` uses `expose: ["2368"]` for port exposure; `template.toml` maps domain to Ghost service; meta entry tags as ["blogging", "cms"]. Complex example: `blueprints/triggerdotdev-v4/`—multi-service stack with `template.yml` defining multiple domains, generated secrets, and ClickHouse config mounts.
 
 ## Development Workflow
 
@@ -34,7 +34,7 @@
    - **Verify Docker Images**: Before using any Docker image in `docker-compose.yml`, verify it exists using `docker manifest inspect <image:tag>` (e.g., `docker manifest inspect docker.io/bitnami/discourse:3.5.0`). This ensures the image is available and prevents deployment failures.
    - Create `blueprints/<id>/` (e.g., `ghost`).
    - Implement `docker-compose.yml` (single service typical; use `expose` for ports, volumes for persistence).
-   - Configure `template.toml`—reference vars in `[config.domains]`, `[config.env]`, `[config.mounts]`.
+   - Configure `template.toml` or `template.yml`—reference vars in domains, env, mounts sections.
    - Add/update `meta.json` entry with exact `id` matching folder.
    - Run `node dedupe-and-sort-meta.js --backup` to validate/sort.
    - Commit; PR triggers Dokploy preview (base64 import for testing).
@@ -53,13 +53,25 @@
   - **Port Mappings**: **NEVER use `ports` with host port mappings** (e.g., `"8080:8080"`)—**always use `expose` only** (e.g., `expose: ["8080"]`). Dokploy handles port proxying via its internal reverse proxy, so host port bindings are unnecessary and create potential port conflicts. This applies to ALL blueprints; some older templates may still incorrectly use `ports` and should be updated to use `expose` instead.
   - Use persistent volumes for data storage (e.g., `- db-data:/var/lib/postgresql/data`). 
   - Services named after folder (e.g., `ghost` service).
-- **template.toml**:
+- **Template Configuration** (`template.toml` or `template.yml`): Templates support two configuration formats—TOML and YAML. Both define variables, domains, environment variables, and file mounts.
+  
+  **TOML format (template.toml)**:
   - Variables: `[variables] main_domain = "${domain}"`; use helpers for secrets (`${password:64}`, `${base64:32}`).
   - Domains: `[[config.domains]] serviceName = "<service>" port = 80 host = "${main_domain}"` (path="/" optional).
   - Env: `[[config.env]]` array of "KEY=VALUE" strings, interpolating vars (e.g., "DB_PASSWORD=${db_pass}").
   - **URL Variables**: When environment variables require URLs (e.g., `WEB_URL`, `NEXTAUTH_URL`, `PUBLIC_URL`), **always use HTTP by default** (e.g., `"http://${main_domain}"`). HTTPS should only be used if explicitly required by the application or when using a reverse proxy with SSL termination.
   - Mounts: `[[config.mounts]] filePath = "/etc/config" content = """multi-line\ncontent"""`.
   - JWT helper: `${jwt:secret_var:payload_var}` for auth tokens; payload as JSON string with `exp: ${timestamps:YYYY-MM-DDTHH:mm:ssZ}`.
+  
+  **YAML format (template.yml)**:
+  - `variables`: Define template variables with default values and generation functions. Supports `${domain}`, `${password:length}`, `${base64:length}`, and `${uuid}` generators. Example: `postgres_password: ${password:32}` generates a 32-character password.
+  - `config`: Template configuration with three main sections:
+    - `domains`: Array of domain mappings with `serviceName`, `port`, and `host` (can reference variables with `${variable_name}`). Example: `- serviceName: trigger` / `port: 3000` / `host: ${main_domain}`.
+    - `env`: Key-value pairs of environment variables passed to all services (can reference variables using `${variable_name}`). Example: `POSTGRES_PASSWORD: ${postgres_password}`.
+    - `mounts`: Array of file mounts with `filePath` and `content` (for configuration files injected into containers). Example: `- filePath: /clickhouse/override.xml` / `content: |` / (multi-line content).
+  - **URL Variables**: Same HTTP-by-default rule applies; use `http://${main_domain}` unless HTTPS is explicitly required.
+  
+  Example: `blueprints/triggerdotdev-v4/template.yml` demonstrates a complex multi-service stack (9 services) with multiple domain configurations, generated secrets using `${password:32}` and `${base64:32}`, file mounts for ClickHouse configuration, and environment variable interpolation. This blueprint showcases advanced patterns: private Docker registry, multiple databases (PostgreSQL, Redis, ClickHouse), object storage (MinIO), and docker socket proxy.
 - **Meta.json**: Entries as JSON objects; tags array of lowercase strings (e.g., ["monitoring", "database"]); links object with `github`, `website`, `docs`.
 - **No Networks**: Rely on Dokploy's isolated deployments—avoid explicit `networks:`.
 - **Versions**: Pin images to specific versions in `docker-compose.yml` (e.g., `ghost:5.82.0-alpine`); match in `meta.json.version`. **NEVER use `latest` tag**—it can break templates when upstream images change unexpectedly. **Always verify image exists** using `docker manifest inspect <image:tag>` before committing.

[Accept] [Decline]

Note: You must be authenticated to accept/decline updates.

^{How did I do? Any feedback?}