DEV Community: Prince

Counting exam repeats without double-counting: one tag per paper

Prince — Fri, 06 Nov 2026 05:29:14 +0000

Disclosure: I work on GTU Hero. We count how often topics repeat in Gujarat Technological University exam papers. This note is about one counting rule that looks trivial and still breaks dashboards when you get it wrong.

The rule

A topic counts once per paper, even if that paper asks it twice (compulsory + OR, or two different sub-parts).

Why: students care about "will this idea show up in my paper?", not "how many times can the setter stamp the same idea". If Green's theorem is Q.1(c) and also hides inside an OR elsewhere, that is still one paper that tested Green's.

For Mathematics-2 (3110015) that rule turned into a clean table across 9 official papers (Summer 2022 to Summer 2026): Green's, Fourier integral, Laplace IVP, variation of parameters, undetermined coefficients, Euler-Cauchy and power series all landed at 9/9.

A tiny counter

from collections import defaultdict

def count_topics(papers):
    """papers: list of (paper_id, list_of_topic_tags_including_ORs)"""
    per_paper = defaultdict(set)
    for paper_id, tags in papers:
        for t in tags:
            per_paper[paper_id].add(t)  # set = once per paper
    totals = defaultdict(int)
    for tags in per_paper.values():
        for t in tags:
            totals[t] += 1
    n = len(per_paper)
    return {t: (c, n) for t, c in sorted(totals.items(), key=lambda x: -x[1])}

# demo shaped like the Maths 2 guide
demo = [
    ("S2024", ["green", "laplace_ivp", "green"]),          # green twice -> once
    ("W2025", ["green", "fourier_integral", "vop"]),
    ("S2026", ["green", "laplace_ivp", "power_series"]),
]
for topic, (c, n) in count_topics(demo).items():
    print(f"{topic}: {c}/{n}")

Run that and green prints 3/3, not 4/3. The duplicate tag inside S2024 is ignored on purpose.

What we also had to watch

Subject code, not subject name. Maths 2 is 3110015 on the older scheme and BE02000011 / BE02R00011 on the newer one. Mixing them inflates or dilutes counts.
OR options still count. Students can pick the OR side, so the topic is "in the paper".
Say when text extraction failed. Under-counts should be labelled, not hidden.

None of this is clever. It is the difference between "Green's came in 9 of 9 papers" and a number nobody can defend.

The published Maths 2 table (after these checks) is on GTU Hero.

A boring data bug: one exam PDF, two file names

Prince — Thu, 05 Nov 2026 05:49:06 +0000

Disclosure: I work on GTU Hero, a site that counts repeated questions in Gujarat Technological University exam papers. This post is about one boring data bug that came up while counting first-year Physics papers, and the small check I would add to any pipeline like this.

The setup: download every official paper for a subject code, extract text, tag each sub-question with a topic, and count a topic once per paper. For the Physics guide that meant 22 papers across three subject codes, Summer 2022 to Summer 2026.

The bug: the same file under two names

The new-scheme Physics code BE01000021 has a sibling code, BE01R00021. For Winter 2025 and Summer 2026, the repository served a PDF under each code. They were the exact same file, headed "BE01000021/BE01R00021".

If you count both, every topic in those papers gets counted twice, and a 2 out of 4 topic suddenly looks like 4 out of 6. So the fix is to dedupe on content, not on file name:

import hashlib

def sha256(path):
    h = hashlib.sha256()
    with open(path, "rb") as f:
        for block in iter(lambda: f.read(1 << 16), b""):
            h.update(block)
    return h.hexdigest()

def unique_papers(paths):
    seen = {}
    for p in sorted(paths):
        seen.setdefault(sha256(p), []).append(p)
    return seen  # hash -> every file name that served the same bytes

Any hash with more than one file name is a duplicate. Keep one, and log the others so a human can see why the count dropped.

A limit worth knowing

Hashing only catches exact copies. A rescanned or re-exported PDF will have a different hash, so it is still worth glancing at the header text of each paper.

Say it in the output

In the published guide, the two duplicate files are counted once, and the guide says so. That matters because students make real decisions from these numbers. If a duplicate inflates a count and nobody notices, the advice is wrong while the table still looks clean.

Two rules I follow now:

Dedupe by content hash before counting anything.
Write what you deduped into the output, not only into your logs.

Neither is clever. Both are cheaper than explaining a wrong number later.

If you are curious what the counts look like after this check, the Physics write-up is on GTU Hero.

Same subject, three codes: handling syllabus versions when indexing exam papers

Prince — Wed, 04 Nov 2026 04:43:06 +0000

I work on GTU Hero, a site that organises GTU (Gujarat Technological University) exam papers. This is a small data-modelling note from that work, and it applies to any project that indexes exam papers or course material.

The problem: subject name is not a safe key

GTU Maths 1 exists under three subject codes: 3110014, BE01000041 and BE01R00041. They are all "Maths 1" by name, but the modules are not the same:

3110014: calculus, sequences and series, Fourier series, multivariable calculus, multiple integrals, matrices. 5 credits.
BE01000041 (w.e.f. 2024-25): no Fourier series, no matrices. 4 credits.
BE01R00041 (w.e.f. 2025-26): the same five modules as BE01000041, only the hours and weightage differ.

If you key papers by subject name, a student on BE01000041 can end up solving a 3110014 paper and spending time on Fourier series, which is not in their syllabus. Keying by subject code keeps each paper attached to the syllabus version it was set for.

A tiny model

A dictionary from code to modules is enough to start with:

SYLLABUS = {
    "3110014": {
        "calculus", "sequences and series", "fourier series",
        "multivariable calculus", "multiple integrals", "matrices",
    },
    "BE01000041": {
        "calculus", "sequences and series",
        "multivariable calculus", "multiple integrals",
    },
    "BE01R00041": {
        "calculus", "sequences and series",
        "multivariable calculus", "multiple integrals",
    },
}

Note that BE01R00041 has the same module set as BE01000041. The differences (hours, weightage) would live in separate fields, so I keep modules as their own set.

Flagging out-of-syllabus questions

Each question in an old paper is tagged with a module. Given the student's current code, we can flag the questions that are out of syllabus:

def out_of_syllabus(paper_questions, student_code):
    """paper_questions: list of (question_id, module) from an old paper."""
    allowed = SYLLABUS[student_code]
    return [qid for qid, module in paper_questions if module not in allowed]


old_paper = [
    ("Q1", "calculus"),
    ("Q2", "fourier series"),
    ("Q3", "matrices"),
    ("Q4", "multiple integrals"),
]

print(out_of_syllabus(old_paper, "BE01000041"))
# ['Q2', 'Q3']

The same function works the other way round too. If a student on 3110014 opens a newer paper, you can compare module sets and see what is missing.

Why this is worth doing early

Subject codes are stable identifiers. Names get reused across syllabus versions.
Storing modules per code lets you answer "is this question still relevant?" with a set lookup instead of manual checking.
When a new code appears, you add one entry instead of reworking your data.

Takeaway

Key by subject code, store modules per code, and compute relevance instead of assuming that same name means same syllabus. That is the whole idea, and it is a good first data-modelling exercise if you are learning Python.

If you want to see the papers this applies to, they are here: GTU Hero.

The 8 beginner C programs every GTU first-year should be able to write blind

Prince — Tue, 03 Nov 2026 04:46:10 +0000

Disclosure: I work on GTU Hero, a site for GTU (Gujarat Technological University) exam prep. This is aimed at first-year engineering students taking Programming for Problem Solving.

If you are new to C, these eight programs cover most of the basics you will be tested on: conditions, loops, integer arithmetic and recursion.

Program	Concept it tests
Even or odd	if-else, %
Factorial	loops, recursion
Prime check	loops, flags, edge cases (1 is not prime)
Fibonacci	updating two variables
Sum of digits	% 10 and / 10
Reverse and palindrome	temp variables
Largest of three	comparisons, equal inputs
Armstrong number	digit extraction, powers

Here is the simplest one, to show the style GTU expects (write the algorithm too):

#include <stdio.h>
int main(void) {
    int n;
    printf("Enter a number: ");
    scanf("%d", &n);
    if (n % 2 == 0)
        printf("Even number");
    else
        printf("Odd number");
    return 0;
}

Edge cases are where marks go. Test prime check with 1 and 2, test largest-of-three with equal values, and test palindrome with a single digit.

For GTU specifically, PPS appears under codes like 3110003 and BE01000121, so match your code before using old papers. The full list with past paper links is here: GTU Hero PPS guide.

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.