Skip to main content

​
Overview

A profile is a named set of credentials, MCP connections, prompts, and env variables that you can inject into a VM to give it specific capabilities or a personality. You can maintain as many as you’d like. For example, a production profile might be connected via MCP to your error monitoring and log aggregation tools, and carry a prompt template that resolves the top issues:
The VM comes up ready: gh and git are authenticated, claude is logged in, and the profile’s MCP endpoint is preconfigured in Claude Code and Codex (see MCP gateway to configure other clients). profiles deploy applies a profile to an already-running VM the same way. For claude-code, the VM receives whichever credential kind you connected: the Anthropic Subscription option is injected as the account login (~/.claude/.credentials.json), while the Anthropic API Key option is injected as an API key in ~/.claude.json (primaryApiKey), exactly the way claude login records each on your own machine. Every account starts with a profile named default, so you can connect integrations and set variables without creating one first. You always have at least one profile. The integrations, prompts, and env commands target your current profile: default out of the box, or whatever you set with machine0 profiles use <name>. Target another profile for a single command with -p/--profile, or pin one per project by putting DEFAULT_PROFILE=<name> in a machine0.env file in that directory. machine0 profiles get shows which profile is current and where the setting comes from.

​
Profile objects

​
Integrations

Integrations connect a profile to external services and store the resulting credentials encrypted. There are two types:
  • System integrations (claude-code, codex, github, machine0-cli) hold provider credentials that are injected into VMs: connect once, and every VM created with the profile is pre-authenticated. claude-code and codex accept either your own API key or an account-based OAuth login — for claude-code the choices are Anthropic Subscription (a Claude Pro/Max/Team login) and Anthropic API Key (the right choice for Console/API-billing accounts); codex defaults to the API key. See integrations connect.
  • MCP integrations are remote MCP servers you add by URL; their tools are served through the profile’s MCP gateway (and to VMs created with the profile). You can add up to 50 per profile.
Because integrations live inside profiles, the same service can be connected several times with different accounts. For example, github with access to different repos on different profiles.
Injected credentials are plain files on the VM and travel with snapshots. When a VM is created from an image without a profile, cloud-init wipes the stale profile files. Created with a profile, each connected integration’s file is replaced (including switching auth mode), but a baked credential for an integration the new profile doesn’t have stays in place — and the credentials always sit inside the image itself, so rotate or disconnect them before sharing one.

​
Prompts

Each profile carries a prompt library, served through its MCP gateway. Prompts appear as slash commands in connected Claude clients.

​
Environment variables

Environment variables injected into every VM created with the profile. Use --secret for write-only values.
Alongside your own variables, every VM whose profile has machine0-cli connected (automatic on create and deploy) also exports two machine0-provided variables:
  • MACHINE0_MCP_URL — the profile’s own MCP gateway endpoint
  • MACHINE0_API_KEY — an API key that authenticates against it. Note this is the same account-level API key the injected machine0 CLI uses — it works against any of your profiles’ endpoints and the machine0 API itself, so treat processes you run on the VM accordingly.
Use them to point any third-party tool at the profile’s MCP gateway without hardcoding the URL or minting a separate key — for example an MCP client config that takes a url plus an x-api-key header. If you set either name yourself with machine0 env set, machine0 injects neither and your values win — this affects only these two env vars; the key is still injected into ~/.machine0/auth-token and any connected agent configs. Like all injected credentials, the values refresh on profiles deploy or resume — they are not updated live on a running VM, and the same applies after rotating the key (machine0 integrations connect machine0-cli): redeploy or resume each profiled VM to pick up the new one. Like your own secret variables, the injected values live in the VM’s standard env files (on Ubuntu, /etc/environment and /etc/profile.d/ are readable by every user on the VM) — machine0 VMs are single-user machines, but factor this in before running untrusted multi-user workloads on a profiled VM. These land in the same places as your own variables: login shells and SSH sessions see them automatically. Systemd units don’t read those files — point service definitions at EnvironmentFile=/etc/environment (Ubuntu) or EnvironmentFile=/home/<user>/.ssh/environment (NixOS; that file is plain KEY=value lines).

​
MCP gateway

Each profile aggregates its MCP integrations and prompts behind a single endpoint:
You can use it independently of machine0 VMs with any MCP-compatible client. It supports both OAuth and API key authentication (via the x-api-key header). The gateway also gives you control over what upstream servers expose:
  • Prefixing: newly added integrations expose every tool and prompt prefixed with their integration name — an integration named sentry serves sentry_<name> — so each server’s tools are namespaced. integrations update sentry --prefix s_ -p production changes it; --prefix "" removes prefixing. Integrations added before this default are unchanged: any prefix you set still applies, and unprefixed ones keep serving the server’s original names until you set a prefix.
  • Tool whitelist: --tool-whitelist list,get serves only the tools whose names start with one of the entries. Entries match the server’s original names, before any prefix is applied.

​
Commands

See the CLI reference: profiles, integrations, env, prompts.