> ## 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 a project
> Deploy everything or only specific modules.
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
```bash theme={null}
keystroke auth login
keystroke projects list
```
If you do not have a project yet, create one:
```bash theme={null}
keystroke projects create --name "Support automations"
```
## 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):
```bash theme={null}
keystroke projects link --project support-automations
keystroke 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 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](/cli#targets-local-vs-cloud).
## Deploy from another directory
Use `--dir` when your current shell is not inside the project codebase:
```bash theme={null}
keystroke deploy --dir ./apps/support-automations --project support-automations
```
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 from the cloud target:
```bash theme={null}
keystroke projects deployments list --project support-automations
keystroke --project support-automations workflow run greeting --input '{"name":"Ada"}'
```
You can also inspect the project in the web app and review [run history](/learn/logs/overview) 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.
```bash theme={null}
keystroke pull --project support-automations # into the current directory
keystroke pull --project support-automations --dir ./support-automations
```
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`:
```bash theme={null}
keystroke deploy --filter agents/support
keystroke deploy --filter workflows/morning-check
```
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](/learn/projects/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
Create projects and invite teammates before you deploy.
Redeploy a targeted module or keep work-in-progress code out of production.
See the full deploy command reference.
Inspect what happens after your deployed agents and workflows run.