---
title: "Your first deploy"
canonical: "https://admiral.io/docs/get-started/first-deploy"
description: "Deploy your first workload with Admiral: define a component in dev, stage it in a changeset, apply it through your Kubernetes agent, and watch it go live."
---

# Your first deploy

{/*
  OUTLINE / DRAFT. Step 3 = AHA 0: a real deployment happened through Admiral and it
  is live. Keep this step as short as possible to the live result. Concepts: Component
  (workload kind), Changeset, Change, Run (plan+apply), Revision.
  */}

This is the payoff: you define a workload component in `dev`, stage it in a changeset, apply it, and see it running in your cluster. This deploys through your Kubernetes agent from [step 1](https://admiral.io/docs/get-started/connect-a-cluster.md).

## 1. Add a workload component [#1-add-a-workload-component]

A [Component](https://admiral.io/docs/concepts/applications-and-components.md) of kind `workload` deploys via the Kubernetes agent. You add it as a [Change](https://admiral.io/docs/concepts/changesets-and-runs.md) inside a changeset; you never edit an environment directly.

<Steps>
  ### Open a changeset [#open-a-changeset]

  <Tabs items="[&#x22;CLI&#x22;, &#x22;Web&#x22;]">
    ### CLI

```bash
      admiral changeset create --env demo/dev --name add-podinfo
      ```
    
### Web

In the `dev` environment, choose **New changeset** and name it `add-podinfo`.
    

### Stage a change that creates the component [#stage-a-change-that-creates-the-component]

  <Tabs items="[&#x22;CLI&#x22;, &#x22;Web&#x22;]">
    ### CLI

```bash
      # TODO: confirm flags - source/engine/path + target agent + values.
      admiral changeset add-change <changeset> \
--name web \
--kind workload \
--source podinfo \
--engine helm \
--target admiral-demo
      ```
    
### Web

1. Add a change to the changeset.
      2. Choose the `podinfo` source, engine **helm**, kind **workload**.
      3. Bind it to the `admiral-demo` Kubernetes agent.
    

</Steps>

## 2. Plan, review, apply [#2-plan-review-apply]

A [Run](https://admiral.io/docs/concepts/changesets-and-runs.md) has two phases. Plan first, review what will happen, then apply at the single approval gate.

<Tabs items="[&#x22;CLI&#x22;, &#x22;Web&#x22;]">
  ### CLI

```bash
    admiral changeset plan  <changeset>
    admiral changeset apply <changeset>
    ```
  
### Web

Click **Plan**, review the planned change, then **Apply**.
  

## 3. See it live [#3-see-it-live]

<Tabs items="[&#x22;CLI&#x22;, &#x22;Web&#x22;]">
  ### CLI

```bash
    kubectl get pods --context kind-admiral-demo
    # TODO: admiral-side view of the resulting Revision / run status
    admiral run get <run>
    ```
  
### Web

The environment shows the component as deployed, with its [Revision](https://admiral.io/docs/concepts/changesets-and-runs.md#revision) and run logs.
  

{/* TODO: if podinfo exposes a UI/port, show a port-forward so the user SEES a live
   result (stronger aha than "pod is Running"). */}

> **Note:** You just ran a real deployment through Admiral. The next step shows the part competitors do badly: wiring one component's output into another.

## Next [#next]

- [4. Wire infrastructure](https://admiral.io/docs/get-started/wire-infrastructure.md): Add an infra component and feed its output to this workload