# Deploy targets
Source: https://docs.infraista.com/en/developer-tools/pipelines/deploy-targets



A **deploy target** is somewhere your pipelines deploy to or push images to. Targets are shared by every
pipeline in the organization, and a pipeline names them in its file (`target: web-servers`). Open
**Pipelines** > **Targets** to see them all.

<Shot name="developer-tools/pipelines/targets" alt="The Deploy targets page with Infraista resources, an SSH server, the built-in Container Registry and cloud accounts" />

Adding a target needs permission to manage Pipelines.

## Infraista resources [#infraista-resources]

Your instances, Kubernetes clusters and buckets are already targets, with **no keys needed**: each job
gets access made for it, to the one resource it names, valid only while it runs. Production deploys
still need the approvals set in the pipeline's
[environments](/en/developer-tools/pipelines/environments-and-deployments), and pull requests from
forks never get access.

```yaml
- uses: infraista/deploy-kubernetes@v1
  with:
    cluster: production
    manifests: k8s/
    deployment: web       # wait for this rollout to finish

- uses: infraista/sync-object-storage@v1
  with:
    bucket: northwind-assets
    path: dist
    delete: true
```

## SSH servers [#ssh-servers]

Any Linux server that accepts SSH from the internet.

1. Open **Targets** and select **Add target** > **SSH server**.
2. Enter a **Target name**, the **Host or IP address**, **Port** and **User**. Use a dedicated user
   (for example `deploy`) with only the rights your deploy needs.
3. Choose **Generate a new key pair** (ED25519) or **Use my own private key** (OpenSSH or PEM, without a
   passphrase). The private key is stored encrypted and never shown again.
4. Add the public key it shows to `~/.ssh/authorized_keys` of that user on the server.
5. Compare the host key fingerprint with the one on your server and confirm it. The host key is
   pinned: if it ever changes, deploys stop until you re-read and pin the new one.
6. Select **Save and test**.

<Shot name="developer-tools/pipelines/new-target" alt="Add a deploy target, with the choice of Infraista resource, SSH server, deploy agent, container registry or cloud account" />

```yaml
- uses: infraista/deploy-ssh@v1
  with:
    target: web-servers
    registry: infraista            # sign the server in to your Container Registry first
    script: |
      cd /srv/web-app
      docker compose pull && docker compose up -d
```

To run containers without writing a script, use `infraista/deploy-docker` (see the
[file reference](/en/developer-tools/pipelines/pipeline-file-reference#containers-on-a-server-deploy-docker)).

When you remove an SSH target, its private key is deleted; remove the public key from the server's
`authorized_keys` yourself.

## Deploy agents [#deploy-agents]

For servers Infraista can't reach: on a private network, behind NAT, or with no inbound SSH. A small
agent on the server keeps an outbound HTTPS connection (port 443) to Infraista and runs deploy tasks.
No ports to open, no VPN, no public IP.

1. Select **Add target** > **Deploy agent**, name it and select **Create install command**.

2. Run the command on the server as root:

   ```bash
   curl -fsSL https://api.infraista.com/install/deploy-agent | sudo bash -s -- pdt_…
   ```

3. Wait for **Agent connected**, then save.

* The token in the command is shown only once. Making a new install command stops the old token.
* Scripts run as a new user, `infraista-deploy`. Give it what your deploys need (for example
  `usermod -aG docker infraista-deploy`), or add `root` at the end of the command to run them as root.
* Re-running the install command later upgrades the agent.

```yaml
- uses: infraista/deploy-agent@v1
  with:
    target: office-server
    script: ./deploy.sh
```

## Container registries [#container-registries]

Your [Container Registry](/en/developer-tools/container-registry) is built in: push and pull with
`registry: infraista`, and each job gets its own short-lived login. Nothing to set up.

For other registries (Docker Hub, GitHub Container Registry, GitLab Container Registry, or any Docker
Registry v2), select **Add target** > **Container registry** and enter the registry host, username and a
token with push and pull rights. Build steps then push there with `registry: <name>`, with no secrets
in each pipeline. Rotate the token by editing the target.

## Cloud accounts [#cloud-accounts]

**Cloud accounts** let `infraista/cloud-login` get short-lived cloud credentials for a job through
OIDC, with no stored keys. You set up trust once on the cloud's side; the console shows the issuer,
audience and subject to use, and the subject names the pipeline and environment, so only the ones you
allow can sign in. Select **Verify** to check the connection.

```yaml
- uses: infraista/cloud-login@v1
  with:
    target: production-cloud
- run: ./deploy-infra.sh
```

## Test, edit and remove [#test-edit-and-remove]

Each target shows its status (**Connected**, **Failing**, **Not tested**, or **Online** and
**Offline** for agents), which pipelines use it and when it was last used. Use **Verify connection**
to test it again. Removing a target that pipelines use makes their deploy steps fail until it's added
again.

## Related [#related]

* [Pipeline file reference](/en/developer-tools/pipelines/pipeline-file-reference)
* [Environments and deployments](/en/developer-tools/pipelines/environments-and-deployments)
* [Container Registry](/en/developer-tools/container-registry)