--- title: Deploy Profiles --- # Deploy Profiles ## What it is A **deploy profile** is a named, reusable bundle of "which account to use for which service when deploying." You create a profile once (e.g. **"Personal Google"** or **"Client Prod"**), list one or more service→account mappings inside it (Google → `you@example.com`, Vercel → `my-team`, …), and then assign that profile to a project. From then on, whenever an AI session spawns for that project, Omniscio injects a short **Deploy Profile** block into the agent's instructions telling it exactly which account to deploy under — so the agent runs `firebase deploy` / `vercel deploy` against the _right_ account instead of guessing (or worse, shipping your client's site to your personal project). Two things it is **not**: it does **not** store any credentials or tokens — only the non-secret identifier (an email, a team slug, or a CLI profile name) you'd type at a login prompt anyway. And it does **not** technically _force_ the agent to switch accounts — it's authoritative _guidance_ injected into the system prompt ("ALWAYS verify you are using the correct account before any deploy operation"). The safety comes from the agent reading and following it, the same way it follows the rest of its instructions. The six services Omniscio knows about are **Google (Firebase / gcloud)**, **Vercel**, **Netlify**, **Render**, **AWS**, and **Other** (a free-text catch-all for anything else — DigitalOcean, Cloudflare, npm publish, etc.). Each has a built-in CLI hint so the injected block reminds the agent _how_ to select the account for that tool (e.g. `firebase login:use `, `vercel --scope `, `export AWS_PROFILE=`). ## Where to find it ### How to use it **Create or edit a profile (Settings):** 1. Open **Settings → Access & Sharing → Deploy Profiles** (the 🚀 Rocket icon — it sits alongside SSH Remotes, CLI Control, and PR Merge Queue). 2. Click **Create new profile** and give it a **name** (this is just a label you'll recognize later — "Personal", "Acme Prod", etc.). 3. For each service you want the profile to cover, pick a **service** from the dropdown and type the **account or profile identifier** — the email, team slug, or CLI profile name you'd use to log in. Click **Add another service** to add more mappings. 4. If you pick **Other**, an extra **Service name** field appears so you can name the service yourself. 5. **Save.** The profile now appears as a card showing its entries and a "Used by …" line listing any projects assigned to it. **Edit** a profile with the pencil icon on its card; **delete** it with the trash icon. If you delete a profile that projects are using, the confirmation names those projects and warns they'll lose the assignment — the projects themselves are never deleted, they just go back to having no profile. **Assign a profile to a project:** 1. Right-click the project → **Edit Project** (or use **Add Project** for a new one). 2. Click **More options →** to reveal the advanced settings. 3. In the **Deploy Profile** picker, choose an existing profile from the dropdown — or use the inline **+ Create new profile…** to make one on the spot. Once assigned, the picker shows the profile with **Change** / **Remove** controls. That's it — the next session you start in that project will carry the deploy guidance automatically. (The picker is hidden for Omniscio's built-in "virtual" projects like Skills or Recipes, since those don't deploy anywhere.) ## How it behaves ### How it works **Profiles are stored in the local database, not in `config.json`.** Migration v125 added two tables plus one column: `deploy_profiles` (`id`, `name`, timestamps), `deploy_profile_entries` (one row per service→account mapping, foreign-keyed to its profile **ON DELETE CASCADE**), and `projects.deploy_profile_id` (the per-project assignment, foreign-keyed **ON DELETE SET NULL** so deleting a profile cleanly un-assigns every project without touching the projects). Queries live in [queries-deploy-profiles.ts](../../src/main/db/queries-deploy-profiles.ts). There is deliberately **no UNIQUE constraint on the profile name** — the create handler does a find-or-create by name so a double-clicked "Save" can't produce two identical profiles. Editing a profile **deletes all its entries and re-inserts them**, so entry ids and `created_at` values are regenerated on every save (only the profile id is stable). **The Settings panel** is [DeployProfileSettings.tsx](../../src/renderer/src/features/settings/sections/deploy-profile/DeployProfileSettings.tsx); the per-project **picker** is [DeployProfilePicker.tsx](../../src/renderer/src/features/projects/DeployProfilePicker.tsx), embedded in the "More options" step of the Edit / Add Project dialogs. Both talk to the main process over five IPC channels defined in `src/shared/ipc-channels/project.ts`: `deploy-profile:list` / `:create` / `:update` / `:delete`, plus `project:set-deploy-profile`. The handlers in [deploy-profile-handlers.ts](../../src/main/ipc/deploy-profile-handlers.ts) validate every request with Zod — a profile **name** is 1–100 chars, it must hold **1–20 entries**, each entry's **service** is 1–50 chars and **account identifier** 1–200 chars, and the UI blocks **duplicate services within one profile** (except `Other`, which you can list several times with different service names). **The consumption path — where a profile actually does something — is session spawn.** When Omniscio spawns a session, [spawn-cluster-manager.ts](../../src/main/process/spawn-cluster-manager.ts) calls `getDeployProfileForProject(session.projectId)`; if the project has a profile, [deploy-profile-prompt.ts](../../src/main/process/deploy-profile-prompt.ts) turns its entries into a `## Deploy Profile` markdown block and appends it to the agent's system prompt via `--append-system-prompt`. Each entry becomes a bullet with the service label, the account identifier, and that service's CLI hint (the hint templates live in `DEPLOY_SERVICES` in [deploy-profile-types.ts](../../src/shared/deploy-profile-types.ts), with `{account}` substituted). If the project has no profile, no flag is added and nothing changes — the whole feature is inert until you assign one. ## For agents ### CLI parity Assigning a profile to a project is reachable over the CLI control server: `project:set-deploy-profile` maps to **`PATCH /project/:id`** (send the profile id, or `null` to clear). Creating, editing, and deleting the _profiles themselves_ are desktop-only (classified `dev-diagnostic` in the CLI-parity manifest — there's no dedicated CLI route for profile CRUD). See [cli-control.md](cli-control.md) for the full route list. ## Related - [edit-a-project.md](edit-a-project.md) — the Edit Project dialog whose **More options** step hosts the Deploy Profile picker (alongside isolation, default model, MCP tools) - [add-a-project.md](add-a-project.md) — the Add Project flow, which offers the same picker in its footer - [switching-providers.md](switching-providers.md) — a different "which account/service does the AI use" concept (session _providers_, not deploy _targets_) - [cli-control.md](cli-control.md) — the CLI control server, including `PATCH /project/:id` for setting a project's deploy profile