kms/docs/cli/commands/run.mdx

---
title: "hanzo-kms run"
description: "The command that injects your secrets into local environment"
---

<Tabs>
  <Tab title="Single command">
    ```bash
    hanzo-kms run [options] -- [your application start command]

    # Example
    hanzo-kms run [options] -- npm run dev
    ```

  </Tab>

  <Tab title="Chained commands">
    ```bash
    hanzo-kms run [options] --command [string command]

    # Example
    hanzo-kms run [options] --command "npm run bootstrap && npm run dev start; other-bash-command"
    ```

  </Tab>
</Tabs>

## Description

Inject secrets from KMS into your application process.

## Subcommands & flags

<Accordion title="hanzo-kms run" defaultOpen="true">
  Use this command to inject secrets into your applications process

```bash
$ hanzo-kms run -- <your application command>

# Example
$ hanzo-kms run -- npm run dev
```

### Environment variables

  <Accordion title="KMS_TOKEN">
    Used to fetch secrets via a [machine identity](/documentation/platform/identities/machine-identities) apposed to logged in credentials. Simply, export this variable in the terminal before running this command.

    ```bash
      # Example
      export KMS_TOKEN=$(hanzo-kms login --method=universal-auth --client-id=<identity-client-id> --client-secret=<identity-client-secret> --silent --plain) # --plain flag will output only the token, so it can be fed to an environment variable. --silent will disable any update messages.
    ```

    <Info>
      Alternatively, you may use service tokens.

      ```bash
        # Example
        export KMS_TOKEN=<service-token>
      ```
    </Info>
  </Accordion>

  <Accordion title="KMS_DISABLE_UPDATE_CHECK">
    Used to disable the check for new CLI versions. This can improve the time it takes to run this command. Recommended for production environments.
    
    To use, simply export this variable in the terminal before running this command.

    ```bash
      # Example
      export KMS_DISABLE_UPDATE_CHECK=true
    ```
  </Accordion>

### Flags

  <Accordion title="--watch">
    By passing the `watch` flag, you are telling the CLI to watch for changes that happen in your KMS project.
    If secret changes happen, the command you provided will automatically be restarted with the new environment variables attached.

    ```bash
      # Example
      hanzo-kms run --watch -- printenv
    ```
  </Accordion>

  <Accordion title="--project-config-dir">
    Explicitly set the directory where the .kms.json resides. This is useful for some monorepo setups.

    ```bash
      # Example
      hanzo-kms run --project-config-dir=/some-dir -- printenv
    ```
  </Accordion>

  <Accordion title="--command">
    Pass secrets into multiple commands at once

    ```bash
    # Example
    hanzo-kms run --command="npm run build && npm run dev; more-commands..."
    ```

  </Accordion>

  <Accordion title="--projectId">
    The project ID to fetch secrets from. This is required when using a machine identity to authenticate.

    ```bash
    # Example
    hanzo-kms run --projectId=<project-id> -- npm run dev
    ```

  </Accordion>

  <Accordion title="--token">
    If you are using a [machine identity](/documentation/platform/identities/machine-identities) to authenticate, you can pass the token as a flag

    ```bash
    # Example
    hanzo-kms run --token="<universal-auth-access-token>" --projectId=<project-id> -- npm run start
    ```

    You may also expose the token to the CLI by setting the environment variable `KMS_TOKEN` before executing the run command. This will have the same effect as setting the token with `--token` flag

  </Accordion>

  <Accordion title="--expand">
    Turn on or off the shell parameter expansion in your secrets. If you have used shell parameters in your secret(s), activating this feature will populate them before injecting them into your application process.

    Default value: `true`

  </Accordion>

  <Accordion title="--include-imports">
    By default imported secrets are available, you can disable it by setting this option to false.

    Default value: `true`
  </Accordion>

{" "}

<Accordion title="--env">
  This is used to specify the environment from which secrets should be
  retrieved. The accepted values are the environment slugs defined for your
  project, such as `dev`, `staging`, `test`, and `prod`. Default value: `dev`
</Accordion>

  <Accordion title="--secret-overriding">
    Prioritizes personal secrets with the same name over shared secrets

    Default value: `true`

  </Accordion>

  <Accordion title="--tags">
    When working with tags, you can use this flag to filter and retrieve only secrets that are associated with a specific tag(s).

    ```bash
    # Example
    hanzo-kms run --tags=tag1,tag2,tag3 -- npm run dev
    ```

    Note: you must reference the tag by its slug name not its fully qualified name. Go to project settings to view all tag slugs.

    By default, all secrets are fetched

  </Accordion>

  <Accordion title="--path">
    The `--path` flag indicates which project folder secrets will be injected from.

    ```bash
    # Example
    hanzo-kms run --path="/nextjs" -- npm run dev
    ```

  </Accordion>

</Accordion>


## Automatically reload command when secrets change

To automatically reload your command when secrets change, use the `--watch` flag.

```bash
hanzo-kms run --watch -- npm run dev
```

This will watch for changes in your secrets and automatically restart your command with the new secrets.
When your command restarts, it will have the new environment variables injeceted into it.

<Note>
  Please note that this feature is intended for development purposes. It is not recommended to use this in production environments. Generally it's not recommended to automatically reload your application in production when remote changes are made.
</Note>