Deploy targets
A deploy target is a named destination a project deploys to: a set of hosts reached over SSH, plus the credential used to reach them. Targets live on the project, under Settings → Targets.
Deploy targets are gated behind a workspace feature flag. If you don't see the tab, the feature isn't enabled for your workspace: ask your workspace owner, or get in touch.
What a target holds
| Field | Notes |
|---|---|
| Name | How the target is referred to in the UI and in deploy records |
| Hosts | One or more user@host:port entries. Port defaults to 22 |
| SSH private key | The credential used to reach every host on the target |
| Strategy | replace is the only strategy today; rolling, blue/green, and canary are planned |
| Notify on | Which deploy events raise a notification: deploy_success, deploy_failure, deploy_rollback |
Hostnames accept letters, digits, dots, and dashes only. The value reaches an ssh invocation, so characters that are significant to a shell are rejected outright rather than escaped.
Create a target
Project → Settings → Targets → New target. Give it a name, add at least one host, and paste the SSH private key.
Use Test connection before saving anything that matters. It probes each host with the credential you supplied and reports back per host, which is much faster than discovering a bad key during a deploy.
About the SSH key
The private key is encrypted at rest and never leaves the platform in any response. There is no "show key": the API projects only whether a key is present, and decryption happens exclusively inside the build runtime at deploy time. If you lose your copy, replace it rather than trying to read it back.
Give the key its own account on the target hosts, with only the permissions a deploy needs. It's a workspace-wide blast radius if it's a root key.
Who can manage targets
Target configuration (including reading the host list) is restricted to workspace admins. Host lists are infrastructure detail, and there is no project-level role to scope it more finely yet.
Deploy notifications
A target does not carry its own notification settings. When a deploy fails, use
outbound webhooks to relay the event to a channel your team
watches, or a notify-* step inside the pipeline.
Build failures are emailed automatically to the build's trigger actor and the workspace's owners/admins. See Notifications.
Deleting a target
Deleting removes the target and its stored credential. Past deploy records remain.
See also
- Working with projects: where targets live
- Notifications: groups and channels
- Secrets management: for credentials used inside a build rather than by a target