fix: bring scrutiny, stack-auth and vault in line with the compose conventions

[DPS0340]

What

Brings three blueprints — scrutiny, stack-auth, vault — in line with the repository's documented Docker Compose conventions. Six files, all deletions or one-line edits.

Part of #1047.

Note on scope: this PR started out as just the container_name removal, and the title said so. Review feedback correctly pointed out that it had grown past that, so the title and this description now describe the whole change. Everything here is one theme (making these three files satisfy the documented conventions), but I'm happy to split it if you'd rather review the pins separately.

Changes

1. Removed no-op container_name (all three)

validate-docker-compose.ts rejects container_name, and CONTRIBUTING says not to use it. In each of these the value is identical to the service name, so removing it changes nothing about service-to-service DNS:

blueprint	services	container_name	referenced elsewhere in the file?
scrutiny	scrutiny	scrutiny	no
stack-auth	stack-auth-db, stack-auth	stack-auth	no
vault	vault	vault	no

I checked that last column rather than assuming it: parsed each file, stripped comments, and searched for any use of the name outside its own declaration.

2. Pinned floating image tags (scrutiny, vault)

.github/copilot-instructions.md: "Pin images to specific versions … NEVER use latest tag", and meta.json.version must match.

• vault: hashicorp/vault:latest → 2.0.3. Verified on Docker Hub, multi-arch (386/amd64/arm64), published 2026-06-17.
• scrutiny: master-omnibus → v0.8.3-omnibus. Worth noting the upstream release is v0.9.2, but there is no v0.9.x omnibus image — the omnibus tags stop at v0.8.3. Pinning to the newest release would have produced a template that can't pull. Manifest confirmed HTTP 200 via a GHCR pull token.
• Both meta.json.version fields updated to match.

Not pinned: stack-auth. stackauth/server publishes no semantic version tags at all — the tag list is commit SHAs (5186b14, 27456b8, dc2eed6, …) plus latest and dev. Pinning to a SHA satisfies the letter of the rule while making the template harder to maintain and impossible to express as a meaningful meta.json.version. Left for you to decide.

3. Added the missing version: "3.8" header (scrutiny)

4. Removed the empty [[config.mounts]] block (vault/template.toml)

Not cosmetic, and not something I went looking for — CI surfaced it. Editing vault/docker-compose.yml made the workflow validate vault/template.toml for the first time since the rule tightened, and it failed with config.mounts[0]: Missing required field 'filePath'. TOML parses a bare [[config.mounts]] as [{}] — one mount with no fields. I confirmed it predates this PR by stashing my change and re-running (same two errors).

That is #1047, where 80 blueprints share the same problem. I fixed only vault here, since it was blocking this PR's CI; the other 79 are untouched pending your call on how you'd like them handled.

Scope I deliberately did not take

• :latest elsewhere. It appears in 205 of 500 blueprints (259 of 1109 image lines). This PR happened to touch two of them. A 205-file sweep belongs in its own change.
• enshrouded, wg-easy. Their container_name is a no-op too, but both files also fail on ports mappings (15637/udp game server, 51820/udp WireGuard) that I am not proposing to change — those genuinely need host ports and Dokploy's HTTP routing can't substitute. I didn't want to half-fix a file and leave it red.
• datalens, elastic-search, pre0.22.5-supabase. Multi-service, and their container names differ from the service names, so removing them could change resolvable hostnames.
• systemprompt — false positive; the match is inside a comment.

Testing

$ node build-scripts/generate-meta.js --check
✅ 500 templates validated

scrutiny   compose: PASS   toml: PASS
stack-auth compose: PASS   toml: PASS
vault      compose: PASS   toml: PASS

All three failed validate-docker-compose.ts before this change. All four CI checks (build-preview, validate, validate-docker-compose, validate-meta) pass.

What I did not do: I have no Dokploy instance, so this is validator-level plus static reference and image-manifest checks, not a live redeploy. The image pins are the part with real behavioural risk — vault:2.0.3 is a major version ahead of whatever latest resolved to on any given day, so if you'd prefer a more conservative pin for that one, say the word.

[github-actions]

built with Refined Cloudflare Pages Action

⚡ Cloudflare Pages Deployment

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

[DPS0340]

CI caught the thing I predicted in the PR body, which is worth spelling out because it's a nice demonstration of #1047.

validate-docker-compose failed on:

❌ config.mounts[0]: Missing required field 'filePath'
❌ config.mounts[0]: Missing required field 'content'

That is not from my change. It's the pre-existing empty [[config.mounts]] in blueprints/vault/template.toml. The workflow validates every blueprint directory a PR touches, so by editing vault/docker-compose.yml I made CI look at vault/template.toml for the first time since the rule tightened — exactly the accumulation mechanism described in #1047, now demonstrated rather than argued.

Fixed in 3274480 by deleting the bare header. TOML parses [[config.mounts]] with no keys as [{}] (one mount, no fields), which is why the validator objects; with the header gone config.mounts is simply absent, matching the 197 blueprints that write mounts = [].

$ pnpm exec tsx validate-template.ts --dir ../blueprints/vault
✅ Template structure is valid
🔍 📋 Domains configured:
🔍    - Service: vault, Port: 8200, Host: ${main_domain}

The diff is now 3 deleted container_name lines plus the 3-line empty-mounts block in vault. I've kept it to vault only — the other 79 are still untouched pending your call in #1047 on how you'd like them handled.

[Copilot]

Pull request overview

This PR removes container_name from three Dokploy blueprints (scrutiny, stack-auth, vault) to align with the repository’s Docker Compose validation rules and documented Dokploy conventions.

Changes:

• Removed container_name from blueprints/scrutiny/docker-compose.yml
• Removed container_name from blueprints/stack-auth/docker-compose.yml
• Removed container_name from blueprints/vault/docker-compose.yml

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 4 comments.

File	Description
blueprints/scrutiny/docker-compose.yml	Drops container_name from the scrutiny service definition.
blueprints/stack-auth/docker-compose.yml	Drops container_name from the stack-auth service definition.
blueprints/vault/docker-compose.yml	Drops container_name from the vault service definition.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

[DPS0340]

Thanks — I checked all four against .github/copilot-instructions.md and acted on three of them. Pushed in a0ebc34.

Adopted:

• vault: hashicorp/vault:latest → 2.0.3. Verified the tag exists and is multi-arch (386/amd64/arm64, published 2026-06-17). Also updated meta.json.version from "latest" to "2.0.3", since the convention is that they match.
• scrutiny: master-omnibus → v0.8.3-omnibus. Confirmed via the GHCR tag list that v0.8.3-omnibus is the newest released omnibus tag, and pulled its manifest (HTTP 200) rather than assuming. Worth noting the upstream release is v0.9.2, but there is no v0.9.x omnibus image published — the omnibus tags stop at v0.8.3 — so that is the correct pin, not a stale one. meta.json.version updated to match.
• scrutiny: added the missing version: "3.8" header.

Not adopted, with a reason:

• stack-auth: stackauth/server:latest. I would have pinned it, but that image publishes no semantic version tags at all — the entire tag list is commit SHAs (5186b14, 27456b8, dc2eed6, …) plus latest and dev. Pinning to a SHA would satisfy the letter of the rule while making the template harder to maintain and impossible to map onto a meaningful meta.json.version. I'd rather leave it and let you decide than pick a SHA on your behalf.

One piece of context on scope. The :latest finding is real, but it is not specific to this PR: 205 of the 500 blueprints contain at least one :latest image (259 occurrences out of 1109 image lines). This PR happened to touch three of them. I've fixed the two that are cleanly pinnable rather than expanding it into a 205-file sweep — that belongs in its own change, and I raised the related "rules only get enforced on files a PR happens to touch" problem in #1047.

Validation after the changes:

$ node build-scripts/generate-meta.js --check
✅ 500 templates validated

scrutiny   compose: PASS   toml: PASS
stack-auth compose: PASS   toml: PASS
vault      compose: PASS   toml: PASS

[Copilot]

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (1)

blueprints/stack-auth/docker-compose.yml:21

• stackauth/server:latest still uses the latest tag, which makes the blueprint non-reproducible and can break unexpectedly when upstream updates. Since this file is being touched anyway, consider pinning to a specific published image tag and updating the blueprint's metadata version to match.

  stack-auth:
    image: stackauth/server:latest
    environment:

[DPS0340]

Fair point, and taken. The PR did outgrow its title: it started as the container_name removal, then the image pins came from your earlier review and the vault/template.toml fix came from CI failing on a pre-existing problem that my edit caused the workflow to notice.

Retitled to fix: bring scrutiny, stack-auth and vault in line with the compose conventions and rewrote the description to cover all four changes, each with its reason and the verification behind it. I've also spelled out what I deliberately left alone and why (205 blueprints have :latest; enshrouded/wg-easy need their UDP host ports; datalens/elastic-search/supabase have container names that differ from service names, so removing them could change resolvable hostnames).

Happy to split the pins into their own PR if you'd still prefer to assess them separately — say the word and I'll do that rather than argue for the combined form.