v0.1.9 / active development

Desired state in. Reviewed provider actions out.

Hypervibe is an infrastructure control loop. A CLI and an MCP server share one command core, one persisted plan boundary, and one redacted result contract. It is being built in public, but it is not ready to pretend everything works.

read the architecture browse source
  • 19 shared commands
  • repo-backed JSON intent
  • Apache-2.0
  • no public release yet
~/serious-api illustrative session / gcp
00 / the control loop

Intent is cheap. Mutation needs a receipt.

Hypervibe observes live infrastructure, computes drift, persists an executable plan, and applies only the actions that plan authorized. MCP and CLI are adapters over that same lifecycle.

01 / intent hypervibe spec

Write or inspect desired services, data, deploys, domains, email, and environment contracts.

02 / observation hypervibe plan

Compare desired state with provider-confirmed state and persist the exact proposed actions.

03 / mutation hypervibe apply

Converge the reviewed plan. Billable, destructive, and data-bearing work has explicit gates.

04 / evidence hypervibe status

Re-observe drift. Configuration sync is separate from runtime health and deploy evidence.

A timeout is not absence. A noop is not permission to repair. A persisted plan is the mutation boundary.
01 / current build

A build ledger, not a feature wall.

These are the surfaces currently represented in the codebase. Support still varies by provider and lifecycle contract; pre-release means the sharp edges are real.

command coreimplemented19 commands registered once and routed through both CLI and MCP.
hostingimplementedRailway and Google Cloud Run adapters behind the lifecycle boundary.
postgresimplementedRailway, Cloud SQL, Supabase, and RDS lifecycle paths.
dns + domainsimplementedCloudflare-backed desired state, planning, and verification.
emailimplementedSendGrid sender identities, aliases, domain authentication, and inbound parsing declarations.
secret inputread boundaryEnvironment files and lazy secret-manager references resolve values without exposing them in output.
deploy automationimplementedGitHub Actions workflows are generated as reviewed repository infrastructure.
public releasenot yetDevelopment build only. The public quickstart waits for a smaller, proven surface.
02 / non-goals

Not a bag of cloud shortcuts.

Provider differences are real. Hypervibe tries to make the safety model consistent without flattening those differences into an interface that lies.

No provider CLI backdoors

Infrastructure mutations flow through adapters and recorded connections so state, drift, and audit history remain coherent.

No optimistic observation

Permissions, malformed responses, timeouts, and unsupported reads stay unknown or blocked. They do not quietly become “not found.”

No implied cross-resource work

A service action cannot silently create a database, attach unrelated infrastructure, or clean up a dependency outside its plan edge.

No secrets in the interface

Specs declare ownership and references. Results, logs, plans, snapshots, CLI JSON, and MCP structured output stay on the same redacted boundary.

version
0.1.9
channel
development
public package
pending
spec format
JSON
interfaces
CLI / MCP
03 / coming soon

The small, reliable version ships first.

Hypervibe is still being reduced and hardened: fewer commands, declarative resource lifecycles, typed provider boundaries, and tests that prove a noop cannot mutate anything. There is no fake waitlist and no public install command yet.

follow the repository inspect the command catalog