DEV Community: Pavan S

Most Developers Can Write the Code. Almost None of Them Can Ship It.

Pavan S — Thu, 25 Jun 2026 12:59:35 +0000

A real story about a job assignment, a broken Docker config, and a deployment that went live in minutes.

It started with a panic message

A developer reached out to us with 24 hours left on a DevOps job assignment.

The task: take a Task Manager application (already fully built) and deploy it to a live production server with:

Docker + Docker Compose
PostgreSQL, Redis, NGINX reverse proxy
GitHub Actions CI/CD pipeline
SSL setup
A real, accessible domain — not localhost

The code was done. That wasn't the problem.

The problem was everything that comes after the code.

The gap nobody talks about

Here's what most bootcamps, tutorials, and CS courses teach you:

✅ Write the code

✅ Make it work locally

✅ Push it to GitHub

Here's what they don't teach you:

❌ Write a production Dockerfile

❌ Configure NGINX as a reverse proxy

❌ Set up a CI/CD pipeline that actually deploys

❌ Get it running on a real server with a domain

This developer had spent hours on Stack Overflow, watching YouTube tutorials, and manually editing config files. Nothing worked. Docker wouldn't build. NGINX was misconfigured. The pipeline kept failing.

Sound familiar?

What happened when they used DevLauch

They connected their repository to DevPilot — our AI-powered DevOps platform.

Here's what happened in the next few minutes:

Task	Status
Dockerfile	✅ Generated and fixed
Docker Compose	✅ Configured (app + PostgreSQL + Redis)
NGINX reverse proxy	✅ Running
GitHub Actions CI/CD	✅ Pipeline live
Domain deployment	✅ Live on a real URL

Total time: minutes.

The live project: https://webvory-intern.devlauch.com

While other candidates submitted screenshots of apps running on localhost:3000, this developer submitted a fully deployed, publicly accessible application.

Why Docker + NGINX trips everyone up

Let's break down the two things that break 90% of deployment attempts.

Docker mistakes beginners make

# ❌ Wrong — copies everything, bloats the image
COPY . .

# ✅ Right — copy dependency files first, then install, then copy source
COPY package*.json ./
RUN npm install
COPY . .

Always use a .dockerignore file:

node_modules
.env
.git
*.log

NGINX reverse proxy — the config that actually works

server {
    listen 80;
    server_name yourdomain.com;

    location / {
        proxy_pass http://app:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

The key mistake most people make: they try to proxy to localhost inside the Docker network. Use the service name from your docker-compose.yml instead (in this case, app).

The Docker Compose structure that connects everything

version: '3.8'
services:
  app:
    build: .
    environment:
      DATABASE_URL: postgresql://user:password@db:5432/taskdb
      REDIS_URL: redis://redis:6379
    depends_on:
      - db
      - redis

  db:
    image: postgres:16
    environment:
      POSTGRES_DB: taskdb
      POSTGRES_USER: user
      POSTGRES_PASSWORD: password
    volumes:
      - postgres_data:/var/lib/postgresql/data

  redis:
    image: redis:alpine

  nginx:
    image: nginx:alpine
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf
    depends_on:
      - app

volumes:
  postgres_data:

The CI/CD pipeline that actually deploys

name: Deploy to Production

on:
  push:
    branches: [main]

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

      - name: Deploy to server
        uses: appleboy/ssh-action@master
        with:
          host: ${{ secrets.SERVER_HOST }}
          username: ${{ secrets.SERVER_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            cd /app
            git pull origin main
            docker compose down
            docker compose up -d --build

Store your secrets in GitHub → Settings → Secrets and variables → Actions.

The real lesson

The developer who came to us wasn't a bad engineer. They just hit the wall that almost every developer hits the first time they try to ship something for real.

The tools exist. The knowledge is out there. But it takes days to piece together — and when you have a 24-hour deadline, you don't have days.

That's why we built DevPilot.

You focus on the code. We handle the Dockerfile, the pipeline, the NGINX config, the server deployment — and when something breaks, our AI fixes it and redeploys automatically.

Whether it's a job assignment, a college project, a freelance client, or your startup's MVP — you deserve to ship it with confidence.

Try it yourself

🔗 Live student assignment: webvory-intern.devlauch.com

🚀 DevPilot: devlauch.com

📧 Questions: support@devlauch.com

Built something you can't ship? We can help. Drop a comment below or reach out directly.

Tags: devops docker nginx cicd beginners github-actions deployment webdev

DevPilot: I Built the IDP I Wish Existed as a DevOps Engineer

Pavan S — Fri, 05 Jun 2026 15:18:48 +0000

DevPilot: How I Finally Finished My IDP After Abandoning It for a Year

What I Built

DevPilot — a self-hosted Internal Developer Platform (IDP) that does in one UI what used to take a full platform team: connects your GitHub/Bitbucket repos, auto-generates Jenkinsfiles and Dockerfiles using AI, runs CI/CD pipelines, self-heals failed builds automatically, deploys to any VM via SSH, and provisions AWS infrastructure (EC2, RDS, S3) on demand.

No Backstage. No YAML sprawl. No plugin ecosystem to maintain. Just connect your repo and go.

GitHub repo:

pavan-3000 / DevopsPilot

The Problem I Was Solving

I was working as a DevOps engineer in India. Most of our developers were based in the US — which means their working hours are our midnight.

The pattern repeated itself every week:

A US developer hits a blocker at their 10am (our 10pm) — they need a new Jenkins pipeline, or an EC2 instance, or a Dockerfile fix
Our DevOps team is asleep
The developer waits. Half a day of productivity gone.
Or we get a call. Someone on the India team works through the night to unblock one developer on the other side of the world.

This wasn't a people problem. Our team was good. It was a process problem — developers shouldn't need to wait for a DevOps engineer to create a Jenkins job. That's not skilled work. It's a form.

I started asking: what if a developer could just click a button, pick their repo and branch, and have a working pipeline in 60 seconds? No Slack message. No ticket. No waiting for someone in a different timezone to wake up.

That's when I found Platform Engineering and the concept of an IDP — a self-service layer that puts pipeline creation, infrastructure provisioning, and build management directly in the developer's hands. My first attempt was Backstage.

The "Before" — The Abandoned Backstage Project

About a year ago I started building an IDP on top of Backstage (Spotify's open-source platform). I got excited. I read the docs. I cloned the repo.

Then reality hit:

Backstage is a framework, not a product. You still build everything yourself.
The plugin ecosystem is huge but poorly documented.
Kubernetes is basically required for production hosting.
Every config change meant rebuilding the entire catalog.
My day job kept interrupting — on-call rotations, release freezes, incident reviews.

After 3 months I had: a running Backstage instance that showed a software catalog. That's it. No pipelines. No automation. No healing.

I closed the laptop and didn't open that folder again for eight months.

The "After" — DevPilot

This challenge made me pick it up again. Except I didn't pick up Backstage — I threw it out and built what I actually needed.

DevPilot is the IDP I wish existed when I started as a DevOps engineer:

Connect in minutes

Link GitHub or Bitbucket via OAuth. Connect your Jenkins server with a URL + API token. That's the setup.

AI-powered pipeline creation

No Jenkinsfile? No Dockerfile? DevPilot generates both using Claude AI — a production-ready Dockerfile based on your language, and a Jenkinsfile with Docker build, Trivy security scan, registry push, and VM deploy stages pre-wired.

Self-healing CI

When a build fails, DevPilot reads the build log, asks the AI what's wrong, patches the Jenkinsfile or Dockerfile, pushes the fix to your repo, and retriggers the build — automatically, up to 5 times. Engineers wake up to a green build, not a Slack mention.

Infrastructure provisioning

EC2, RDS, S3 — provision from the UI. DevPilot generates the SSH keypair, spins the instance, bootstraps Docker, and registers it as a deploy target in under 5 minutes. Or sync your existing AWS resources with one click.

Command Center

A split-panel AI chat UI. Ask "what's failing?" or "give me a pipeline report" in plain English. Deploy, stop, or debug pipelines directly from the chat. Manage Docker containers running on your EC2 instances without leaving the browser.

How GitHub Copilot Helped

When I restarted this project, I used AI heavily throughout development — including GitHub Copilot for autocompletion in VS Code. The parts where it made the biggest difference:

AWS SDK v3 modular imports — the new @aws-sdk/client-* pattern was unfamiliar to me. Copilot correctly autocompleted CreateBucketCommand, PutPublicAccessBlockCommand, and the polling loop for DescribeInstanceStatus without me having to read the full SDK docs every time.
Jenkins XML config generation — the config.xml format for pipeline jobs is tedious. Copilot completed the XML template once I typed the opening tags, saving me from reading the Jenkins API docs for each credential type.
SSE (Server-Sent Events) streaming — I hadn't implemented SSE before. Once I typed res.setHeader('Content-Type', 'text/event-stream'), Copilot suggested the correct keep-alive, flush pattern, and cleanup on req.on('close') which I would have missed.
node-forge RSA keypair generation — unfamiliar library. Copilot autocompleted the async keygen call and the PEM export format on the first try.

The self-healing loop logic I wrote myself — it was the core innovation and I wanted full ownership of how it worked. But Copilot saved me hours on the boilerplate that surrounds the interesting parts.

Key Features (Before vs After)

Capability	Backstage attempt (Before)	DevPilot (After)
CI pipeline creation	Manual plugin setup, never finished	AI-generated Jenkinsfile, one wizard
Dockerfile	Not implemented	AI-generated on first push
Build failure recovery	Not implemented	Self-healing loop (5 retries, AI-patched)
Infrastructure	Not implemented	EC2 + RDS + S3 provisioning
AI integration	Not implemented	Claude/GPT throughout — generate, fix, analyze, chat
Deploy to VM	Not implemented	SSH deploy stage, docker pull + run
Status	Abandoned	Shipped

Technical Stack

Frontend: React 18, React Router v6, inline CSS (dark GitHub-style theme)
Backend: Node.js, Express 4, PostgreSQL 16
AI: Anthropic Claude (claude-haiku-4-5) or OpenAI GPT-4o-mini
AWS SDK: @aws-sdk/client-ec2, @aws-sdk/client-rds, @aws-sdk/client-s3 (v3)
SSH/Crypto: node-forge (RSA keypair gen), ssh2 (EC2 bootstrap)
Deploy: Docker + docker-compose, Nginx reverse proxy

What I Learned

Building this in the "finish-up" sprint taught me something I should have known earlier: the value of a product comes from finishing, not from architecting. Backstage is architecturally beautiful. DevPilot is a 4,000-line Express app. DevPilot is the one that actually solves the problem.

The self-healing loop is the feature I'm most proud of — not because it's technically impressive (it's a polling loop with an AI call inside), but because it's genuinely useful. The first time I watched it fix a broken Dockerfile at midnight without me touching anything, I understood why I built this.

What's Next

Rate limiting on auth endpoints (pre-beta blocker)
HTTPS + Let's Encrypt for public URL + working OAuth callbacks
Build history timeline (last 10 builds per pipeline)
Email/Slack notifications on build failure
GCP and Azure infrastructure support

Built solo during the GitHub Finish-Up-A-Thon challenge. The abandoned Backstage project was started in mid-2025. DevPilot was the restart.

"Building a Serverless REST API with AWS Lambda, API Gateway, and DynamoDB Using Python"

Pavan S — Sun, 27 Oct 2024 09:07:59 +0000

Overview

In this project, I developed a serverless REST API using AWS Lambda, API Gateway, and DynamoDB. The API enables CRUD operations on employee records, demonstrating how to leverage AWS's serverless architecture to build scalable, cost-effective applications.

Tech Stack

AWS Lambda: Executes CRUD functions without the need for server management.
API Gateway: Routes HTTP requests to specific Lambda functions.
DynamoDB: Stores employee records in a NoSQL database.
Python (boto3): Handles the application logic and database operations.

Step-by-Step Project Setup

Step 1: Set Up DynamoDB Table

Navigate to DynamoDB in the AWS Console and create a new table.
Table Name: employee_info.
Primary Key: employeeid (String).
Attributes: Define fields such as name, department, position, and salary.

DynamoDB offers a highly scalable NoSQL solution perfect for handling unstructured employee data.

Step 2: Create an IAM Policy

Sign in to the AWS Management Console.
Navigate to the IAM console.
In the left navigation pane, click on Policies.
Click on the Create policy button.
ADD policy for Dynamodb

Step 3: Write the Lambda Function Code

Create a Lambda function in Python that will handle requests for:

Retrieving all employees or a specific employee (GET).
Adding a new employee (POST).
Updating an employee's details (PATCH).
Deleting an employee record (DELETE)

Step 4: Create API Gateway Endpoints

Set Up API Gateway

Go to API Gateway and create a REST API.
Define Resources and Methods:
- /employee:
  - GET - Retrieve employee data.
  - POST - Add new employee.
  - PATCH - Update existing employee data.
  - DELETE - Remove an employee record.
- /employees:
  - GET - Retrieve all employees.
- /Status:
  - GET - Retrieve all employees Status.

Connect Methods to Lambda

For each HTTP method, connect the endpoint to the appropriate Lambda function.

Step 5: Deploy the API

Create a Deployment Stage in API Gateway.
Deploy the API to make the endpoints accessible.
Note the endpoint URL generated by API Gateway; this will serve as the base URL for the REST API.

Example Requests

GET /employee?employeeid=123

Retrieves data for employee with ID 123.

POST /employee

Adds a new employee.

Body:


json
  {
    "employeeid": "123",
    "name": "John Doe",
    "position": "Engineer",
    "salary": 60000
  }