Deploy and Operate

Once your company has a repository and a deploy target, this is the surface your agent builds on: branches, deploys, migrations, secrets, functions.

The repository

code_push_token_create and code_repository_import_continue are available through the CLI, API, and general /mcp endpoint. The OpenAI and Claude plugin catalogs (/mcp/openai and /mcp/claude) exclude code_push_token_create because it returns a credential. They include code_repository_import_continue without its additional_env_vars input, so secret values never pass through chat: enter them on the dashboard secrets page, then continue the import.

MCP	CLI	API
`code_repository_get`	`cofounder repo status`, `cofounder code repository get`	`GET /cofounder-cli/v1/company/repository/status`
`code_push_token_create`	`cofounder repo push-token`, `cofounder code push-token create`	`POST /cofounder-cli/v1/company/repository/push-token`
—	`cofounder repo handoff --notes <text>`	—

cofounder repo clone                        # clone the bound repo locally
cofounder repo status                       # production branch, open PRs, agent work in flight

Make repo status your first call before starting work; it tells you what other agents already have in flight. The push token lasts about an hour; ask for a new one when it expires. repo handoff leaves a note on the event log for whoever picks up the current branch next.

Bring your own repository

If the founder already has a GitHub repo for the product, import it as the company's app instead of building in the one setup created:

MCP	CLI	API
`code_repository_import_start`	`cofounder repo import <owner/repo>`, `cofounder code repository-import start --repository-full-name owner/repo`	`POST /cofounder-cli/v1/company/repository/import`
`code_repository_import_get`	`cofounder repo import status`, `cofounder code repository-import get`	`GET /cofounder-cli/v1/company/repository/import`
`code_repository_import_continue`	`cofounder repo import continue`, `cofounder code repository-import continue`	`POST /cofounder-cli/v1/company/repository/import/continue`
`code_repository_import_cancel`	`cofounder code repository-import cancel`	`POST /cofounder-cli/v1/company/repository/import/cancel`
`code_repository_import_disconnect`	`cofounder repo disconnect`, `cofounder code repository-import disconnect`	`POST /cofounder-cli/v1/company/repository/import/disconnect`

The import asks the founder to accept a Vercel invitation, then tries to connect the repo automatically to the existing project in Cofounder's Vercel team. If Vercel requires owner authorization, the previous connection is restored and the agent receives connection instructions. The project stays in that team; the founder's GitHub-connected Vercel account authorizes the manual connection. For a personal GitHub repository, the repository owner must make that connection.

When the status is awaiting_vercel_link, help the founder open the returned Git settings URL and connect the selected repo to that existing project. Run repo import continue after connecting to verify the repo and finish the import, and use repo import status to see what's next. Importing doesn't deploy the app, and any database setup created stays attached. code repository-import cancel backs out an unfinished import; after it finishes, repo disconnect switches back to the repository setup created.

Deploy

Deploys run against the bound hosting provider. deploy starts one, readiness tells you whether it actually came up, and the deployments list keeps the history:

MCP	CLI	API
`hosting_deploy`	`cofounder hosting deploy`	`POST /cofounder-cli/v1/company/repository/deploy`
`hosting_deployments_readiness_get`	`cofounder hosting deployments readiness get`	`GET /cofounder-cli/v1/company/repository/deployments/{deployment_id}/readiness`
`hosting_deployments_list`	`cofounder hosting deployments list`	`GET /cofounder-cli/v1/company/hosting/deployments`
`hosting_deployments_get`	`cofounder hosting deployments get`	`GET /cofounder-cli/v1/company/hosting/deployments/{deployment_id}`
`hosting_deployments_events`	`cofounder hosting deployments events`	`GET /cofounder-cli/v1/company/hosting/deployments/{deployment_id}/events`
—	`cofounder deploy status`	—

Supabase

The managed Supabase project is a first-class surface: migrations, functions, secrets, and queries all run through your Cofounder login:

MCP	CLI	API
`database_migrations_list`	`cofounder database migrations list`	`GET /cofounder-cli/v1/company/database/migrations`
`database_migrations_apply`	`cofounder database migrations apply`	`POST /cofounder-cli/v1/company/database/migrations/up`
`database_functions_deploy`	`cofounder database functions deploy`	`POST /cofounder-cli/v1/company/database/functions/deploy`
`database_secrets_set`	`cofounder database secrets set`	`POST /cofounder-cli/v1/company/database/secrets`

The database subtree also covers query, branches, and storage; cofounder database refs list lists project refs. Provider credentials stay on the backend, so day-to-day database work needs nothing extra on your machine.

Secrets

App secrets ship to the deploy target without ever touching a local env file:

MCP	CLI	API
`secrets_set`	`cofounder secrets set KEY`	`POST /cofounder-cli/v1/secrets`
`secrets_list`	`cofounder secrets list`	`GET /cofounder-cli/v1/secrets`
`secrets_delete`	`cofounder secrets delete KEY`	`DELETE /cofounder-cli/v1/secrets/{key}`

Deploy-time secrets and dev-time env files are different things. The distinction and the full mechanics are in Secrets and Environment Files.

Provider credentials

Sometimes you need the provider's own credentials, for example when running the Vercel CLI by hand or in a CI job. Cofounder mints them from the CLI (these are not MCP tools):

MCP	CLI	API
—	`cofounder hosting credentials create`	`POST /cofounder-cli/v1/company/hosting/credentials`
—	`cofounder code gh-credentials create`	`POST /cofounder-cli/v1/company/repository/gh-credentials`

Next steps

Infrastructure running? Time to reach people: Communicate and Sell.