Repository and Deployment Strategy

Prepared: 2026-05-27

Recommendation

Create one private GitHub repository for Hermes operating infrastructure, not for the living second brain itself.

Suggested repository: easiermarketing/easier-hermes-ops
Visibility: private

Commit to the Private Operations Repository

• Research and architecture decisions.
• Pinned deployment scripts and Compose definition.
• Non-secret configuration templates.
• Empty Obsidian vault schema and governance templates.
• Later: reviewed Hermes skills, retrieval benchmarks and migration tooling.

Do Not Commit

• Provider credentials, Google credentials, MCP tokens or SSH keys.
• Active .env or runtime config.yaml files.
• Hermes session history, databases or logs.
• QMD indexes, embeddings or model caches.
• The live Obsidian vault once it contains business, client, sales, relationship or personal knowledge.

Why Not Put the Live Obsidian Vault in GitHub

A private Git repository is technically convenient for Markdown version history, but it becomes a permanent replicated history of deleted facts and sensitive relationship material. It also encourages agents and deployments to obtain far broader access than they need. That is a poor default for a vault intended to cover marketing, sales, fulfilment and customer relationships.

Start the live vault on controlled storage with encrypted backups and a clear retention/access policy. Once its real sensitivity is known, choose a sync and versioning model intentionally. Options worth evaluating later include:

• Obsidian Sync with end-to-end encryption for human devices, plus a restricted server copy only when required.
• An encrypted backup destination with restore testing.
• A separated public/internal research vault that may safely use Git, and a confidential operational vault that does not.

Upstream Hermes Source

Do not fork or vendor the entire Hermes Agent repository merely to deploy it. The host preparation script pins the reviewed upstream release v2026.5.16 and stages source from that tag. Building the image is deliberately opt-in because the current n8n VM has limited free disk and memory. A fork becomes justified only if Easier must maintain code patches rather than configuration or skills.

Google Cloud Deployment Path

The clean route, once signed into Google Cloud Console, is:

1. Identify the GCE project, instance name, zone, current containers, resources and firewall without changing anything.
2. Confirm the instance is in fact the one hosting n8n and that it has capacity.
3. Transfer the private operations package by an authenticated administrative route.
4. Run only deployment/prepare-hermes-host.sh, which stages pinned Hermes source and an empty vault template. Build the image later only with HERMES_BUILD_IMAGE=1 during a maintenance window or on a roomier host.
5. Leave the Compose activate profile stopped until provider credentials, backup strategy and permissions are approved.

Cloud Shell is acceptable for the staging step because it is authenticated to Google Cloud and can use gcloud compute ssh/scp. It is not itself the runtime: Hermes should live on the VM in its isolated container.