DEV Community: Pedro Garduno

I moved StoryKept from a $0 host to a $19/month one on purpose

Pedro Garduno — Sun, 16 Aug 2026 05:25:51 +0000

Vercel is the easiest way to ship a Next.js app. I moved StoryKept off it anyway from a bill of exactly $0 to $19 a month.

That sounds backwards. Free is cheaper than $19. But "free" was only free for the
part of StoryKept that Vercel does beautifully: the frontend. The moment the app
needed a database, persistent storage for user media, and Docker, "free" was about
to stop being the number — and the number it was about to become was not $19.

This is the story of that move: why I made it, what I set up by hand, the two things
that didn't just work, and why $19 flat turned out to be the cheaper decision.

Why leave a free host at all

StoryKept isn't a frontend. People send in voice notes and videos over WhatsApp,
and those files have to be stored safely and served back. That means, at minimum:

Next.js — the part Vercel is genuinely best at
A database — Postgres
Object storage — for the media, potentially a lot of it
Docker — so the whole thing runs the same everywhere

On Vercel, the frontend is free and the rest is a menu. Each managed piece the database, the storage, the bandwidth once media traffic grows is its own line
item, and each one climbs with usage. The free tier is a doorway, not a house. For
a media-heavy app, the honest projection wasn't "$0 forever." It was "$0 until it
isn't, then a bill that grows with every uploaded video."

So I went shopping for a box that could run the whole stack for one predictable
number. DigitalOcean, Linode, Hetzner. Hetzner won on price-for-performance, and
$19/month covers both the VPS and an S3-compatible storage bucket. One number,
flat, for the entire stack.

What you actually get: a bare Linux box

Hetzner hands you something deliberately minimal: a Linux VPS with a public IP. You
pick the type, the RAM, the location, the OS and that's the end of the hand-holding.
Everything else is yours to stand up:

Docker and the container runtime
Postgres
The storage bucket
The SSL certificate
An SSH-based deploy path

This is the "old way," and it's exactly the part that scares people off Hetzner.
It shouldn't. None of it is exotic it's a sequence of well-documented steps, and
the whole thing was easier than the reputation suggests. The setup, roughly:

Spin up the VPS, lock down SSH (key-only, no password login).
Install Docker and bring up the app + Postgres as containers.
Point a domain at the public IP.
Put the app behind a reverse proxy and get a TLS cert.
Wire up the storage bucket via the S3 API.
Set up a simple SSH deploy so shipping a new version is one command.

Two of those six steps are where I actually spent my time. The rest was typing.

The storage bucket: same SDK, different endpoint

Here's the piece that makes lock-in a non-issue, and it's the most reusable idea in
this whole post. Amazon's S3 became so ubiquitous that other providers built their
storage to speak the exact same API. Hetzner's bucket is S3-compatible, which means
my application code doesn't know or care that it isn't AWS.

You don't rewrite anything. You keep the same S3 SDK and change three values — the
endpoint, the credentials, and (for some providers) the addressing style:

import { S3Client } from "@aws-sdk/client-s3";

const s3 = new S3Client({
  region: "auto",
  endpoint: process.env.S3_ENDPOINT,        // Hetzner bucket URL, not AWS
  credentials: {
    accessKeyId: process.env.S3_ACCESS_KEY,
    secretAccessKey: process.env.S3_SECRET_KEY,
  },
  forcePathStyle: true,                       // matters more than you'd think
});

That's the whole switch. The same code that talked to AWS now talks to Hetzner by
changing environment variables. And the reverse is just as cheap: if Hetzner ever
slips, moving back to AWS — or to any other S3-compatible provider is a config
change, not a migration project. The point of avoiding lock-in was never to refuse
to pick a vendor. It's to build so the choice never becomes a cage.

The two things that didn't just work

A migration where everything works on the first try isn't a real migration. Two
things fought me.

1. Presigned URLs needed configuration. StoryKept serves user media through
presigned URLs — time-limited links that let a browser fetch a file directly from
the bucket without routing bytes through my server. Against AWS these are close to
zero-config. Against an S3-compatible provider, they didn't work out of the box; the
signing had to be configured to match how the provider expects the request to be
addressed before the generated URLs would validate. Once that was aligned, they
worked exactly like the AWS ones — but it was the opposite of plug-and-play, and
it's the kind of thing that passes in local testing and fails the first time a real
file is requested.

2. HTTPS: the config was manual, the cert was not. On a managed platform, HTTPS
is a checkbox. On a bare VPS, it's yours to handle — and here the right tool choice
did most of the work for me. I put the app behind Caddy as the reverse proxy, and
Caddy does automatic HTTPS: it provisions a free Let's Encrypt certificate on its
own and renews it before it expires, with no cron job and no certbot ritual to
remember. That's a deliberate senior call picking the tool whose default is the
thing you don't want to babysit.

It still wasn't zero-effort. You write the Caddyfile, point DNS at the box, and make
sure the ACME challenge can actually reach the server — get any of those wrong and
the cert silently never issues. But that's setup you do once, not a renewal you have
to nurse forever. Compared to hand-rolling certbot on a bare box, choosing Caddy
turned "SSL is a chore I'll forget to renew" into "SSL is a line of config."

The number, and the actual senior call

So: $0 to $19/month. Framed as a raw bill, that's a $19 increase. Framed honestly,
it's the cheaper decision — because the $0 was temporary and load-bearing on a
frontend-only definition of the app. $19 flat buys the database, the storage, the
compute, and the bandwidth headroom in one predictable line that doesn't spike when
a user uploads a 200MB video. The bill I avoided isn't $0; it's the per-service
climb the $0 was quietly deferring.

I want to be careful not to oversell it. Hetzner isn't AWS. There are no fifty
managed services on tap, no autoscaling magic, no one to page when the box misbehaves
at 3am that's you. If your time is worth more than the money a managed platform
saves you, pay for the managed platform. That's a real and correct call for a lot of
teams.

But that is the call and making it well is the actual senior skill here. Not
"can you run a Linux box," but knowing when a managed platform's convenience is worth
paying for and when it's just a tax on things you're perfectly capable of running
yourself. For a solo founder watching a budget, who knows his way around a server,
$19/month for the whole stack — with the freedom to walk away from any piece of it
by changing an environment variable — was the right trade.

The hard part was never knowing the tools. It was knowing which brand-name defaults
were worth paying for, and building so that every one of those choices could be
undone.

The night my World Cup model started fighting itself

Pedro Garduno — Fri, 07 Aug 2026 15:44:54 +0000

Back in July I wrote up my World Cup model — Elo, jet-lag penalties, and 10,000 Monte Carlo tournaments, refreshing itself on a schedule all through the tournament. That "refreshing itself on a schedule" part is where this story lives.

A GitHub Action wakes up, pulls the latest scores from the football API, re-runs the simulation, writes a snapshot of the day's predictions, and pushes the result back to the repo. Nothing exotic. It ran fine for weeks.

Then one night in early July it just... failed. And kept failing.

What I saw

The Action would go red with a merge conflict, of all things — on a file that no human had touched. The conflict was always on the daily snapshot:

CONFLICT (add/add): Merge conflict in data/snapshots/2026-07-03.json

An add/add conflict means two commits each created the same file, from scratch, with different contents. Git has no idea which one you meant, so it gives up and the job exits 1.

But there's only one cron job. How do two commits create the same file at the same time?

The actual bug

The answer was in the schedule. The cron runs every 30 minutes:

- cron: "10,40 * * * *"

Except GitHub Actions cron isn't punctual. Under load it lags — 15 to 60 minutes is normal, and I'd deliberately set it to fire twice an hour to catch matches quickly. So on a busy evening, the :10 run would still be grinding away when the :40 run started. Two copies of the same job, running at once.

That overlap on its own would've been harmless if the job produced the same bytes every time. It didn't. Two things in the pipeline are non-deterministic:

A timestamp. Every build stamps itself: generatedAt: new Date().toISOString(). Two runs, two different clocks.
Monte Carlo noise. The whole model is 10,000 randomized tournament simulations — Math.random() at its core. Run it twice and Spain's title odds come back 24.1% one time, 24.3% the next. Close, but not byte-identical.

So both overlapping runs generated data/snapshots/2026-07-03.json — a brand-new file that day — with slightly different numbers inside. Whoever pushed first, won. The second run came back, tried to rebase its commit on top of the first, and hit two commits both adding the same path with different contents. Add/add conflict. Exit 1. Red X.

The old reconciliation step was trying to be careful, and that was exactly the problem:

git add data/
git commit -m "data: refresh scores (...)"
git pull --rebase --autostash origin main   # <- tries to MERGE two generated files
git push || (git pull --rebase --autostash origin main && git push)

It was attempting to merge two machine-generated files that were never meant to be merged. There's no sensible resolution — you don't want half of one simulation and half of another.

The fix

The insight: this data isn't something you merge. It's something you rebuild. The scores live in the API, not in the repo — the repo is just a cache. So instead of reconciling two divergent versions, throw the loser away and regenerate on top of the winner:

for attempt in 1 2 3 4 5; do
  git fetch origin main
  git reset --hard origin/main      # start from whatever main is NOW

  npm run scores                    # re-fetch from the API (source of truth)
  npm run lock:knockouts            # cascade the bracket (idempotent)
  npm run build:data                # regenerate the derived data
  npm run snapshot                  # write today's snapshot if absent

  [[ -z "$(git status --porcelain)" ]] && { echo "No changes."; exit 0; }

  git add data/
  git commit -m "data: refresh scores ($(date -u +%Y-%m-%dT%H:%MZ))"
  git push && exit 0                # won the race? done.

  echo "Push lost a race; rebuilding on new main…"
  sleep $((RANDOM % 5 + 2))         # jittered backoff, then try again
done
exit 1

The whole shape changes. If a push loses the race, the job doesn't try to force its stale work through — it resets to the new main and rebuilds from there. Because every step is idempotent and re-reads scores from the API, rebuilding on fresh main can never conflict and can never drop a result. The random sleep keeps two retriers from lockstepping into each other again.

It's been green ever since — all 104 matches captured, right through to Spain lifting the trophy.

The lesson I keep relearning

The bug wasn't really in the git commands. It was in treating generated, non-deterministic output like hand-written source you can merge. Two overlapping jobs, a timestamp, and a random seed were all it took.

Once I stopped asking git to reconcile two simulations and instead made the job regenerate from the source of truth, the race condition didn't need clever handling — it just stopped being able to happen. The best fix for a race is usually to remove the thing being raced over, not to guard it more carefully.

I built a World Cup model around jet lag, then graded it in public

Pedro Garduno — Tue, 21 Jul 2026 23:51:22 +0000

Most World Cup prediction models rank teams by strength and leave it there. The 2026 tournament was spread across the US, Canada, and México — four time zones, cities at sea level and cities a mile up, June heat in some places and air conditioning in others, and kickoff times that can drag a European team's body clock to four in the morning. Some teams got an easy run of it. Others got a schedule that would flatten a touring band.

So I built JetLag XI to measure that, simulate the whole tournament on top of it, and save every prediction so I could see afterward how wrong it was.

The tournament's done now. Spain beat Argentina 1–0 in the final. What the model got right, what it didn't, and the one thing it was never going to get right given how I built it.

How it works

Two things go into every match prediction.

The first is strength — plain Elo ratings, sanity-checked against squad market values. Elo is just a number per team that goes up when they win and down when they lose, and the gap between two teams turns "who's better" into "by how much," which is what you need to get a scoreline out.

The second is fatigue, and this is the part I hadn't seen anyone actually put on the board. It's all computable from the fixture list: how far each team flies (the trip in, plus every hop between cities), how many time zones they cross and re-cross, how much the altitude jumps around, the heat, the rest days between games, and a little circadian penalty for how far each kickoff sits from a comfortable mid-afternoon on the team's home clock. A 9pm local kickoff is a different game if your body still thinks it's in Buenos Aires. I rolled all of that into one "Edge Index," with a bonus for the host nations who got to sleep in their own beds.

Then it all runs through a Monte Carlo simulation — 10,000 full tournaments every time it refreshes. Each group match draws goals from the Elo gap, the real tiebreakers sort the tables, and the bracket plays out through the knockouts. I went with simulation instead of just using Elo directly because Elo can only tell you the odds of one team beating another. It can't tell you a team's chance of winning the group or reaching the final through a 48-team bracket with third-place qualifiers — for that you have to actually play the thing out, thousands of times, and count.

The whole pipeline refreshes itself hourly during the tournament off a GitHub Action that pulls the latest scores, rebuilds, and re-runs the sim. I mostly just watched.

The scorecard

Over 104 matches it went 65% straight up, with a Brier score of 0.220. Every prediction got written down next to the real result the moment the game finished, so none of this is me remembering the good calls and forgetting the bad ones.

The chart is the bit I'd actually stand behind. Each dot is a confidence band — above the line the model was too cautious, below it too sure of itself. Four of the five bands sit close enough to the line. It's the red one that's interesting, and it points straight at the thing I got wrong.

What it got right

The travel idea paid off where you'd most expect it to: the hosts. The US, México, and Canada flew basically nowhere and slept at home the whole time — exactly what the Edge Index rewards — and all three did better than their raw ratings said they should. The US was an underdog on paper against Paraguay and won 4–1. A strength-only model calls that game the other way; the one that knew about the travel didn't. That single result is the whole premise working.

The favorites also held up top. The four teams the sim liked most — France, Spain, Argentina, England — all made the semis, the final was Spain against Argentina, and its pick won. It had the final itself as pretty much a coin flip (52% Spain), which, for a 1–0, feels about right.

What it got wrong

It only ever outputs a winner, so a 0–0 is a miss no matter what. And its most confident calls were the worst offenders — Spain at 94% over Cape Verde, 0–0; England 92% over Ghana, 0–0. Seven of its eight biggest misses were draws.

In games it called roughly 90% locks, the favorite actually won only about two-thirds of the time, and that whole gap is draws. It's baked into how I built it: the sim turns an Elo gap into goals and then just picks whoever scored more, tossing the draw out. But a draw is the most common result in a tight group game — especially a strong side against one happy to sit ten men behind the ball, which is exactly the matchup the model was most confident about. Twenty draws across the tournament, every one an automatic miss. A proper win/draw/loss output is the first thing I'd change.

Why grade it at all

If you want the methodology, the live pages, or every prediction it ever made, it's all here: jetlagxi.com. The minimal engine behind it — Elo + Poisson + Monte Carlo, ~200 lines of TypeScript — is on GitHub.