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

MCP	CLI	API
`company_repository_import_start`	`cofounder company repository-import start --repository-full-name owner/repo`	`POST /cofounder-cli/v1/company/repository/import`
`company_repository_status`	`cofounder repo status`	`GET /cofounder-cli/v1/company/repository/status`
`company_repository_push_token`	`cofounder repo push-token`	`POST /cofounder-cli/v1/company/repository/push-token`

For a repo you already have, the friendlier spelling is repo import owner/repo — it takes the repo as a positional argument. repo import status tracks the import, repo import continue finishes it after a provider hand-off, and repo import cancel backs it out.

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. repo handoff and repo disconnect cover hand-offs and unbinding.

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
`company_repository_deploy`	`cofounder company repository deploy`	`POST /cofounder-cli/v1/company/repository/deploy`
`company_repository_deployment_readiness`	`cofounder company repository deployment-readiness`	`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
`supabase_migrations_list`	`cofounder supabase migration list`	`GET /cofounder-cli/v1/company/database/migrations`
`supabase_migrations_up`	`cofounder supabase migration up`	`POST /cofounder-cli/v1/company/database/migrations/up`
`supabase_functions_deploy`	`cofounder supabase functions deploy`	`POST /cofounder-cli/v1/company/database/functions/deploy`
`supabase_secrets_set`	`cofounder supabase secrets set`	`POST /cofounder-cli/v1/company/database/secrets`

The supabase subtree also covers refs, db query, branches, and storage. 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 — running vercel by hand, or a CI job. Cofounder mints them:

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

Next steps

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