# Deploy an Artifact

You can deploy both containers and binaries with the Chassy platform. This guide contains instructions for both.

This guide assumes you have created a fleet. If you have not created one, it is recommended you read the [Fleet User Guide](/user-guides/fleet-user-guide.md) first.

If you're unfamiliar with Chassy Workflows, then starting with the [Workflow User Guide](/user-guides/workflow-user-guide.md) is a good resource.

## Create a new Workflow

{% tabs %}
{% tab title="Docker" %}

1. Go to the *Workflows* section and select create a new workflow. We can name it “Deploy Docker to fleet”.
2. We assume a fleet has already been created prior, so we will simply select “*Test Fleet*”.
3. Click “*Create Workflow*” to move onto the next step.
   {% endtab %}

{% tab title="Binary" %}

1. Go to the *Workflows* section and select create a new workflow. We can name it “Deploy Binary to fleet”.
2. We assume a fleet has already been created prior, so we will simply select “*Test Fleet*”.
3. Click “*Create Workflow*” to move onto the next step.
   {% endtab %}
   {% endtabs %}

## Add “Import Package” Task

{% hint style="info" %}
For this specific example, we will be importing from a Github Actions Workflow container. A full list of sources and docker registries we support can be found in the [Steps](/reference/workflow-components/steps.md#import-package)section of the Steps Reference Guide.
{% endhint %}

{% tabs %}
{% tab title="Docker" %}

1. There will be an empty unconfigured step called “*Step 1*” present. Select it and rename it to “Retrieve Docker Artifact”. Under the details menu, select “*Import Package*”. For the timeout, select a reasonable timeout for the download, such as 600 seconds. 
2. Under configuration, for *artifact name* enter the artifact name that is stated in the Github Actions (GHA) job. We will assume it’s gha\_docker for this example.
3. For Source, select "*Github Actions Workflow*". We assume that a certain GHA such as creating a release branch will trigger the generation of a docker container, and we’re retrieving that artifact. 
4. For Type, select “*Container*”.
5. Name the package name “application\_docker\_contaner”. 
6. For versioning, we will auto increment the minor release and thus select that option.
   {% endtab %}

{% tab title="Binary" %}

1. There will be an empty unconfigured step called “*Step 1*” present. Select it and rename it to “Retrieve Binary Artifact”. Under the details menu, select “*Import Package*”. For the timeout, select a reasonable timeout for the download, such as 600 seconds. 
2. Under configuration, for *artifact name* enter the artifact name that is stated in the Github Actions (GHA) job. We will assume it’s gha\_binary for this example.
3. For Source, select "*Github Actions Workflow*". We assume that a certain GHA such as creating a release branch will trigger the generation of a binary, and we’re retrieving that artifact. 
4. For Type, select “*Binary*”.
5. Name the package name “application\_binary”. 
6. For versioning, we will auto increment the minor release and thus select that option.
   {% endtab %}
   {% endtabs %}

## Add “Release” Task

{% tabs %}
{% tab title="Docker" %}

1. Locate the icon of the “Retrieve Docker Artifact” task icon in the workflow graph (this was created in the previous step). Hover your mouse over it and click the + icon. This will create a new task that depends on the “Retrieve Docker Artifact” task.
2. Under the details menu, select “*Release*” as the *Type*. Name this to be “Configure Release”. Set a reasonable value for the timeout, such as 300s.  You will observe that the “Retrieve Docker Artifact” task is already listed as a dependency on the “*depends on*” field. 
3. In the Configuration menu, under *Release Name*, enter a descriptive name for the release we’re about to create. We’ll call it “application\_docker\_release”.
4. We need to select the target chip this release will target. We assume that fleets and chips have already been previously defined, so we will simply select “x86\_ubuntu24.04\_LTS”. 
5. Under *Manifest*, we will now add fields to our release manifest. The rule of thumb is to add one manifest entry for each package. Since we only have one docker container to deploy, we only need one field. In the future if we have multiple packages to release, we can click the “*Add another package*” option to add another package entry. Under package name, we can use the same name we chose in the “Retrieve Docker Artifact”’s package name task, “application\_docker\_container”.
6. For the package version, we will simply use the latest. 
   {% endtab %}

{% tab title="Binary" %}

1. Locate the icon of the “Retrieve Binary Artifact” task icon in the workflow graph (this was created in the previous step). Hover your mouse over it and click the + icon. This will create a new task that depends on the “Retrieve Binary Artifact” task.
2. Under the details menu, select “*Release*” as the *Type*. Name this to be “Configure Release”. Set a reasonable value for the timeout, such as 300s.  You will observe that the “Retrieve Binary Artifact” task is already listed as a dependency on the “depends on” field. 
3. In the Configuration menu, under *Release Name*, enter a descriptive name for the release we’re about to create. We’ll call it “application\_binary\_release”.
4. We need to select the target chip this release will target. We assume that fleets and chips have already been previously defined, so we will simply select “x86\_ubuntu24.04\_LTS”. 
5. Under *Manifest*, we will now add fields to our release manifest. The rule of thumb is to add one manifest entry for each package. Since we only have one binary to deploy, we only need one field. In the future if we have multiple packages to release, we can click the “*Add another package*” option to add another package entry. Under package name, we can use the same name we chose in the “Retrieve Binary Artifact”’s package name task, “application\_binary”.
6. For the package version, we will simply use the latest. 
   {% endtab %}
   {% endtabs %}

## Add “Deploy” Task 

{% tabs %}
{% tab title="Docker" %}

1. Locate the icon of the “Configure Release” task icon in the workflow graph (this was created in the previous step). Hover your mouse over it and click the + icon. This will create a new task that depends on the “Configure Release” task.
2. Under the details menu, select “*Deploy*” as the *Type*. Name this to be “Deploy Container”. Set a reasonable value for the timeout, such as 300s.  You will observe that the “Configure Release” task is already listed as a dependency on the “depends on” field. 
3. Under *Fleet*, select the fleet to target. Since we already have a preconfigured fleet, we select “Test Fleet San Francisco”. 
4. Under “*Release*”, enter  “application\_docker\_release” from the field above. 
5. Under *Type*, we will select “Testbed”. 
6. Under *Count*, we select “All” to release to the whole fleet.
7. Under *Attributes*, we append some important information about what we’re deploying to. Under *OS Name*, we state Ubuntu Base. Under *OS Version*, we state 24.04. We leave *IP address* blank and enter the machine’s hostname “bot01”. 
   {% endtab %}

{% tab title="Binary" %}

1. Locate the icon of the “Configure Release” task icon in the workflow graph (this was created in the previous step). Hover your mouse over it and click the + icon. This will create a new task that depends on the “Configure Release” task.
2. Under the details menu, select “*Deploy*” as the *Type*. Name this to be “Deploy Binary”. Set a reasonable value for the timeout, such as 300s.  You will observe that the “Configure Release” task is already listed as a dependency on the “depends on” field. 
3. Under *Fleet*, select the fleet to target. Since we already have a preconfigured fleet, we select “Test Fleet San Francisco”. 
4. Under “*Release*”, enter  “application\_binary\_release” from the field above. 
5. Under *Type*, we will select “Testbed”. 
6. Under *Count*, we select “All” to release to the whole fleet.
7. Under *Attributes*, we append some important information about what we’re deploying to. Under *OS Name*, we state Ubuntu Base. Under *OS Version*, we state 24.04. We leave *IP address* blank and enter the machine’s hostname “bot01”. 
   {% endtab %}
   {% endtabs %}

## Complete and Run the Workflow

1. On the top right of the workflow graph, select *Create workflow*. This will create the workflow and you can see it newly created in the *Workflows* tab as well as its status.
2. Next we will need to hook it up to a Github action so it will run automatically. 


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.chassy.io/tutorials/deploy-an-artifact.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.