> ## Documentation Index
> Fetch the complete documentation index at: https://app.keystroke.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Deploy individual files

> Keep work-in-progress modules out of deploys.

You do not always need to deploy the whole project. Keystroke gives you two ways to control what changes reach the platform:

* Use `--filter` to redeploy one or more specific modules on top of the current platform artifact.
* Use `@keystroke ignore` comments to keep unfinished modules out of local builds or deploys.

Use these tools when you are iterating quickly, splitting work across teammates, or keeping draft agents and workflows in the codebase without shipping them.

## Filtered deploys

A filtered deploy rebuilds only the modules you name and overlays them onto the active deployed artifact.

```bash theme={null}
keystroke deploy --filter agents/support
keystroke deploy --filter workflows/morning-check
keystroke deploy --filter agents/support --filter workflows/signup-pipeline
```

Link the directory first with `keystroke projects link --project <slug>`, or pass `--project` on each command.

Filters use exact build entry keys:

| Source file                        | Filter key                  |
| ---------------------------------- | --------------------------- |
| `src/agents/support.ts`            | `agents/support`            |
| `src/workflows/morning-check.ts`   | `workflows/morning-check`   |
| `src/triggers/incoming-message.ts` | `triggers/incoming-message` |

There are no globs or negation patterns. The first deploy for a project must be a full deploy, because filtered deploys need an active artifact to patch.

## When to use a filtered deploy

Use `--filter` when you changed one or a few deployable modules:

* A single agent prompt or tool list
* A workflow implementation
* A trigger module
* A small set of related modules you want to ship together

Run a full deploy instead when you change project-wide pieces:

* `keystroke.config.ts`
* Shared skills or files
* Built-in integration routes
* Anything that should refresh every module in the runtime

Filtered deploys carry forward untouched modules from the current platform artifact. They do not rebuild the whole project.

## Keep drafts out of deploys

Add an ignore directive at the top of an agent, workflow, or trigger module when it should not be included.

```ts theme={null}
// @keystroke ignore
```

Use `@keystroke ignore` for code that should be skipped everywhere: local build, `keystroke dev`, `keystroke start`, and deploy.

```ts theme={null}
// @keystroke ignore:deploy
```

Use `@keystroke ignore:deploy` for code that can run locally but should not ship to the platform yet.

| Directive                     | Local build and dev | Deploy  |
| ----------------------------- | ------------------- | ------- |
| `// @keystroke ignore`        | Skipped             | Skipped |
| `// @keystroke ignore:deploy` | Included            | Skipped |

## Import guard

A shipped module cannot import a module marked with either ignore directive. If it does, the build fails.

This prevents production code from depending on a file that Keystroke is about to omit. If a trigger attaches to an ignored workflow, give the trigger the same ignore treatment so the project behaves consistently across local builds and deploys.

## How filtered deploys and ignores differ

Filtered deploys and ignore directives solve different problems:

| Need                                               | Use                                 |
| -------------------------------------------------- | ----------------------------------- |
| Ship one live module without rebuilding everything | `keystroke deploy --filter <entry>` |
| Keep broken or experimental code out of all builds | `// @keystroke ignore`              |
| Run code locally but keep it out of the platform   | `// @keystroke ignore:deploy`       |

One important difference: `ignore:deploy` omits a module from a new full deploy. It does not preserve the previous production version of that module. If you want to update one module while carrying forward the rest of production, use a filtered deploy.

## Verify the result

After a filtered deploy, check that the new artifact is active and run the changed module:

```bash theme={null}
keystroke projects deployments list --project support-automations
keystroke --project support-automations workflow run morning-check --input '{}'
```

If you updated one module in a larger project, spot-check an unchanged route too. That confirms the carried-forward artifact still behaves as expected.

## Next steps

<CardGroup cols={2}>
  <Card title="Deploy a project" href="/learn/projects/deploy-a-project">
    Learn the full deploy flow and when to use filtered deploys.
  </Card>

  <Card title="Build agents" href="/learn/agents/build-agents">
    Define agent modules that can be deployed individually.
  </Card>

  <Card title="Build workflows" href="/learn/workflows/build-workflows">
    Define workflow modules that can be deployed individually.
  </Card>

  <Card title="CLI reference" href="/cli#deploy">
    See the deploy command reference.
  </Card>
</CardGroup>