Using a service like DeployHQ with Git or another SCM is great for streamlining your deployment process. However, you'll often find files in your repository that shouldn't be uploaded to your server — development configs, build dependencies, test fixtures, documentation source files, and more.
DeployHQ gives you several ways to control exactly what gets deployed and what gets left behind.
flowchart LR
A[Repository<br/>All Files] --> B{Exclusion Rules}
B -->|Matched| C[❌ Skipped]
B -->|Not matched| D[✅ Deployed to Server]
Excluded Files
Within any project, you can set up a list of Excluded Files — file path patterns that DeployHQ checks during each deployment and skips anything that matches. Think of excluded files as a filter that prevents matching files from being modified on your server during deployment.
Adding an excluded file
Head to any project, then click Excluded Files on the left hand side, followed by the New Excluded File button:

Enter the file path relative to your repository root, then optionally choose one or more specific servers to apply the rule to. This is useful if you want to deploy a file to your production server but exclude it from your staging server.
Click Create Excluded File, and any future deployments to the selected servers will ignore matching files.
File patterns
Exclusion rules go beyond just matching a specific file. You can use wildcards to exclude files by extension or within entire directories.
Pattern syntax reference
| Pattern | What it matches | Example use |
|---|---|---|
filename |
Exact file name | Makefile |
path/to/file |
File at a specific path | config/database.yml |
*.ext |
Files with extension in root | *.log |
**/*.ext |
Files with extension at any depth | **/*.env |
dirname |
A directory entry | node_modules |
dirname/** |
All contents inside a directory | node_modules/** |
!pattern |
Whitelist — keep a file despite parent being excluded | !vendor/autoload.php |
Important: To fully exclude a directory and its contents, you need two rules — one for the directory itself and one for everything inside it:
node_modules
node_modules/**
The ** means match anything at any depth
, so all files and subdirectories within node_modules will be excluded.
Common exclusion patterns
Here are ready-to-use patterns for common scenarios:
Dependencies and build tools:
node_modules
node_modules/**
vendor
vendor/**
bower_components
bower_components/**
Environment and config files:
.env
.env.*
config/local.php
config/database.yml
Test and development files:
tests
tests/**
coverage
coverage/**
**/*.test.js
**/*.spec.js
phpunit.xml
jest.config.js
Build artifacts and source maps:
**/*.map
**/*.log
.cache
.cache/**
Using .deployignore
As well as configuring excluded files through the UI, you can commit your rules to your repository using a .deployignore file. If you're familiar with .gitignore, it works the same way — add the file to your repository's root and place each rule on a new line:
@title: .deployignore
# Dependencies
node_modules
node_modules/**
vendor
vendor/**
# Environment files
.env
.env.*
# Tests
tests
tests/**
**/*.test.js
# Build artifacts
**/*.map
**/*.log
Once committed and pushed, DeployHQ will detect the file and apply the rules automatically. The .deployignore file must be present in the commit you're deploying — DeployHQ reads it when checking out the repository.
Key difference: .deployignore rules apply to all servers. If you need different exclusion rules per server, use the Excluded Files UI instead.
Whitelisting exceptions
Sometimes you need to exclude a directory but keep specific files inside it. You can whitelist files by prefixing a rule with !:
vendor
vendor/**
!vendor/autoload.php
!vendor/composer
!vendor/composer/**
This excludes the entire vendor directory but keeps the Composer autoloader deployed.
Verifying exclusions
After running a deployment, check the log under the Generate Manifest
step. DeployHQ displays a full list of excluded files for each server, so you can confirm your rules are working as expected.
For the full documentation, see our support article on excluded files.
Related guides
- Excluding files with .deployignore — version-controlled exclusion rules
- Whitelisting excluded files — create exceptions with the
!prefix - Excluded files per server — different rules for different servers
- Protect your environments: practical security tips — keep secrets out of deployments
- Building a CI/CD pipeline from scratch — broader deployment automation
Ready to streamline your deployments? Sign up for DeployHQ and get started in minutes. If you have any questions, reach out to us at support@deployhq.com or on Twitter/X @deployhq.