Every time you deploy with DeployHQ, 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 finishes in 10 seconds.
How Incremental Deployments Work
Instead of uploading your entire codebase on every deploy, DeployHQ 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:
- DeployHQ records the deployed commit SHA after each successful deployment
- On the next deploy, it runs a diff between the recorded SHA and the new target commit
- Only modified, added, or deleted files are transferred via SFTP, FTP, or your chosen protocol
- 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 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): 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 uses incremental deployments by default for every project because they're the right choice for the vast majority of deploys:
Faster feedback loops: Deploy 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, 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 for more on optimizing deploys to virtual servers.
Safer rollbacks: Since DeployHQ tracks every deployed commit, you can rollback to any previous deployment instantly — and the rollback itself is also incremental.
When Incremental Deployments Won't Work
There are situations where you need 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 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, 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 in DeployHQ 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 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 walks through setting this up with GitHub Actions, GitLab CI, and other providers. You can also use DeployHQ's API 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 — 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 — incremental deployments are enabled by default, with no setup required.
For questions about deployment strategies, reach out to us at support@deployhq.com or on Twitter/X.