DEV Community: Jedsadakorn Suma

I built a deploy template pack for vibe-coded apps — here's what's inside and how I made it

Jedsadakorn Suma — Fri, 17 Apr 2026 09:45:54 +0000

I kept repeating the same painful cycle: build something in Cursor, then spend 2-3 hours copy-pasting Dockerfiles,
debugging nginx SSL configs, and fixing GitHub Actions YAML before I could actually ship.

So I packaged everything into Vibe Deploy Kit.

## What I built

3 deployment template packs, each covering a different stack:

next-production-kit → Next.js 14+ to Vercel or self-hosted VPS
fastapi-deploy-kit → FastAPI + Python to Railway (free tier)
react-supabase-kit → React + Vite + Supabase to Vercel

## How I built it

Started by listing every file I was copy-pasting project to project. Turned out it was always the same ~5 files:

Dockerfile (multi-stage, non-root user, Alpine base)
docker-compose.yml (app + nginx services, healthcheck)
nginx.conf (rate limiting, SSL, security headers, gzip)
GitHub Actions workflow (preview on PR, prod on push to main)
.env.example (every required variable documented)

## next-production-kit — the Dockerfile

Multi-stage build keeps the final image small. Non-root user for security:

  FROM node:20-alpine AS deps
  WORKDIR /app
  COPY package.json package-lock.json* pnpm-lock.yaml* yarn.lock* ./
  RUN \
    if [ -f package-lock.json ]; then npm ci; \
    elif [ -f pnpm-lock.yaml ]; then corepack enable pnpm && pnpm i --frozen-lockfile; \
    else npm i; fi

  FROM node:20-alpine AS runner
  RUN addgroup --system --gid 1001 nodejs \
    && adduser --system --uid 1001 nextjs
  COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./
  USER nextjs
  CMD ["node", "server.js"]

Requires output: 'standalone' in next.config.js.

## fastapi-deploy-kit — rate limiting

The FastAPI kit uses slowapi so you don't get hammered on Railway's free tier:

  from slowapi import Limiter
  from slowapi.util import get_remote_address

  limiter = Limiter(key_func=get_remote_address)

  @app.get("/api/hello")
  @limiter.limit("30/minute")
  async def hello(request: Request):
      return {"message": "Hello"}

## react-supabase-kit — the client setup

One thing vibe-coded apps almost never have is a proper ErrorBoundary. The kit includes one, plus a Supabase client
with auto-refresh:

  export const supabase = createClient(url, anonKey, {
    auth: {
      autoRefreshToken: true,
      persistSession: true,
      detectSessionInUrl: true,
    },
  });

## nginx WebSocket config

If you're self-hosting Next.js, you need this or hot reload breaks:

  proxy_http_version 1.1;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection "upgrade";

## Tools used

Docker + nginx for self-hosted path
Vercel + Railway + Supabase for zero-cost cloud path
GitHub Actions for CI/CD
Gumroad for distribution

## Result

A ZIP you drop into any project. Fill in .env, push to main → deployed.

Available for $9: peachjed.gumroad.com/l/frosbp

Self-host Open WebUI + Ollama in production — the config nobody writes about

Jedsadakorn Suma — Fri, 17 Apr 2026 09:38:33 +0000

Open WebUI's quickstart is great for local dev. One command, it's running. But putting it on a real server for a team
requires a lot more — SSL, auth lockdown, WebSocket proxy, backups.

Here's the full production config I use.

## The stack

ollama — LLM runner
openwebui — Chat UI
nginx — Reverse proxy + SSL

## The nginx config that trips everyone up

Open WebUI uses WebSockets for streaming. Without this, responses just hang:


nginx
  proxy_http_version 1.1;
  proxy_set_header Upgrade $http_upgrade;
  proxy_set_header Connection "upgrade";
  proxy_read_timeout 300s;

  Also set client_max_body_size 50M — users will upload documents and images.

  Lock down auth

  By default Open WebUI allows anyone to sign up. For a team setup:

  WEBUI_AUTH=true
  ENABLE_SIGNUP=false

  Now only the admin can create accounts. Add SMTP config to send email invites.

  GPU passthrough (NVIDIA)

  In docker-compose.yml, uncomment:

  deploy:
    resources:
      reservations:
        devices:
          - driver: nvidia
            count: all
            capabilities: [gpu]

  Then install nvidia-container-toolkit and restart. Without this, Ollama runs on CPU — still works but much slower.

  Automated backups

  docker run --rm \
    --volumes-from "$(docker compose ps -q openwebui)" \
    -v "$(pwd)/backups:/backup" \
    alpine \
    tar czf "/backup/openwebui_$(date +%Y%m%d).tar.gz" /app/backend/data

  Add to cron: 0 2 * * * /opt/openwebui/scripts/backup.sh

  Recommended free VPS

  Oracle Cloud Always Free — 4 vCPU / 24GB RAM ARM. Enough for llama3.2 (2B) with a small team.

  Full kit

  I packaged everything above into a ZIP — docker-compose, nginx config, backup + model scripts, .env.example.

  Gumroad: https://peachjed.gumroad.com/l/cazucc

I built a runbook generator with FastAPI and Groq — here's how it works

Jedsadakorn Suma — Fri, 17 Apr 2026 09:08:31 +0000

Every time there's an incident or a deployment, I need a runbook. The structure is always the same: Overview → Prerequisites → Procedure → Verification → Troubleshooting → Rollback.

I got tired of filling in the same skeleton over and over, so I built Auto Runbook Generator.

What it does

Paste a Kubernetes YAML, a docker-compose file, or just describe your system in plain English. Pick a runbook type (deployment, incident response, rollback, maintenance, onboarding). Get a complete Markdown runbook back in seconds.

Live demo: https://auto-runbook-gen-v0-1-0.onrender.com

How I built it

Backend: FastAPI + AsyncGroq

The core is a single /api/generate endpoint. It takes the user's input and runbook type, builds a prompt, and calls Groq's API with llama-3.3-70b.

response = await get_groq().chat.completions.create(
    model="llama-3.3-70b-versatile",
    messages=[
        {"role": "system", "content": SYSTEM_PROMPT},
        {"role": "user", "content": user_prompt},
    ],
    max_tokens=2048,
    temperature=0.3,
)

I use AsyncGroq (not Groq) because FastAPI is async — calling a sync client inside an async endpoint blocks the event loop.

Rate limiting: slowapi

Free tier gets 10 generations/day per IP. Pro API key bypasses this.

@app.post("/api/generate")
@limiter.limit("10/day")
async def generate(request: Request, ...):

The system prompt matters a lot

The prompt enforces a consistent structure with 6 sections every time:

# [Service Name] Runbook
## Overview
## Prerequisites
## Procedure
## Verification
## Troubleshooting
## Rollback

Low temperature (0.3) keeps outputs consistent and factual rather than creative.

Frontend: zero dependencies

Single HTML file, vanilla JS. fetch() to call the API, navigator.clipboard to copy the result. No React, no build step.

Deploy: Docker on Render

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000"]

Results

The output quality is good enough to use directly for most common cases. Kubernetes and Docker scenarios work especially well since the LLM has strong training data for those.

Source

GitHub: https://github.com/Jedsadakorn-Suma/auto-runbook-gen

Self-hostable (MIT). Needs a free Groq API key from console.groq.com.

I built 3 MCP servers so I can ask Claude about my DevOps stack

Jedsadakorn Suma — Fri, 17 Apr 2026 07:01:04 +0000

Every time something looked off in production, I'd switch between 4 tabs:
Prometheus → check metrics, kubectl → check pods, Grafana → check dashboards, terminal → check logs.

So I built MCP DevOps Pack — 3 MCP servers that let Claude Desktop talk to your infra directly.

## What's included

| Package | What it does |
|---------|-------------|
| @peachjed/mcp-prometheus | PromQL queries, firing alerts, rule inspection |
| @peachjed/mcp-kubernetes | List pods, get logs, describe resources, watch events |
| @peachjed/mcp-grafana | Search dashboards, list datasources, check alert states |

## Install


bash
  npm install -g @peachjed/mcp-prometheus @peachjed/mcp-kubernetes @peachjed/mcp-grafana

  Configure Claude Desktop

  Add to your claude_desktop_config.json:

  {
    "mcpServers": {
      "prometheus": {
        "command": "mcp-prometheus",
        "env": { "PROMETHEUS_URL": "http://localhost:9090" }
      },
      "kubernetes": {
        "command": "mcp-kubernetes"
      },
      "grafana": {
        "command": "mcp-grafana",
        "env": {
          "GRAFANA_URL": "http://localhost:3000",
          "GRAFANA_TOKEN": "your-token"
        }
      }
    }
  }

  What you can ask Claude

  - "What's the current CPU usage across all nodes?"
  - "Show me the last 50 lines from pod api-server-xyz in production"
  - "Are there any firing alerts right now?"
  - "List all dashboards in the Infrastructure folder"

  How it works

  Each server is a small TypeScript process that runs locally via stdio. Claude Desktop spawns it automatically when
  needed. The Kubernetes server uses your existing ~/.kube/config — no extra auth setup.

  Stack

  - TypeScript + @modelcontextprotocol/sdk
  - @kubernetes/client-node for the k8s server
  - Prometheus and Grafana via their HTTP APIs

  Source

  GitHub: https://github.com/Jedsadakorn-Suma/mcp-devops-pack

  npm: @peachjed/mcp-prometheus, @peachjed/mcp-kubernetes, @peachjed/mcp-grafana

  Feedback welcome — especially if you use a different observability stack.