agentleFS
prinxprinx/agents/skills/deploy-vps/SKILL.md

deploy-vps

Skill0 starsChanged 4 months agoMITView on GitHub

Use when deploying to a VPS via GitHub Actions and Docker.

  • Pipes a download into a shell
  • Reads credentials

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

14 rules. About 0 are common, 7 are distinctive, and 7 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈7

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 7

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Ask: Do you have Docker installed on your server?

    line 20
  2. Very specific:

    Run on the VPS: docker --version

    line 22
  3. Distinctive:

    If not installed, guide them:

    line 24
  4. Very specific:

    If the project does not have a Dockerfile, create one.

    line 30
  5. Very specific:

    If the project uses docker-compose.yml at the root, this works as-is.

    line 83
  6. Distinctive:

    If they already have one: copy the private key content.

    line 103
  7. Very specific:

    If not: run ssh-keygen -t ed25519 -f deploy_key on their local machine, then add the public key to the VPS ~/.ssh/authorized_keys.

    line 104
  8. Distinctive:

    Check the Actions tab in GitHub for the workflow run.

    line 111
  9. Very specific:

    If it passes, visit http://<their-vps-ip>:3000 (or their configured port).

    line 112
  10. Distinctive:

    If it fails, check the SSH step output for the specific error.

    line 113
  11. Very specific:

    After successful deployment, save to .agents/skills/deploy-project/SKILL.md:

    line 117
  12. Distinctive:

    Never print or log the SSH key, VPS credentials, or any secrets.

    line 138
  13. Very specific:

    Keep the Dockerfile minimal.

    line 139
  14. Distinctive:

    If the deploy fails, diagnose the specific step (build?

    line 140

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Deploy VPS

Deploy to a VPS using GitHub Actions and Docker. This is the simplest repeatable setup for VPS deployment: push to GitHub, GitHub Actions builds and deploys.

Prerequisites

Before starting, confirm:

  1. The project has a GitHub repository.
  2. The user has a VPS with SSH access.
  3. Docker is installed on the VPS (or will be installed).

Step 1 — Check Docker on VPS

Ask: Do you have Docker installed on your server?

Run on the VPS: docker --version

If not installed, guide them:

  • Ubuntu/Debian: curl -fsSL https://get.docker.com | sh
  • Then: sudo usermod -aG docker $USER (they may need to log out and back in)

Step 2 — Create Dockerfile

If the project does not have a Dockerfile, create one. Keep it simple:

# Use the smallest appropriate base image
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM node:20-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
COPY --from=builder /app/package.json ./
EXPOSE 3000
CMD ["node", "dist/index.js"]

Adjust for the project's stack (Python, Go, etc.). Ask the user what their project uses if unclear.

Step 3 — Create GitHub Actions workflow

Create .github/workflows/deploy.yml:

name: Deploy to VPS

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Deploy via SSH
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.VPS_HOST }}
          username: ${{ secrets.VPS_USER }}
          key: ${{ secrets.VPS_SSH_KEY }}
          script: |
            cd /opt/${{ github.event.repository.name }}
            git pull
            docker compose down
            docker compose build
            docker compose up -d

If the project uses docker-compose.yml at the root, this works as-is. If not, suggest a simple one:

services:
  app:
    build: .
    ports:
      - "3000:3000"
    restart: unless-stopped

Step 4 — Set up GitHub secrets

Tell the user to add three secrets in their GitHub repo (Settings > Secrets and variables > Actions):

  1. VPS_HOST — their server IP or domain
  2. VPS_USER — the SSH username (e.g. root or deploy)
  3. VPS_SSH_KEY — the private SSH key for connecting

For the SSH key, tell them:

  • If they already have one: copy the private key content.
  • If not: run ssh-keygen -t ed25519 -f deploy_key on their local machine, then add the public key to the VPS ~/.ssh/authorized_keys.

The agent never handles these values. The user adds them in GitHub.

Step 5 — First deploy

Push to main. GitHub Actions will run the workflow. Tell the user to:

  1. Check the Actions tab in GitHub for the workflow run.
  2. If it passes, visit http://<their-vps-ip>:3000 (or their configured port).
  3. If it fails, check the SSH step output for the specific error.

Save as project skill

After successful deployment, save to .agents/skills/deploy-project/SKILL.md:

---
name: deploy-project
description: Deploy this project to the VPS via GitHub Actions.
---

# Deploy Project

Push to `main` on GitHub. GitHub Actions builds and deploys to the VPS automatically.

- **VPS**: <host>
- **Port**: 3000 (or as configured)
- **Check**: visit http://<host>:3000
- **Logs**: SSH to VPS, run `docker compose logs -f`
- **Restart**: SSH to VPS, run `docker compose restart`

Rules

  • Never print or log the SSH key, VPS credentials, or any secrets.
  • Keep the Dockerfile minimal. Do not add monitoring agents, log shippers, or complexity unless the user asks.
  • If the deploy fails, diagnose the specific step (build? SSH? Docker?) before suggesting fixes.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.