name

vibe-ship

description

Generates a complete, production-ready deployment setup for any app in one pass -- Dockerfile, docker-compose.yml, .dockerignore, CI/CD (GitHub Actions), scalability config (health checks, resource limits, K8s on request), and security hardening (non-root user, secrets, dependency scanning). Auto-detects the stack from repo files (package.json, requirements.txt, go.mod, pom.xml, Gemfile, etc.) and writes real working files, not just advice. Also audits an EXISTING Dockerfile/compose/CI setup with a static scoring script and reports concrete findings. Use whenever the user asks to "dockerize", "containerize", "make this deployable", "production-ready", "vibe ship this", "add CI/CD", "set up deployment", "ship this app", requests a Dockerfile/docker-compose/GitHub Actions workflow, or wants a deployment setup reviewed -- even for just one piece (e.g. "add a Dockerfile"), since the full set is interdependent.

vibe-ship

Turns any codebase into something that can be deployed with docker compose up and shipped through CI/CD with sane, hardened defaults - all generated in one pass, tailored to the actual project. You bring the vibe; this brings the infrastructure.

Two modes

Generate (default) - no deployment files exist yet, or the user wants a fresh setup. Walk through the workflow below.
Audit - deployment files already exist and the user wants them reviewed/scored rather than replaced. Skip straight to "Audit an existing setup" below.

Generate: Workflow

1. Detect the stack

Look for these signal files in the project root (and one level into common subfolders like backend/, server/, api/):

File found	Stack	Default port	Start command
`package.json`	Node.js	3000	read `scripts.start`
`requirements.txt` / `pyproject.toml`	Python	8000	detect Flask/FastAPI/Django
`go.mod`	Go	8080	`go build`
`pom.xml` / `build.gradle`	Java/Kotlin (JVM)	8080	detect Spring Boot / Gradle app
`Gemfile`	Ruby	3000	detect Rails/Sinatra
`Cargo.toml`	Rust	8080	`cargo build --release`
`composer.json`	PHP	8000	detect Laravel/Symfony

If multiple signal files exist (e.g. a frontend/ and backend/ folder), treat it as a multi-service app - generate one Dockerfile per service plus a docker-compose.yml that wires them together.

If you can't confidently detect a stack, ask the user rather than guessing - a wrong Dockerfile base image is worse than no Dockerfile.

Also detect:

Package manager (npm vs yarn vs pnpm, pip vs poetry vs uv) from lockfiles present.
Database/cache dependencies (look for pg, mongoose, redis, sqlalchemy, etc. in dependency files) - these become services in docker-compose.yml.
Existing .env or .env.example - never overwrite; read it to learn what env vars the app expects.
Existing Dockerfile/CI config - if present, offer Audit mode instead of silently overwriting.

2. Read the relevant stack reference

Before writing the Dockerfile, read references/docker-patterns.md and jump to the section matching the detected stack. It has copy-ready multi-stage Dockerfile templates per language - adapt to the project's actual entry point, build command, and dependencies rather than pasting blind.

Also skim references/anti-patterns.md so the generated files avoid the common mistakes listed there by construction.

3. Generate the files

Write these into the project (paths relative to repo root unless multi-service):

Dockerfile - multi-stage build (build stage + slim runtime stage), non-root user, HEALTHCHECK instruction, pinned base image version.
.dockerignore - excludes node_modules, .git, .env, build artifacts, test files, etc. per stack.
docker-compose.yml - the app service plus any detected dependent services (postgres, redis, etc.) with named volumes, resource limits, a shared network, env vars from .env.
.env.example - every env var the app reads, with placeholder values and a comment on what each is for. Never put real secrets here.
.github/workflows/ci-cd.yml - see references/cicd-patterns.md. At minimum: install deps → lint → test → build Docker image → (on main branch) push to a registry, plus a dependency vulnerability scan step. Ask which registry (Docker Hub / GHCR / ECR / GCR) before filling in the push step - default to GHCR since it needs no extra secrets beyond GITHUB_TOKEN.
DEPLOYMENT.md - a short doc at the project root summarizing what was generated, how to run it locally (docker compose up), how CI/CD triggers, and a checklist of anything the user still needs to do manually.

For scalability and security specifics, read references/scalability-checklist.md and references/security-checklist.md before finalizing the Dockerfile and compose file - apply every relevant item, and note anything needing manual follow-up in DEPLOYMENT.md rather than silently skipping it.

If the user mentions Kubernetes, a specific cloud provider, or says Compose alone isn't enough, read references/kubernetes.md and generate manifests there instead of (or alongside) docker-compose.yml.

4. Run the audit script on what you just generated

Run scripts/audit.py against the generated Dockerfile/compose/CI files as a final sanity pass (see next section for usage). Fix anything it flags before presenting to the user - it should score clean on your own output.

5. Summarize, don't dump

Don't paste all file contents into the chat. Give a short summary: what was created, what stack was detected, what services are wired up, the audit score, and point to DEPLOYMENT.md for details. Offer to walk through any specific file if the user wants to review it.

Audit: Reviewing an existing setup

When the user already has a Dockerfile, docker-compose.yml, or CI config and wants it reviewed rather than replaced:

python3 scripts/audit.py --path /path/to/project

This statically scans for the Dockerfile, docker-compose.yml, and .github/workflows/*.yml under the given path and checks each against the same rules in references/security-checklist.md, references/scalability-checklist.md, and references/anti-patterns.md - no Docker daemon or network access needed, pure text analysis. It prints a scored report (CRITICAL/HIGH/MEDIUM/LOW findings) with file:line references and a fix suggestion per finding.

Walk through the findings with the user, prioritizing CRITICAL/HIGH first (things like running as root, :latest tags, secrets in ARG/ENV, missing .dockerignore). Offer to fix them directly rather than just listing them.

Principles

Real files, not essays. Working artifacts the user can run, not a markdown lecture.
Multi-stage builds always. Never ship build tools or dev dependencies in the final image.
Non-root by default. Every Dockerfile creates and switches to an unprivileged user before CMD.
Never hardcode secrets. Anything sensitive goes through env vars / .env (gitignored) with .env.example as the documented template.
Don't clobber existing config. If deployment files already exist, offer Audit mode instead of overwriting.
Scale defaults, not over-engineering. Health checks and resource limits by default; Kubernetes/Terraform/autoscaling only on request or when the project clearly needs it.

name

vibe-ship

description

vibe-ship

Two modes

Generate (default) - no deployment files exist yet, or the user wants a fresh setup. Walk through the workflow below.
Audit - deployment files already exist and the user wants them reviewed/scored rather than replaced. Skip straight to "Audit an existing setup" below.

Generate: Workflow

1. Detect the stack

Look for these signal files in the project root (and one level into common subfolders like backend/, server/, api/):

File found	Stack	Default port	Start command
`package.json`	Node.js	3000	read `scripts.start`
`requirements.txt` / `pyproject.toml`	Python	8000	detect Flask/FastAPI/Django
`go.mod`	Go	8080	`go build`
`pom.xml` / `build.gradle`	Java/Kotlin (JVM)	8080	detect Spring Boot / Gradle app
`Gemfile`	Ruby	3000	detect Rails/Sinatra
`Cargo.toml`	Rust	8080	`cargo build --release`
`composer.json`	PHP	8000	detect Laravel/Symfony

If you can't confidently detect a stack, ask the user rather than guessing - a wrong Dockerfile base image is worse than no Dockerfile.

Also detect:

Package manager (npm vs yarn vs pnpm, pip vs poetry vs uv) from lockfiles present.
Database/cache dependencies (look for pg, mongoose, redis, sqlalchemy, etc. in dependency files) - these become services in docker-compose.yml.
Existing .env or .env.example - never overwrite; read it to learn what env vars the app expects.
Existing Dockerfile/CI config - if present, offer Audit mode instead of silently overwriting.

2. Read the relevant stack reference

Also skim references/anti-patterns.md so the generated files avoid the common mistakes listed there by construction.

3. Generate the files

Write these into the project (paths relative to repo root unless multi-service):

Dockerfile - multi-stage build (build stage + slim runtime stage), non-root user, HEALTHCHECK instruction, pinned base image version.
.dockerignore - excludes node_modules, .git, .env, build artifacts, test files, etc. per stack.
docker-compose.yml - the app service plus any detected dependent services (postgres, redis, etc.) with named volumes, resource limits, a shared network, env vars from .env.
.env.example - every env var the app reads, with placeholder values and a comment on what each is for. Never put real secrets here.
.github/workflows/ci-cd.yml - see references/cicd-patterns.md. At minimum: install deps → lint → test → build Docker image → (on main branch) push to a registry, plus a dependency vulnerability scan step. Ask which registry (Docker Hub / GHCR / ECR / GCR) before filling in the push step - default to GHCR since it needs no extra secrets beyond GITHUB_TOKEN.
DEPLOYMENT.md - a short doc at the project root summarizing what was generated, how to run it locally (docker compose up), how CI/CD triggers, and a checklist of anything the user still needs to do manually.

4. Run the audit script on what you just generated

5. Summarize, don't dump

Audit: Reviewing an existing setup

When the user already has a Dockerfile, docker-compose.yml, or CI config and wants it reviewed rather than replaced:

python3 scripts/audit.py --path /path/to/project

Principles

Real files, not essays. Working artifacts the user can run, not a markdown lecture.
Multi-stage builds always. Never ship build tools or dev dependencies in the final image.
Non-root by default. Every Dockerfile creates and switches to an unprivileged user before CMD.
Never hardcode secrets. Anything sensitive goes through env vars / .env (gitignored) with .env.example as the documented template.
Don't clobber existing config. If deployment files already exist, offer Audit mode instead of overwriting.
Scale defaults, not over-engineering. Health checks and resource limits by default; Kubernetes/Terraform/autoscaling only on request or when the project clearly needs it.