The agent finished the code. Now give it somewhere to run. One command, one org host, one URL, the org login built in, and a small set of operations the agent can understand.

Install the CLI, log in, and tell the agent. It works in local coding environments, CI jobs and agent shells.

$ npm i -g @hubhq/cli@beta
$ hub login

Use the Hub CLI to deploy and operate this project.
After changes, run `hub deploy`.
If a release fails, read `hub logs <app> --build` before changing code.
Return the live URL and the release number.

The commands map to app, instance, release and service rather than cloud-provider primitives. Native MCP comes next. coming soon

What the agent runs.

$ hub deploy
$ hub status inventory-tool
$ hub logs inventory-tool --build
$ hub env inventory-tool
$ hub exec inventory-tool -- node scripts/check.mjs
$ hub rollback inventory-tool

A narrow deployment loop is easier to trust.

1. 1

   Build. The agent creates the app in the stack that suits the job.

2. 2

   Deploy. The agent runs hub deploy. Hub detects the app, packs it and builds it on the org's host.

3. 3

   Verify. Hub waits for the public service to answer, or checks that worker services stay running.

4. 4

   Share. The URL is behind the org login by default.

5. 5

   Operate. The agent reads release state, logs and status through the same commands.

The agent needs no access to a cloud account or to the host's Docker socket.

When a GitHub deploy fails, Hub can propose the next commit. For eligible build, start or compose failures, Hub:

1. 1

   classifies the failure;

2. 2

   opens the source in a sandbox on the org's host;

3. 3

   lets the fix agent read files and run approved build commands;

4. 4

   checks a small patch;

5. 5

   opens a pull request for a person to review.

Hub does not merge the pull request. What the sandbox gets and does not get is on the security page.

Let the agent finish the job.