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 justkeystroke 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
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
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:
- Runs lint and typecheck
- Builds the project for the deploy phase
- Regenerates the route manifest for agents, workflows, and triggers
- Packs the
dist/output into an artifact - Uploads the artifact to the platform
- Promotes the new runtime for the project
dist/ tree — your lockfile and node_modules are not uploaded.
After the first successful deploy, the CLI switches your default target to cloud. Project targeting comes from project and organization in keystroke.config.ts (set by keystroke projects link). See targets: local vs cloud.
Deploy from another directory
Use--dir when your current shell is not inside the project codebase:
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 from the cloud target: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.
--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:
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
| Mistake | What to do instead |
|---|---|
Running --filter on the first deploy | Run a full deploy first |
| Deploying from the wrong directory | Pass --dir or change into the project codebase |
Expecting .env to upload | Set credentials on the cloud project |
Changing shared project assets with --filter | Run a full deploy |
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.