diff --git a/README.md b/README.md
index ab0061f5..36a6f2d2 100644
--- a/README.md
+++ b/README.md
@@ -94,8 +94,9 @@ There are 2 ways to create Bundles:
1. Inside an OCI registry: `uds create
-o ghcr.io/defenseunicorns/dev`
1. Locally on your filesystem: `uds create `
-> [!NOTE]
-> The `--insecure` flag is necessary when interacting with a local registry, but not from secure, remote registries such as GHCR.
+{{% alert-note %}}
+The `--insecure` flag is necessary when interacting with a local registry, but not from secure, remote registries such as GHCR.
+{{% /alert-note %}}
### Bundle Deploy
@@ -164,8 +165,9 @@ As an example: `uds remove uds-bundle-.tar.zst --packages init,nginx`
### Logs
-> [!NOTE]
-> Only works with `uds deploy` for now, may work for other operations but isn't guaranteed.
+{{% alert-note %}}
+Only works with `uds deploy` for now, may work for other operations but isn't guaranteed.
+{{% /alert-note %}}
The `uds logs` command can be used to view the most recent logs of a bundle operation. Note that depending on your OS temporary directory and file settings, recent logs are purged after a certain amount of time, so this command may return an error if the logs are no longer available.
@@ -186,8 +188,9 @@ UDS CLI supports multi-arch bundles. This means you can push bundles with differ
When deploying a local bundle, the bundle's architecture will be used for comparison against the cluster architecture to ensure compatibility. If deploying a remote bundle, by default the bundle is pulled based on system architecture, which is then checked against the cluster.
-> [!NOTE]
-> It is possible to override the bundle architecture used at validation time by using the `--architecture` / `-a` flag.
+{{% alert-note %}}
+It is possible to override the bundle architecture used at validation time by using the `--architecture` / `-a` flag.
+{{% /alert-note %}}
If, for example, you have a multi-arch remote bundle that you want to deploy from an arm64 machine to an amd64 cluster, the validation with fail because the system arch does not match the cluster arch. However, you can pull the correct bundle version by specifying the arch with the command line architecture flag.
@@ -317,8 +320,9 @@ The naming conventions for deploying duplicate packages are as follows:
1. The duplicate packages must be deployed in different namespaces
1. In order to deploy duplicates of local packages, the `path` field must point to a Zarf package tarball instead of to a folder.
-> [!NOTE]
-> Today the duplicate packages feature is only supported for packages with Helm charts. This is because Helm charts' [namespaces can be overridden](docs/overrides.md#namespace) at deploy time.
+{{% alert-note %}}
+Today the duplicate packages feature is only supported for packages with Helm charts. This is because Helm charts' [namespaces can be overridden](docs/overrides.md#namespace) at deploy time.
+{{% /alert-note %}}
## Zarf Integration
@@ -326,8 +330,9 @@ UDS CLI includes a vendored version of Zarf inside of its binary. To use Zarf, s
## Dev Mode
-> [!NOTE]
-> Dev mode is a BETA feature
+{{% alert-note %}}
+Dev mode is a BETA feature
+{{% /alert-note %}}
Dev mode facilitates faster dev cycles when developing and testing bundles
@@ -350,9 +355,9 @@ The `dev deploy` command performs the following operations:
## Scan
-> [!NOTE]
-> Scan is an ALPHA feature.
-> Trivy is a prerequisite for scanning container images and filesystem for vulnerabilities. You can find more information and installation instructions at [Trivy's official documentation](https://aquasecurity.github.io/trivy).
+{{% alert-note %}}> Scan is an ALPHA feature.
+Trivy is a prerequisite for scanning container images and filesystem for vulnerabilities. You can find more information and installation instructions at [Trivy's official documentation](https://aquasecurity.github.io/trivy).
+{{% /alert-note %}}
The `scan` command is used to scan a Zarf package for vulnerabilities and generate a report. This command is currently in ALPHA.
diff --git a/docs/_index.md b/docs/_index.md
new file mode 100644
index 00000000..634261dc
--- /dev/null
+++ b/docs/_index.md
@@ -0,0 +1,12 @@
+---
+title: Overview
+linkTitle: UDS CLI
+type: docs
+menu:
+ main:
+ weight: 30
+---
+
+The [UDS CLI](https://github.com/defenseunicorns/uds-cli) is the primary interface for users to interact with various components within the UDS landscape. It streamlines the deployment process of mission applications and secure infrastructure, simplifying tasks involved in running mission applications while maintaining regulatory compliance in a unified and efficient manner.
+
+The UDS CLI simplifies deployment by bundling multiple Zarf Packages into a single deployable artifact. This process ensures that UDS Bundles, which encompass infrastructure, platform, and mission applications, can be efficiently deployed within any Mission Hero's system environment. Additionally, the UDS CLI extends its capabilities to Pepr, where multiple Pepr applications are bundled and deployed as a single Pepr Module to support UDS Bundles during runtime.
diff --git a/docs/anatomy.md b/docs/anatomy.md
deleted file mode 100644
index f6f69b97..00000000
--- a/docs/anatomy.md
+++ /dev/null
@@ -1,4 +0,0 @@
-## Bundle Anatomy
-A UDS Bundle is an OCI artifact with the following form:
-
-![](.images/uds-bundle.png)
diff --git a/docs/bundle-anatomy.md b/docs/bundle-anatomy.md
new file mode 100644
index 00000000..140b8e91
--- /dev/null
+++ b/docs/bundle-anatomy.md
@@ -0,0 +1,10 @@
+---
+title: Bundle Anatomy
+type: docs
+weight: 6
+---
+
+## Bunble Anatomy
+A UDS Bundle is an OCI artifact with the following form:
+
+![](https://github.com/defenseunicorns/uds-cli/blob/main/docs/.images/uds-bundle.png?raw=true)
diff --git a/docs/overrides.md b/docs/overrides.md
index 9aaf0e1b..240c17b5 100644
--- a/docs/overrides.md
+++ b/docs/overrides.md
@@ -1,16 +1,10 @@
-# Bundle Overrides
-
+---
+title: Bundle Overrides
+type: docs
+weight: 5
+---
Bundle overrides provide a mechanism to customize Helm charts inside of Zarf packages.
-## Table of Contents
-
-1. [Quickstart](#quickstart)
-1. [Overrides](#variables)
- - [Syntax](#syntax)
- - [Values](#values)
- - [Variables](#variables)
- - [Namespace](#namespace)
-
## Quickstart
Consider the following `zarf.yaml` and `values.yaml` which deploys [podinfo](https://github.com/stefanprodan/podinfo)
@@ -152,6 +146,7 @@ The `value` is the value to set at the `path`. Values can be simple values such
```
#### Bundle Variables as Values
+
Bundle and Zarf variables can be used to set override values by using the syntax `${...}`. For example:
```yaml
# uds-config.yaml
@@ -242,8 +237,9 @@ There are 3 ways to override the `UI_COLOR` variable:
> **:warning: Warning**: Because Helm override variables and Zarf variables share the same --set syntax, be careful with variable names to avoid conflicts.
-> [!NOTE]
-> A variable that is not overridden by any of the methods above and has no default will be ignored.
+{{% alert-note %}}
+A variable that is not overridden by any of the methods above and has no default will be ignored.
+{{% /alert-note %}}
#### Variable Precedence
Variable precedence is as follows:
@@ -255,8 +251,9 @@ Variable precedence is as follows:
#### Variable Types
Variables can be of either type `raw` or `file`. The type will default to raw if not set explicitly.
-> [!WARNING]
-> If a variable is set to accept a file as its value, but is missing the `file` type, then the file will not be processed.
+{{% alert-caution %}}
+If a variable is set to accept a file as its value, but is missing the `file` type, then the file will not be processed.
+{{% /alert-caution %}}
```yaml
kind: UDSBundle
@@ -286,7 +283,7 @@ packages:
If a file path is not absolute, it will be set as relative to the `uds-config.yaml` directory.
-e.g. the following `uds-config.yaml` is in [`src/test/bundles/07-helm-overrides/variable-files/`](../src/test/bundles/07-helm-overrides/variable-files/uds-config.yaml)
+e.g. the following `uds-config.yaml` is in [`src/test/bundles/07-helm-overrides/variable-files/`](https://github.com/defenseunicorns/uds-cli/blob/main/src/test/bundles/07-helm-overrides/uds-config.yaml)
```yaml
variables:
helm-overrides:
@@ -297,10 +294,11 @@ This means when `test.cert` is evaluated it will first be appended to the config
If the file path is already set to the same relative path as the config, then no merging will take place.
-> [!NOTE]
-> UDS CLI does not encrypt or base64 encode any file contents before passing said data to Zarf or Helm.
-> For example, if the file contains a key to be used in a Kubernetes secret, it must be base64 encoded before being ingested by UDS CLI.
+{{% alert-note %}}
+UDS CLI does not encrypt or base64 encode any file contents before passing said data to Zarf or Helm.
+For example, if the file contains a key to be used in a Kubernetes secret, it must be base64 encoded before being ingested by UDS CLI.
+{{% /alert-note %}}
### Namespace
It's also possible to specify a namespace for a packaged Helm chart to be installed in. For example, to deploy the a chart in the `custom-podinfo` namespace, you can specify the `namespace` in the `overrides` block:
diff --git a/docs/quickstart-and-usage.md b/docs/quickstart-and-usage.md
new file mode 100644
index 00000000..4b421330
--- /dev/null
+++ b/docs/quickstart-and-usage.md
@@ -0,0 +1,366 @@
+---
+title: Quickstart and Usage
+type: docs
+weight: 1
+---
+
+## Install
+
+Recommended installation method is with Brew:
+
+```
+brew tap defenseunicorns/tap && brew install uds
+```
+
+UDS CLI Binaries are also included with each [Github Release](https://github.com/defenseunicorns/uds-cli/releases)
+
+## Contributing
+
+Build instructions and contributing docs are located in [CONTRIBUTING.md](https://github.com/defenseunicorns/uds-cli/blob/main/CONTRIBUTING.md).
+
+## Quickstart
+
+The UDS-CLI's flagship feature is deploying multiple, independent Zarf packages. To create a `UDSBundle` of Zarf packages, create a `uds-bundle.yaml` file like so:
+
+```yaml
+kind: UDSBundle
+metadata:
+ name: example
+ description: an example UDS bundle
+ version: 0.0.1
+
+packages:
+ - name: init
+ repository: ghcr.io/defenseunicorns/packages/init
+ ref: v0.33.0
+ optionalComponents:
+ - git-server
+ - name: podinfo
+ repository: ghcr.io/defenseunicorns/uds-cli/podinfo
+ ref: 0.0.1
+```
+
+The above `UDSBundle` deploys the Zarf init package and podinfo.
+
+The packages referenced in `packages` can exist either locally or in an OCI registry. See [here](https://github.com/defenseunicorns/uds-cli/tree/main/src/test/bundles/03-local-and-remote) for an example that deploys both local and remote Zarf packages. More `UDSBundle` examples can be found in the [src/test/bundles](https://github.com/defenseunicorns/uds-cli/tree/main/src/test/bundles) folder.
+
+#### Declarative Syntax
+
+The syntax of a `uds-bundle.yaml` is entirely declarative. As a result, the UDS CLI will not prompt users to deploy optional components in a Zarf package. If you want to deploy an optional Zarf component, it must be specified in the `optionalComponents` key of a particular `package`.
+
+#### First-class UDS Support
+
+When running `deploy`,`inspect`,`remove`, and `pull` commands, UDS CLI contains shorthand for interacting with the Defense Unicorns org on GHCR. Specifically, unless otherwise specified, paths will automatically be expanded to the Defense Unicorns org on GHCR. For example:
+
+- `uds deploy unicorn-bundle:v0.1.0` is equivalent to `uds deploy ghcr.io/defenseunicorns/packages/uds/bundles/unicorn-bundle:v0.1.0`
+
+The bundle matching and expansion is ordered as follows:
+
+1. Local with a `tar.zst` extension
+2. Remote path: `oci://ghcr.io/defenseunicorns/packages/uds/bundles/`
+3. Remote path: `oci://ghcr.io/defenseunicorns/packages/delivery/`
+4. Remote path: `oci://ghcr.io/defenseunicorns/packages/`
+
+That is to say, if the bundle is not local, UDS CLI will check path 2, path 3, etc for the remote bundle artifact. This behavior can be overridden by specifying the full path to the bundle artifact, for example `uds deploy ghcr.io/defenseunicorns/dev/path/dev-bundle:v0.1.0`.
+
+### Bundle Create
+
+Pulls the Zarf packages from the registry and bundles them into an OCI artifact.
+
+There are 2 ways to create Bundles:
+
+1. Inside an OCI registry: `uds create -o ghcr.io/defenseunicorns/dev`
+1. Locally on your filesystem: `uds create `
+
+{{% alert-note %}}
+The `--insecure` flag is necessary when interacting with a local registry, but not from secure, remote registries such as GHCR.
+{{% /alert-note %}}
+
+### Bundle Deploy
+
+Deploys the bundle
+
+There are 2 ways to deploy Bundles:
+
+1. From an OCI registry: `uds deploy ghcr.io/defenseunicorns/dev/:`
+1. From your local filesystem: `uds deploy uds-bundle-.tar.zst`
+
+#### Specifying Packages using `--packages`
+
+By default all the packages in the bundle are deployed, but you can also deploy only certain packages in the bundle by using the `--packages` flag.
+
+As an example: `uds deploy uds-bundle-.tar.zst --packages init,nginx`
+
+#### Resuming Bundle Deploys using `--resume`
+
+By default all the packages in the bundle are deployed, regardless of if they have already been deployed, but you can also choose to only deploy packages that have not already been deployed by using the `--resume` flag
+
+As an example: `uds deploy uds-bundle-.tar.zst --resume`
+
+### Bundle Inspect
+
+Inspect the `uds-bundle.yaml` of a bundle
+
+1. From an OCI registry: `uds inspect oci://ghcr.io/defenseunicorns/dev/:`
+1. From your local filesystem: `uds inspect uds-bundle-.tar.zst`
+
+#### Viewing Images in a Bundle
+
+It is possible to derive images from a `uds-bundle.yaml`. This can be useful for situations where you need to know what images will be bundled before you actually create the bundle. This is accomplished with the `--list-images` flag. For example:
+
+`uds inspect ./uds-bundle.yaml --list-images`
+
+This command will return a list of images derived from the bundle's packages, taking into account optional and required package components.
+
+#### Viewing SBOMs
+
+There are 2 additional flags for the `uds inspect` command you can use to extract and view SBOMs:
+
+- Output the SBOMs as a tar file: `uds inspect ... --sbom`
+- Output SBOMs into a directory as files: `uds inspect ... --sbom --extract`
+
+This functionality will use the `sboms.tar` of the underlying Zarf packages to create new a `bundle-sboms.tar` artifact containing all SBOMs from the Zarf packages in the bundle.
+
+### Bundle Publish
+
+Local bundles can be published to an OCI registry like so:
+`uds publish .tar.zst oci://`
+
+As an example: `uds publish uds-bundle-example-arm64-0.0.1.tar.zst oci://ghcr.io/github_user`
+
+### Bundle Remove
+
+Removes the bundle
+
+There are 2 ways to remove Bundles:
+
+1. From an OCI registry: `uds remove oci://ghcr.io/defenseunicorns/dev/: --confirm`
+1. From your local filesystem: `uds remove uds-bundle-.tar.zst --confirm`
+
+By default all the packages in the bundle are removed, but you can also remove only certain packages in the bundle by using the `--packages` flag.
+
+As an example: `uds remove uds-bundle-.tar.zst --packages init,nginx`
+
+### Logs
+
+{{% alert-note %}}
+Only works with `uds deploy` for now, may work for other operations but isn't guaranteed.
+{{% /alert-note %}}
+
+The `uds logs` command can be used to view the most recent logs of a bundle operation. Note that depending on your OS temporary directory and file settings, recent logs are purged after a certain amount of time, so this command may return an error if the logs are no longer available.
+
+## Bundle Architecture and Multi-Arch Support
+
+There are several ways to specify the architecture of a bundle according to the following precedence:
+
+1. Setting `--architecture` or `-a` flag during `uds ...` operations: `uds create --architecture arm64`
+2. Setting a `UDS_ARCHITECTURE` environment variable
+3. Setting the `options.architecture` key in a `uds-config.yaml`
+4. Setting the `metadata.architecture` key in a `uds-bundle.yaml`
+
+This means that setting the `--architecture` flag takes precedence over all other methods of specifying the architecture.
+
+UDS CLI supports multi-arch bundles. This means you can push bundles with different architectures to the same remote OCI repository, at the same tag. For example, you can push both an `amd64` and `arm64` bundle to `ghcr.io//:0.0.1`.
+
+### Architecture Validation
+
+When deploying a local bundle, the bundle's architecture will be used for comparison against the cluster architecture to ensure compatibility. If deploying a remote bundle, by default the bundle is pulled based on system architecture, which is then checked against the cluster.
+
+{{% alert-note %}}
+It is possible to override the bundle architecture used at validation time by using the `--architecture` / `-a` flag.
+{{% /alert-note %}}
+
+If, for example, you have a multi-arch remote bundle that you want to deploy from an arm64 machine to an amd64 cluster, the validation with fail because the system arch does not match the cluster arch. However, you can pull the correct bundle version by specifying the arch with the command line architecture flag.
+
+e.g.
+`uds deploy -a amd64 --confirm`
+
+## Variables and Configuration
+The UDS CLI can be configured with a `uds-config.yaml` file. This file can be placed in the current working directory or specified with an environment variable called `UDS_CONFIG`. The basic structure of the `uds-config.yaml` is as follows:
+
+```yaml
+options:
+ log_level: debug
+ architecture: arm64
+ no_log_file: false
+ no_progress: false
+ uds_cache: /tmp/uds-cache
+ tmp_dir: /tmp/tmp_dir
+ insecure: false
+ oci_concurrency: 3
+
+shared:
+ domain: uds.dev # shared across all packages in a bundle
+
+variables:
+ my-zarf-package: # name of Zarf package
+ ui_color: green # key is not case sensitive and refers to name of Zarf variable
+ UI_MSG: "Hello Unicorn"
+ hosts: # variables can be complex types such as lists and maps
+ - host: burning.boats
+ paths:
+ - path: "/"
+ pathType: "Prefix"
+```
+
+The `options` key contains UDS CLI options that are not specific to a particular Zarf package. The `variables` key contains variables that are specific to a particular Zarf package. If you want to share insensitive variables across multiple Zarf packages, you can use the `shared` key, where the key is the variable name and the value is the variable value.
+
+### Sharing Variables
+Zarf package variables can be passed between Zarf packages:
+
+```yaml
+kind: UDSBundle
+metadata:
+ name: simple-vars
+ description: show how vars work
+ version: 0.0.1
+
+packages:
+ - name: output-var
+ repository: localhost:888/output-var
+ ref: 0.0.1
+ exports:
+ - name: OUTPUT
+ - name: receive-var
+ repository: localhost:888/receive-var
+ ref: 0.0.1
+ imports:
+ - name: OUTPUT
+ package: output-var
+```
+
+Variables that you want to make available to other packages are in the `export` block of the Zarf package to export a variable from. By default, all exported variables are available to all of the packages in a bundle. To have another package ingest a specific exported variable, like in the case of variable name collisions, use the `imports` key to name both the `variable` and `package` that the variable is exported from, like in the example above.
+
+In the example above, the `OUTPUT` variable is created as part of a Zarf Action in the [output-var](https://github.com/defenseunicorns/uds-cli/tree/main/src/test/packages/no-cluster/output-var) package, and the [receive-var](https://github.com/defenseunicorns/uds-cli/tree/main/src/test/packages/no-cluster/receive-var) package expects a variable called `OUTPUT`.
+
+### Sharing Variables Across Multiple Packages
+
+If a Zarf variable has the same name in multiple packages and you don't want to set it multiple times via the import/export syntax, you can set an environment variable prefixed with `UDS_` and it will be applied to all the Zarf packages in a bundle. For example, if multiple packages require a `DOMAIN` variable, you could set it once with a `UDS_DOMAIN` environment variable and it would be applied to all packages. Note that this can also be done with the `shared` key in the `uds-config.yaml` file.
+
+On deploy, you can also set package variables by using the `--set` flag. If the package name isn't included in the key
+(example: `--set super=true`) the variable will get applied to all of the packages. If the package name is included in the key (example: `--set cool-package.super=true`) the variable will only get applied to that package.
+
+### Variable Precedence and Specificity
+
+In a bundle, variables can come from 4 sources. Those sources and their precedence are shown below in order of least to most specificity:
+
+- Variables declared in a Zarf pkg
+- Variables `import`'ed from a bundle package's `export`
+- Variables configured in the `shared` key in a `uds-config.yaml`
+- Variables configured in the `variables` key in a `uds-config.yaml`
+- Variables set with an environment variable prefixed with `UDS_` (ex. `UDS_OUTPUT`)
+- Variables set using the `--set` flag when running the `uds deploy` command
+
+That is to say, variables set using the `--set` flag take precedence over all other variable sources.
+
+## Duplicate Packages And Naming
+
+It is possible to deploy multiple instances of the same Zarf package in a bundle. For example, the following `uds-bundle.yaml` deploys 3 instances of the [helm-overrides](https://github.com/defenseunicorns/uds-cli/blob/main/src/test/packages/helm/zarf.yaml) Zarf packages:
+
+```yaml
+kind: UDSBundle
+metadata:
+ name: duplicates
+ description: testing a bundle with duplicate packages in specified namespaces
+ version: 0.0.1
+
+packages:
+ - name: helm-overrides
+ repository: localhost:5000/helm-overrides
+ ref: 0.0.1
+ overrides:
+ podinfo-component:
+ unicorn-podinfo: # name of Helm chart
+ namespace: podinfo-ns
+
+ # note the unique name and namespace
+ - name: helm-overrides-duplicate
+ repository: localhost:5000/helm-overrides
+ ref: 0.0.1
+ overrides:
+ podinfo-component:
+ unicorn-podinfo:
+ namespace: another-podinfo-ns
+
+ # note the unique name, namespace and the path to the Zarf package tarball
+ - name: helm-overrides-local-duplicate
+ path: src/test/packages/helm/zarf-package-helm-overrides-arm64-0.0.1.tar.zst
+ ref: 0.0.1
+ overrides:
+ podinfo-component:
+ unicorn-podinfo:
+ namespace: yet-another-podinfo-ns
+```
+
+The naming conventions for deploying duplicate packages are as follows:
+
+1. The `name` field of the package in the `uds-bundle.yaml` must be unique
+1. The duplicate packages must be deployed in different namespaces
+1. In order to deploy duplicates of local packages, the `path` field must point to a Zarf package tarball instead of to a folder.
+
+{{% alert-note %}}
+Today the duplicate packages feature is only supported for packages with Helm charts. This is because Helm charts' [namespaces can be overridden](https://github.com/defenseunicorns/uds-cli/blob/main/docs/overrides.md) at deploy time.
+{{% /alert-note %}}
+
+## Zarf Integration
+
+UDS CLI includes a vendored version of Zarf inside of its binary. To use Zarf, simply run `uds zarf `. For example, to create a Zarf package, run `uds zarf create `, or to use the [airgap tooling](https://docs.zarf.dev/docs/the-zarf-cli/cli-commands/zarf_tools) that Zarf provides, run `uds zarf tools `.
+
+## Dev Mode
+
+{{% alert-note %}}
+Dev mode is a BETA feature
+{{% /alert-note %}}
+
+Dev mode facilitates faster dev cycles when developing and testing bundles
+
+```sh
+uds dev deploy |
+```
+
+The `dev deploy` command performs the following operations:
+
+- Deploys the bundle in [YOLO](https://docs.zarf.dev/faq/#what-is-yolo-mode-and-why-would-i-use-it) mode, eliminating the need to do a `zarf init`
+ - Any `kind: ZarfInitConfig` packages in the bundle will be ignored
+- For local bundles:
+ - For local packages:
+ - Creates the Zarf tarball if one does not already exist or the `--force-create` flag can be used to force the creation of a new Zarf package
+ - The Zarf tarball is created in the same directory as the `zarf.yaml`
+ - The `--flavor` flag can be used to specify what flavor of a package you want to create (example: `--flavor podinfo=upstream` to specify the flavor for the `podinfo` package or `--flavor upstream` to specify the flavor for all the packages in the bundle)
+ - For remote packages:
+ - The `--ref` flag can be used to specify what package ref you want to deploy (example: `--ref podinfo=0.2.0`)
+ - Creates a bundle from the newly created Zarf packages
+
+## Scan
+
+{{% alert-note %}}> Scan is an ALPHA feature.
+Trivy is a prerequisite for scanning container images and filesystem for vulnerabilities. You can find more information and installation instructions at [Trivy's official documentation](https://aquasecurity.github.io/trivy).
+{{% /alert-note %}}
+
+The `scan` command is used to scan a Zarf package for vulnerabilities and generate a report. This command is currently in ALPHA.
+
+### Usage
+
+To use the `scan` command, run:
+
+```sh
+uds scan --org --package-name --tag [options]
+```
+
+### Required Parameters
+
+- `--org` or `-o`: Organization name (default: `defenseunicorns`)
+- `--package-name` or `-n`: Name of the package (e.g., `packages/uds/gitlab-runner`)
+- `--tag` or `-g`: Tag name (e.g., `16.10.0-uds.0-upstream`)
+- `--output-file` or `-f`: Output file for CSV results
+
+### Optional Parameters
+
+- `--docker-username` or `-u`: Docker username for registry access, accepts CSV values
+- `--docker-password` or `-p`: Docker password for registry access, accepts CSV values
+
+### Example Usage
+
+```sh
+uds scan -o defenseunicorns -n packages/uds/gitlab-runner -g 16.10.0-uds.0-upstream -u docker-username -p docker-password -f gitlab-runner.csv
+```
diff --git a/docs/runner.md b/docs/runner.md
index db641c26..6b7debd6 100644
--- a/docs/runner.md
+++ b/docs/runner.md
@@ -1,5 +1,8 @@
-# UDS Runner
-
+---
+title: UDS Runner
+type: docs
+weight: 4
+---
UDS CLI contains vendors and configures the [maru-runner](https://github.com/defenseunicorns/maru-runner) build tool to make compiling and building UDS bundles simple.
diff --git a/go.mod b/go.mod
index 1e053ec3..c5676959 100644
--- a/go.mod
+++ b/go.mod
@@ -1,8 +1,6 @@
module github.com/defenseunicorns/uds-cli
-go 1.22.1
-
-toolchain go1.22.3
+go 1.22.3
require (
github.com/AlecAivazis/survey/v2 v2.3.7