docs: defer dedicated-server migration with explicit gates

[ComBba]

Summary

• record Glasshat/Panelyst as explicitly deferred
• define the dedicated-runtime, data-compatibility, security, CD quarantine, and rollback backlog
• make clear that this PR authorizes no deployment or infrastructure mutation

Validation

• documentation-only change
• git diff --cached --check passed before commit

Blocking evidence for future work

• source PostgreSQL major must be proven from the archived dump before choosing a restore image
• server port/listener/nginx/Cloudflare/Docker inventory must be completed before placement

This Draft PR is the durable TODO requested for later execution.

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 35f03954-e4b6-4c3a-a114-5cd6f46b3d4d

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch codex/dedicated-runtime-contract

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[gemini-code-assist]

Code Review

This pull request introduces a comprehensive backlog and TODO list (docs/dedicated-migration-todo.md) for the dedicated-server migration of Glasshat/Panelyst. The review feedback highlights two critical operational and security improvements: first, specifying writable mounts (such as tmpfs or volumes) for read-only database and application containers to prevent startup failures, and second, resolving a permission conflict where non-root containers would be unable to read root-owned runtime secret files.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

When running containers with a read-only root filesystem, stateful or runtime-heavy services like PostgreSQL and Phoenix will fail to start unless they have writable paths for data, sockets, and temporary files. Consider specifying that these containers require appropriate writable mounts (such as tmpfs or volumes) for directories like /var/lib/postgresql/data, /var/run/postgresql, and /tmp.

Suggested change

	- [ ] Produce non-root, read-only, resource-limited API, web, edge, PostgreSQL, and
	Phoenix containers with private networks and zero host-published ports.
	- [ ] Produce non-root, read-only (with necessary writable tmpfs/volume mounts for database/app runtimes), resource-limited API, web, edge, PostgreSQL, and
	Phoenix containers with private networks and zero host-published ports.

[gemini-code-assist]

There is a potential conflict between running containers as non-root (line 39) and storing runtime secrets in root-owned files (line 41). If the secret files are strictly root-readable (e.g., permissions 0400 or 0600), the non-root container processes will encounter 'Permission denied' errors when attempting to read them. Consider specifying that secret files should be owned by or readable by the specific non-root UID/GID used by the containers, or managed via Docker secrets which handles container-user ownership automatically.

Suggested change

	- [ ] Move runtime secrets to root-owned files; keep only secret names and schemas in
	Git. Validate that images, logs, Compose output, and CI artifacts contain no
	secret values.
	- [ ] Move runtime secrets to securely mounted files (e.g., via Docker secrets with appropriate non-root ownership); keep only secret names and schemas in
	Git. Validate that images, logs, Compose output, and CI artifacts contain no
	secret values.