Skip to content

21 Deployment Landscape

Jump to bottom
Henry edited this page Aug 28, 2026 · 1 revision

Deployment Landscape

Where this service is built, mirrored and published — from a local working copy through to PyPI, Docker Hub and mcpmemory.services.

➜ Open the diagram

Note

A hand-authored snapshot of 2026-08-28, not generated from repository state. When the topology changes it gets re-authored rather than refreshed. The diagram is not embedded here because the wiki renders neither iframes nor raw HTML.

The nodes

Node Role Evidence
Developer Mac local work; every push originates here —
Codeberg doobidoo/mcp-memory-service origin, issues, PRs, releases, Forgejo Actions CLAUDE.md
Forgejo Runner self-hosted on the Hetzner VM, label docker header of .forgejo/workflows/release.yml
Gitea 1.26.4 pull mirror of Codeberg, every 8 hours, reachable only over the Tailnet the same VM
GitHub Mirror Actions off, CodeQL only, no secrets CLAUDE.md, .github/workflows/codeql.yml
GitHub Pages serves docs/ — a redirect stub to mcpmemory.services CLAUDE.md
Cloudflare Pages mcpmemory.services, the canonical landing page .forgejo/workflows/deploy-site.yml
PyPI mcp-memory-service, tag-triggered job publish-pypi
Docker Hub doobidoo/mcp-memory-service, plus slim and multi-arch job publish-docker

One machine, two roles

The most interesting part of the landscape: the Hetzner VM tinyclaw (ubuntu-4gb-nbg1-1) runs both services. The Forgejo runner executes CI and publishes packages; the same host holds the Gitea mirror. If that VM goes down, the release pipeline and the mirror stop together.

Three one-way streets

  1. GitHub only ever receives a fast-forwarded main, and never tags. Tag-triggered workflows run the workflow files of their own commit, and every tag from before June 2026 carries publish workflows that would push to PyPI and Docker Hub a second time.
  2. Gitea pulls; it never pushes back. Pull mirror every 8 hours.
  3. GitHub Pages serves no content, only a 19-line stub redirecting to mcpmemory.services. That is why every mirror sync fires a pages build and deployment run — expected, not a stray workflow.

Exactly one publisher

Only release.yml on the Hetzner runner publishes packages. The GitHub mirror holds no repository secrets, so it cannot publish anything. That invariant is the reason for the tag rule above.

Guided views

The diagram carries three predefined views:

  1. Release path — tag push to Codeberg, runner, PyPI and Docker Hub
  2. Mirror path — Codeberg to Gitea and GitHub, both directions one-way
  3. Site path — merge to main touching site/**, wrangler, Cloudflare Pages

Related

Metadata

  • Generated with: Archify v2.16, type architecture
  • Key: bf529481... (spec SHA256)
  • Artifact hash: 64e53d05... (HTML SHA256)
  • Validation: 9/9 showcase checks, 0 errors, 0 warnings; visual-check pass at 1440x900, 1600x1000, 1920x1080 and 2048x1320 in light and dark
  • Created: 2026-08-28

Clone this wiki locally