Summary
Add an option to the agentuity deploy command that creates a new deployment without replacing/promoting it over the current active (production) deployment.
Motivation
Today, agentuity deploy pushes a build and makes it the active deployment. There's no first-class way to ship a deployment that exists alongside production without taking over live traffic. This is useful for:
- Validating a build in the cloud (real runtime, real resources) before promoting it.
- Staging/preview deployments that shouldn't affect the live domain.
- Safer rollouts — deploy first, promote as a separate, deliberate step.
Proposed solution
Add a flag to agentuity deploy, e.g.:
agentuity deploy --no-activate # deploy but keep the current active deployment serving traffic
# or equivalently: --no-promote / --inactive
When set, the CLI uploads and provisions the deployment but leaves the currently active deployment in place. The new deployment would then be promotable via a follow-up command (e.g. an existing/future agentuity deploy promote <id> or dashboard action).
Alternatives considered
Notes
Filed from the theagentcompany project. Happy to refine the flag name / UX to match CLI conventions.
Summary
Add an option to the
agentuity deploycommand that creates a new deployment without replacing/promoting it over the current active (production) deployment.Motivation
Today,
agentuity deploypushes a build and makes it the active deployment. There's no first-class way to ship a deployment that exists alongside production without taking over live traffic. This is useful for:Proposed solution
Add a flag to
agentuity deploy, e.g.:When set, the CLI uploads and provisions the deployment but leaves the currently active deployment in place. The new deployment would then be promotable via a follow-up command (e.g. an existing/future
agentuity deploy promote <id>or dashboard action).Alternatives considered
Notes
Filed from the
theagentcompanyproject. Happy to refine the flag name / UX to match CLI conventions.