[deividasma]

What

Merging a PR that adds a template now publishes its demo to https://<id>.hostingertemplates.com automatically. This replaces the manual Hostinger Connector step in skills/deploy-templates. (Slack thread)

When it deploys

• Trigger: a push to main that adds a templates/<id>/package.json (changed-templates.mjs --added).
• Why not just skip Dependabot: people also merge dependency and security PRs by hand ([HSTG-23219] Bump next to 16.3.8 across Next.js templates #27, [HSTG-23219] Pin vulnerable transitives Dependabot cannot reach #40), so the PR author can't tell template PRs apart.
• Checked against history: PR chore(deps): bump the security group across 24 directories with 2 updates #42 (Dependabot, 24 templates) → nothing deployed. PR [HSTG-23219] Pin vulnerable transitives Dependabot cannot reach #40 (manual pins) → nothing deployed. Commit 3612919 (nine new templates) → all nine selected.
• Redeploying an existing demo: Actions → Deploy template demos → Run workflow with template IDs. The IDs are checked against ^[a-z0-9-]+$ and an existing templates/<id>/package.json.

How

Job	Secrets	Does
detect	none	Picks the templates to deploy
build (matrix)	none	npm ci and npm run build, then package-demo.mjs zips the result
deploy	template-demos environment	deploy-demos.mjs publishes the zips one at a time

package-demo.mjs decides the deploy type:

• Static: no deploy.entryFile, and the build output has an index.html (deploy.outputDirectory, else dist, build or out). It zips that output.
• Node.js app: everything else (Express, Fastify, Hono, Nest, Nuxt SSR). It zips the committed source with git archive, leaving out preview/, node_modules and build output. Hostinger runs npm ci and the build on the server.

deploy-demos.mjs uses the same public API endpoints as the Hostinger MCP deploy tools (@hostinger/mcp). For each template it:

1. Finds the account username for hostingertemplates.com (exact domain match, never a subdomain).
2. Creates the subdomain <id> with folder <id> if it doesn't exist, then waits until it's listed.
3. Gets upload credentials, retrying because new subdomains briefly return 500.
4. Uploads the zip in 10 MB chunks.
5. Deploys it:
   • static: POST …/deploy
   • Node.js: GET …/nodejs/builds/settings/from-archive, merges the catalog deploy settings (appType, buildCommand, outputDirectory, entryFile), defaults to Node 22, starts the build, then polls until it completes. If it fails, the log tail is printed.
6. Checks the live URL until it returns 200 and, for static sites, contains the built page's <title>. That skips Hostinger's browser-check page while DNS and TLS are still setting up.

Templates are deployed one at a time on purpose: parallel subdomain creation or upload-credential requests on one account fail with unfinished-action limits and 500s.

Security

• Token location: HOSTINGER_API_TOKEN is stored only in the template-demos environment, and only main can deploy to it. There's no repo-level secret.
• No PR triggers: the workflow never runs on pull_request or pull_request_target, so forks and PR code never get the token.
• Template code never runs with the token: templates are installed and built in the secret-free build job. The deploy job only checks out .github/scripts and runs deploy-demos.mjs, which uses Node built-ins only.
• Artifacts are checked: the deploy job only accepts template IDs that detect selected, so a tampered build artifact can't target another subdomain.

Catalog demoUrl

TEMPLATE_SCHEMA.md now asks for demoUrl: https://<id>.hostingertemplates.com in the PR that adds a template. Before, it stayed null until someone deployed by hand.

The alternative is a bot PR that writes demoUrl after deploying. main needs a review, so that would mean a second approval for every template. The cost of this choice: if a deploy fails, the catalog links to a dead demo until someone fixes it and reruns the workflow. A failed run turns red and lists the failure in the job summary.

deploy-templates skill

Its description told agents to use it "when publishing, deploying, or refreshing template demos". So Dex Code or Claude asked to create and publish a template would follow the manual connector steps. That duplicates the workflow, needs an interactive Hostinger sign-in that Dex Code jobs can't do, and its catalog step contradicts the new demoUrl rule. The skill (same file and name, 175 → 84 lines) is now a runbook:

• Redeploy: run the workflow with gh workflow run … --ref main -f templates="…" and watch it.
• Failed runs: what each failure looks like (build job, Hostinger Node.js build, live-check timeout, expired token), and that a merged fix needs a manual rerun.
• Manual fallback: for moving to another hosting plan or when Actions is unavailable.

Testing

• Packaging: ran locally on callout (Vite → static), couch-to-5k (SvelteKit, catalog outputDirectory → static), consultancy (Nuxt SSR → Node.js), api-reference (Nest → Node.js) and quickstart (Hono, entryFile → Node.js). Static zips have index.html at the root; source zips have no preview/, node_modules or build output.
• Deploy script: ran end to end against a mocked API and upload server, covering:
  • new and existing subdomains
  • a transient 500 retry
  • catalog settings applied to Node.js builds
  • a failed build, with the log tail printed and exit 1
  • an artifact that wasn't selected, which is refused
  • a missing build artifact
  • a 25 MB zip uploaded in three chunks
  • a wrong token (401, exit 1)
• Live check: confirmed against today's real demo at callout.hostingertemplates.com.
• Workflow lint: actionlint is clean.
• Not tested yet: the real Hostinger API. The first real call happens after merge.

After merge

• Run Deploy template demos from the Actions tab with callout. It redeploys an existing demo with the same content, as a first real check of the upload, subdomain and live-URL steps.
• template-demos environment created, limited to main, with HOSTINGER_API_TOKEN set.

🤖 Generated with Claude Code

[github-actions]

Template preview

No templates/* package changed in this PR.