Generally no. The Composer FAQ answer is that the general recommendation is no: add vendor to your ignore file, commit composer.json and composer.lock, and have developers, CI and deploy tools run composer install. Committing vendor bloats the repository and makes reviews noisy.
The reasons the FAQ gives
| Problem | Detail |
|---|---|
| Repository size | Large repositories and large diffs on every update |
| Duplicated history | Your history stores the full history of every dependency |
| Broken submodules | Git installed dependencies look like submodules but are not real ones |
The security angle
People sometimes commit vendor so they can read exactly what runs. The intent is good, but the cost is a diff nobody reads. A thousand changed files in a pull request hides a malicious change better than a short composer.lock diff does. The lock file diff is small enough for a human to review, and each change is a package name and version.
The better approach is to keep the lock file reviewable, then verify installs against it.
When people still commit vendor
Some teams deploy to hosts with no outbound network, or must be able to build with no external service. If that is you, the FAQ gives a path: install only tagged releases so you get zip archives rather than git checkouts, prefer dist installs, delete each dependency's git directory before committing, and ignore nested git folders. Remove those directories again before running an update.
A cleaner alternative is to build the vendor directory in CI, then ship it as a build artifact rather than committing it.
Steps for a clean pipeline
- Ignore vendor in version control.
- Commit composer.lock and review its diffs.
- In CI, run install with no development packages.
- Run an advisory check on the lock file.
- Package the built application as an artifact and deploy that.
- Keep production file permissions read only for the web user.
composer install --no-dev --no-interaction
composer audit --locked
What to check on an existing repo
Look at whether vendor is already committed. If so, the tree contains code nobody has reviewed in years. Removing it from version control, then rebuilding from the lock file, gives you a clear record of what each dependency version is.
Try it yourself
Click through it at your own pace, or open it full screen. See how a built artifact is scanned before it ships.
Where Safeguard fits
Safeguard's reachability analysis helps separate advisories your code can reach from those it cannot. You can try a free scan on your own lock file.
Quick check
Does ignoring vendor hurt reproducibility?
Not if composer.lock is committed. The lock file gives the same versions on every install.
How do I deploy with no network on the server?
Build the vendor directory in CI and ship it with the application artifact, rather than committing it.
Sources
Last reviewed: 19 October 2026.
