
I'm a product-minded engineer who bootstraps new domains inside growing companies — taking them end to end, from architecture and code to product decisions and the people who deliver them.

**Currently:** Engineer in ShipMonk's B2B fulfillment domain.
**Education:** MSc, Open Informatics, CTU FEE — with honours.

**Roles:**
|             |           |                                         |
|-------------|-----------|-----------------------------------------|
| 2021 - present | [ShipMonk](/cv/shipmonk)  | Team Lead, B2B Domain (Senior → TL)     |
| 2020 - 2021 | [NFCtron](/cv/nfctron)   | Fullstack engineer (after seed round)   |
| 2021        | [Sportmatiq](/cv/sportmatiq) | Founding engineer & tech lead (part-time) |
| 2019 - 2019 | [AI Center](/cv/aicenter) | Research tooling (Python)               |
| 2016 - 2016 | [MALPRO](/cv/malpro)    | Automation developer (Python)           |


Ondřej Tůma


I run [zpl.tools](https://zpl.tools), a ZPL-to-PDF rendering API written in Rust, on Fly.io. While benchmarking it I found a step in the latency curve between 40 and 45 pages that had nothing to do with the renderer.

## The symptom

<FlyProxyCliffChart />

40 pages take ~0.6 s, 45 pages take ~3.5 s, with no measured processing-time difference on the server side. That pointed me towards fly.io.

The step lands at ~10 MB of request body, and my benchmark labels cross that line between 40 and 45 pages.

## The cause

After searching Fly's forums I found [a mention of similar behaviour](https://community.fly.io/t/replay-with-file-stream/19611/11). It confirmed that `fly-proxy`'s HTTP handler buffers the first 10 MB of a request body so it can retry or `fly-replay` it. Once that buffer fills it stops reading from the client until the app answers, or a hardcoded 3 s timeout fires.

That exactly explains what I observed. A render cannot answer before it has the whole label, so there is no early response for the proxy to see, and every request over 10 MB paid the full 3 s.

Then I wrote [a post on Fly's community forum](https://community.fly.io/t/request-bodies-over-10-mb-pay-a-fixed-3-s-ttfb-penalty-http-service/28460), where Fly confirmed the behaviour and pointed me in the next direction for the mitigation.

## Nothing releases the pause

The workaround suggested in that earlier thread is that the pause ends when the proxy gets a response from the instance. An interim response looked ideal: it wouldn't force me to commit a status code before parsing the body. So I tested the entire 1xx space: 100, 102, 103, 199. `fly-proxy` keeps waiting through all of them: an interim response doesn't release the buffer.

Fly [suggested to us](https://community.fly.io/t/request-bodies-over-10-mb-pay-a-fixed-3-s-ttfb-penalty-http-service/28460/4) [HTTP trailers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Trailer), and they would work. It means we would have to commit to a response code before processing the full request. A label can fail to render, exceed a quota, or turn out malformed, and none of that is visible before processing the full request.

API clients expect a standard status code, so I'd have needed a Cloudflare Worker in front to read the trailer and reconstruct the real response. It would have worked, but it is a lot of moving parts to keep a workaround invisible, and I decided against it.

## What the buffer buys

Two `http_service` features need that buffer.

`retry`: covers Fly's own routing rather than your app failing. The proxy can route to an intermediary host that has just died and that it hasn't learned about yet. With the body buffered it sends the request somewhere healthy and the client never notices. Without the body it can't.

`fly-replay` allows you to read a request (up to 10MB in size), then hand it to a different machine or region.

## Why I stopped fighting it

The `retry` is a genuinely good property, and at enough traffic you would hit that window regularly. I have not hit that scale. And a render is idempotent (there's no state to corrupt by doing it twice), so a failed request is safe to send again. I would rather the client retry, or retry under my own policy, than delay every large request.

I never used `fly-replay`.

So the trade is a fixed 3 s on every request over 10 MB, against a rare failure I can absorb and a routing feature I do not need.

## Leaving the HTTP handler

I decided to use a [raw TLS service](https://fly.io/docs/networking/services/). Fly terminates TLS and pipes the TCP connection to the app. Skipping the whole fly.io http processing.

The TTFB dropped instantly. 45 pages went 3.51 s → 538 ms.

<FlyProxyRawTlsChart />

## Autoscaling

The original autoscaling was based on the request count. Dropping to raw TLS makes it possible to scale only by TCP connection count. So I tried that. Behind Cloudflare it is not viable.

Cloudflare doesn't close an origin connection after a response. Its [connection limits documentation](https://developers.cloudflare.com/fundamentals/reference/connection-limits/) puts the Proxy Idle Timeout at 900 s (15 minutes) and states that it "reuses open TCP connections up to the `Proxy Idle Timeout` limit after the last HTTP request", and lists it as not configurable.

Based on my observation, each Cloudflare edge machine holds its own connection pool. So the count `fly-proxy` sees tracks Cloudflare's edge fan-out and idle timers, not how much work is in flight.

Under sustained load the autoscaling either scales too far, or hits the hard limit, which reaches clients as 520s on a quarter of all requests in my benchmark, while the machine sat nearly idle.

Responding with `Connection: close` could help. But it also costs a fresh TLS handshake on essentially every request, plus a cold congestion window on every large upload. That is a tax on exactly the requests I had just made fast.

I measured the handshake on its own, on a body small enough to have no upload ramp to hide it: about 100 requests each, pooled against closed.

<FlyProxyHandshakeChart />

22 ms, and on a large upload the cold congestion window is charged on top of it.

<FlyProxyLargeBodyChart />

No setting makes socket count mean "work in progress." To get that signal back, something has to count dispatched requests.

## Why not just drop Cloudflare

We started using Cloudflare primarily for better visibility into customer latency.
We add a timestamp to the request at the edge, which lets us measure the latency the end user actually observes.
Fly has a header carrying one too, but it isn't in the [documented request headers](https://fly.io/docs/networking/request-headers/), and it is not documented where in the pipeline it gets applied.

So Cloudflare stays and connection counting stays broken. The scaling decision has to move somewhere that understands the workload.

## So I run Pingora

After another [response](https://community.fly.io/t/request-bodies-over-10-mb-pay-a-fixed-3-s-ttfb-penalty-http-service/28460/6) from the Fly.io team, who confirmed that calling the Machines API yourself costs the same as the built-in autostart, because `fly-proxy` does that internally, I decided to add my own proxy.

The app is now split into two process groups: a **proxy** and a **worker**.

The proxy, built on [Pingora](https://github.com/cloudflare/pingora), terminates the public surface and owns auth and the billing gate. Making the workers stateless rendering nodes. Previously the app was a single monolithic container, and every copy of it carried auth and billing along with the renderer.
This lets us independently scale the worker nodes.

<FlyProxyTopology />

The connection problem went away with it. An always-on proxy is the thing Cloudflare pools its sockets against, and those sockets are no longer anybody's scaling signal: the proxy counts dispatched requests and starts workers on that. The same hour-long benchmark that had failed a quarter of its requests now runs at a zero error rate.

And because the proxy is now the thing holding the public surface, keep-alive came back. Measured from the same Hetzner client across the hosted benchmark suite, against the `Connection: close` build:

| comparison | median ratio | median delta |
| ---------- | ------------ | ------------ |
| vs the `Connection: close` run | 0.828 | −22 ms |
| vs the original keep-alive run | 1.028 | +2 ms |

The −22 ms is almost exactly the per-request handshake I had been paying. Removing `Connection: close` gave back what it cost.

## The final numbers

<FlyProxyApproachesChart />

We managed to cut the request time from ~3.5 s down to ~0.52 s, and streamline the app scaling at the same time.

---

## Suspend, don't stop

The proxy **suspends idle workers rather than stopping them.** A stopped machine has to boot; a suspended one restores a memory snapshot. Across the measured cold requests, a stopped machine processed the request in ~1.51 s and a suspended one in ~0.59 s, 61% faster. A warm worker answers in ~150 ms. The snapshot's storage cost is negligible.

<FlyProxySuspendChart />

## The new bottleneck

The split moved a ceiling rather than removing it. Every request now goes through one proxy machine, and a Fly machine gets 1 Gbit of internal network. That gigabit used to belong to a single renderer; it is now shared by the whole cluster sitting behind the proxy.

At 10 MB a label it takes a lot of concurrent uploads to saturate, and I have not come close. But it is a real limit, and it is the kind you only meet under load.

The fix is the lever the split already bought me: run more than one proxy. It is a small machine, 1 shared CPU and 512 MB, so a second one is cheap, and it brings another gigabit with it.

## Measurement methodology

Three runs in August 2026: the cliff on the 9th, the raw TLS service on the 10th, and the proxy split on the 12th. k6 drove the API one request at a time from a Hetzner cpx12 in FSN1 against Fly machines in Frankfurt. Before the split the API was a single machine on 2 dedicated CPUs and 2 GB of RAM; it is now a proxy on 1 shared CPU with 512 MB and renderers on dedicated compute. Each point is the median of 10 requests, 5 on the heaviest, and the renderer itself is unchanged throughout: the only thing that moves is the network path in front of it.

## Next steps

Next I want to look at machine types for the workers. Shared CPUs are a lot cheaper than dedicated ones, but a sustained render workload runs over its CPU share and gets throttled for it, so I have stayed on dedicated. The proxy is in a position to change that. It already sees the size of every request, so it can predict roughly what a render will cost and track what each shared machine has left, instead of handing work to one that has already burned its budget.


Two weeks ago Claude and I worked out why our staging deploys were flaky. Today it's happening again, and the answer is sitting in some session transcript on my disk. Which one? No idea. I remember a phrase from the conversation, not a session title.

Claude Code's own picker doesn't help here. `claude --resume` lists recent sessions for the current project, by title. If the title doesn't ring a bell, you're done. The transcripts themselves are JSONL files under `~/.claude/projects/`, so the fallback is grepping JSON-encoded lines by hand and copy-pasting session ids into `--resume`. I did that maybe three times before deciding it was a tooling problem.

## The palette

I run my agents inside [herdr](https://herdr.dev) (the terminal-native agent multiplexer from [the previous post](/blog/claude-code-herdr-status-plugin)), so I built the fix as a herdr plugin: [herdr-agent-palette](https://github.com/ondratuma/herdr-agent-palette). Press a key, type what you remember, land where it was said. It fuzzy-searches your live panes and their scrollback too, but the section that fixed this particular pain is **sessions**: every Claude Code session on disk, searched by full transcript content. Not titles. Content.

![The palette searching "staging deploy flaky" across sessions: a list of sessions on the left, each led by how long since it last moved and an open/closed marker, and a transcript preview on the right with the matched words highlighted.](/blog/claude-code-herdr-agent-palette.png)

Each row leads with how long since the session last moved and whether it's still open (`●`) or already closed (`○`); the preview shows the conversation with the query highlighted. `Enter` jumps to an open session's pane, and resumes a closed one in a fresh workspace, cwd set to where it ran. So: type `staging deploy flaky`, hit `Enter`, and ask the two-week-old session "that deploy fix, apply it here too".

That last part is what changed how I use it. Old sessions stopped being an archive I dig through and became something I casually jump back into.

It's a self-contained curses TUI, Python standard library only, with a clean-room [fzy](https://github.com/jhawthorn/fzy)-style matcher that folds diacritics (`Matejcek` matches `Matějček`, which matters more than you'd think in a Czech codebase). Install is one command; the keybinding and the resume-command override (useful if you [run multiple accounts](/blog/claude-code-multiple-accounts)) are in the [README](https://github.com/ondratuma/herdr-agent-palette#install).

The transcripts were on disk all along. All they were missing was a search box.



I run several Claude Code agents at once. [herdr](https://herdr.dev) makes that painless. It's a terminal-native agent multiplexer, like tmux but it knows which panes are running agents and lists them in a sidebar. Spinning up five of them is easy. The hard part is knowing which one needs me right now.

They all sit in the sidebar churning, so I'd tab through them one by one looking for the pane that had been stuck on a question for ten minutes while I babysat a different one. The supervising got more expensive than the work.

## What herdr already shows

herdr detects an agent's status on its own and puts it in the sidebar: `working`, `idle`, `blocked`, `done`. Useful, but coarse for triage:

- `blocked` doesn't say whether the agent is waiting on CI or waiting on **me**.
- `idle` and `done` look about the same when you're scanning fast.
- None of it tells you *how long*. The pane that's needed you for eight minutes looks identical to the one that stopped five seconds ago.

So when I glance at the sidebar, two questions go unanswered: what is this pane actually doing, and how long has it been doing it.

## What the plugin adds

An icon and a live timer per agent pane. The icon disambiguates the stopped states; the timer counts how long the pane has held the current one.

| icon | meaning |
|------|---------|
| ⚡ | working |
| 🔁 | looping (running `/loop`) |
| ⏳ | waiting on something automated: CI, a build, a deploy |
| ✋ | stopped, needs me: a question, a decision, an approval |
| ✅ | done, nothing left |
| 💤 | idle at its prompt box |
| 💀 | stale: hasn't moved in over a day |

![herdr sidebar listing seven agent panes, each with a status icon and a live timer: 🔁 7m release watch running /loop watch-ci, ⚡ 12m auth refactor wiring the token middleware, ✋ 18m schema migration waiting on approval, ⏳ 21m e2e suite waiting on CI, ✅ 26m changelog done, 💤 32m scratch idle, and 💀 30h old spike stale.](/blog/claude-code-herdr-status-sidebar.png)

So a pane reads `✋ 8m`: it's wanted me for eight minutes. I scan the sidebar, find the oldest ✋, and go there. **Triage instead of polling.**

## How it knows: the agent reports itself

herdr can tell that a pane stopped. It can't tell *why* it stopped — but the agent knows why. So the interesting half of this is just a convention I gave Claude, dropped into my global `CLAUDE.md` so every session picks it up:

```markdown
## herdr session status

Call the `herdr-status` helper as your activity changes, to tell the user
what you're doing — above all when you need something from them:

- `herdr-status input`   — ✋ you need me before you can continue
- `herdr-status done`    — ✅ finished, nothing left
- `herdr-status waiting` — ⏳ blocked on something automated (CI, a build)
- `herdr-status looping` — 🔁 working in a loop
- `herdr-status working` — ⚡ back to plain progress

End every turn with `done` or `input` — never leave me guessing which.
```

That last line does most of the work. End on `input` and the pane shows ✋ the instant it stops; end on `done` and it shows ✅. The sidebar always tells me whether a stopped pane is blocked on me or genuinely finished, without my opening it.

The states release on their own. `waiting`, `input`, and `done` clear the moment the agent starts working again, while `working` and `looping` stick until it stops. A pane that says ⏳ flips back to ⚡ by itself once CI comes back and Claude resumes.

## How it knows: a daemon fills the gaps

The self-reports cover intent — *why* a pane stopped. herdr already tracks the coarse state of every pane on its own, idle included (sitting at the prompt), so the plugin never has to scrape output to notice an idle pane; it just renders 💤 for the state herdr already reports. What's left is the time. A small background daemon covers the gaps between events: every tick it advances the timer and drops panes that have gone away.

herdr exposes the plumbing for both halves. A plugin hook fires on the lifecycle transitions (`pane.agent_detected`, `pane.agent_status_changed`) and pushes an update the instant a pane changes state; the daemon polls `herdr pane list` on a timer for everything that isn't an event — no socket subscription, no output scraping. The display rides in two herdr metadata slots: the icon and timer share one as a single `⚡ 6m` string (herdr swaps the icon per detected state), and the self-reported detail goes in the other, so a pane can read `⚡ 6m fixing the parser`. The plugin and daemon write to a shared state file so they never disagree about a pane.

I won't paste the whole thing; it's a few hundred lines of bash and Python. But that's the shape of it, and none of it is exotic.

## A small bonus: renaming panes

herdr labels a pane by its repo or folder by default. When three panes live in the same repo doing different things, that label is useless. One more helper fixes it:

```bash
herdr-status-rename "auth refactor"
```

I wired that into `CLAUDE.md` too, so an agent renames its own pane when its task changes. The sidebar stops being three identical repo names and starts telling me who's doing what.

## The result

The agents got cheap to run in parallel long before they got easy to supervise. This closes the gap. The sidebar went from a list of panes I opened one by one into a board I read at a glance, and the only pane I open now is the one with the oldest ✋.



**zpl.tools** is a fast, privacy-first parser and renderer for ZPL — the Zebra Programming Language behind virtually every shipping and retail label.

The pain it solves: a single wholesale order can ship as **thousands of boxes**, each with its own retail or carton label. When you need to *preview* those labels before they print, the existing tools fall down — they're rate-limited, paged, paid, or they want you to upload label data with real customer details to someone else's server. None of them comfortably render a whole order's worth of labels at once.

zpl.tools does. It renders ZPL to pixel-accurate images instantly in the browser — one label or thousands — with no Zebra printer, no API limits, and no round-trip to a third party, so sensitive label data never leaves your machine. The core is written in Rust and built to run anywhere: an online viewer today, with desktop apps and SDKs (Rust, JavaScript, native) on the way.

Carrier labels (FedEx, UPS, DHL) work too — but the thing no other tool does well is previewing retail and carton labels at the scale a real order demands.

Currently in beta, with a full launch planned for 2026.

[Try the online viewer →](https://zpl.tools/online-viewer)



**bytiq.cz** pulls property listings from all the major Czech real-estate portals into a single, queryable analytical view.

I built it for myself. A partner and I were actively investing and wanted to rank offers by *our* parameters — above all **price per m² against the neighborhood average** — instead of whatever order each portal happened to show. No existing tool sliced the market that way, and the data was scattered across portals that never compare against each other.

- **Scraping:** Node.js scrapers across the major Czech property-listing platforms.
- **Application data:** PostgreSQL.
- **Analytics:** Snowflake on top, powering the analytical layer.

It's the personal version of a pattern I keep applying at work: scrape disparate external sources, normalize them, and surface the result as a queryable analytical layer with a usable UX on top. In active use since 2025.



**Awincado** was a heavily customized e-commerce store. I ran the build with a small team — a backend and a frontend engineer reporting to me — and owned the product and delivery side myself.

# The technical side
Technically it was a set of extensions on top of the [Vendure](https://vendure.io) e-commerce platform, plus a custom storefront:
- contest / event mechanics
- coupon-code handling with automated email fulfillment
- [Zalando](https://zalando.com) integration
- GoPay payment integration
- PayU payment integration
- [Pohoda](https://pohoda.cz) accounting integration


I am a Product Engineera Tools Buildera Domain Bootstrapperan Engineering Leader

Latest projects

zpl.tools

bytiq.cz

Awincado

Latest blog posts

Contact


2021 - present	ShipMonk	Team Lead, B2B Domain (Senior → TL)
2020 - 2021	NFCtron	Fullstack engineer (after seed round)
2021	Sportmatiq	Founding engineer & tech lead (part-time)
2019 - 2019	AI Center	Research tooling (Python)
2016 - 2016	MALPRO	Automation developer (Python)