Managed Setup

Managed setup is the fast path to a working company: one run provisions the baseline — repository, deploy target, database, email, billing, and a managed Meta ads account (see Ads) — then reports what succeeded and what's still waiting on you.

Start a run

MCP	CLI	API
`company_setup_start`	`cofounder company setup`, `cofounder company setup start`	`POST /cofounder-cli/v1/company/setup`
`company_setup_start_profile`	`cofounder company setup start-profile --profile managed-app-v1 --required-capability company-email`	`POST /cofounder-cli/v1/company/setup/profile`
`company_setup_get`	`cofounder company setup status`, `cofounder company setup get`	`GET /cofounder-cli/v1/company/setup`
`company_setup_retry`	`cofounder company setup retry <run-id>`	`POST /cofounder-cli/v1/company/setup/{run_id}/retry`
`company_status`	`cofounder company status`	`GET /cofounder-cli/v1/company/status`

cofounder company setup
cofounder company setup status

Setup creates real accounts and projects (GitHub, Vercel, and the rest), so start it only when the founder asks. It runs in the background: the command returns right away, and setup status shows each step until the run finishes. company status is the one-line version. Use setup start-profile instead when your app needs specific capabilities, such as a company inbox (--required-capability company-email).

Automatic Mailtrap sender provisioning and Supabase Auth email setup are temporarily paused during onboarding. New runs and resumed pending steps skip this work and report it as not_applicable in setup status. Configure app email separately with the email tools. Existing email configurations stay in place; successful setup does not confirm delivery to an inbox.

If a step fails on something transient, don't restart. Grab the failed run's run_id from setup status and pass it to retry, which picks up from the failed step.

Phone is the one baseline resource that's opt-in: on the CLI, pass --phone to provision the company's number in the same command (--country and --area-code pick it). The request fires right after the setup run starts (it's not a step inside the run), so if it fails, retry it directly with cofounder phone provision rather than setup retry. On MCP it's always a separate phone_provision call.

To watch the run live:

cofounder watch company

Inspect what you got

See Company resources for what Cofounder tracks.

Every managed resource (the repo binding, the database, the inbox, the phone number) shows up as a company resource with a state, so listing them tells you what's live and what's missing:

MCP	CLI	API
`resources_list`	`cofounder company resources list`, `cofounder resources list`	`GET /cofounder-cli/v1/company/resources`
`resources_get`	`cofounder resources get --resource-id <id>`	`GET /cofounder-cli/v1/company/resources/{resource_id}`

Copy the resource_id exactly as the list prints it; connected resources carry composite ids like connected:github, not just UUIDs.

On the CLI there's a shortcut: cofounder company resources show <primitive> inspects by resource type (resources show code for the repository) and prompts when several match. The primitives are the ones resources list prints.

A resource that failed to provision shows up as a gap rather than silently missing. Its detail view explains why, and billing failures point you at cofounder company billing resources retry --binding-id <id>.

Choose between resources of the same type

A company can have more than one resource of a type, such as two inboxes. Mark one as the default and commands that need that type use it without asking:

MCP	CLI	API
`resources_default_set`	`cofounder resources default set --resource-id <id> [--scope <scope>]`	`POST /cofounder-cli/v1/company/resources/{resource_id}/default`
`resources_default_clear`	`cofounder resources default clear --resource-id <id>`	`DELETE /cofounder-cli/v1/company/resources/{resource_id}/default`
`resources_resolve`	`cofounder resources resolve --resource-type <type>`	`POST /cofounder-cli/v1/company/resources/resolve`
`resources_rename`	`cofounder resources rename --resource-id <id> --display-name <name>`	`PATCH /cofounder-cli/v1/company/resources/{resource_id}`

resources resolve tells you which resource of a type (for example mailbox) a command would use. Pass one selector — a resource_id, key, handle, or display_name, as resources list prints them — else it uses the default, else the only one. If there are several and no default, it lists them so you can pick. company resources show <primitive> <selector> accepts the same set. A social account is the default for its own platform: resources default set picks that platform for you (a --scope must match it, and ads-only accounts can't be defaults); resources list shows each resource's default_scope and the valid_scopes it accepts. Clearing a default doesn't delete the resource, and renaming changes only its display name.

Invite people into resources

Company admins can grant people write access to the managed GitHub repos and admin access to the managed Vercel projects:

MCP	CLI	API
`code_access_invite`	`cofounder code access invite --github-username <name>`	`POST /cofounder-cli/v1/settings/repo-import/access-invite`
`hosting_access_invite`	`cofounder company connections invite vercel --email <email>`, `cofounder hosting access invite --email <email>`	`POST /cofounder-cli/v1/settings/managed-project-access/vercel-invite`

cofounder code access invite --github-username octocat
cofounder company connections invite vercel --email dev@acme.co

GitHub invitations land as repo-collaborator invites; Vercel invitations go by email. The other person accepts to get access on their own account. A repository you imported yourself isn't included. If an invite fails partway, some may already have gone out. Check before sending again.

Next steps

Once the resources exist, Deploy and Operate covers the day-to-day work on them.