ComputeSphereLearn
Console
Learning paths / Vibe coding to production / Ship it with an agent

Deploy the starter with an agent

Reading · 6 min · Module 8, lesson 2 of 446 min left in this module

Module 8 · Ship it with an agentLesson 2 of 4

Goal: Plan an agent-assisted deploy of the starter, deciding what you set up, what the agent runs with a project token, and what you approve.

Key idea

An agent-assisted deploy splits the work. You set up the service and approve every change to it. The agent runs csph with a project token, watches the status and logs, and reports back. Nothing reaches your live app until you say yes.

Who does what

Creating the service, with a runtime build, is a one-time decision about how the app is built and served, and it's where you choose exactly which repository ComputeSphere may read. The token is the one from lesson 4.8.1. When you check the agent's report, check it against what you can see in the console.

The starter's build settings

The starter lives in a subfolder, and builds start from the repository root, so both commands move into the folder first (lesson 5.3.5):

  • Runtime: Node.js, version 20
  • Build command: cd labs/vibe-starter && npm ci
  • Start command: cd labs/vibe-starter && npm start
  • Port: 3000, where the fixed starter listens unless PORT is set
  • Health check: Endpoint path /healthz, Port 3000

These need the module 2 fix: the app must listen on 0.0.0.0.

Shipping new code

With your repository connected, every push to the service's branch builds and deploys. So the gate is the merge. The agent works on its own branch and opens a pull request, you review the diff, and you merge. Never let the agent push to the branch the service builds from, and protect that branch (lesson 2.7.2) so it can't.

The agent's csph deployments redeploy applies the service's saved settings, for example after you change a variable. With nothing changed, it has nothing to roll out. It doesn't pick up new commits.

Reading the command before you approve

Before you say yes, check:

  • The command. Redeploy, logs and status are routine. Anything with delete, stop, secrets set or --replace needs a reason.
  • The ID. Does the deployment ID belong to the service you mean? csph deployments list --service <service-id> shows it.
  • Where. The right project and environment, not production when you meant the lab.
The commands your agent will use
  • csph services list --project <project-id>: find the service.
  • csph deployments list --service <service-id>: find its deployment ID.
  • csph deployments redeploy <deployment-id>: roll it out again.
  • csph deployments get <deployment-id>: its status and URL.
  • csph logs vibe-starter --kind deploy: what the rollout did; --kind runtime for the app's own output.

Why not the MCP server? It could do all of this, but it acts as you, with everything your account can reach. csph with a project token limits the agent to one project. The MCP connection is still handy for reading logs while you debug.

Check yourself

Your agent pushed straight to main, the branch your connected service builds from. What happens?
The agent proposes csph services secrets set API_KEY=... --replace. What do you check first?

In the docs