DEV Community: Prince

Counting "repeated questions" in exam PDFs: the rule that keeps the numbers honest

Prince — Sun, 01 Nov 2026 04:39:46 +0000

When I tallied GTU (Gujarat Technological University) Physics papers for juniors, the hardest part was not the code. It was deciding what "repeated" means, so the numbers do not lie to you.

The setup

22 official GTU Physics question papers, Summer 2022 to Summer 2026, across three subject codes (3110011, 3110018 and the new BE01000021), downloaded from GTU's own repository. Text came out with pdftotext, then every sub-question, including the OR options, got a topic tag.

Rule 1: count a topic once per paper

If Ruby laser shows up in Q.3(c) and again in Q.5(a) OR, that is still one paper. Otherwise a single paper that loves lasers inflates the count.

from collections import defaultdict

def papers_per_topic(tagged):
    # tagged: list of (paper_id, topic) for every sub-question
    seen = defaultdict(set)
    for paper_id, topic in tagged:
        seen[topic].add(paper_id)
    return {t: len(p) for t, p in seen.items()}

The set does all the work. Topic count = number of distinct papers it appeared in.

Rule 2: deduplicate identical files

Two BE01R00021 PDFs turned out to be byte-for-byte the same files as BE01000021 papers (the header literally says "BE01000021/BE01R00021"). Counting them twice would have doubled the evidence for free. A hash check catches this:

import hashlib, pathlib

def unique_pdfs(folder):
    seen = {}
    for f in sorted(pathlib.Path(folder).glob("*.pdf")):
        h = hashlib.sha256(f.read_bytes()).hexdigest()
        seen.setdefault(h, f)
    return list(seen.values())

So BE01000021 ended up with 4 papers, not 6.

Rule 3: say when extraction failed

A few lines in two 3110018 papers (Summer 2025 and Summer 2026) did not come out as text. Those two may be slightly under-counted, and the write-up says so instead of pretending.

What the honest numbers showed

For 3110018 (Group 2 Physics), solar cell or photovoltaic effect appeared in 9 of 9 papers. Kronig-Penney, hot point probe and four probe method each hit 7 of 9. Some questions repeated word for word, like "Kronig and Penney model explains origin of band gap" in W2022, S2024 and W2025.

Past repetition is a pattern, not a promise. But with these three rules, at least the pattern is real.

I put the papers on GTU Hero if you want to check the Winter 2025 one yourself.

Modelling GTU's 4-backlog detain rule in 15 lines of Python

Prince — Sat, 31 Oct 2026 04:40:26 +0000

I keep seeing GTU (Gujarat Technological University) juniors panic about the "4 backlog" rule, and half of them count it wrong. The rule has one twist that makes it a nice little exercise in code.

The rule

A backlog is a subject with an FF grade (below 35 marks). Missing the exam also counts as not cleared.
At any time you can carry at most 4 pending backlogs. More than 4 and you can be detained for one year.
Backlogs from the semester just before your current one are not counted.

That last line is the bug in most people's mental model.

The code

def detention_check(current_sem: int, pending: dict[int, int]) -> tuple[int, bool]:
    """pending maps semester -> number of FF subjects still not cleared."""
    just_previous = current_sem - 1
    counted = sum(
        n for sem, n in pending.items()
        if sem < just_previous
    )
    return counted, counted > 4


# Sem 4 student: 2 in Sem 1, 1 in Sem 2, 3 in Sem 3 (6 total)
print(detention_check(4, {1: 2, 2: 1, 3: 3}))  # (3, False) -> safe

# Same student moves to Sem 5 and clears nothing
print(detention_check(5, {1: 2, 2: 1, 3: 3}))  # (6, True) -> detained

Same backlogs, different semester, opposite result. A backlog that is "free" today gets counted the moment you move up, so the real deadline for clearing a paper is one semester later than it looks.

What the function does not cover

Students admitted from 2018-19 onward follow a stricter table from GTU circular 5440 (19 July 2018), where certain semesters must be fully cleared before you enter the semester two years ahead.
Attendance: you need at least 75% to fill the exam form at all.

So treat this as a sanity check, not a verdict. Your college exam cell has the final word for your batch.

The full write-up, with the 2018 table, fees and a semester-by-semester plan, is on GTU Hero. Disclosure: I build GTU Hero.

A 4-hour GTU syllabus unit showed up in all 9 Maths 1 papers. Here is the data

Prince — Thu, 29 Oct 2026 04:38:36 +0000

Disclosure: I built GTU Hero, a GTU previous-papers site. This count was done on GTU's own question paper repository and is not tied to anything you need to buy.

Bhai, every GTU first-year student has heard "Fourier toh chhota chapter hai, skip kar". So I checked. I took the 9 official Mathematics-1 papers for subject code 3110014 (Summer 2022 to Summer 2026) from GTU's own repository (gtu.ac.in/Download1.aspx) and counted every topic, one count per paper, OR options included.

Syllabus hours vs exam reality

In the official 3110014 syllabus, Unit 3 (Fourier series and half range expansions) is 4 hours and 10% weightage. The smallest unit on paper.

It appeared in all 9 papers, usually as a 7 marker.

The seven topics that appeared in all 9 papers

Topic	Unit	Papers (of 9)
Fourier series (full or half range)	3	9/9
Local extreme values of f(x, y)	4	9/9
Change of order of integration	5	9/9
Solving a linear system (Gauss elimination or Gauss-Jordan)	6	9/9
Eigenvalues and eigenvectors	6	9/9
Taylor or Maclaurin series, or approximation	2	9/9
L'Hospital and indeterminate forms	1	9/9

Same Fourier sum, different year

Not "similar type". Same question:

Fourier series of x² on (−π, π): S2022 Q.2(c), S2025 Q.1(c), S2026 Q.2(c) OR
Fourier series of (π − x)/2 on (0, 2π), deduce π/4 = 1 − 1/3 + 1/5 − ...: S2024 Q.3(c) OR, S2026 Q.2(c)
Fourier series of x + |x| on (−π, π): W2022 Q.2(c), W2024 Q.2(c) OR

One thing that almost broke the count

The Winter 2025 PDF gave only 587 characters from pdftotext, which is just the header. The questions were images. So I read those pages as images instead. If you ever count papers yourself, check text length per file, otherwise a paper silently counts as "no questions".

Important: check your subject code

The newer codes BE01000041 and BE01R00041 do not have Fourier series or the matrix unit in their official syllabus. So this whole post is for 3110014 students. New-code students, ignore the Fourier and eigenvalue part.

How to use this

Do the 9/9 topics first, then the rest of the syllabus. Past repetition is a pattern, not a promise, so do not skip units. If you want to see what a recent paper looks like, here is the Winter 2025 Maths 1 paper on GTU Hero.

All the best for exams. Fourier ko halke mein mat lena.

How I count repeated questions across 44 GTU exam papers (and what broke)

Prince — Wed, 28 Oct 2026 04:40:58 +0000

Disclosure: I built GTU Hero, a site that shows GTU previous-year papers with repeated questions highlighted. This post is about the counting exercise behind it.

Students at Gujarat Technological University (GTU) love "IMP question" lists. Google autocomplete suggested phrases like gtu imp question bank sem 2 when I checked in October 2026. The problem with most of those lists is that nobody says where they came from.

So I tried a boring question first: if you take the official papers for one subject and just count, what actually repeats? No ML, no scraping tricks. A folder of PDFs, a spreadsheet and some Python. This post is the build story, including the parts that broke.

The dataset

I counted 44 official papers across three first-year subjects:

Subject	Code	Papers
Mathematics-2	3110015	9 (Summer 2022 to Summer 2026)
Mathematics-1	3110014	9 (same sessions)
Mathematics-1	BE01000041	4 (Winter 2024 to Summer 2026)
Physics	3110011	9
Physics	3110018	9
Physics	BE01000021	4

Every PDF came from GTU's own question paper repository (gtu.ac.in/Download1.aspx: pick a session, pick BE, search the subject code). No third-party uploads, so anyone can rebuild the numbers.

Step 1: get text out of the PDFs

I ran pdftotext on every file and checked the output length. Most papers gave somewhere between 3,000 and 8,000 characters. Then there was the Winter 2025 paper for 3110014. The PDF is about 195 KB, but pdftotext returned 587 characters, which is just the header: subject code, date, time, total marks. The questions were images.

That is the first lesson: a length check per file catches silent extraction failures. If I had only looked at the combined output, I would have counted that paper as "has no questions". For the image-based papers I read the pages as images instead.

Step 2: decide what a "topic" is

This is the part no library does for you. I tagged every sub-question, OR options included, with a topic like "Green's theorem" or "Ruby laser". The rule that kept the counts honest:

A topic counts once per paper if it appears anywhere in that paper, compulsory question or OR option.

Without that rule, a paper with Green's theorem in both Q.1 and an OR option would count twice and inflate the repeat rate.

Judgement calls still happen. One Summer 2025 Mathematics-2 question solves an initial value problem without the word "Laplace" in it, but it sits in the Laplace question, so I counted it as Laplace. Calls like that are noted in the data so someone else can disagree.

Step 3: a long CSV, not a wide one

My first version was a wide sheet: one row per topic, one column per session. It is nice to read and annoying to validate. The shipped version is long: one row per topic per paper, with a 0 or 1.

subject_code,subject,topic,unit_or_module,session,appeared,position
3110015,Mathematics-2,Green's theorem (evaluate/verify),,S2022,1,Q2c-OR
3110015,Mathematics-2,Green's theorem (evaluate/verify),,S2023,1,Q1c

Long data means the summary can be recomputed and checked against the hand-built one:

import csv
from collections import defaultdict

hits = defaultdict(int)
checked = defaultdict(int)

with open("data/topic_by_paper.csv", newline="", encoding="utf-8") as f:
    for r in csv.DictReader(f):
        key = (r["subject_code"], r["topic"])
        checked[key] += 1
        hits[key] += int(r["appeared"])

for (code, topic), n in sorted(hits.items(), key=lambda kv: -kv[1]):
    if code == "3110015" and n == checked[(code, topic)]:
        print(f"{n}/{checked[(code, topic)]}  {topic}")

Nothing clever. My rebuild script does the same thing and fails loudly if a count in the summary file does not match the per-paper rows, so the two files cannot drift apart.

What the counts showed

Mathematics-2 (3110015), 9 papers. I tagged 22 topics. Nine appeared in all 9 papers: Green's theorem, div/curl checks, Fourier integral, a Laplace initial value problem, variation of parameters, undetermined coefficients, Euler-Cauchy equations, equations not of first degree (p and Clairaut), and power series solutions. Green's theorem sat in the compulsory Q.1(c) in 8 of the 9 papers.

Syllabus hours are not exam frequency. The official syllabus gives the Fourier integral unit 2 teaching hours and lists no separate weightage for it. It still appeared in all 9 papers.

Mathematics-1 (3110014). 7 of 23 tagged topics appeared in every one of the 9 papers, including Fourier series, local extreme values of f(x, y) and change of order of integration.

The newer code is more uniform. For BE01000041, 15 of 19 tagged topics appeared in all 4 papers. With only 4 papers that is an early signal, not a law.

Physics. For 3110011, four topics were in all 9 papers: Ruby laser, torsion, NDT and a superconductor critical field numerical. For 3110018, solar cell or photovoltaic effect was the only topic in all 9.

Exact repeats exist. I logged 38 questions that came back copy-paste level in two or more sessions. One Physics numerical (ultrasonic source at 0.09 MHz, pulse returning after 0.55 s) shows up in two 3110011 papers and two BE01000021 papers. That one jumped across subject codes.

Where it gets messy

One subject name, several codes. GTU has more than one "Mathematics-2". 3110015 covers vector calculus, Laplace and series solutions. BE02000011 covers matrices, ODEs and complex variables. Tallies do not transfer between codes, so my data stores the code on every row.
The same PDF under two codes. Where one file was served under two codes, I counted it once, otherwise the numbers double.
Possible under-counting. A few lines in the 3110018 Summer 2025 and Summer 2026 PDFs did not extract as text, so those two papers may be slightly under-counted.
Small samples. Four papers is not a pattern yet.
Past repetition is not a promise. GTU can change a paper any time. Use counts to decide the order of study, not what to skip.

Try it yourself

You do not need my files to repeat this. Download one subject's papers from the GTU repository, tag each sub-question with a topic, keep one row per topic per paper, and count. It takes an evening per subject and you will know your paper better than any IMP list.

If you are a GTU student and want the plain-language version of the Mathematics-2 count, with the exam pattern and a study plan, it is here: GTU Maths 2 Paper: PYQs, Old Papers and Repeated Sums.

If you have counted exam questions before, how did you handle topics that straddle two chapters? I tagged by the main method the question asks for, and I am not sure that is the best rule.

Writing note: I used an AI assistant to help tidy the draft. The counting, the numbers and the judgement calls are mine and were checked against the papers.

How to Set an Hourly Rate That Actually Covers Your Costs

Prince — Wed, 21 Oct 2026 09:05:23 +0000

Many freelancers and small agencies pick an hourly rate by looking at what others charge. That feels safe, but it ignores the one thing that matters most: your own costs and the hours you can realistically bill. A rate that works for someone else can quietly lose you money.

Start with your target income

Decide what you need to earn in a year before taxes. Include your salary, savings, and a buffer for slow months. This number is the foundation for everything else, so be honest with it.

Add your business costs

Next, list the costs of running the business for a year. Software, hardware, internet, insurance, accounting, training, and marketing all belong here. Freelancers often forget the tools they already pay for monthly, so check your bank statements. Add this total to your target income.

Estimate billable hours honestly

This is where most rates go wrong. A year has about 2,080 working hours if you work 40 hours a week, but you will not bill all of them. Holidays, sick days, sales calls, admin, and learning all take time. Many independent professionals bill between 50 and 70 percent of their working hours.

If you are not sure what your real ratio is, track your time for a month. Log both client work and internal work. The numbers usually surprise people, and they give you a solid base for pricing instead of a guess.

Do the math

Divide your target income plus costs by your realistic billable hours. For example, if you need 60,000 in income, have 10,000 in costs, and expect to bill 1,200 hours a year, your minimum rate is about 58 per hour. Round up and add a margin for profit and risk.

If you want to skip the arithmetic, our guide to Time Tracking Software for Consultants shows how to log billable hours and see how changes affect the result.

Check the rate against the market

Once you know your floor, compare it with market rates for your skills and region. If your floor is above the market, look for ways to raise your value, narrow your niche, or reduce costs. If it is below the market, you have room to charge more.

Revisit the rate every six months

Costs change, skills improve, and client demand shifts. Set a reminder to review your rate twice a year. Use the time data you have collected to see whether your billable ratio has changed. If admin work keeps growing, that is a sign to automate or delegate.

Keep tracking after you set the rate

A good rate only holds up if you know where your hours go. Tracking time against projects and tasks shows which clients are profitable and which ones take more effort than they pay for. It also makes invoicing faster and reduces disputes, because you can show exactly what was done.

Tools like Tracko make this simple. You track time against tasks with one click or automatically through the desktop app, and review reports by client and project. Over time, that data turns pricing from a guess into a decision.

Final thoughts

Your hourly rate should be built from your own numbers, not borrowed from someone else. Start with your income goal, add your costs, divide by honest billable hours, and check the result against the market. Then keep tracking, keep reviewing, and adjust as your business grows. Learn more at Tracko.

Deploying FastAPI on a VPS with Docker Compose: The Production Checklist

Prince — Mon, 28 Sep 2026 11:13:03 +0000

Getting FastAPI running in Docker takes five minutes. Getting it to behave well on a real server takes a little longer, because the things that bite you in production rarely show up in the "hello world" tutorial: client IPs that all look the same, migrations racing the app on startup, containers running as root, and logs slowly filling the disk.

This post is the checklist I work through when moving a FastAPI service from a laptop to a single Linux VPS with Docker Compose. It assumes you already have a working app and a server with Docker installed.

1. A Dockerfile that is boring on purpose

FROM python:3.13-slim

ENV PYTHONDONTWRITEBYTECODE=1 \
    PYTHONUNBUFFERED=1 \
    PIP_NO_CACHE_DIR=1

WORKDIR /app

COPY requirements.txt .
RUN pip install -r requirements.txt

COPY app ./app
COPY alembic.ini .
COPY migrations ./migrations

RUN useradd --create-home --uid 10001 appuser
USER appuser

EXPOSE 8000
CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000", \
     "--workers", "2", "--forwarded-allow-ips", "*"]

A few choices worth explaining:

Copy requirements.txt first. Dependency installation is cached until that file changes, so code-only changes rebuild in seconds.
Pin versions in requirements.txt (fastapi==0.115.6, not fastapi). An unpinned rebuild months later is a different application.
Run as a non-root user. If something in your dependency tree is ever exploited, the attacker lands as an unprivileged user inside the container instead of root.
Use the exec form of CMD. With the JSON array form, Uvicorn is PID 1 and receives SIGTERM directly, so in-flight requests finish during docker compose down or a redeploy.
PYTHONUNBUFFERED=1 makes log lines appear immediately in docker logs instead of arriving in bursts.

On workers: recent Uvicorn versions can supervise several worker processes themselves with --workers, so a separate Gunicorn layer is no longer required for most apps. Start with one or two workers per vCPU and measure. If your endpoints are mostly async and I/O bound, fewer workers than you expect often perform fine.

2. Trust the proxy, and only the proxy

Your app will sit behind a reverse proxy that terminates HTTPS. Without extra configuration, FastAPI sees every request as plain HTTP coming from the proxy container's IP. That breaks redirects (they point to http://), rate limiting, and any audit logging of client IPs.

Uvicorn reads X-Forwarded-For and X-Forwarded-Proto headers, but only from addresses listed in --forwarded-allow-ips. Setting it to * is acceptable only because the API container publishes no ports: the proxy is the only thing that can reach it. If you ever expose port 8000 directly, tighten this to the proxy's network range.

If you mount the API under a path prefix such as /api, also set root_path so the generated OpenAPI docs use the correct URLs.

3. Compose file with health checks and a migration step

services:
  db:
    image: postgres:16.4-alpine
    environment:
      POSTGRES_USER: app
      POSTGRES_DB: app
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:?set in .env}
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U app -d app"]
      interval: 5s
      timeout: 3s
      retries: 10
    restart: unless-stopped

  migrate:
    image: ghcr.io/acme/api:${API_TAG:?set in .env}
    command: ["alembic", "upgrade", "head"]
    env_file: .env
    depends_on:
      db:
        condition: service_healthy
    restart: "no"

  api:
    image: ghcr.io/acme/api:${API_TAG}
    env_file: .env
    depends_on:
      migrate:
        condition: service_completed_successfully
    healthcheck:
      test: ["CMD", "python", "-c", "import urllib.request; urllib.request.urlopen('http://127.0.0.1:8000/health', timeout=3)"]
      interval: 10s
      timeout: 5s
      retries: 3
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"
    restart: unless-stopped

  caddy:
    image: caddy:2
    ports: ["80:80", "443:443"]
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
    restart: unless-stopped

volumes:
  pgdata:
  caddy_data:

What this buys you:

Postgres is actually ready before anything connects, not merely "started". depends_on without a condition only waits for the container to exist.
Migrations run exactly once per deploy, in their own short-lived container, before the API starts. If a migration fails, the API does not start on a half-migrated schema, and docker compose logs migrate tells you why.
The health check uses Python itself, so you do not need to install curl in a slim image just to probe /health.
Log rotation caps each container at about 30 MB of logs. The default JSON log driver has no limit, and "disk full" is one of the most common ways a small VPS falls over.

Your /health endpoint should be cheap. A good pattern is a liveness check that returns immediately, plus an optional readiness check that runs SELECT 1 against the database with a short timeout.

The Caddyfile for the API is two lines, and it handles certificates and HTTP to HTTPS redirects automatically:

api.example.com {
    reverse_proxy api:8000
}

4. Configuration through the environment

Keep secrets and per-environment values in .env on the server (never in Git) and read them with pydantic-settings:

from pydantic_settings import BaseSettings

class Settings(BaseSettings):
    database_url: str
    secret_key: str
    cors_origins: list[str] = []

settings = Settings()

The app fails fast at startup if DATABASE_URL is missing, which is exactly when you want to find out. Note the host in the URL is the Compose service name: postgresql+asyncpg://app:...@db:5432/app. Using localhost here is the classic cause of "connection refused", because inside the API container localhost is the API container.

5. Deploys you can roll back

Build images in CI, tag them with the Git commit SHA, and push them to a registry. On the server, a deploy becomes:

sed -i "s/^API_TAG=.*/API_TAG=3f9c2ab/" .env
docker compose pull
docker compose up -d

Rolling back is the same three commands with the previous SHA. Avoid the latest tag in production: when something breaks, you want to know exactly which build is running. Be careful with migrations here, too. A rollback of code is easy; a rollback of a destructive schema change is not, so prefer additive migrations (add a column, backfill, remove the old one in a later release).

For a longer walkthrough that also covers first-time server preparation, domain setup and HTTPS from scratch, this step-by-step guide to deploying FastAPI on a VPS with Docker is a good companion to the checklist here.

6. Back up the database before you need to

The pgdata volume is the only irreplaceable thing on this server. Containers and images can be rebuilt in minutes; data cannot. At minimum, run a nightly pg_dump to storage that lives somewhere other than the VPS, keep a few weeks of history, and actually test a restore once. If you want a concrete setup with scheduling, retention and encryption, see this walkthrough on automating Postgres backups to S3.

The short version

Pin versions, run as non-root, use exec-form CMD.
Publish no app ports; let the reverse proxy be the only entry point, and configure forwarded headers.
Gate startup on a healthy database and a successful migration container.
Rotate logs so they cannot fill the disk.
Tag images by commit so deploys and rollbacks are one command.
Back up Postgres off the server and test the restore.

None of this is exotic, but together it is the difference between an API that runs and an API you can leave alone for months.

Traefik vs Caddy on One Docker Host: Same Three Apps, Two Configs

Prince — Fri, 25 Sep 2026 07:55:48 +0000

Most "Traefik vs Caddy" debates stay abstract: one is "dynamic", the other is "simple". That is true, but it does not help much when you are staring at a fresh VPS with three containers that all want ports 80 and 443.

So here is a more practical test. Take one small but realistic stack and wire it up twice:

app.example.com: a web frontend listening on port 3000
api.example.com: an API listening on port 8000, with a /health endpoint
admin.example.com: an internal tool that should sit behind basic auth

Requirements for both versions: automatic HTTPS, HTTP to HTTPS redirects, no application ports published on the host, and a health check on the API. Then we compare what it felt like.

The shared starting point

Both setups use one Docker network that the proxy and the apps share. The apps never publish ports; only the proxy binds to the host.

networks:
  web:
    name: web

DNS for all three hostnames points at the server's public IP, and ports 80 and 443 are open in the firewall. Both proxies need port 80 reachable for the HTTP-01 ACME challenge unless you switch to DNS challenges.

Version 1: Traefik

Traefik's model is "configure the proxy once, then describe routes on each container with labels". The static configuration goes on the Traefik container itself:

services:
  traefik:
    image: traefik:v3
    command:
      - --providers.docker=true
      - --providers.docker.exposedbydefault=false
      - --providers.docker.network=web
      - --entrypoints.web.address=:80
      - --entrypoints.websecure.address=:443
      - --entrypoints.web.http.redirections.entrypoint.to=websecure
      - --entrypoints.web.http.redirections.entrypoint.scheme=https
      - --certificatesresolvers.le.acme.email=ops@example.com
      - --certificatesresolvers.le.acme.storage=/letsencrypt/acme.json
      - --certificatesresolvers.le.acme.httpchallenge.entrypoint=web
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./letsencrypt:/letsencrypt
    networks: [web]
    restart: unless-stopped

Then each service declares its own routing:

  app:
    image: ghcr.io/acme/frontend:1.4.2
    networks: [web]
    labels:
      - traefik.enable=true
      - traefik.http.routers.app.rule=Host(`app.example.com`)
      - traefik.http.routers.app.entrypoints=websecure
      - traefik.http.routers.app.tls.certresolver=le
      - traefik.http.services.app.loadbalancer.server.port=3000

  api:
    image: ghcr.io/acme/api:2.0.1
    networks: [web]
    labels:
      - traefik.enable=true
      - traefik.http.routers.api.rule=Host(`api.example.com`)
      - traefik.http.routers.api.entrypoints=websecure
      - traefik.http.routers.api.tls.certresolver=le
      - traefik.http.services.api.loadbalancer.server.port=8000
      - traefik.http.services.api.loadbalancer.healthcheck.path=/health
      - traefik.http.services.api.loadbalancer.healthcheck.interval=10s

  admin:
    image: ghcr.io/acme/admin:0.9.0
    networks: [web]
    labels:
      - traefik.enable=true
      - traefik.http.routers.admin.rule=Host(`admin.example.com`)
      - traefik.http.routers.admin.entrypoints=websecure
      - traefik.http.routers.admin.tls.certresolver=le
      - traefik.http.routers.admin.middlewares=admin-auth
      - traefik.http.middlewares.admin-auth.basicauth.users=admin:$$apr1$$REPLACE$$WITHHASH
      - traefik.http.services.admin.loadbalancer.server.port=8080

Generate the basic auth hash with htpasswd -nb admin 'your-password' and double every $ so Compose does not treat it as variable interpolation. That doubling trips up almost everyone once.

What stood out:

Adding a fourth app never touches the proxy. You add labels, run docker compose up -d, and Traefik picks up the route within seconds.
The labels are verbose. Router, service and middleware names must line up exactly, and a typo fails quietly: the route simply does not exist and you get a 404.
Mounting the Docker socket gives Traefik broad control over the Docker daemon. On anything shared or important, put a socket proxy such as tecnativa/docker-socket-proxy in between and expose only read access to containers.

Version 2: Caddy

Caddy's model is "one readable file describes every site". The container is minimal:

services:
  caddy:
    image: caddy:2
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy_data:/data
      - caddy_config:/config
    networks: [web]
    restart: unless-stopped

volumes:
  caddy_data:
  caddy_config:

The app services keep their images and the web network, but lose all labels. The routing lives in the Caddyfile:

app.example.com {
    reverse_proxy app:3000
}

api.example.com {
    reverse_proxy api:8000 {
        health_uri /health
        health_interval 10s
    }
}

admin.example.com {
    basic_auth {
        admin $2a$14$REPLACE_WITH_BCRYPT_HASH
    }
    reverse_proxy admin:8080
}

Generate the hash with docker compose exec caddy caddy hash-password. HTTPS, certificate renewal, and the HTTP to HTTPS redirect all happen without a single extra line. The published 443/udp port lets Caddy serve HTTP/3, which it enables by default.

After editing the file, reload without downtime:

docker compose exec -w /etc/caddy caddy caddy reload

What stood out:

The whole routing table fits on one screen. A new teammate can read it and understand the server in a minute.
The /data volume matters. Lose it and Caddy requests fresh certificates on every restart, which can run you into Let's Encrypt rate limits.
Adding an app means editing a central file and reloading. That is a feature for small, stable servers and friction for servers where containers come and go all day.

Side by side

Concern	Traefik	Caddy
Where routes live	Labels on each container	One Caddyfile
New app workflow	Add labels, `up -d`	Edit file, reload
HTTPS defaults	Needs resolver + entrypoint config	On by default
Debugging a missing route	Dashboard or logs; typos fail silently	Config errors fail loudly on reload
Docker socket access	Required for discovery	Not required
Dynamic environments (Swarm, many short-lived stacks)	Strong	Possible via the caddy-docker-proxy plugin

How I would choose

Pick Caddy when you have a handful of long-lived services, one or two people managing the server, and you value being able to read the entire configuration at a glance. For most single-VPS setups this is the calmer option, and its error messages are friendlier when something goes wrong.

Pick Traefik when services appear and disappear often, when several people deploy independently and should not need to edit a shared file, or when you are already on Swarm or planning to move towards an orchestrator. The label model scales with the number of teams rather than the number of config files.

If you want a broader breakdown that also covers load balancing strategies, middleware, and performance considerations, this deeper Traefik vs Caddy comparison for Docker goes further than the hands-on test above. And if your real question is less "which proxy" and more "how do I lay out a server that hosts many projects cleanly", this guide on running multiple apps on one VPS covers domains, networks, and resource limits around the proxy.

A few gotchas that apply to both

Do not publish app ports. If api still has ports: ["8000:8000"], it is reachable over plain HTTP on the server IP, bypassing your auth and TLS. Remove it and let the proxy be the only door.
Use service names, not localhost. Inside the proxy container, localhost is the proxy itself. Always target api:8000, never 127.0.0.1:8000.
Pass real client IPs. Both proxies set X-Forwarded-For, but your app framework must be told to trust the proxy. Otherwise rate limiting and logs see every request as coming from the proxy container.
Back up certificate storage. That means acme.json for Traefik and the /data volume for Caddy. Both are small and save you from rate limit trouble after a rebuild.

Either proxy will serve you well. The better question is where you want your routing to live: next to each service, or in one file you can read top to bottom. If you would rather not maintain that layer at all, self-hosted platforms like Peon, Coolify and Dokploy generate the proxy configuration for you, but knowing what they do underneath makes debugging much easier when a certificate refuses to issue at 2 a.m.

Docker Compose in Production on a Single VPS: A Practical Checklist

Prince — Fri, 25 Sep 2026 07:51:13 +0000

Kubernetes gets most of the attention, but a large share of real production workloads run on one or two virtual machines with Docker Compose. For a SaaS in its first years, an internal tool, or a content site, a single well configured VPS is cheaper, easier to reason about, and fast to recover.

The catch is that the Compose file that works on a laptop is not the Compose file you want in production. This checklist covers the changes that matter most, in roughly the order I apply them.

1. Pin image versions

image: postgres:latest is a time bomb. The next docker compose pull can bring a new major version and a data format your volume does not support.

services:
  db:
    image: postgres:16.4-alpine

Pin to a specific minor or patch version, and upgrade deliberately. For your own images, tag with the Git SHA or a release version rather than latest, so you always know what is running and can roll back to a known tag.

2. Always set a restart policy

Containers crash, and hosts reboot for kernel updates. Without a restart policy, a reboot means downtime until someone notices.

    restart: unless-stopped

unless-stopped survives reboots but respects a manual docker compose stop, which is usually what you want.

3. Add health checks and use them

A running container is not the same as a healthy service. Health checks let Docker know when your app is actually ready, and depends_on can wait for them.

  api:
    build: .
    depends_on:
      db:
        condition: service_healthy
    healthcheck:
      test: ["CMD", "wget", "-qO-", "http://localhost:3000/health"]
      interval: 15s
      timeout: 5s
      retries: 3
      start_period: 20s
  db:
    image: postgres:16.4-alpine
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U app"]
      interval: 10s
      retries: 5

Keep the health endpoint cheap. It should confirm the process can serve requests and reach critical dependencies, not run a full test suite.

4. Keep secrets out of the Compose file

Hardcoded passwords in docker-compose.yml end up in Git history. Use an .env file that is excluded from version control, or Docker secrets for more sensitive values.

  api:
    env_file: .env.production

Set file permissions to 600, and keep a separate env file per environment. Rotate anything that was ever committed, even briefly.

5. Do not publish database ports

A common mistake is ports: - "5432:5432" on the database service. On a public VPS, that exposes Postgres to the internet, and Docker's iptables rules can bypass host firewalls like UFW.

Services on the same Compose network can already reach each other by name. Only publish the ports your reverse proxy needs, and bind them to localhost if the proxy runs on the host:

    ports:
      - "127.0.0.1:3000:3000"

6. Put a reverse proxy in front

You want TLS, HTTP to HTTPS redirects, and the ability to run several apps on one machine. Caddy and Traefik both handle Let's Encrypt certificates automatically. Caddy wins on simplicity; Traefik wins when you want routing driven by container labels.

Either way, the proxy is the only thing that should listen on ports 80 and 443.

7. Use named volumes and back them up

Named volumes survive container recreation and are easy to find:

volumes:
  pgdata:
services:
  db:
    volumes:
      - pgdata:/var/lib/postgresql/data

A volume is not a backup. Schedule logical dumps (pg_dump) to object storage such as S3 or a compatible provider, keep several days of history, and test a restore at least once a quarter. Untested backups are a hope, not a plan.

8. Cap log size

Docker's default json-file driver grows without limit. A chatty container can fill the disk and take down everything on the host.

x-logging: &default-logging
  driver: json-file
  options:
    max-size: "10m"
    max-file: "3"

services:
  api:
    logging: *default-logging

Using a YAML anchor keeps the setting consistent across services. If you need search and retention, ship logs to a central store instead of keeping them on the box.

9. Set resource limits

One runaway process should not starve the rest. Compose supports memory and CPU limits under deploy.resources, which modern Docker Compose applies outside Swarm as well:

    deploy:
      resources:
        limits:
          memory: 512M
          cpus: "1.0"

Start generous, watch real usage for a week, then tighten.

10. Plan how you deploy updates

docker compose up -d --build on the server works, but it rebuilds on the production machine and briefly stops the old container before the new one is ready. Better options, from simplest to most robust:

Build images in CI, push to a registry, and only pull and up -d on the server.
Run two instances behind the proxy and replace them one at a time.
Use a blue/green setup where the proxy switches traffic only after the new version passes its health check.

The last two are the basis of zero downtime deployments with Docker, and they depend on the health checks from step 3.

11. Harden the host

Compose settings do not help if the host is weak. At minimum:

Disable SSH password login and use keys.
Enable unattended security updates.
Allow only ports 22, 80, and 443 at the firewall or provider level.
Run containers as a non-root user where the image supports it.
Keep enough free disk: prune old images with docker image prune on a schedule.

12. Monitor from the outside

Internal health checks tell Docker what is wrong. External monitoring tells you. A simple uptime checker hitting your public URL every minute, plus alerts on disk usage and memory, catches most incidents before users report them.

Putting it together

None of these steps is complicated, but skipping any one of them is how a small outage turns into a long night. The order above also works as a review checklist for an existing server: go through it top to bottom and fix whatever is missing.

If you want a longer walkthrough with a complete example file, this production Docker Compose guide goes deeper on env handling, networking, and deployment workflow.

A single VPS with a disciplined Compose setup will carry you further than most people expect. Move to an orchestrator when you genuinely need multi-node scheduling, not because the Compose file on your laptop was never production ready.

Letting AI Agents Deploy to Your Own Servers With MCP (Without Handing Them Root)

Prince — Fri, 25 Sep 2026 06:02:33 +0000

Coding agents got good at writing code long before they got safe at running it. The moment you ask Cursor or Claude to "deploy this and check the logs", you hit a real question: what exactly is the agent allowed to touch?

The lazy answer is an SSH key or a cloud admin token pasted into a config file. It works, and it is also how you end up with an agent that can rm -rf a production volume because it misread a stack trace.

This post walks through a better pattern for self-hosted infrastructure: expose deployment operations to agents through the Model Context Protocol (MCP), and let the same role based access control that governs your human team govern the agent too.

What MCP changes

MCP is a standard way for an AI client to discover and call tools on a server. Instead of the agent improvising shell commands, it sees a typed catalog: list_services, deploy, get_logs, set_env, and so on. Each tool has a schema, and the server decides what each call is allowed to do.

That shift matters for operations work for three reasons:

The surface is explicit. You can read the tool list and know what the agent can do. There is no "anything bash can do" category.
Authorization lives on the server. The client sends a token; the server checks it on every call. The agent cannot talk its way past a permission check.
Actions are auditable. Tool calls go through the same API as your dashboard, so they land in the same logs.

The threat model in plain terms

Before wiring anything up, write down what you are protecting against. For most small teams it looks like this:

The agent misunderstands an instruction and changes the wrong service.
The agent leaks a credential into a chat transcript or a commit.
A prompt injection in a README, issue, or log line convinces the agent to do something you never asked for.
A token issued "just for testing" never gets revoked.

None of these are solved by a smarter model. They are solved by scoping.

A scoping checklist that works

Whatever platform you use, these rules hold up well:

Use a per-person, per-workspace token. Never share one token across a team, and never reuse your own admin token for an agent that works on a single project. If your platform supports it, create a separate user or membership for automation.

Inherit roles, do not invent them. The agent should get exactly the permissions of the human who issued the token, or less. If a developer can only deploy to the staging project, their agent should hit the same wall.

Leave out interactive shells. Shell access is the escape hatch that makes every other control pointless. Deployments, restarts, env changes, and log reads cover nearly everything an agent needs. Keep terminals for humans.

Treat tokens like passwords. Keep them in your MCP client config or a secret manager, not in repos. Rotate by revoking and reissuing.

Prefer reversible actions. Rollback should be one tool call. If an agent can deploy, it should also be able to undo its own deploy.

What this looks like in practice

I have been testing this pattern with Peon's MCP server docs as the reference setup, because it follows the checklist closely. Peon is an open source, self-hostable deployment platform, and its MCP endpoint is part of the app itself rather than a side script.

The client configuration is short. In Cursor or Claude Desktop you add a streamable HTTP server with a bearer token:

{
  "mcpServers": {
    "peon": {
      "url": "https://app.peon.sh/mcp",
      "headers": {
        "Authorization": "Bearer peon_xxxxxxxx"
      }
    }
  }
}

If you self-host, the URL becomes https://your-domain/mcp. The token is created in the dashboard under Keys and Tokens, is scoped to one workspace, and inherits the creator's role. An owner or admin token can manage servers; a project member token only reaches the projects that member belongs to. The details are in the docs on workspace and project roles.

Two design choices are worth copying even if you build your own server:

Shell exec tools are not registered on MCP. The agent can deploy, restart, roll back, read logs, and manage env vars, but it cannot open a shell on a server or inside a container.
The same RBAC applies to the API, the MCP server, and the in-app assistant. The UI is not the security boundary; the API is.

A realistic agent session

Here is the kind of loop that works well once scoping is in place:

"List services in the blog project and tell me which one failed its last deploy."
The agent calls the list and deployment tools, finds a failed build, and pulls the build logs.
It spots a missing DATABASE_URL, explains the fix, and asks before setting it.
After you confirm, it sets the variable, triggers a redeploy, and watches the status.
If the new deployment fails health checks, it rolls back and reports what happened.

Nothing in that loop needed root. Every step is a typed call that your platform can log and deny. If you want a full example, there is a walkthrough of an agent shipping an app end to end that covers the same flow with screenshots.

Guardrails on the client side

Server side scoping is the foundation, but a few client habits help:

Require confirmation for writes. Most MCP clients can ask before running a tool. Leave that on for anything that deploys, deletes, or changes env.
Keep read-only tokens for exploration. If your role model supports a viewer role, issue a viewer token for "what is running and why is it slow" sessions.
Be suspicious of instructions found in data. Logs, READMEs, and issue text can contain text that looks like instructions. Tell the agent explicitly that tool output is data, not a command.
Review the audit trail weekly. It takes five minutes and catches forgotten tokens.

When not to use an agent for deploys

Agents are great at the boring middle of operations: reading logs, correlating a failed deploy with a config change, and doing the obvious fix. They are a poor fit for:

First-time infrastructure setup where you need to understand every choice.
Database migrations with data loss risk.
Anything involving billing, DNS for your primary domain, or deleting backups.

Keep those human, or at least human-approved step by step.

Wrapping up

MCP gives you a clean contract between an AI client and your infrastructure. The contract is only as safe as the permissions behind it, so start from the rules above: personal scoped tokens, inherited roles, no shell tools, reversible actions, and an audit trail.

If you run your own servers, this is one of the few places where self-hosting makes AI tooling safer rather than riskier, because you control both the tool catalog and the permission model. I would love to hear how others are scoping agent access in their own stacks.

Deploy Peon on a DigitalOcean Droplet (self-hosted Docker PaaS)

Prince — Fri, 18 Sep 2026 12:30:50 +0000

Peon is an open-source, self-hostable deployment platform. Think Vercel or Heroku workflows on a server you control: Git deploys, Docker Compose, databases, workspaces, and RBAC.

This guide walks through a clean DigitalOcean droplet setup. Same pattern works on Hetzner, Vultr, and Contabo.

What you will build

A DigitalOcean Ubuntu droplet running Peon so you can connect the server over SSH and deploy apps from Git.

Prerequisites

DigitalOcean account
SSH key added to DigitalOcean
Domain name (optional, recommended for TLS)
Basic SSH comfort

1. Create the droplet

Create an Ubuntu 24.04 LTS droplet (2 GB RAM minimum; 4 GB preferred).
Choose your SSH key.
Note the public IPv4 address.

2. Point DNS (optional)

Create an A record for peon.example.com to the droplet IP.

3. Harden basics

ssh root@YOUR_DROPLET_IP
apt update && apt upgrade -y
ufw allow OpenSSH
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

4. Install Docker

curl -fsSL https://get.docker.com | sh
docker --version

5. Install Peon

Follow current official docs:

README: https://github.com/Peon-sh/Peon
Docs: https://peon.sh/docs

Typical flow: clone repo, configure .env secrets, start Postgres/queue, migrate, run app + worker.

6. Open Peon and add the droplet

Add the server over SSH, create a workspace/project, deploy a sample Git repo.

7. Verify

App URL responds, deploy logs clean, optional second project for RBAC.

Why Peon vs Coolify / Dokploy

All three are strong self-hosted PaaS options. Peon focuses on workspace/project tenancy, audit logs, and MCP hooks for AI agents, while staying MIT and self-host free.

Peon vs Coolify: picking a self-hosted PaaS in 2026

Prince — Fri, 04 Sep 2026 12:19:56 +0000

Managed platforms are excellent until the invoice and the lock-in start arguing with your roadmap. Seat pricing, usage cliffs, and "you can leave anytime" exports that are never quite painless push a lot of teams toward a different model: keep the git-push UX, run the apps on hardware you control.

That is the promise of a self-hosted PaaS. Two names that keep showing up in that conversation are [Coolify] and [Peon]. Both turn a Linux box into something closer to Heroku or Vercel, without giving up the server. This piece is a practical comparison for developers, DevOps folks, and SaaS founders who are deciding which one fits.

Why people leave managed PaaS

The usual triggers are boring and expensive:

Per-seat bills that grow faster than headcount value. Inviting a contractor or a designer should not feel like a budget meeting.
Vendor gravity. Preview deploys, edge features, and proprietary build tooling are sticky. Moving later is harder than starting elsewhere.
Wanting a real VPS. Many teams already pay for Hetzner, DigitalOcean, AWS EC2, or a spare bare-metal machine. Paying again for someone else's orchestration on top feels redundant.
Data and networking control. Some products need private networking, unusual databases, or compliance stories that managed PaaS plans treat as enterprise upsells.

None of that means managed PaaS is bad. It means the tradeoff stopped matching the team.

What "self-hosted PaaS" actually means

A self-hosted PaaS is not Kubernetes-by-default and it is not "SSH and pray." In this category, a control plane talks to your servers (usually over SSH), runs Docker for you, wires a reverse proxy, issues Let's Encrypt certificates, and deploys from Git, images, or Compose files.

You still own:

The VPS or machines where containers run
DNS for your domains
Backups and capacity planning

The platform owns the workflow:

Connect a repo or image
Build and roll out with fewer manual Docker steps
Manage databases, env vars, logs, and rollbacks from a UI

Coolify and Peon both live in that lane. They are closer to each other than either is to "just Docker Compose on a VPS" or to a full cluster platform.

Coolify, fairly summarized

Coolify is a mature open-source, self-hostable alternative to Vercel, Heroku, Netlify, and Railway. You point it at servers you can reach over SSH and deploy websites, APIs, databases, and a large catalog of one-click services.

In practice, Coolify is strong when you want:

A well-known community and lots of tutorials
A wide one-click service marketplace
Git push deploys, Docker and Compose, automatic HTTPS
Multi-server management from one dashboard
PR preview style workflows and solid day-to-day Docker hosting

Self-hosting Coolify itself is free; you pay for the machine it runs on. There is also a hosted control-plane option if you prefer not to operate that layer. For solo builders and teams that mainly need "Docker hosting with a good UI," Coolify is a legitimate default recommendation, not a straw man.

Where Peon aims differently

Peon sits in the same self-hosted PaaS category: your servers, Docker under the hood, git-based deploys, Compose, databases, custom domains, and automatic HTTPS. The product bet is that once more than one person touches production, the hard problems become permissions, accountability, and how AI tools interact with deploys.

Project-level RBAC

Peon models work as workspaces and projects, with roles at both levels. That matters when you want to invite someone to one app without handing them every server in the workspace. Agencies, multi-product startups, and teams with contractors feel this gap quickly on platforms that only think in "team on the whole instance."

Audit logs on standard plans

Owner-visible audit history for who changed what across projects, services, servers, and deploys is included on Peon's self-hosted and Cloud offerings, rather than treated as a distant enterprise checkbox. If you care about "who restarted production at 2 a.m.," that is the feature, not a nice-to-have slide.

MCP for AI agents

Peon ships a hosted Model Context Protocol (MCP) server so tools like Cursor or Claude can operate against your projects with the same permission model as a human user. The point is not novelty. It is giving agents a governed path to deploys and config instead of pasting raw SSH into a chat window.

In-app AI assistant

There is also an in-app assistant that uses your own OpenAI or Anthropic keys, shares the MCP tool surface, and expects approval before mutating production. That is useful for "how do I wire this domain" questions and for proposed actions you can accept or reject in the UI.

Pricing shape: $3 per project Cloud, unlimited seats

Peon Cloud is priced per project (published at $3/month or $30/year), with unlimited servers and unlimited team members on that model. Self-hosting the control plane is free and open source. Apps still run on infrastructure you bring. The intent is predictable cost that tracks how you organize products, not seat count or every extra connected box.

For a side-by-side feature view maintained by the Peon team, see Peon vs Coolify. Treat any comparison table as a starting point and verify current plan details on both sites before you buy.

Who should pick which

Lean Coolify if you want:

The larger community gravity and template ecosystem
A battle-tested Docker PaaS for personal projects or a small shop that mostly needs deploys, SSL, and one-click services
To follow abundant third-party guides and stay close to a widely documented stack

Lean Peon if you want:

Workspace and project RBAC as a first-class concern
Audit logs without waiting for an enterprise conversation
MCP and an in-app assistant wired into the same permissions model
Flat per-project Cloud pricing with unlimited seats, or a free self-hosted control plane with those team features included
A path that feels closer to "platform for a growing engineering team" than "excellent solo Docker dashboard"

Many people will be happy on either. The wrong choice is usually picking on vibes, then discovering you needed project isolation or that you did not need AI agent hooks at all.

Quick start (without the sales pitch)

If you try Peon, the boring successful path is:

Bring a Linux server with SSH and Docker (a small Hetzner or DigitalOcean VPS is fine for experiments).
Use Peon Cloud or self-host the control plane.
Connect the server, link a Git source, create a project and service, deploy.

The official walkthroughs live in the Peon docs (introduction, self-hosting, first deployment, roles). The code is on GitHub at Peon-sh/Peon if you want to read it before you install anything.

For Coolify, start from their site and docs the same way: one server, one app, prove the loop, then add teammates.

Honest caveats

Self-hosted PaaS removes platform markup. It does not remove infrastructure cost or ops ownership.

You still pay for the VPS (or several). A $3 control plane or a free self-hosted panel does not include CPU, RAM, disk, or bandwidth.
You own failure modes. Disk full, bad Docker upgrade, mis-pointed DNS, and backup restore drills are yours whether the UI is pretty or not.
Migration is work. Moving from Vercel or from Coolify to Peon (or the reverse) is incremental at best: non-prod first, same Git repo, then cut over when you trust the path.
AI features need keys and judgment. MCP and chat assistants are powerful; treat production mutations like you would treat a junior with root, with approvals on.
Community size differs. Coolify currently has more ambient internet knowledge around it. Peon is newer in that social sense; weigh docs quality and your willingness to file issues.

A simple decision rule

If your main job is "get containers on my VPS with git push and HTTPS," both Coolify and Peon can do that job. Prefer Coolify when community breadth and one-click catalog depth matter most. Prefer Peon when project isolation, auditability, and governed AI/agent workflows are part of how your team already works, or how you expect to work in 2026.

Either way, keep the apps on servers you can SSH into, keep backups off-box, and pick the panel your future teammates will not hate. That is the whole self-hosted PaaS bet in one sentence.

Deploy your apps on your server in clicks

Prince — Wed, 26 Aug 2026 07:20:51 +0000

Peon is an open-source application deployment platform you can run yourself: a practical Vercel alternative, and a stand-in for Heroku, Netlify and Railway, when you want to push websites, databases, apps and one-click templates onto hardware you control.