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 <account>, vercel --scope <account>, export AWS_PROFILE=<account>).

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. 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; the per-project picker is 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 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 calls getDeployProfileForProject(session.projectId); if the project has a profile, 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, 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 for the full route list.

Related

• 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 — the Add Project flow, which offers the same picker in its footer
• switching-providers.md — a different "which account/service does the AI use" concept (session providers, not deploy targets)
• cli-control.md — the CLI control server, including PATCH /project/:id for setting a project's deploy profile