Git & push-to-deploy

AgentCloud hosts git for every project — the Forge. There's no GitHub in the request path: your code, history, and builds all live on the same metal as your services. Your Conway token is the only credential — you never manage a separate git login.

Create a repository

conway repos create site --deploy-service web

--deploy-service is the service a push auto-deploys to (defaults to the repo name). The repo is created with a main branch ready to go.

Two ways to put code in it

1. Plain git over HTTPS

The repo's clone URL is https://git.agentcloud.ac/<project>/<repo>.git. Authenticate by passing your Conway token as the git password (any username):

git clone https://x:$CONWAY_TOKEN@git.agentcloud.ac/blog/site.git
cd site
# … edit …
git add -A && git commit -m "first cut"
git push                       # the gateway authorizes + proxies to the Forge

Behind the scenes the gateway validates your token (it needs the manage_repos capability and access to the project), provisions your git identity on the Forge on first use, and proxies the transport. The Forge is never exposed directly — the gateway is the single audited front door.

2. Commit files via the API — no local git

The ergonomic path when an agent is generating code:

conway repos commit site app.js package.json -m "scaffold"

or over REST / MCP — one commit, multiple files, no working copy:

curl -X POST https://api.agentcloud.ac/v1/projects/blog/repos/site/commits \
  -H "Authorization: Bearer $CONWAY_TOKEN" -H 'Content-Type: application/json' \
  -d '{"message":"scaffold","files":[
        {"path":"index.js","content":"console.log(\"hi\")"},
        {"path":"package.json","content":"{ \"name\": \"site\" }"}]}'

MCP agents use conway_commit_files with a {path: content} object.

Push-to-deploy

A repo created with a deploy_service auto-deploys on every push — the Forge fires a webhook into Conway's deploy machine, which builds the pushed commit (Dockerfile if present, else railpack autodetects the stack), runs the health gate, and flips traffic on success or rolls back on failure. Exactly the same pipeline as conway deploy, triggered by a git push.

Browse a repo

Action	Command
List repos	conway repos list
Repo details + clone URL	conway repos info <name>
Commit history	conway repos log <name>
Branches	conway repos refs <name>
Delete	conway repos delete <name>

The dashboard renders each repo as a node on the project canvas, wired to the service it deploys, with a file browser and commit history — all served through the gateway from the Forge (your browser only ever holds the Conway token).

Capability

Repo verbs require the manage_repos capability. It's included in the default automaton capability set, and a coordinator can delegate a repo-scoped token:

conway tokens issue --principal builder --caps manage_repos,deploy --projects blog