dockerignore-generation
This Claude Code skill generates ecosystem-specific `.dockerignore` files to optimize Docker builds and prevent secret exposure. Use it when a project lacks a `.dockerignore` file, the build context is unnecessarily large, or when `.env` files and other sensitive data risk being copied into container images. The skill detects the project's tech stack and applies appropriate exclusion patterns for Node.js, Python, Go, Rust, Java, Ruby, PHP, Elixir, and .NET ecosystems.
git clone --depth 1 https://github.com/nixopus/nixopus /tmp/dockerignore-generation && cp -r /tmp/dockerignore-generation/api/skills/dockerignore-generation ~/.claude/skills/dockerignore-generationSKILL.md
# .dockerignore Generation ## Why It Matters Without a `.dockerignore`: - Build context includes `node_modules` (hundreds of MB), `.git` history, and local env files - Secrets in `.env` files get copied into the image and are extractable - Build is slow because Docker sends the entire directory to the daemon ## Base Template (all ecosystems) Every `.dockerignore` should include: ``` .git .gitignore .env .env.* !.env.example !.env.sample *.md !README.md LICENSE docker-compose*.yml .dockerignore Dockerfile .vscode .idea .cursor ``` ## Ecosystem-Specific Entries ### Node.js ``` node_modules .next .nuxt .output dist build .cache coverage .nyc_output *.log npm-debug.log* yarn-debug.log* yarn-error.log* .pnpm-debug.log* .turbo .vercel .netlify storybook-static ``` ### Python ``` __pycache__ *.pyc *.pyo *.egg-info .eggs .venv venv env .tox .pytest_cache .mypy_cache .ruff_cache htmlcov *.cover ``` ### Go ``` vendor/ *.test *.out bin/ tmp/ ``` ### Rust ``` target/ *.rs.bk ``` ### Java ``` target/ build/ .gradle/ *.class *.jar !*.jar # if copying JARs intentionally, remove this line .settings/ .classpath .project ``` ### Ruby ``` vendor/bundle .bundle log/ tmp/ coverage/ spec/reports ``` ### PHP ``` vendor/ storage/logs/ storage/framework/cache/ storage/framework/sessions/ storage/framework/views/ bootstrap/cache/ ``` ### Elixir ``` _build/ deps/ .elixir_ls/ cover/ ``` ### .NET ``` bin/ obj/ *.user *.suo packages/ ``` ## Generation Logic 1. Start with the base template 2. Detect ecosystem from the project (check for `package.json`, `go.mod`, `requirements.txt`, etc.) 3. Append the matching ecosystem entries 4. If `test/` or `tests/` or `__tests__/` exists: add test directories 5. If `.github/` exists: add `.github/` 6. Write to `.dockerignore` at the project root ## Gotchas - `!.env.example` negates the `.env.*` exclusion — keep example env files so Dockerfile can reference them - Monorepos: `.dockerignore` is relative to the build context root, not the Dockerfile location - Docker Compose `build.context` changes what `.dockerignore` applies to — if context is `.`, the root `.dockerignore` applies - Don't ignore `prisma/` if Prisma is used — `prisma/schema.prisma` is needed for `postinstall` - Don't ignore lockfiles (`package-lock.json`, `yarn.lock`, etc.) — they're essential for reproducible builds ## Related Skills - **`pre-deploy-checklist`** — Checks for `.dockerignore` existence and flags missing ones - **`dockerfile-generation`** — Generate `.dockerignore` alongside the Dockerfile
Reference for all Nixopus API operations callable via nixopus_api(method, path, body)
Generate Caddyfile configurations for static sites and reverse proxies — SPA fallback routing, cache headers, compression, redirects, and error pages. Use when deploying a static site that needs custom Caddy configuration, or when the user needs SPA routing, caching, or redirect rules.
Generate docker-compose.yml for multi-service setups including databases, caches, and service dependencies. Use when the app needs a database, cache, message broker, or has multiple independently deployable services.
Size container memory and CPU limits, diagnose OOM kills and CPU throttling, and recommend resource adjustments by ecosystem. Use when containers are being OOM-killed, running slowly, or when setting initial resource limits for a deployment.
Build and deploy C/C++ applications — CMake, Meson, Ninja, and Dockerfile patterns. Use when deploying a C or C++ project, or when CMakeLists.txt or meson.build is detected.
Run database migrations safely during deployment — framework-specific commands, pre-deploy vs post-deploy timing, health gates, and rollback strategies. Use when the app has a database migration system and needs migrations run during deployment.
Build and deploy Deno applications — version detection, dependency caching, and Dockerfile patterns. Use when deploying a Deno project, or when deno.json or deno.jsonc is detected.
Sub-agent routing table — which agent handles diagnostics, machine health, infrastructure, GitHub, billing, and notifications. Load when the current task is not a direct deployment.