Skip to main content
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. 
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 fileFilter key
src/agents/support.tsagents/support
src/workflows/morning-check.tsworkflows/morning-check
src/triggers/incoming-message.tstriggers/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. 
// @keystroke ignore
Use @keystroke ignore for code that should be skipped everywhere: local build, keystroke dev, keystroke start, and deploy. 
// @keystroke ignore:deploy
Use @keystroke ignore:deploy for code that can run locally but should not ship to the platform yet.
DirectiveLocal build and devDeploy
// @keystroke ignoreSkippedSkipped
// @keystroke ignore:deployIncludedSkipped

​
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:
NeedUse
Ship one live module without rebuilding everythingkeystroke 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: 
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

Deploy a project

Learn the full deploy flow and when to use filtered deploys.

Build agents

Define agent modules that can be deployed individually.

Build workflows

Define workflow modules that can be deployed individually.

CLI reference

See the deploy command reference.