Edit: github-backup/research/repository-and-deployment-strategy.md

Note Content (Markdown)

# 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.