Deployments
A deployment is one of your built applications running on real infrastructure. Forginate plans the deployment with AI, asks you to approve the plan, executes it on a deploy target, and then keeps watching it — health, logs, metrics, and uptime — from the Deploy screen.
Creating a deployment
From the Deploy screen, create a deployment for a project and pick the target it should run on. The deployment starts in Planning: an AI pass reads the project and produces a concrete deployment plan for that target — what to run, how it's exposed, and how it's configured.
When the plan is ready the deployment sits in Awaiting approval. Review the plan, then:
- Approve — execution begins (status moves to Deploying).
- Replan — send it back to Planning for a fresh AI plan, for example after you've changed the instructions.
You can attach instructions to a deployment — free-text guidance the planner honors (ports, env expectations, scaling preferences) — and edit them later.
The deployment lifecycle
Planning → Awaiting approval → Deploying → Running
│
Stopping → Stopped ───┤ (resume → Deploying → Running)
Upgrading ────────────┤
Tearing down → Torn down (terminal)
Failed / Suspended| Status | Meaning |
|---|---|
| Planning | AI is producing the deployment plan |
| Awaiting approval | Plan ready — waiting for you |
| Deploying | Executing the plan on the target |
| Running | Live and healthy |
| Stopping / Stopped | Scaled to zero; resume any time |
| Upgrading | Rolling out a new version |
| Tearing down / Torn down | Workloads being removed / removed (terminal) |
| Failed | A transition failed — see the error and events on the detail page |
| Suspended | Paused by the platform (for example, billing issues) |
Stop is always available
Whatever state a deployment is in, Stop works. It scales the workload to zero so nothing runs (and on AWS, nothing accrues compute cost) without destroying anything. Start again later to bring it back.
Day-2 operations
The deployment detail page gives you:
- Events and incidents — a timeline of everything that's happened to the deployment, including detected incidents.
- Logs — request the app's recent logs on demand (from your cluster via the agent, or from CloudWatch for AWS deployments).
- Metrics — CPU and memory over a selectable window.
- Uptime — external health-probe history with status and latency per check.
- Scale — change the replica count. Scaling to zero is equivalent to stopping; scaling a stopped deployment up restarts it.
- Refresh status — force an immediate status re-check.
Upgrades
When a new version of your product is delivered (for example after an improvement request merges), the deployment can roll it out — status Upgrading, then back to Running. You can enable auto-upgrade on a deployment so merged changes roll out without a manual step, or leave it off and trigger upgrades yourself.
Ending a deployment
Two terminal paths, deliberately different:
- Teardown — removes the workloads from the target. The app stops existing there. Terminal.
- Separate — leaves the app running but removes Forginate's management assets from it. Use this when you're taking over operations yourself: the software keeps serving traffic, Forginate just stops managing it. Also terminal.
A torn-down or separated deployment's record can then be deleted from the list.
Terminal means terminal
Neither teardown nor separate can be undone from Forginate's side. To run the app under Forginate again afterwards, create a new deployment.
Permissions
Any org member can view deployments; creating, approving, stopping, scaling, and tearing down require owner or admin in the organization.
Next
- Deploy targets — setting up where deployments run.