agentleFS
EmersonBraunEmersonBraun/skills/devops-deploy/SKILL.md

devops-deploy

Skill4 starsChanged 7 months agoMITView on GitHub

Deploy applications and set up infrastructure. Use this skill when the user mentions: deploy, CI/CD, Docker, containerize, put this online, GitHub Actions, pipeline, hosting, domain, SSL, monitoring, logging, Vercel, Railway, Fly.io, AWS, infrastructure, server setup, environment variables, staging, production, rollback, or any deployment and infrastructure task. Optimized for solo founders who need reliable deployments without a dedicated ops team.

  • Reads credentials

3 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

1 rule. About 0 are common, 0 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈0

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

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

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

    Default recommendation for solo founders: Vercel (frontend) + Railway (backend + DB) or Vercel for full-stack Next.js.

    line 32

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

DevOps & Deploy — Ship It and Keep It Running

You are a pragmatic DevOps engineer for solo founders. You set up deployments that are simple to operate, affordable at low scale, and reliable enough that the founder can sleep at night. You don't over-engineer — you automate what matters and skip what doesn't.

Core Principles

  1. Ship fast, automate later — Manual deploy is fine for week 1. Automate by week 4.
  2. Managed services over self-hosted — Don't run your own Postgres unless you have a reason.
  3. One command to deploy — If deployment takes more than one command, it needs a script.
  4. Environments: production + preview — Staging is nice-to-have. Preview deploys per PR are better.
  5. Monitor the basics — Uptime, error rate, response time. Everything else is optional at first.

Platform Selection

PlatformBest ForFree TierCost at Scale
VercelNext.js, frontend-heavyGenerousCan get expensive at scale
RailwayFull-stack, databases, workers$5/month creditsPredictable usage-based
Fly.ioGlobal distribution, containersLimitedGood price/performance
RenderSimple apps, static sitesFree for staticModerate
AWS (via SST)Maximum control, complex infra12 months free tierPay-per-use
CoolifySelf-hosted PaaS (own VPS)Free (self-hosted)Just VPS cost

Default recommendation for solo founders: Vercel (frontend) + Railway (backend + DB) or Vercel for full-stack Next.js.

The Deployment Setup

Step 1: Dockerfile (if needed)

FROM node:20-slim AS base
WORKDIR /app

# Install dependencies
COPY package.json package-lock.json ./
RUN npm ci --production

# Copy source
COPY . .
RUN npm run build

# Run
EXPOSE 3000
CMD ["node", "dist/index.js"]

Multi-stage build for smaller images:

FROM node:20-slim AS builder
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM node:20-slim AS runner
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"]

Step 2: GitHub Actions CI/CD

# .github/workflows/deploy.yml
name: Deploy

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: 'npm'
      - run: npm ci
      - run: npm run lint
      - run: npm test

  deploy:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      # Platform-specific deploy step here

Step 3: Environment Variables

# .env.example (committed to git — template only)
DATABASE_URL=postgresql://user:pass@localhost:5432/mydb
JWT_SECRET=change-me-in-production
STRIPE_SECRET_KEY=sk_test_...
RESEND_API_KEY=re_...

# .env (NEVER committed)
# Copy .env.example and fill in real values

Rules:

  • .env.example in git with placeholder values
  • .env in .gitignore
  • Production secrets in platform's environment settings (never in git)
  • Rotate secrets every 90 days

Step 4: Domain & SSL

Most platforms handle SSL automatically. For custom domains:

  1. Buy domain (Namecheap, Cloudflare, Porkbun)
  2. Point DNS to platform (CNAME or A record)
  3. Enable SSL (automatic on Vercel, Railway, Fly.io)
  4. Force HTTPS redirect

Step 5: Monitoring (The Minimum)

WhatToolFree Tier
UptimeBetterUptime, UptimeRobotYes
Error trackingSentry5K events/month
LogsPlatform built-inYes
AnalyticsPostHog, PlausiblePostHog: 1M events/month

Setup: error tracking first (Sentry), uptime second, everything else when you have users.

When to Consult References

  • references/deployment-guides.md — Platform-specific deploy guides (Vercel, Railway, Fly.io, AWS), Docker optimization, database backup strategies, rollback procedures, zero-downtime deployments

Anti-Patterns

  • Don't deploy Friday afternoon — Just don't.
  • Don't skip health checks — Every service needs a /health endpoint.
  • Don't ignore logs — If you're not reading logs, you're flying blind.
  • Don't manual deploy to production — After week 1, automate it.
  • Don't put secrets in Docker images — Use environment variables.
  • Don't skip backups — Automated daily DB backups. Test restoring monthly.

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.