ssh-vps-deployment
SkillWeb & browsingDeep knowledge about deploying applications to Baremetal servers or Virtual Private Servers (VPS) using SSH, SCP, Rsync, and PM2/Systemd.
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the ssh-vps-deployment skill
What this skill tells your AI
The instructions your AI receives, as published by porcupine-md/anoa-browser in .claude/skills/library/deploy/ssh-vps-deployment/SKILL.md and read by ahel’s review.
Context
Deploying {{project_name}} ({{project_type}}) to a VPS via SSH. You will follow a strict 6-phase Deployment Lifecycle Contract.
Instructions
Execute the following phases in order:
Phase 1: Authentication
- Ensure the SSH key is correctly configured (
~/.ssh/id_rsaor another identity file). - For automated agents, ensure the SSH key string is written to a file, its permissions are restricted (
chmod 600), and it is used correctly with thessh -icommand. - Test connectivity by running
ssh -i <path-to-key> -o StrictHostKeyChecking=no <user>@<host> "echo Authentication successful". If this fails, abort the deployment.
Phase 2: Build
- Prepare the artifacts for deployment.
- If this is a Node.js or static frontend application, run
npm run buildoryarn buildlocally to generate thedist/orbuild/directory. - If this is a compiled language (Go, Rust), run the appropriate build command (e.g.,
go build -o app main.go) ensuring the target architecture matches the VPS (e.g.,GOOS=linux GOARCH=amd64).
Phase 3: Install / Provisioning
- Ensure the target directory structure exists on the VPS. For example:
ssh -i <key> <user>@<host> "mkdir -p /var/www/{{project_name}}". - Ensure necessary dependencies (e.g., Node.js, Python, PM2, Nginx) are installed on the server. Do not automatically install these unless explicitly required by the project configuration.
- Stop the existing application process (e.g.,
pm2 stop {{project_name}}orsudo systemctl stop {{project_name}}) to prevent file lock issues during deployment.
Phase 4: Deploy
- Ship the artifact to the VPS.
- Use
rsync(preferred for speed and reliability) orscpto copy the necessary files to the VPS. Example:rsync -avz -e "ssh -i <key> -o StrictHostKeyChecking=no" dist/ package.json <user>@<host>:/var/www/{{project_name}}/. - SSH into the VPS and install production dependencies if necessary:
ssh -i <key> <user>@<host> "cd /var/www/{{project_name}} && npm ci --production". - Start the application process. E.g.,
pm2 start {{project_name}}orsudo systemctl start {{project_name}}.
Phase 5: Checking
- Verify the deployment was successful.
- SSH into the VPS and check the application status:
ssh -i <key> <user>@<host> "pm2 status {{project_name}}". - Check the application logs for any startup errors:
ssh -i <key> <user>@<host> "pm2 logs {{project_name}} --lines 50 --nostream". - Curl the application's public URL or local port to check for an HTTP 200 OK status. E.g.,
curl -sSf http://<host>orssh -i <key> <user>@<host> "curl -sSf http://localhost:<port>".
Phase 6: Update / Rollback
- If Phase 5 fails, immediately initiate a rollback.
- If using a rollback script, execute it. Otherwise, manually copy the backup files (if created during Phase 3/4) back into the deployment directory.
- Restart the application process using the old codebase (
pm2 restart {{project_name}}). - Note the failure in the progress log.
Validation
- SSH authentication succeeds.
- Local build succeeds.
- Files are transferred successfully.
- Remote installation/start succeeds.
- Health check (curl) returns 200 OK.
Signals
- GitHub stars
- 23
- Forks
- 2
- Last commit
- Sep 2026
ahel recommends instead
Advanced
- Catalog kind
- skill
- Gateway key
ssh-vps-deployment-porcupine-md- Source
- github.com/porcupine-md/anoa-browser