> ## Documentation Index > Fetch the complete documentation index at: https://docs.machine0.io/llms.txt > Use this file to discover all available pages before exploring further. # Profiles ## 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: ```bash theme={"theme":"css-variables"} machine0 profiles new production --description "Production debugger" machine0 profiles use production # make it the current profile machine0 integrations connect claude-code # pre-authenticate claude-code machine0 integrations connect github # gh + git work on the VM machine0 integrations add sentry --url https://mcp.sentry.dev/mcp # add the sentry MCP machine0 prompts add top-sentry --body "go through the top issues on sentry and ..." machine0 new my-vm --profile production ``` 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](#mcp-gateway) to configure other clients). `profiles deploy` applies a profile to an already-running VM the same way. 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 `vars` commands target your **current profile**: `default` out of the box, or whatever you set with `machine0 profiles use `. Target another profile for a single command with `-p/--profile`, or pin one per project by putting `DEFAULT_PROFILE=` 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 (recommended — bills to your provider API credits) or an account-based OAuth login; see [integrations connect](/cli/integrations#integrations-connect). * **MCP integrations** are remote MCP servers you add by URL; their tools are served through the profile's [MCP gateway](#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. ```bash theme={"theme":"css-variables"} machine0 integrations ls -p production ┌───────────────────────────────────────────────────────────────────────────┐ │ Name Status Type Description │ │ claude-code connected system claude-code authentication │ │ codex connected system codex authentication │ │ github connected system gh cli and git commands │ │ machine0-cli connected system machine0 CLI │ │ linear-mcp connected mcp https://mcp.linear.app/mcp │ │ sentry connected mcp https://mcp.sentry.dev/mcp │ └───────────────────────────────────────────────────────────────────────────┘ ``` Injected credentials are plain files on the VM and travel with [snapshots](/platform/images). 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. ```bash theme={"theme":"css-variables"} machine0 prompts ls -p production ┌─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │ Name Description Body │ │ inventory -- give me a table of all the mcp tools provided by the machine0 MCP, add title, arguments, short description │ │ top-sentry -- give me a list of the top 3 sentry issues today │ └─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘ ``` ### Environment variables Environment variables injected into every VM created with the profile. Use `--secret` for write-only values. ```bash theme={"theme":"css-variables"} machine0 vars set DEV_MODE=true -p production machine0 vars set POSTGRES_URL=... --secret -p production ``` ## MCP gateway Each profile aggregates its MCP integrations and prompts behind a single endpoint: ``` https://app.machine0.io/profiles//mcp ``` 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**: `integrations update sentry --prefix sentry_ -p production` renames every tool and prompt from that server to `sentry_`, avoiding collisions between servers. * **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`](/cli/profiles), [`integrations`](/cli/integrations), [`vars`](/cli/vars), [`prompts`](/cli/prompts).