Skip to main content
A profile is a named group of integrations, prompts, and env variables. Integrations connect your machine0 account to external services and store the resulting credentials encrypted — and because they live inside profiles, the same integration can be connected several times with different accounts (e.g. github as your work account in one profile and your personal account in another). Creating a VM with machine0 new --profile <name> injects the profile’s credentials and env variables into it: gh is authenticated (~/.config/gh/hosts.yml + the git credential helper), codex is logged in (~/.codex/auth.json), and the profile’s MCP endpoint is preconfigured for both Claude Code (~/.claude.json) and Codex (~/.codex/config.toml). Each entity has its own command group: profiles manages the profile itself, integrations (alias int) its integrations, env (alias vars) its env variables, and prompts its prompt library. New accounts start with a profile named default, so you can connect integrations and set variables without creating one first. You always have at least one profile — profiles rm refuses to remove your last remaining profile. Profile targeting — the integrations, env, and prompts commands don’t take a profile argument. They target the current profile, resolved as: the -p/--profile flag if given, else the DEFAULT_PROFILE setting (environment variable, then a machine0.env in the current directory, then ~/.machine0/machine0.env), else default. Set it once with profiles use, override per command with -p, or pin it per project by adding DEFAULT_PROFILE=<name> to a machine0.env in that directory (the CLI announces an active project pin on stderr). Every command names the profile it acted on.

The profile MCP endpoint

Each profile aggregates its MCP integrations behind one endpoint:
The endpoint speaks stateless Streamable HTTP (JSON responses, no sessions, no SSE) and serves the combined tools of every MCP integration in the profile — system integrations hold provider credentials and are not part of the aggregation. It also serves the profile’s own prompts over the native MCP prompts/list / prompts/get, merged ahead of any prompts the upstream servers expose (on a name collision, the profile’s prompt wins). Two ways to authenticate: OAuth (interactive clients) — MCP clients supporting RFC 9728 discover the OAuth flow automatically. Claude Desktop, claude.ai connectors, and Claude Code handle this out of the box — just add the URL and approve the browser consent:
API key (programmatic) — pass your machine0 API key in the x-api-key header:
On a VM created (or deployed) with the profile, both values are already exported as environment variables — use $MACHINE0_MCP_URL and $MACHINE0_API_KEY instead of hardcoding them. Profiles are an organizational boundary, not a security boundary: any of your API keys — and any MCP OAuth grant on your account — can call any of your profiles’ endpoints.

profiles ls

List your profiles with the number of VMs using each one and its description. The current profile is marked with *; if the current profile no longer exists (deleted, or a stale setting), the listing says so instead.

profiles use

Set the current profile — the one integrations, env, and prompts commands target when -p/--profile isn’t given. Validates the profile exists, then writes DEFAULT_PROFILE to ~/.machine0/machine0.env. If an environment variable or a project machine0.env currently overrides the setting, the CLI warns and reports the write as not yet active.
To pin a profile for one project instead, add DEFAULT_PROFILE=<name> to a machine0.env file in that directory — it beats the home config there and only there.

profiles new

Create a profile. Aliased as profiles create and profiles add. Pass --description to describe the profile (it shows in profiles ls and profiles get). Profile names follow the same rules as machine names (letters, digits, and dashes; max 63 characters) and are unique per account. Accounts are limited to 50 profiles, and a starter default profile counts toward that limit like any other (remove it once you have another profile if you need the slot back).

profiles duplicate

Copy a profile — its description, env variables (secret markers included), prompts, and integrations — into a new profile. Aliased as profiles copy. Each integration is copied with its description, tool/prompt prefix, and tool whitelist intact, so the copy’s MCP endpoint exposes the same names as the source. Copied integrations arrive disconnected: credentials are never copied, so reconnect any that need them in the new profile with integrations connect. (Custom MCP integrations that don’t require credentials keep working without a reconnect.) Without a target name the copy is named <profile>-copy, then <profile>-copy-2, -copy-3, … if taken; an explicit target name must be free. Copies count toward the 50-profile account limit.

profiles update

Update a profile’s settings. Pass --name to rename it, --description to change the description (pass an empty string to clear it). You can pass both at once.
Renaming preserves the profile’s variables, secrets, and connected integrations — it only changes the name. If you rename the profile you’re currently using (your DEFAULT_PROFILE), the CLI updates that setting so profile-scoped commands keep working. Renaming is not retroactive to machines you’ve already provisioned. A profile’s MCP endpoint URL (/profiles/<name>/mcp) and any MCP URL already injected into a running machine keep the old name until you redeploy the profile with profiles deploy (or resume/recreate the machine). External tools that hardcode the old MCP URL will also need updating.

profiles deploy

Deploy a profile onto a running VM — wipes the previously injected profile’s credentials and env variables off the machine and injects this profile’s instead. The profile is the current one, or pass -p/--profile. Because it replaces what’s on the machine, the command asks for confirmation naming both the profile and the machine; pass --yes to skip it (required in scripts and with --json). Deployment happens server-side over SSH; integration secrets never pass through your terminal. Works on both Ubuntu and NixOS machines (NixOS needs a current image version; older images apply credentials but shells won’t see env vars until the image updates). New env vars and credentials apply to new sessions — running shells and agent processes (claude, codex) keep the old state until restarted.

profiles get

Show a profile’s details — its description and MCP connection string, its integrations (built-in and custom) with their connection status, its prompts (with the start of each body), and its environment variables. With no argument it shows the current profile, plus a line saying where the setting comes from (the DEFAULT_PROFILE environment variable, a project machine0.env, the home config, or the built-in default).
For a single integration’s details see integrations get; for a prompt’s body see prompts get; for the variables alone see env ls.

profiles rm

Remove a profile. This deletes its integrations and their stored credentials (a connected machine0-cli key is revoked), removes its prompts, and its MCP endpoint stops working. Your last remaining profile cannot be removed — create another profile first. Removing the current profile warns in the confirmation: run profiles use afterwards or commands fall back to a profile that no longer exists (they fail with a pointer at profiles use).