Why I decommissioned it

OpenCode was decommissioned because its role substantially overlapped with the remaining coding agents, while its headless server, Telegram bot, SQLite session store, watchdogs, cleanup jobs, daily restart logic, and backup automation created a disproportionate maintenance burden. Repeated session database hardening and recovery work made it a poor fit for my goal of a smaller, more predictable fleet.

Purpose: The decision was specific to my environment. I wanted fewer overlapping coding interfaces, fewer always-on processes, and less time spent repairing session-state issues. The encrypted backup keeps reversal possible if OpenCode later becomes uniquely useful.

What was in scope

  • OpenCode CLI/runtime and provider configuration
  • Headless opencode serve endpoint and systemd unit
  • OpenCode Telegram bot service and credentials
  • SQLite session data, caches, state, watchdogs, cleanup and restart scripts
  • GitHub/SMB backup jobs, startup entries, and dashboard registrations

Backup before removal

Before removal, the complete OpenCode footprint was archived. The SMB restore archive contains the full configuration and state (including protected secrets); the private GitHub repository contains an encrypted and chunked copy with SHA-256 manifests. Decryption and archive integrity were tested before destructive cleanup.

The decommissioning process

  1. Inventory: identify processes, systemd units, tmux sessions, ports, configuration, credentials, data, cron jobs, startup entries, backups, and dashboard references.
  2. Preserve: create complete SMB and encrypted private-GitHub archives; record file manifests and SHA-256 checksums.
  3. Verify: test archive integrity and encrypted-stream decryption before deleting anything.
  4. Quiesce: stop and disable agent services, terminate remaining processes and sessions, and confirm its ports are closed.
  5. Detach automation: remove startup hooks, watchdogs, restart/update tasks, Telegram gateway jobs, and recurring backups.
  6. Remove footprint: delete agent-specific binaries, packages, configuration, caches, state, logs, bot code, and token files from the VM.
  7. Clean interfaces: remove Mission Control/dashboard registrations and stale links that imply the agent is still active.
  8. Validate: confirm the agent is absent, shared infrastructure remains healthy, and no orphaned timers or credentials remain.

Security and rollback notes

  • No secrets are published in this article.
  • Public documentation records the method and rationale, not recovery credentials.
  • Private encrypted backups are retained so the retirement is reversible.
  • Any future restoration should happen in an isolated test environment first, followed by credential rotation.

Result

OpenCode was removed as a distinct operational agent while shared services—such as the model router, memory layer, NAS, GitHub backup infrastructure, and the agents intentionally retained—were kept separate. The result is a smaller attack surface, fewer always-on processes, fewer credentials and update paths, and a clearer operating model.

Editorial note: This is a record of a decision made for my own lab requirements. It is not a universal recommendation or a negative review of the project.