agentleFS
takimdigitaltakimdigital/saas-pipeline/skills/03-deploy-vps/SKILL.md

deploy-vps

Skill1 starsChanged 2 months agoMITView on GitHub

Use when the app needs to go live on the user's own server, when PIPELINE_STATUS.md says current_phase: ready_to_deploy, or when the user mentions Coolify, a VPS, a domain, DNS, SSL/HTTPS, server hardening, backups, rollbacks, or uptime alerts. Not for choosing a boilerplate or building features.

  • Commits and pushes

1 other project uses a version of this.

Adopted by

Most recently taken up by

  • Other versions1 project uses a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 1

    1. prinx/agents★ 0same name

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • In this repository7 other files it gives its agents.

The file

We split this skill into the rules it gives an agent

3 rules. About 0 are common, 1 is distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Run the dynamic-skill-discovery check (shared/references/dynamic-skill-discovery.md) for the Coolify reference (bundled).

    line 29
  2. Very specific:

    Update PIPELINE_STATUS.md section 4 with what's confirmed.

    line 37
  3. Distinctive:

    If a deploy notification channel is set up (it should be, per the checklist), you'll get a pass/fail notification automatically — don't …

    line 62

≈ “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

Phase 3 — Deploy to VPS

Goal: the app is live at the user's domain, over HTTPS, deployed via Coolify on their own VPS, hardened, with auto-deploy-on-push, database backups, and alerts wired up so the user finds out about problems from a notification, not from a customer complaint. The user understands, in plain language, how to check on it later.

Read PIPELINE_STATUS.md in full first. Section 3 tells you what's actually in the repo to deploy; section 4 tells you what's already been done in deployment if resuming.

This phase has 4 reference files — read the one relevant to the step you're on, not all 4 at once:

  • references/coolify.md — install, deploy-from-git, domains/SSL, databases
  • references/security-hardening.md — VPS + Coolify + app-level security, done once, checked periodically
  • references/alerting-monitoring.md — notifications and uptime monitoring, so problems surface automatically
  • references/one-time-deploy-checklist.md — the ordered first-deploy checklist, per-step

Step 0 — Check what the user already has

Run the dynamic-skill-discovery check (shared/references/dynamic-skill-discovery.md) for the Coolify reference (bundled). Ask the user plainly:

  1. VPS already? Not yet → shared/references/user-setup-guides.md has the buy-a-VPS steps — point there instead of improvising.
  2. Coolify installed on it? Not yet → checklist covers install.
  3. Domain pointed at it? Not yet → user-setup-guides.md covers buying a domain + the A record steps.

Update PIPELINE_STATUS.md section 4 with what's confirmed. "Probably" isn't "yes" — don't proceed past what's actually confirmed.

Cost of the VPS + domain are the two accepted recurring costs — nothing else should be.

Step 1 — Run the one-time deploy checklist

For a first-ever deploy of this project, follow references/one-time-deploy-checklist.md top to bottom — it's ordered deliberately (e.g. security hardening happens before exposing the app to real traffic, not after). Don't skip ahead to "just get it live" and come back for security/alerting later — that's how those steps quietly never happen.

For a redeploy of an already-live project (most of Phase 3 work after the first time), skip to Step 2 below instead — the full checklist is a one-time-per-VPS/one-time-per-project thing, not a per-deploy thing.

Step 2 — Ordinary redeploys (project already live once)

  1. Change should already be on main via the branch+CI+merge sequence (shared/references/ci-and-branching.md) — this step is what happens after that, not a substitute for it.
  2. Coolify's webhook triggers the build automatically — watch it complete.
  3. Actually visit the live URL (via a web fetch/browser tool if available) to confirm it's really serving the new version — a successful build with a broken runtime is a common failure mode that "build succeeded" alone won't catch.
  4. If a deploy notification channel is set up (it should be, per the checklist), you'll get a pass/fail notification automatically — don't rely solely on watching the dashboard.

Step 3 — Record and hand off

Fill in PIPELINE_STATUS.md section 4 completely on first deploy — all of it, not a partial subset: vps_provider, vps_ip_or_host (or a note that it's stored securely elsewhere if the user prefers not to record the raw IP in a git-committed file), domain_name, coolify_installed: yes, coolify_project_id, deployment_method, ssl_status, first_deploy_date, deploy_url_live, security_checklist_done (per Part B of the checklist), backups_configured (only yes if actually verified to land, per Part D), alerting_configured: yes/no + which channel. Skipping the security/backup fields here because "they're not the deploy itself" is exactly how they end up permanently unknown for the next session.

Set current_phase: live.

Tell the user, in plain language: the app is live at [URL], here's how they'll find out if something breaks (the alert channel they chose), and what they should never do themselves (e.g. don't manually edit files on the server — always go through git push so history stays intact). Mention 04-maintain-evolve exists for future changes.

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.