GBrain Dashboard
Browse Notes
New Note
Edit: github-backup/research/repository-and-deployment-strategy.md
Cancel
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.
Save Changes