Dropbox ignore folders: node_modules, build files, and existing uploads

Yes, Dropbox can ignore folders. Create a plain-text file named rules.dropboxignore in the root of your Dropbox folder. The catch for developers: that file does not sync between computers, its rules only apply to new files, and it does not reuse the .gitignore files already in your projects.

The quick Dropbox fix

Open the Dropbox desktop app, go to Preferences → Sync → Set Ignore Rules, and select Modify Rules. Dropbox will create rules.dropboxignore in the root of your Dropbox folder. For a typical developer workspace, start with:

# Dependencies and build output
**/node_modules
**/dist
**/build
**/.next
**/.venv
**/__pycache__
*.log
**/.cache

Dropbox supports glob patterns, so **/node_modules matches that folder anywhere under your Dropbox root and *.log ignores log files. Ignored items remain local and do not count against Dropbox storage. This feature is currently limited to individual Dropbox accounts.

Dropbox's rules differ from .gitignore in a few ways that matter for code. Only the one rules.dropboxignore file in your Dropbox root is read, so rules don't cascade from nested files the way.gitignore does. Matching is case-insensitive, and ! re-includes something an earlier rule ignored.

Why Dropbox still syncs your existing node_modules

Rules only apply to files and folders created after the rule. Dropbox says so directly: a folder that already existed keeps syncing, and adding a rule never deletes anything already in Dropbox.

Apply a rule to a folder that's already uploaded

Dropbox's own fix is to remove the matching files and add them back. The safe way to do that keeps your local copy the whole time:

1. Add the rule to rules.dropboxignore and save. Dropbox applies it as soon as you save.
2. Move (don't delete) the folder out of Dropbox, for example mv ~/Dropbox/app/node_modules ~/node_modules-app. Wait for Dropbox to finish syncing. The cloud copy is now gone, and your files are safe at the new path.
3. Move it back: mv ~/node_modules-app ~/Dropbox/app/node_modules. Because it arrives after the rule, Dropbox ignores it.
4. Repeat on each other computer. rules.dropboxignore does not sync, so every machine needs its own copy of the rules.

For a dependency folder you can also just delete it and run npm install again after the rule is in place. Don't use that shortcut for anything you can't regenerate.

Doing this because Dropbox is syncing a code workspace? rbox skips dependencies, build output, caches, and secrets automatically. It respects your existing .gitignore, and your optional .rboxignore travels to every machine with the workspace.

Dropbox ignore rules vs rbox

The bigger problem with syncing code through Dropbox

Ignoring node_modules fixes wasted storage, but not the risky part. Dropbox treats .git as unrelated files. It cannot tell the difference between committed history, your current branch, staged changes, or a stash—and two machines writing there can produce conflicts.

rbox was built around the whole developer workspace. Your source files sync continuously, rebuildable files stay local, and your checkout travels as coherent Git state. If the other machine has local work, rbox waits instead of overwriting it. Everything is encrypted on your device before upload.

Skip the per-machine workaround. Install rbox to start passive, encrypted sync for your developer workstations, or see the complete rbox vs Dropbox comparison. If your repository is already inside Dropbox, read about using Git with Dropbox safely.

Does Dropbox respect .gitignore?

No. Dropbox's ignore rules are separate from Git's. You need to translate the relevant patterns into rules.dropboxignore and repeat that setup on each computer. rbox reads the .gitignore files already maintained with each project.

Official Dropbox reference

Checked against Dropbox's help center on September 28, 2026. Dropbox changes over time. For its current pattern syntax and restrictions, see Dropbox's official ignore-rules documentation.