vibe-ship

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

1. Generate (default) - no deployment files exist yet, or the user wants a fresh setup. Walk through the workflow below.
2. 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.