I know we are all caught up in the agent hype, but did anyone recognize that this is blocks attempt to fully. Replace the GitHub interface? Not sure how I feel about it yet - wish it was integrated with existing git over nostr solutions that are more decentralized. Hopefully some discussion to come.

Surprised no one had made this yet… Let’s test out buzz! nostr.communities.buzz.xyz

I found it hard to get a buzz relay started so I set up a repo to do it quickly and easily. Quick path to self-hosting buzz instead of going hosted.

GitHub

GitHub - armstrys/buzz-relay-thin: Relay-only deployment bundle for block/buzz: install.sh + docker-compose + systemd unit

Relay-only deployment bundle for block/buzz: install.sh + docker-compose + systemd unit - armstrys/buzz-relay-thin

Was super excited about buzz because it read like the relay was self hosted by default but during set up it is asking for sign in to a hosted relay. Any way around this?

Still unsure if helpful or if stupid. Agent skill that allows docker deployments directly from a GitHub repo. Agent writes code. Human sets up infra. Automation deploys services.

GitHub

GitHub - armstrys/docker-git-deploy: Pull-based GitOps deployment framework for Docker Compose homelabs

Pull-based GitOps deployment framework for Docker Compose homelabs - armstrys/docker-git-deploy

1. **Install the skill.** The human asks the agent to install this skill. 2. **State the goal.** The human asks the agent to deploy services X, Y, Z to a server. 3. **Scope it.** The agent asks about the current server, explains the minimum requirements for install, and explains the git access involved — the **agent needs write** access to create and push the deployment repo, while the **server only needs read-only** access to pull it. Any Git host works (GitHub, GitLab, Bitbucket, self-hosted). 4. **Create the deployment repo.** The agent generates a pure-config repo from the starter (compose files, service definitions, `.env.example`) and pushes it to the git remote. 5. **Bootstrap the server.** The agent hands the human a one-line install command to run as root on the server; it clones the repo and installs the systemd timer. The agent also explains **which secrets and environment values each service needs** (derived from the repo's `.env.example`) and **how to create the `.env`** on the host — e.g. `cp .env.example .env` and then fill in real values. The deploy is skipped until `.env` exists, and secrets never live in the repo. The agent helps troubleshoot but never needs access to the server itself. 6. **Ongoing adjustments and new services.** From then on, the human asks the agent to add a service or change config, and the agent commits it to the repo and merges to `main` — from any location, with no server access. The server polls `origin/main` on its timer and applies the change automatically, reconciling with `docker compose up -d --wait` and rolling back if a new version fails to become healthy. The human's **only** manual step is updating `.env` on the server — and only when the agent says a new or changed service needs a new secret. View quoted note →

New idea in testing: Agent skill that helps you set up a home lab docker deployment that periodically pulls its config from a git repo. Agent sets up framework and service configuration you review and production server pulls with no direct agent access. Want to add or configure new services? Make requests and edits on your local device and they deploy server side with minimal editing on server. Server stays lean and deployments are all version controlled. Will share code after more testing in action.