Skip to main content

Deploy your project

A project needs one successful deploy before its chat sessions can start. Importing a repository starts that first deploy for you. The deploy agent reads your repository, writes the settings that run it and starts your app in a sandbox. When the Deploy Chat shows Deployed, the project is live and ready for sessions.

Before you deploy​

Workspace Deploys use workspace Credentials only, including recovery Deploys. An admin connects them in Settings > your workspace > AI Providers. Your Subscriptions and Sensei free cannot run a workspace Deploy. If usable Credentials are missing, the first Deploy waits for the workspace credential problem to be fixed.

With no stored deploy model, a deploy takes the first connected provider in catalog order and its catalog default model. Every released provider is supported. GLM, Kimi and DeepSeek run in Claude Code, and Grok runs in Grok Build. Deploys on these four are less reliable than on Claude or GPT. While one of them is the deploy model, the Deploy Chat shows a warning above its composer, such as "Deploys on Kimi are less reliable than on Claude or GPT. For the most reliable deploys, connect Anthropic or OpenAI." The deploy still runs. To leave them, connect Claude or Codex and pick a Claude or GPT model in the Deploy Chat header.

Personal-project Deploys use the personal space owner's Deploy model setting. Choose a model from any released provider on the owner's Subscriptions, including Gemini on their Antigravity sign-in. Without a Subscription, choose Auto - Free, shown as Auto - Sensei free once selected. With no stored model, Sensei takes the first connected provider in catalog order and its catalog default model. Whoever starts the Deploy changes nothing. When one of the owner's accounts reaches its limit, the Deploy continues on the owner's next account of the same provider.

A choice that cannot run stops the Deploy with a notice naming the problem and the setting. Limits, reconnects and provider failures never move Subscription work to Free. Connecting the first Subscription moves a Free Deploy to that provider's catalog default model from its next turn; removing the last moves its choice to Free. A running turn keeps its source. Free Deploys work like a personal Subscription, within the Free allowance and staff maximum Turn Level. Each uses one Source. Sensei moves it automatically if that Source reaches its limit, is paused or is removed. The model, Source and provider stay hidden. A member-started Free run spends one prompt from the owner's shared allowance. A Recovery Deploy follows the same credential rule and stays uncharged. See AI providers.

When a workspace has no usable Credentials, the import's first deploy does not start. It waits for the workspace credential problem to be fixed. Sensei draws a card about it in your thread "Deploys of storefront", with a link to the Deploy Chat. When an admin connects workspace Credentials, press Deploy in the Deploy Chat, and a receipt says "storefront's first Deploy started."

A deploy runs in a sandbox, so it uses the workspace's credits like any other work. Rates are on Plans and billing.

Follow the first deploy​

  1. Import the repository. See Import a repository. Sensei starts the first deploy, as you, and you stay where you were. Click the project in the sidebar to open its settings. The Deploy Chat on the left shows the deploy running.
  2. Watch the phases in the Deploy Chat. Answer the agent if it asks you something.
  3. Wait for the pill that reads "Deployed: Your project is live."

To give the agent instructions, such as the command that starts the app, send them in the Deploy Chat. You can attach files too.

To open the settings later, click the project in the sidebar. An App keeps its chat on its page, so press Settings (the gear) in its header.

The settings view of a project after its first deploy. On the left, the Deploy Chat under a header reading Deploy and the model, "Anthropic - Opus 5.5 (xHigh)". It holds the message "deploy my project", the phases Creating sandbox, Starting services and Promoting the new sandbox, the line "Deployed successfully from the saved configuration.", then "Warming 2 more sandboxes" and a "Deployed: Your project is live." pill above the composer. On the right, the Project settings panel open on its Sandbox section, with four sandbox tiers, the host setup script and a Redeploy button.

What the deploy agent does​

The agent reads the repository and works out what has to run, such as apps, workers and databases. It writes their start commands, ports, environment variables and setup scripts into the project settings. Sensei then boots a sandbox from those settings, checks that the services are healthy and makes that sandbox the project's main sandbox.

The agent also picks the project's sandbox tier. Project settings explains tiers.

Creating sandbox, Starting services, Promoting the new sandbox and Warming N more sandboxes show as lines in the Deploy Chat. While the agent works or asks you something, the chat shows its messages or its question.

PhaseWhat is happening
Creating sandboxSensei creates a sandbox for the project.
Starting servicesThe services start, and Sensei waits for them to become healthy.
Agent workingThe deploy agent sets up and checks the project.
Awaiting your inputThe agent has a question for you.
Promoting the new sandboxSensei runs final checks and makes the new sandbox the project's main sandbox.
Warming N more sandboxesSensei starts spare sandboxes so new chat sessions open without waiting. They count as Warm-up usage.
UpdatingThe deploy agent is working on the project's main sandbox.

The sidebar shows the same state on the project's row. It reads Setup before the first deploy and shows a spinner while one runs. During the first deploy, the spinner carries its step, such as 2/4. A yellow dot means the agent is waiting for you. A red dot means the deploy failed.

Answer the deploy agent​

The agent deploys on its own as far as it can. It turns on the optional services the app needs and leaves the rest off. It generates the secrets it can make, such as session secrets and signing keys, and runs databases, caches and queues itself. For a third-party key it uses the provider's test mode, a mock, or turns the feature off, whichever lets the app start. It asks only when the app cannot start at all without a value only you have, such as a production API key with no test mode.

Then it pauses and asks once in the Deploy Chat, for every such value together. Its question names each variable and says in one line why the app needs it. The composer then reads "Answer the deploy agent...". Reply there, and the deploy continues. Every member who can open the project sees the same Deploy Chat and can answer. The sidebar shows a yellow dot on the project's row while the deploy waits.

Messages you send while the agent works wait Up next and start the next turn. On an Anthropic deploy model you can steer a waiting message into the running turn. A message you send before the sandbox is ready joins the agent's first turn as instructions. Messages, Up next and steering has the full rules.

To end a running deploy, press Stop in the composer.

Save secrets from Sensei​

When the agent does ask, with Sensei the member who imported the project gets a card for it in the thread "Deploys of storefront", such as "storefront needs 2 secrets to start its services". So does the member who started the deploy, when that is someone else. The card has a field for each variable.

ButtonWhat it does
Save and continueSaves the values as the project's environment variables, encrypted like any other, and resumes the deploy with them. A field you leave empty is not saved
Deploy without themResumes the deploy with none of the values
Open Deploy ChatOpens the Deploy Chat, to answer there

Save and continue and Deploy without them work only while the deploy still waits on that same question, and while the workspace is within its credit limit. A value you save this way stays. The deploy agent does not delete or overwrite it when the deploy ends.

Sensei draws this card from the deploy's event. The values you fill in go straight to the Deploy, so no Sensei turn sees them. You can also answer in the Deploy Chat.

Choose the deploy model​

The model pickers in Project settings and the Deploy Chat header list every released provider: Claude, Codex, Gemini, Muse, GLM, Kimi and DeepSeek. In a workspace project, only workspace Credentials run the Deploy; a provider they cannot run shows Needs auth. In a personal project, the owner's Subscriptions run it, or Auto - Free appears when the owner holds none. With no stored model, Sensei takes the first connected provider in catalog order and its catalog default model.

The choice is saved for the project. You can change it between deploys. When you switch provider, the next turn starts on the new model, and Sensei hands it the conversation so far as text. Models explains providers and reasoning effort.

Edit the settings yourself​

Before the first deploy, the settings panel is locked, because the agent writes it. Press Edit manually to unlock it. The next deploy starts from what you save there, such as a service or an environment variable.

Redeploy​

After the first deploy, the Deploy Chat's message box shows Redeploy, beside its other controls. Press it after you change settings, or when the Deploy Chat reads "Press Redeploy to rebuild the deployment...". That line means the project's main sandbox is gone.

A redeploy first tries to start the saved settings without the agent. This is the Unattended Boot.

  • If it works, the Deploy Chat reads "Deployed successfully from the saved configuration."
  • If it fails, it reads "Automatic deploy failed. Starting the deploy agent to diagnose and fix." The agent takes over and may change the settings to make the project start.

Once the project is deployed, you can also message the deploy agent. Ask it to inspect the deployment or change it, for example to add a service.

When a deploy fails​

A failed deploy shows the reason, then a "Deploy failed" pill with a Retry Deploy button. A failed first deploy gets one Recovery Deploy first. See Recovery Deploys.

  1. Open the Logs tab in the settings panel. Pick Full logs, Setup or one service.
  2. Find the error.
  3. Tell the deploy agent what you found in the Deploy Chat. Or fix the setting yourself and press Retry Deploy.

Recovery Deploys​

Sensei starts a deploy on its own in four cases. This is a Recovery Deploy.

  • The project's first deploy failed. Sensei starts one Recovery Deploy of it, and a receipt in your Sensei thread tells you while it runs. If it fails too, Sensei can draw a card in the thread with what failed and the fix the deploy agent proposes. Its Approve asks Sensei to retry the deploy with that fix, and a link opens the Deploy Chat. Sensei starts at most one per attempt. Your next deploy is a new attempt.
  • The main sandbox failed to run new commits on the branch sessions start from. The Deploy Chat names the commit and says it is "starting an automatic recovery deploy."
  • The main sandbox was lost.
  • Sensei released a platform update.

Recovery Deploys follow the same credential rule as the deploy they recover: workspace Credentials only in a workspace project, the owner's stored Deploy choice in a personal project. They never borrow another member's Subscription, never switch source and spend no prompt. Recovery Deploys show in the Deploy Chat. You answer them there like any other deploy.

Deploys and sessions​

  • Sessions start only after the first deploy lands. Until then, the New Session dialog cannot start one, but Backlog works at once. With Sensei, ask it to start a session, and it files the session to the Backlog and starts it by itself when the deploy lands. If that start is refused, an event is written in the session's thread, and Sensei can draw a card there whose Approve starts it. See Sensei. While the first deploy runs, the dialog says how far it is, such as "storefront is on its first Deploy, step 2 of 4. Sessions start when it lands. Add this to the Backlog now and start it then." The four steps are Cloning, Agent working, Starting services and Health check.
  • When the first deploy lands, a receipt in your Sensei thread tells you, such as "storefront is deployed. 3 services are up." It sends no notification. When the agent stood in for values or turned features off, one line under it says so, such as "3 values stubbed, Stripe checkout off. Add real keys in project settings." Replace them in project settings and redeploy.
  • After that, while a deploy runs, you can only add sessions to the Backlog. Start them once the deploy ends.

Limits​

  • GLM-5.3 reads text only. While the deploy model is GLM-5.3, the Deploy Chat takes no images or PDFs.
  • While the deploy model is DeepSeek, the Deploy Chat takes no PDFs.
  • The deploy model cannot change while a deploy runs.

Next steps​