When deploying with [DeployHQ](https://www.deployhq.com), you'll often want to prevent certain files from reaching your server — development configs, build dependencies, test fixtures, and other files that belong in your repository but not on production. The `.deployignore` file gives you a version-controlled way to define these exclusion rules.

## What is `.deployignore`?

A `.deployignore` file works similarly to `.gitignore`: you place it in the root of your repository, and [DeployHQ](https://www.deployhq.com) reads it during each deployment to determine which files and directories should be excluded. It works with all supported version control systems — Git, Mercurial, and Subversion.

```
flowchart LR
    A[Repository Push] --> B[DeployHQ Detects Changes]
    B --> C{Read .deployignore}
    C --> D[Match Files Against Rules]
    D --> E[Excluded Files Skipped]
    D --> F[Remaining Files Deployed]
    F --> G[Server Updated]
```

## Setting it up

Create a `.deployignore` file in the root of your repository and add one exclusion rule per line. Comments start with `#`:

```
@title: .deployignore
# Dependencies (installed on server via build commands)
node_modules
node_modules/**
vendor
vendor/**

# Environment and config files
.env
config/local.php
config/database.yml

# Build and test artifacts
tests
tests/**
coverage
coverage/**
**/*.log

# Development tools
.editorconfig
.eslintrc
.prettierrc
docker-compose.yml
Makefile
```

Once the file is pushed to your repository, [DeployHQ](https://www.deployhq.com) will automatically check your rules and exclude the matched files from all future deployments.

## Pattern syntax reference

The `.deployignore` file uses the same pattern syntax as the [Excluded Files UI](https://www.deployhq.com/support/excluded-files):

| Pattern | What it matches | Example |
| --- | --- | --- |
| `filename` | A specific file or directory name | `Makefile`, `vendor` |
| `path/to/file` | A file at a specific path | `config/database.yml` |
| `*.ext` | Files with an extension in the current directory | `*.log` |
| ` **/*.ext` | Files with an extension at any depth | `** /*.env` |
| `dir/ **` | All contents inside a directory | `node_modules/** ` |
| `dir/prefix-*` | Files matching a prefix in a directory | `config/test-*` |
| `!pattern` | [Whitelist](https://www.deployhq.com/blog/whitelisting-excluded-files) — keep a file even if its parent is excluded | `!vendor/autoload.php` |

**Important notes:**

- To fully exclude a directory and its contents, you need **two rules** : one for the directory itself (`vendor`) and one for its contents (`vendor/**`)
- Rules must **not** end with trailing slashes
- Use `**` to match files recursively at any depth

## Common examples by project type

### PHP / Laravel

```
@title: .deployignore (PHP/Laravel)
node_modules
node_modules/**
tests
tests/**.env
.env.example
phpunit.xml
docker-compose.yml
**/*.log
```

### Node.js / Express

```
@title: .deployignore (Node.js)
tests
tests/**
coverage
coverage/**.env
.env.test
jest.config.js
**/*.test.js
**/*.spec.js
**/*.log
```

### WordPress

```
@title: .deployignore (WordPress)
node_modules
node_modules/**.env
wp-config-local.php
**/*.sql
**/*.log
docker-compose.yml
```

### Static site / Frontend

```
@title: .deployignore (Frontend)
node_modules
node_modules/**
src
src/**
tests
tests/**.env
**/*.map
**/*.test.*
webpack.config.js
tsconfig.json
```

## `.deployignore` vs the Excluded Files UI

[DeployHQ](https://www.deployhq.com) offers two ways to manage exclusions:

| Feature | `.deployignore` | Excluded Files UI |
| --- | --- | --- |
| **Version controlled** | Yes — lives in your repository | No — configured in DeployHQ |
| **Per-server rules** | No — applies to all servers | Yes — can differ per server |
| **Whitelisting** | Yes — use `!` prefix | Yes — use `!` prefix |
| **Shared across team** | Yes — committed to repo | No — per-account setting |

If you need different exclusion rules for different servers (e.g. excluding test data from production but keeping it on staging), use the [Excluded Files per Server](https://www.deployhq.com/blog/excluded-files-per-server) feature in the UI.

For most teams, using `.deployignore` for project-wide rules combined with the UI for server-specific overrides is the recommended approach.

## Verifying your rules

After running a deployment, check the deployment 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.

## Related guides

- [Stop certain files from being uploaded during a deployment](https://www.deployhq.com/blog/stop-certain-files-from-being-uploaded-during-a-deployment) — basics of file exclusions
- [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) — server-specific exclusion rules
- [Building a CI/CD pipeline from scratch with DeployHQ](https://www.deployhq.com/blog/building-a-ci-cd-pipeline-from-scratch-with-deployhq-a-step-) — broader deployment automation
- [Protect your environments: practical security tips](https://www.deployhq.com/blog/protect-your-environments-practical-security-tips-for-smarte) — keep secrets out of deployments

For the full documentation, see our [support article on excluded files](https://www.deployhq.com/support/excluded-files).

* * *

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).