Skip to content

The "Nuke It" Button (devx nuke)

devx nuke is a safe, confirmation-guarded hard reset for your local development environment. When caches go corrupt, containers drift, or you just need to start completely fresh — one command does it all.

What Gets Nuked

Before deleting anything, devx nuke scans first and shows you exactly what will be removed — grouped by category and with disk sizes — then asks for confirmation.

bash
devx nuke
devx nuke — scanning project...

  The following will be permanently deleted:

  Node.js
    ✗  node_modules                              (612.4 MB)
       /Users/james/myapp/node_modules
    ✗  .next (build cache)                       (84.1 MB)
       /Users/james/myapp/.next

  Go
    ✗  module cache (GOPATH/pkg/mod/cache)       (1.1 GB)
       /Users/james/go/pkg/mod/cache
    ✗  build cache (GOCACHE)                     (863.3 MB)
       /Users/james/Library/Caches/go-build

  devx
    ✗  devx-db-postgres                          (container)
    ✗  devx-data-postgres                        (volume)
    ✗  devx-cloud-gcs                            (container)

  Total: 2.7 GB across 7 items

  Safe (never touched):
    ✓  Source code
    ✓  .env files
    ✓  devx.yaml
    ✓  SSH keys
    ✓  ~/.devx/snapshots

⚠ This cannot be undone.
Delete 7 items (2.7 GB) from your project?

Databases, containers, caches, and build artefacts will be permanently removed.
Your source code and config files (.env, devx.yaml) are safe.

[ Yes, nuke it all ] [ Cancel ]

What Is Always Safe

devx nuke never touches:

SafeWhy
Your source codeRead-only — only caches and artefacts are removed
.env filesSecrets are yours to manage
devx.yamlProject config is preserved
SSH keysCredentials are untouched
~/.devx/snapshotsDatabase snapshots you created with devx db snapshot

::: note devx nuke respects the active --provider (e.g., podman vs docker) when executing container teardowns, ensuring it only cleans up containers and volumes managed by devx for that specific runtime. :::

Languages Supported

devx nuke recognises caches and build artefacts for:

Language / ToolWhat gets removed
Node.js / JSnode_modules/, .next/, .nuxt/, dist/, build/, .turbo/, .parcel-cache/
Govendor/, GOPATH/pkg/mod/cache, GOCACHE
Python.venv/, venv/, .pytest_cache/, __pycache__/
Rusttarget/
Java / JVMtarget/ (Maven), build/ (Gradle)
devxAll managed-by=devx containers and volumes

Only directories that actually exist are shown — if your project doesn't use Python, no Python entries appear.

Flags

FlagDescription
--dry-runShow the manifest without deleting anything
-y, --non-interactiveSkip the confirmation prompt (for CI)
--runtimeContainer runtime to use (defaults to active provider runtime e.g. nerdctl, docker, podman)

After Nuking

Once devx nuke completes, you'll have a completely clean slate:

bash
devx nuke                  # Nuke everything
devx up                    # Provision fresh databases, tunnels, and containers
devx config pull           # Re-sync secrets from vault
devx config validate       # Verify all required keys are present
npm install && npm run dev # Reinstall dependencies and start your app

Use snapshots before nuking databases

If your database contains important test data, take a snapshot first:

bash
devx db snapshot create postgres before-nuke
devx nuke
# Later, if needed:
devx db snapshot restore postgres before-nuke

Released under the MIT License.