Using a service like [DeployHQ](https://www.deployhq.com) 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](https://www.deployhq.com) 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](https://www.deployhq.com) 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:

![New excluded file](https://blog.deployhq.com/attachment/d3adb2de-b316-4e69-b6ec-dd20cd216d8a/agmg-HJ2.png)

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](https://www.deployhq.com/blog/excluded-files-per-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](https://www.deployhq.com/blog/whitelisting-excluded-files) — 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](https://www.deployhq.com/blog/excluding-files-with-deployignore). 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](https://www.deployhq.com) will detect the file and apply the rules automatically. The `.deployignore` file must be present in the commit you're deploying — [DeployHQ](https://www.deployhq.com) reads it when checking out the repository.

**Key difference:** `.deployignore` rules apply to all servers. If you need [different exclusion rules per server](https://www.deployhq.com/blog/excluded-files-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](https://www.deployhq.com/blog/whitelisting-excluded-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](https://www.deployhq.com) 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](https://www.deployhq.com/support/excluded-files).

## Related guides

- [Excluding files with .deployignore](https://www.deployhq.com/blog/excluding-files-with-deployignore) — version-controlled exclusion rules
- [Whitelisting excluded files](https://www.deployhq.com/blog/whitelisting-excluded-files) — create exceptions with the `!` prefix
- [Excluded files per server](https://www.deployhq.com/blog/excluded-files-per-server) — different rules for different servers
- [Protect your environments: practical security tips](https://www.deployhq.com/blog/protect-your-environments-practical-security-tips-for-smarte) — keep secrets out of deployments
- [Building a CI/CD pipeline from scratch](https://www.deployhq.com/blog/building-a-ci-cd-pipeline-from-scratch-with-deployhq-a-step-) — broader deployment automation

* * *

Ready to streamline your deployments? [Sign up for DeployHQ](https://www.deployhq.com/signup) and get started in minutes. If you have any questions, reach out to us at [support@deployhq.com](mailto:support@deployhq.com) or on [Twitter/X @deployhq](https://x.com/deployhq).