feat: add Instatic template

[Tekipeps]

Instatic is a self-hosted, open-source visual CMS combining a canvas editor, content engine, and static site publisher. Deployed as a single container backed by SQLite, with uploads and DB on one persistent volume.

What is this PR about?

New PR of Instatic

Checklist

Before submitting this PR, please make sure that:

• I have read the suggestions in the README.md file https://github.com/Dokploy/templates?tab=readme-ov-file#general-requirements-when-creating-a-template
• I have tested the template in my instance, so the maintainers don't spend time trying to figure out what's wrong.
• I have added tests that demonstrate that my correction works or that my new feature works.

Issues related (if applicable)

Close automatically the related issues using the keywords: closes #ISSUE_NUMBER

Screenshots or Videos

[github-actions]

built with Refined Cloudflare Pages Action

⚡ Cloudflare Pages Deployment

Name	Status	Preview	Last Commit
templates	✅ Ready (View Log)	Visit Preview	1f1e3b4

[Siumauricio]

Tested this on a Dokploy instance (imported the blueprint as-is, fresh volumes). Works, and I pushed one small improvement to your branch (1f1e3b4) — see below.

Upstream / legitimacy

• corebunch/instatic is real and very active: created 2026-04-30, ~8.2k stars, 754 forks, 20+ contributors, 100+ commits, tagged releases via GitHub Actions (v0.0.16 = 2026-08-11), MIT, live site at instatic.com. ghcr.io/corebunch/instatic:0.0.16 manifest → 200 without auth. PR author has a GitHub account since 2018.
• The template mirrors the upstream single-volume layout from docs/deployment/docker-image.md (DATABASE_URL=sqlite:/app/storage/data/cms.db, UPLOADS_DIR=/app/storage/uploads, volume at /app/storage), and the instatic-init chown one-shot is the right fix for the image running as the non-root bun user against a root-owned named volume.

Conventions

• No ports/container_name/external networks, per-template meta.json with logo, image pinned, INSTATIC_SECRET_KEY generated via ${base64:32}. generate-meta.js --check, validate-docker-compose.ts, validate-template.ts pass.
• Nit (non-blocking): version: "3.8" at the top of the compose is obsolete in Compose v2 (just a warning) and expose: is redundant; both harmless.

Deploy evidence

• instatic-init-1 exited 0; instatic-1 running healthy, RestartCount 0, log [server] Listening on http://localhost:3001.
• Through Traefik: / → 302 /admin (setup wizard, as designed on a fresh install) → 200 «Instatic»; /health → 200 {"status":"ok"}; GET /admin/api/cms/setup/status → {"needsSetup":true}.
• First-run setup: POST /admin/api/cms/setup → 201 {"ok":true}, status flips to {"hasSite":true,"hasAdmin":true,"hasOwner":true,"needsSetup":false}.

What I changed (pushed as 1f1e3b4)

• With PUBLIC_ORIGIN = "https://${main_domain}" the CSRF check rejects the setup wizard on a plain-HTTP deploy (the default generated Dokploy domain before HTTPS is enabled): POST /admin/api/cms/setup with Origin: http://<domain> → 403 {"error":"Forbidden: invalid origin"}. Upstream documents PUBLIC_ORIGIN as a comma-separated list, so I set it to "https://${main_domain},http://${main_domain}". Re-deployed with fresh volumes: the same POST from an http:// origin now returns 201, and https origins keep working. Users who enable HTTPS lose nothing; users testing over http get a working wizard instead of a silent CSRF failure.

LGTM.