all-deploy

install

source · Clone the upstream repo

git clone https://github.com/Hainrixz/all-deploy

Claude Code · Install into ~/.claude/skills/

git clone --depth=1 https://github.com/Hainrixz/all-deploy ~/.claude/skills/hainrixz-all-deploy-all-deploy

manifest: SKILL.md

source content

all-deploy

Detects, audits, and deploys projects to the right host with a confirmed preview → prod flow. The unique value is detect → audit → route to the right CLI, not wrapping the CLI.

Configuration (edit these lines to change default behavior)

CONFIRMATION_MODE: ask_at_start
  # ask_at_start (default): the skill asks at the start of each cloud deploy
  #                         whether to run full-auto or step-by-step.
  # full_auto:              skip the question. Audit → preview → prod with a
  #                         5-second ESC window before prod.
  # always_ask:             skip the question. Require explicit "yes" before prod.
VISUAL_VERIFY: false           # true → screenshot preview via chrome-bridge-automation (frontend only)
ALLOW_DIRTY_TREE: false        # true → skip the "HEAD is clean" audit check

The default

ask_at_start

works for both solo authors and community users — the mode choice moves to runtime. Pinning to

full_auto

always_ask

is only useful when wrapping the skill in automation that can't answer the question interactively.

Hard Rules (never violate — these are the safety contract)

Never bypass or soften the audit. The audit is the only gate between the user's intent and live infra in
```
full_auto
```
mode. If a check cannot run, that itself is a block, not a reason to skip.
Never deploy to prod before a successful preview with a 2xx/3xx health check. Preview → summary → prod. No prod without a green preview in the same session.
Never commit, print, or log secrets. If a secret is found in tracked files, halt and guide removal + history rewrite as a separate user-approved step. Secret values never appear in summaries, logs, or commit messages.
Never auto-install or auto-authenticate third-party CLIs. Hand the user the command with the
```
!
```
prefix (e.g.,
```
! vercel login
```
,
```
! railway login
```
).
Never wrap a target CLI in a custom script that hides flags. Reference files document real commands the user can read and verify.
Never modify code to make audit pass without showing the diff first.
```
.gitignore
```
,
```
.env.example
```
, Dockerfile scaffolding, port-binding fixes — all shown and approved before applying.
Never deploy from a dirty working tree unless
```
ALLOW_DIRTY_TREE: true
```
is set. Uncommitted changes complicate rollback.
Respect "wait." Between preview and prod, any user utterance resembling hesitation (wait/hold/stop/not yet/abort) aborts the prod step cleanly.

Two Modes

Decide up front from the user's phrasing:

Cloud deploy (default) — Phases 0 through 6 below. Triggers: "deploy", "ship", "push to prod", "get it online", "/all-deploy".
Run locally — Phases 0, 1, 2, then a local-run step. Triggers: "run it locally", "corre esto localmente", "/all-deploy local", "just run it", or
```
--local
```
.

In run locally mode, run a scoped audit — only secrets-in-tracked-files, start-command-exists, and sane port binding. Skip: git-remote, clean HEAD,

npm audit

pip-audit

.env.example

completeness, and env-var delivery (no remote to deliver to). Then execute the detected start command (

npm run dev

uvicorn main:app --reload --host 0.0.0.0 --port $PORT

docker compose up

etc.) in the foreground, streaming output via

Monitor

. If the user asks to also expose the local server, chain into

references/targets/cloudflared-tunnel.md

. Everything else in this file concerns cloud deploy.

Cloud Deploy Workflow

Mode selection (runs before Phase 0 in

ask_at_start

mode)

Resolve the effective

CONFIRMATION_MODE

for this run:

If the user's invocation contains an explicit mode marker, adopt it and skip the question:
- ```
full_auto
```
  triggers: "auto", "full auto", "auto deploy", "deploy auto", "/all-deploy auto", "yolo".
- ```
always_ask
```
  triggers: "step", "step by step", "one at a time", "confirm each step", "paso a paso", "/all-deploy step".
Else if
```
CONFIRMATION_MODE
```
is pinned to
full_auto
or
always_ask
in the config block above, use that and skip the question.
Otherwise (
```
ask_at_start
```
, default), ask the user once, before Phase 0 runs:

"Before we start — how should I run the deploy?

1. Full auto — I run audit → preview → prod promotion in sequence. Prod fires after a 5-second ESC window. 2. Step by step — I stop for your OK between audit, preview, and prod.

Reply 'auto' or 'step'."

The chosen mode scopes to this run only — a future invocation asks again (unless the user explicitly opts in via trigger phrase or the config block is pinned).

"Wait" / "stop" / "hold" at any point still aborts the prod step in both modes (Hard Rule 8). The difference is whether you get a 5-second ESC window (full_auto) or an explicit "yes"-required pause (always_ask) before the prod command runs.

Phase 0 — Prerequisites (target-independent)

Check in order. Each failure halts with a

command for the user.

Git repo. Run
```
git rev-parse --is-inside-work-tree
```
. If not a repo, halt unless mode is
```
run locally
```
(which doesn't require git).
Git remote (cloud deploy only). Run
```
git remote -v
```
. If no remote is configured, halt unless the target will be
```
docker-vps
```
(deployable without a remote). This second clause is re-evaluated after Phase 3.
Language boundary. v1 fingerprints Node and Python. If the primary language is Go, Rust, Ruby, Elixir, Bun, or Deno, exit with: "v1 detects Node/Python ecosystems only. Run the target CLI directly (
vercel
,
railway
,
flyctl
,
docker
). Support for this language is planned in v2."

Target-CLI authentication is checked in Phase 3.5 (below), after the target is chosen.

Phase 0.5 — Permission-prompt seeding (first run only)

Tell the user: "Run the

fewer-permission-prompts

skill once on this project to seed
.claude/settings.json
with a deploy allowlist — otherwise every step will prompt." Pointer only. Never edit the user's settings here.

Phase 1 — Detect

Read

references/project-types.md

(skill-relative path — Claude resolves it against the installed skill directory) for the full fingerprint table. Inspect:

Package managers & manifests:

package.json

pnpm-lock.yaml

yarn.lock

package-lock.json

bun.lockb

pyproject.toml

requirements.txt

poetry.lock

uv.lock

Pipfile

Framework signals:

next.config.*

vite.config.*

astro.config.*

remix.config.*

nuxt.config.*

svelte.config.*

app/

pages/

main.py

with

FastAPI()

Flask()

app = FastAPI()

server.py

index.html

at root.

Runtime version:
```
.nvmrc
```
,
```
.node-version
```
,
```
engines
```
in
```
package.json
```
,
```
.python-version
```
,
```
python_version
```
in
```
pyproject.toml
```
. If a long-running target is chosen and no runtime is pinned, audit blocks.
DB / stateful deps: imports of
```
sqlalchemy
```
,
```
psycopg
```
,
```
prisma
```
,
```
mongoose
```
,
```
redis
```
,
```
ioredis
```
,
```
sqlmodel
```
. If found, surface "this service needs a database — provision one before prod" with the Railway add-on command from the Railway reference.
Port + start command:
```
uvicorn
```
,
```
gunicorn
```
,
```
next start
```
,
```
node server.js
```
,
```
python -m ...
```
. Check for
```
0.0.0.0
```
binding and
```
$PORT
```
usage. Localhost-only binding blocks for long-running targets.
Monorepo:
```
pnpm-workspace.yaml
```
,
```
turbo.json
```
,
```
nx.json
```
,
```
lerna.json
```
, or
```
"workspaces"
```
in root
```
package.json
```
→ enumerate packages and ask which one to deploy. Do not guess.
Library / CLI (not a web deploy): Node signal —
```
bin:
```
field present in
```
package.json
```
OR (
```
files:
```
array present AND no
```
scripts.start
```
AND no HTTP framework imports like
```
express
```
,
```
fastify
```
,
```
hono
```
,
```
next
```
,
```
koa
```
). Python signal —
```
[project.scripts]
```
/
```
console_scripts
```
in
```
pyproject.toml
```
AND no
```
uvicorn
```
/
```
gunicorn
```
/
```
flask
```
/
```
fastapi
```
in declared scripts or imports. Do not use
main:
alone as a library signal — almost every Node web app also sets
```
main:
```
. Exit cleanly: "This looks like a package —
/all-deploy
targets web services, not npm/PyPI publishes."
Existing deploy config:
```
vercel.json
```
,
```
railway.toml
```
,
```
fly.toml
```
,
```
Dockerfile
```
,
```
render.yaml
```
— respect, audit, do not regenerate without explicit ask.
Existing project linkage:
```
.vercel/project.json
```
→ reuse that Vercel project ID.
```
railway.toml
```
with
```
project
```
field → reuse. Re-deploy is the common case; fresh projects require an explicit "start fresh."

Output: a classification block and a ranked list of candidate targets with one-line rationale each. See

references/project-types.md

for the full target-ranking rubric.

Phase 2 — Audit (strict, blocking)

Run the audit script bundled with this skill (

scripts/audit.py

) against the current project directory. Claude resolves the skill path at load time — the invocation looks like:

python3 <SKILL_DIR>/scripts/audit.py <project-path>

Where

<SKILL_DIR>

is wherever the skill is installed (typically

~/.claude/skills/all-deploy/

) and

<project-path>

is usually

. The script checks every item in

references/audit-checklist.md

: secrets in tracked files,

.gitignore

coverage, lockfile sanity,

.env.example

completeness (via

scripts/env_extract.py

), build/start script existence, port binding, clean HEAD, git-remote match,

npm audit --production --audit-level=high

pip-audit

Any failure halts. For each issue, show the fix as a diff (if applicable) and wait for the user's OK before applying. Auto-mode does not bypass audit.

Git-history secret scan is user-run, not automatic. In the audit output, surface:

trufflehog git file://.

git log -p -S 'sk_' -S 'AKIA' -S 'ghp_'

as a separate step. The skill never rewrites git history.

Phase 3 — Target selection

Present the ranked candidates from Phase 1 with one-line rationales. User picks or accepts the top pick with "ok". Only now load the target reference:

```
references/targets/vercel.md
```
— Next, Vite, Astro, Remix, Nuxt, SvelteKit, static
```
references/targets/railway.md
```
— FastAPI, Flask, Express, Python workers, MCP HTTP, Claude Agent SDK
```
references/targets/docker-vps.md
```
— any Dockerfile, stateful workloads, self-hosted

references/targets/cloudflared-tunnel.md

— expose local dev, quick demo

For agent-shaped projects, also load

references/agents.md

for per-agent-type adjustments (FastAPI/Flask HTTP, MCP stdio vs HTTP, Claude Agent SDK script, generic Python worker).

Phase 3.5 — Target CLI installed + authenticated

With the target chosen, verify its CLI is installed and authenticated. Do not auto-install or auto-login — hand the user the command with a

prefix.

Vercel:

vercel whoami

(install:

npm i -g vercel

; login:

! vercel login

Railway:

railway whoami

(install:

npm i -g @railway/cli

brew install railway

; login:

! railway login

Docker + SSH:
```
ssh -o BatchMode=yes <host> true
```
(requires pre-configured SSH key);
```
docker --version
```
locally.

cloudflared:

cloudflared tunnel list

(install:

brew install cloudflared

; login:

! cloudflared tunnel login

If the check fails, stop and surface the install/login command. Resume from Phase 3.5 after the user reports done.

Phase 4 — Execute (preview first, always) + env-var delivery

Follow the target reference's preview playbook. First pass is always preview/staging — never

--prod

on this phase.

Long-running command handling. Deploy commands take 3–10 min; the default 2-min Bash timeout will kill them.

Default: run the deploy command via the Bash tool with
```
run_in_background: true
```
. You'll receive a completion notification when the CLI exits;
```
Read
```
the Bash output file at that point to parse the URL and detect errors. Do not chain
```
sleep
```
loops.
When you need an early line (e.g., Railway prints the preview URL mid-run, cloudflared prints the tunnel URL before settling): use the
```
Monitor
```
tool against the same output file with a regex that matches the URL pattern plus known error signatures (
```
Traceback
```
,
```
FAILED
```
,
```
error:
```
). Monitor emits each match as a notification; the first URL match is what Phase 4.5 probes.

Env-var delivery (before preview runs). Source of truth is the user's local

.env

(never committed). Push required keys to the target:

Vercel:

vercel env add <KEY> preview

then

vercel env add <KEY> production

(paste the value, or pipe it in —

echo -n "$value" | vercel env add <KEY> <env>

). Verify with

vercel env ls

Railway:
```
railway variables --set "KEY=value"
```
— one call per key. There's no bulk-import flag; loop in shell over your local
```
.env
```
(see
```
references/targets/railway.md
```
).

Docker+SSH:

scp .env.production user@host:/app/.env

or the

environment:

block in

docker-compose.yml

cloudflared: inherits local environment; no remote vars needed.

Never print values. Confirm keys only.

Phase 4.5 — Preview health check (BLOCKING)

Capture the preview URL from the deploy CLI's stdout. Each target reference documents the exact parsing step; examples:

Vercel: the preview URL is printed on the last non-empty stdout line, formatted like
```
https://<project>-<hash>-<scope>.vercel.app
```
.
Railway: look for
```
Deployment live at <url>
```
in the
```
railway up
```
output.
Docker+SSH: the URL is the user-configured
```
http://<host>[:port]
```
— the skill must ask or derive from
```
docker-compose.yml
```
port mappings.
cloudflared: the URL is printed as
```
https://<random>.trycloudflare.com
```
or the configured hostname.

Assign the captured URL to

$PREVIEW_URL

, then probe:

curl -sSL -o /dev/null -w "%{http_code}" "$PREVIEW_URL"

(No

-f

— that would suppress the

%{http_code}

output on HTTP errors.

-sSL

keeps curl silent on success but still surfaces transport errors and follows redirects.)

A 2xx or 3xx status promotes to Phase 5. 4xx/5xx, empty output (connection refused, DNS failure), or a curl non-zero exit → stop. Report the failing endpoint with the target's log command (

vercel logs

railway logs

ssh ... 'docker compose logs'

). Do not promote.

Optional visual verify. If

VISUAL_VERIFY: true

and the project is a frontend, use

chrome-bridge-automation

to screenshot the preview and confirm the page renders (not blank, not error page). Curl 2xx/3xx is still the gate; screenshot is a bonus.

Phase 5 — Prod promotion

full_auto

mode, after audit + preview health both pass:

Print a one-screen summary block: target URL, exact command about to run, DNS impact if any, cost implication. For pricing, prefer a live
```
deep-research
```
lookup of current Vercel/Railway pricing. If unavailable, link the provider's pricing page. Do not hardcode plan prices in this file.
Print: "Prod promotion in 5 seconds — press ESC to interrupt." Then issue a real
```
sleep 5
```
via the Bash tool as its own call. This is not theater — ESC during that sleep actually stops the turn. If the user does interrupt, do not issue the prod command on resume; ask what they want to do instead.
After the sleep returns cleanly, issue the prod command as a separate Bash call with
```
run_in_background: true
```
. Wait for the completion notification, then
```
Read
```
the Bash output file to extract the production URL. Use
```
Monitor
```
on the same output file only if you need to parse the URL before the CLI exits (Railway, cloudflared).

always_ask

mode, skip steps 2–3 and require an explicit "yes" in-turn before running the prod command. No sleep.

Respect interruption after preview. If between preview and prod the user types anything resembling hesitation (wait/hold/stop/not yet/abort), do not proceed to prod — treat the preview as the last green state and wait for explicit direction.

Phase 6 — Post-deploy verify + rollback surfacing

Curl the production URL; confirm status.

Confirm env vars are set on the remote (

vercel env ls

railway variables

ssh ... 'docker compose config'

Print the rollback path for this target (the user copies if needed later):
- Vercel:
```
vercel rollback
```
  (interactive picker) or
```
vercel rollback <previous-deployment-url>
```
  — verify current CLI syntax.
- Railway: no first-class
```
rollback
```
  command. Redeploy a prior commit:
```
git checkout <prev-sha> && railway up && git checkout -
```
  , or use the dashboard's Deployments → "Redeploy" on a prior build.
- Docker+SSH:
```
ssh <host> 'docker compose up -d --no-deps <service>'
```
  after re-tagging the prior image, or re-rsync a prior SHA and rebuild. See
```
references/targets/docker-vps.md
```
  for both flows.

Print the log-tail command:

vercel logs <url> --follow

railway logs --follow

ssh <host> 'cd /app && docker compose logs -f'

Target Selection — ranking rubric (quick reference)

Project signals	Top candidate	Why
`next.config.` , `vite.config.` , `astro.config.*` , SPA, SSG	Vercel	Zero-config, preview URLs, edge network
FastAPI / Flask / Express with long-running server	Railway	Simple, fast deploy, DB add-ons available
Any `Dockerfile` present, DB/volumes needed, self-host preference	Docker + SSH VPS	Full control, stateful-friendly
Local dev running, wants a quick public URL	cloudflared tunnel	No host needed, instant
MCP server	Railway (HTTP mode) or Docker+SSH	See `references/agents.md`
Claude Agent SDK script	Railway (worker mode) or cron	See `references/agents.md`

If signals conflict, present the top two with rationale and let the user pick.

Bundled Resources

```
scripts/audit.py
```
— deterministic pre-deploy audit. Invoked in Phase 2.
```
scripts/env_extract.py
```
— scans source for env-var usage, used by audit to verify
```
.env.example
```
completeness.
```
references/project-types.md
```
— full framework fingerprint table.
```
references/audit-checklist.md
```
— every audit rule explained with fix guidance.
```
references/env-mapping.md
```
— how env vars move between local
```
.env
```
and each target.
```
references/agents.md
```
— four agent shapes with per-type deploy adjustments.
```
references/targets/*.md
```
— one playbook per target, loaded only after Phase 3.
```
assets/templates/
```
— Dockerfile.node, Dockerfile.python, docker-compose.example.yml, .env.example.template.

Platform Notes

macOS + Linux only in v1. Windows community users should use WSL2 for path and shell compatibility.
All commands assume bash/zsh. Paths use POSIX conventions.
Network required for all cloud modes;
```
run locally
```
mode works offline.