Every time you deploy with [DeployHQ](https://www.deployhq.com), only the files that changed get uploaded to your server. That's an incremental deployment — and it's the reason a deploy that would take 4 minutes as a [full deployment](https://www.deployhq.com/blog/what-is-a-full-deployment) finishes in 10 seconds.

## How Incremental Deployments Work

Instead of uploading your entire codebase on every deploy, [DeployHQ](https://www.deployhq.com) tracks which files changed between your last successful deployment and the commit you're deploying now. Only the diff gets transferred.

```
flowchart TD
    A[New Commit] --> B[Compare with last deploy]
    B --> C{Changed files?}
    C -->|3 modified| D[Upload changed files]
    C -->|2 deleted| E[Remove from server]
    C -->|1 added| F[Upload new file]
    D --> G[Server updated]
    E --> G
    F --> G
```

Under the hood, this is what happens:

1. **DeployHQ records the deployed commit SHA** after each successful deployment
2. **On the next deploy** , it runs a diff between the recorded SHA and the new target commit
3. **Only modified, added, or deleted files** are transferred via SFTP, FTP, or your chosen protocol
4. **The recorded SHA updates** to the new commit, setting the baseline for next time

This is the same principle behind `rsync --checksum` or `git diff --stat` — only transfer what actually changed. The difference is that [DeployHQ](https://www.deployhq.com) handles it automatically with no configuration.

## Incremental Deployment vs. Incremental Rollout

These terms sound similar but mean different things, and the distinction matters:

- **Incremental deployment** (what this article covers): a file transfer strategy. You deploy the _full release_ to your server, but only _transfer the changed files_. Every server gets the complete new version.

- **Incremental rollout** (also called a progressive rollout or [canary release](https://www.deployhq.com/blog/smoother-deployments-with-canary-releases-a-code-centric-approach)): a release strategy. You deploy the new version to a _subset of servers or users_ first, then gradually expand to everyone. The goal is to limit blast radius if something goes wrong.

You can combine both: use incremental deployments for fast file transfer _and_ a canary rollout strategy for risk management. They operate at different layers.

## Real Performance Numbers

We've benchmarked incremental vs. full deployments across different project sizes. The difference is dramatic:

| Project Type | Files | Full Deploy | Incremental (10 changes) | Time Saved |
| --- | --- | --- | --- | --- |
| Static site | ~200 | 15-30s | 2-3s | ~85% |
| WordPress theme + plugins | ~2,000 | 1-2 min | 5-8s | ~90% |
| Laravel/Rails app | ~5,000 | 3-4 min | 8-12s | ~95% |
| Large monolith | ~15,000+ | 8-15 min | 10-20s | ~97% |

For a team deploying 5 times a day on a 5,000-file project, that's the difference between 15-20 minutes of deployment time daily versus under a minute. Over a year, incremental deployments save roughly 80 hours of waiting.

Bandwidth savings are equally significant. A full deploy of a Laravel project might transfer 150MB. An incremental deploy with 10 changed files? Usually under 500KB.

## Why Incremental Is the Default

[DeployHQ](https://www.deployhq.com) uses incremental deployments by default for every project because they're the right choice for the vast majority of deploys:

- **Faster feedback loops** : [Deploy](https://www.deployhq.com) in seconds, not minutes. This encourages more frequent deployments, which means smaller changesets, which means easier debugging.

- **Lower server impact** : Less data transferred means less I/O load on your production server during deploy. Combined with [zero-downtime deployment](https://www.deployhq.com/blog/zero-downtime-deployments-keeping-your-application-running-smoothly), your users never notice a thing.

- **Reduced bandwidth costs** : If you're deploying to servers with metered bandwidth (common with VPS providers), the difference between 150MB and 500KB per deploy adds up. Read our [VPS deployment guide](https://www.deployhq.com/blog/what-s-the-easiest-way-to-deploy-on-a-vps) for more on optimizing deploys to virtual servers.

- **Safer rollbacks** : Since [DeployHQ](https://www.deployhq.com) tracks every deployed commit, you can [rollback to any previous deployment](https://www.deployhq.com/blog/seamless-recovery-how-deployhq-empowers-you-to-rollback-deployments) instantly — and the rollback itself is also incremental.

## When Incremental Deployments Won't Work

There are situations where you need a [full deployment](https://www.deployhq.com/blog/what-is-a-full-deployment) instead:

- **First deploy to a new server** — there's no previous state to compare against
- **After someone modified files directly on the server** (via FTP, SSH, etc.) — the server state has drifted from what [DeployHQ](https://www.deployhq.com) expects
- **After a major framework upgrade** — hundreds of files changed, and you want a guaranteed clean slate
- **Server migration or rebuild** — the new server needs everything from scratch

In [DeployHQ](https://www.deployhq.com), switching to a full deploy is a single checkbox: check **Deploy the entire repository?** before deploying. After the full deploy completes, subsequent deployments automatically return to incremental.

## Making Incremental Deployments Even Faster

If you want to push the performance further:

### Use Turbo Deployments

[Turbo Deployments](https://www.deployhq.com/blog/turbo-deployments-explained-deploy-faster-with-one-simple-trick) in [DeployHQ](https://www.deployhq.com) skip the file comparison step entirely by using Git's own diff to determine what changed. This can cut deployment times by up to 70% for large projects.

### Keep Your Repository Clean

Files that shouldn't be deployed (test fixtures, documentation, local configs) slow down both the comparison and transfer steps. Use `.gitignore` for files that shouldn't be tracked, and DeployHQ's exclude patterns for tracked files that shouldn't be deployed.

### Use Build Pipelines

If your project has a build step (compiling assets, bundling JavaScript, generating CSS), use [DeployHQ's build pipelines](https://www.deployhq.com/blog/build-pipelines-in-deployhq-streamline-your-deployment-workflow) to run the build on DeployHQ's servers before deploying. This way, your server only receives production-ready files.

### Integrate with Your CI/CD Pipeline

Trigger incremental deployments automatically after your CI tests pass. Our [CI/CD pipeline guide](https://www.deployhq.com/blog/building-a-ci-cd-pipeline-from-scratch-with-deployhq-a-step-by-step-guide) walks through setting this up with GitHub Actions, GitLab CI, and other providers. You can also use [DeployHQ's API](https://www.deployhq.com/blog/using-deployhq-s-api-automating-your-deployment-workflows-with-scripts-and-webhooks) to automate deployments from any workflow.

## Commit Frequently, Deploy Often

Incremental deployments reward a workflow of small, frequent commits. Each deployment transfers less data, finishes faster, and is easier to debug if something breaks. This aligns with the principle of [continuous deployment](https://www.deployhq.com/blog/automate-website-deployments-from-git-without-downtime-with-deployhq) — ship small changes continuously rather than large batches occasionally.

When you deploy 10 times a day with 5-10 changed files each time, each deploy takes seconds and any issue is easy to trace to a specific commit. When you deploy once a week with 200 changed files, each deploy takes minutes and debugging is a nightmare.

Incremental deployments make the deploy often approach practical.

* * *

Ready to deploy faster? [Sign up for DeployHQ](https://www.deployhq.com/signup) — incremental deployments are enabled by default, with no setup required.

For questions about deployment strategies, reach out to us at [support@deployhq.com](mailto:support@deployhq.com) or on [Twitter/X](https://x.com/deployhq).