Skip to main content
When you deploy your project to Keystroke, the platform builds a new runtime from that code, promotes it, and makes the project’s agents, workflows, and triggers available in the cloud. Keystroke is deploy-first: edit src/, deploy, then run and inspect what’s deployed. Deploy often — a full deploy ships everything, or --filter redeploys a single module fast.

​
Where your project lives

A project does not dictate where you keep its code. Deploying is just keystroke deploy pointed at a specific project in the web platform, so the codebase itself can live wherever you’d work:
  • A local directory you are experimenting in, deployed straight from your machine
  • A Git repository (GitHub, GitLab, or anywhere else) that you version, review, and treat like any other codebase
For anything shared or production-facing, we recommend keeping the codebase in a Git repo so changes are tracked and reviewable, then run keystroke deploy to ship a new version.
Today you run keystroke deploy yourself. Connecting a GitHub or GitLab repository to a project for automatic deploys is coming soon.

​
Before you deploy

You need:
  • A Keystroke account and organization
  • A project in that organization
  • A codebase created with keystroke init
  • Any cloud credentials your agents or workflows need
If you do not have a project yet, create one:

​
Full deploy

Run a full deploy the first time you deploy to a project. Link the directory first (or pass --project for a one-off deploy):
keystroke deploy runs lint and typecheck, then builds and uploads. You do not need to run keystroke build, keystroke lint, or keystroke typecheck first — deploy gates on all of them. A full deploy:
  1. Runs lint and typecheck
  2. Builds the project for the deploy phase
  3. Regenerates the route manifest for agents, workflows, and triggers
  4. Packs the dist/ output into an artifact
  5. Uploads the artifact to the platform
  6. Promotes the new runtime for the project
Deploy ships only the built dist/ tree — your lockfile and node_modules are not uploaded. After a successful deploy, runtime commands target your linked cloud project. Project targeting comes from project and organization in keystroke.config.ts (set by keystroke projects link). See project targeting.

​
Deploy from another directory

Use --dir when your current shell is not inside the project codebase:
When the directory is linked via keystroke projects link, you can omit --project. The directory you deploy is the codebase that will define the platform project. Make sure it is the same tree you have been editing.

​
Verify a deploy

After deploy, check the deployment history and run something against the project:
You can also inspect the project in the web app and review run history after agents or workflows run.

​
Pull the active deploy

keystroke pull is the inverse of deploy. It downloads a project’s active deploy source into a local directory and installs dependencies — so you can pick up an existing project on a new machine, or recover the source that’s currently running.
A directory that already contains an unrelated project is refused unless you pass --force. A directory created by a prior pull of the same project refreshes in place, and a pull that’s already on the active artifact is a no-op.
pull brings down the active deploy — the source snapshot that was uploaded on the last successful deploy, not any later local edits. For shared or production work, keep the canonical codebase in a Git repo and treat pull as a way to bootstrap or recover, not as version control.

​
Deploy only specific modules

After a project has an active full deploy, you can redeploy one or more modules with --filter:
Filters match build entry keys such as agents/support, workflows/morning-check, or triggers/incoming-message. They are exact matches, not globs. Use filtered deploys for quick updates to a single agent, workflow, or trigger. Use a full deploy when you change project-wide configuration, shared assets, skills, integrations, or anything that should refresh the entire runtime. See Deploy individual files for details.

​
Common mistakes

​
Next steps

Manage projects

Create projects and invite teammates before you deploy.

Deploy individual files

Redeploy a targeted module or keep work-in-progress code out of production.

CLI reference

See the full deploy command reference.

Run history

Inspect what happens after your deployed agents and workflows run.