In most deployment workflows, you only push the files that changed — that's the default in tools like DeployHQ. But there are specific situations where you need to send everything to the server, whether files changed or not. That's a full deployment, and knowing when to use one (and when not to) can save you hours of debugging.
What Happens During a Full Deployment
A full deployment uploads your entire project to the server in one operation. Every file — source code, assets, configuration, dependencies — gets transferred regardless of whether it changed since the last deploy.
Here's how the process differs from an incremental deployment:
flowchart LR
subgraph Incremental
A[Repository] -->|compare| B[Changed Files]
B -->|upload 3 files| C[Server]
end
subgraph Full
D[Repository] -->|skip compare| E[All Files]
E -->|upload 2,847 files| F[Server]
end
The trade-off is straightforward: full deployments are slower and use more bandwidth, but they guarantee your server matches your repository exactly. There's no room for drift.
When You Actually Need a Full Deployment
Don't default to full deployments — they're a tool for specific situations. Here are the cases where they're the right call:
First Deployment to a New Server
Your server has nothing on it. There's no previous state to compare against, so DeployHQ needs to push everything. This is the one scenario where a full deployment is mandatory.
After a Server Migration or Rebuild
You moved to a new VPS, rebuilt a container, or restored from a backup that's out of date. The server's file state doesn't match what DeployHQ thinks is there. A full deployment re-establishes the baseline. If you're planning a migration, our guide to managing multiple environments covers how to keep dev, staging, and production in sync.
When Files Got Out of Sync
Someone uploaded a hotfix via FTP. A build process generated files that weren't tracked. A failed deployment left partial changes. When the server state has drifted from what's in version control, a full deployment is the reset button.
Major Framework or Dependency Upgrades
Upgrading from Laravel 10 to 11, or Rails 6 to 7, often changes hundreds of files across your project — vendor directories, config files, compiled assets. An incremental deployment will catch the changed files, but a full deployment ensures nothing stale remains. This is particularly important when dealing with database migrations during major upgrades.
Debugging Deployment Issues
If an incremental deployment succeeded but your application is broken, a full deployment can rule out file synchronization as the cause. If the app still breaks after a full deploy, you know the problem is in your code, not in missing files.
How to Run a Full Deployment in DeployHQ
In DeployHQ, deployments are incremental by default — you only need to opt in when you specifically need a full deploy:
- Go to your project dashboard
- Click Deploy
- Click Choose a Commit
- Check Deploy the entire repository?
- Click Deploy
After the full deployment completes, DeployHQ updates its tracking state so subsequent deployments go back to incremental mode automatically.
If you want to speed up your regular incremental deployments even further, take a look at Turbo Deployments — they can cut transfer times by up to 70%.
The Real Cost of Full Deployments
Here's what a full deployment looks like in practice for different project sizes:
| Project Type | Files | Full Deploy Time | Incremental (10 changes) |
|---|---|---|---|
| Static site | ~200 | 15-30 seconds | 2-3 seconds |
| Laravel/Rails app | ~5,000 | 2-4 minutes | 8-12 seconds |
| Large monolith | ~15,000+ | 8-15 minutes | 10-20 seconds |
The bandwidth difference matters too. A 5,000-file Laravel project might transfer 150MB on a full deploy versus 500KB for an incremental one. That's the difference between a quick push and a deployment that ties up your server's I/O.
Best Practices When Running Full Deployments
Run Them During Low-Traffic Windows
Full deployments take longer, which means a longer window where files on the server are being overwritten. Schedule them for off-peak hours. If downtime isn't an option, read up on zero-downtime deployment strategies — DeployHQ supports atomic deployments with symlink switching.
Always Have a Rollback Plan
Before a full deployment, make sure you can roll back. DeployHQ makes this easy — you can redeploy any previous commit with one click. For critical deployments, test the rollback process before you start.
Clean Up Before You Deploy
Remove build artifacts, temporary files, and anything that shouldn't be on production. Check your .gitignore and DeployHQ's exclude patterns to make sure you're not uploading test fixtures, development configs, or documentation files.
Verify After Deployment
Don't assume everything is fine because the deployment completed without errors. Run through your deployment checklist: check critical pages, test authentication flows, verify API endpoints, and monitor error rates for the first 30 minutes.
When to Switch Back to Incremental
After a full deployment resolves whatever issue prompted it, go back to incremental deployments for your regular workflow. They're faster, use less bandwidth, and reduce the risk of disruption during deploy. That's why they're DeployHQ's default — for day-to-day development, incremental is almost always the better choice.
Full deployments are the safety net. Use them when you need a guaranteed clean slate, then get back to shipping fast with incremental deploys.
Ready to streamline your deployment workflow? Sign up for DeployHQ and get both full and incremental deployments out of the box.
For questions about deployment strategies, reach out to us at support@deployhq.com or on Twitter/X.