DEV Community: Qasim Parray

Core Web Vitals: What Cloudflare's BEACON Data Says to Fix First

Qasim Parray — Fri, 02 Oct 2026 16:38:14 +0000

I have a bad habit with performance work. I open Lighthouse, see a red number, and start fixing whatever the report lists first. Usually that's an image that's 40KB too big. It feels productive, and it moves the score, and half the time it has nothing to do with what my client's users actually wait for.

So when Cloudflare released a dataset of real-user measurements from about 10,000 of the biggest sites on its network, I read the BEACON announcement with a specific question: if I had one afternoon to improve Core Web Vitals on a normal client site, where should it go? Short version: fix the server response and the render delay before you touch a single image, and stop testing only on Chrome.

I haven't run BEACON's BigQuery queries against my own client work yet, so treat what follows as a reading of Cloudflare's published numbers plus my opinions about them, not as a lab report.

What the dataset actually is

BEACON is anonymized real-user monitoring data, refreshed daily in Google BigQuery. Cloudflare says it covers roughly 10,000 large sites and every major browser engine. Domain names and URL paths are stripped, and any group with fewer than five data points is dropped. Records are published as histograms, not averages, so you can compute your own percentiles.

That last detail matters more than it sounds. Most "average page speed" charts you see online are averages of averages. A histogram lets you ask the question Google itself asks: what happens at the 75th percentile? The official thresholds on web.dev are LCP within 2.5 seconds, INP at 200 milliseconds or less, and CLS at 0.1 or less, all measured at the 75th percentile of page loads.

One caveat before I lean on any of this. Ten thousand big sites on one CDN is not the web. A five-page brochure site on shared hosting has different problems from a site big enough to be in this sample. I'll come back to that at the end.

Where LCP time actually goes

Largest Contentful Paint gets split into four parts: time to first byte, load delay, load duration, and render delay. Cloudflare publishes the breakdown for pages that land in the good, needs-improvement and poor buckets, and the shape is what interested me.

As I read the table, pages with good LCP have a document TTFB around 598ms, while poor ones sit near 1,891ms. Load delay goes from 76ms to about 1,485ms. Render delay goes from 157ms to about 2,002ms. Load duration, the time actually downloading the LCP resource, barely moves between buckets.

Read that again, because it is the opposite of what most tutorials teach. The advice everywhere is "compress your hero image". But download time is the part that hardly differs between fast and slow pages. What differs is everything around the download: how late the server answers, how late the browser discovers the resource, and how long it sits idle before painting.

So here's the order I'm going to work in from now on:

Check TTFB first. If the HTML takes more than a second to arrive, nothing else you do will get you under 2.5 seconds on a mid-range phone.
Check load delay. This is the gap between the HTML arriving and the browser starting to fetch the LCP image or font.
Check render delay. Usually a blocking script or a client-side framework that hasn't hydrated.
Only then look at file size.

Measure the four parts on your own site

You don't need BigQuery to find out which part hurts. The web-vitals library has an attribution build that hands you the same four numbers per page view.

import { onLCP } from 'web-vitals/attribution';

onLCP(({ value, attribution }) => {
  navigator.sendBeacon('/vitals', JSON.stringify({
    metric: 'LCP',
    total: Math.round(value),
    ttfb: Math.round(attribution.timeToFirstByte),
    loadDelay: Math.round(attribution.resourceLoadDelay),
    loadDuration: Math.round(attribution.resourceLoadDuration),
    renderDelay: Math.round(attribution.elementRenderDelay),
    element: attribution.target,
  }));
});

Collect a week of that, sort by the 75th percentile of each field, and the biggest one is your afternoon. A very common cause of a fat load delay is a boring one: the hero image is set as a CSS background, so the browser can't see it until the stylesheet has been parsed. Moving it to a real image tag with a priority hint fixes most of it.

<!-- before: browser discovers this late, inside the CSS -->
<div class="hero" style="background-image:url(/hero.webp)"></div>

<!-- after: discoverable in the HTML, fetched early -->
<img src="/hero.webp" width="1200" height="600"
     fetchpriority="high" alt="Product dashboard on a laptop">

That is a two-line change and it attacks the load delay bucket, not the file size bucket. The width and height attributes also cover CLS, so you get a second win for free.

The browser engine gap nobody tests

This was the finding that made me put my coffee down. Cloudflare reports that WebKit, the engine under every iPhone browser, is the best performer overall. Fine. But in 46 countries, together over 10% of traffic, WebKit's LCP or INP trails Blink-based browsers by at least 10%. Their example is Cambodia, where WebKit's LCP is 50% worse than Blink's while making up 17.5% of page views.

It's a trap I fall into easily. Testing on desktop Chrome, maybe throttled, means looking at one engine, in one country, on good bandwidth. If your clients sell to people in Southeast Asia, Africa or South America, the browser you never open may be the one a fifth of the customers use.

The practical fix is dull. Put the field data you collect (like the beacon above) behind a breakdown by browser engine and country, and look at the tail instead of the median. If you use a hosted RUM tool, check whether it lets you segment that way. If it doesn't, that's a real reason to switch.

Soft navigations change what "fast" means for SPAs

The other table in the post compares hard navigations (a full page load) with soft navigations (client-side route changes in a single-page app). At the 75th percentile, hard navigations come in at 1,421ms and soft ones at 582ms. At the median it's 791ms against 274ms. Soft navigations render two to three times faster at every percentile Cloudflare lists.

Before anyone tweets "SPAs are faster", look at the second half of that finding: the landing page in those apps is still heavy, with a median around 1,370ms. You pay the cost once, at the door, and then every click is cheap.

That reframes a decision I get asked about a lot. If your users typically land on one page and leave, a heavy client-side framework buys you nothing and costs you the entry. If they land and then click through ten screens, the trade flips. I wrote about a related piece of this in my post on React 19.3 view transitions, where the transition itself was the thing I'd been faking with timeouts. And the entry-cost side of the story showed up in my notes on Turbopack chunking in Next.js 16.3.

Chrome measures soft navigations experimentally at the moment, so I'd treat these numbers as a preview of where measurement is going, not a metric you can put in a client report today.

INP: where the 200ms goes

For INP, Cloudflare splits the interaction into input delay, processing time and presentation delay. The good-bucket values are about 18ms, 55ms and 56ms. The poor bucket has 84ms of input delay, 284ms of processing and 217ms of presentation delay.

Processing time is where your own code lives, and it's the bucket that grows fastest. The usual cause is one click handler doing too much before the browser gets to paint. The smallest fix I know is to yield to the main thread after the visible work is done.

button.addEventListener('click', async () => {
  showSpinner();                       // the thing the user must see now

  // let the browser paint before the heavy part runs
  if ('scheduler' in window && 'yield' in scheduler) {
    await scheduler.yield();
  } else {
    await new Promise(r => setTimeout(r, 0));
  }

  runExpensiveFilter();                // the slow part
});

scheduler.yield() is not in every browser yet, hence the fallback. It won't make the expensive function faster. It makes the interaction feel faster, which is what INP is measuring in the first place.

What I'd do this week

Ten thousand large sites is the right sample to learn from and the wrong one to copy blindly. Use it to decide what to measure, then measure your own.

Here's the afternoon plan. Add the attribution snippet above to one production site and let it run for a few days. Look at the 75th percentile of TTFB, load delay and render delay, and fix the biggest one. Then split the same data by browser engine and check whether Safari on iPhone is worse than Chrome for your audience. If you'd like to see the sort of client work where I do this kind of audit, my portfolio has examples. And if you're curious about the raw data, open BEACON in BigQuery and run one query against the LCP histograms for a browser and country you care about. It takes about ten minutes and it will change what you look at first.

Originally published at abrarqasim.com. I write there about React, PHP, Rust, Go and the AI tooling around them.

Vite+ 1.0 and Oxlint: The Speedup Claims I'll Test Before Switching

Qasim Parray — Thu, 01 Oct 2026 16:38:10 +0000

Confession: I have been putting off a lint cleanup for four months. Not because it's hard, but because every time I run the type-aware ESLint pass on a mid-sized TypeScript project, I go make coffee, come back, and it's still going. So when Evan You published a four-month progress report on VoidZero at Cloudflare with the line "up to 18x faster than ESLint in large codebases", my first reaction was suspicion, and my second was to open a terminal.

Short version for the impatient: the numbers are vendor numbers, the direction is believable, and Vite+ 1.0 is the first time the whole Rust-based JavaScript toolchain comes in one box. I haven't measured any of it on my own repos yet, so this post is a reading of the announcement plus the exact checks I'm going to run before I let any of it near a client project. If you want the checks without the commentary, skip to the last section.

What actually shipped in four months

The post lists five things, and they are worth separating because they are different kinds of claims. The Oxc React Compiler compiles React apps 10x faster than the Babel version. Vitest 5 is up to 50% faster than Vitest 4. tsgolint, the type-aware engine behind Oxlint, is stable and runs 12 to 18 times faster than ESLint with typescript-eslint. Oxfmt is 7x faster than Prettier now that its JSON, CSS, SCSS, Less, GraphQL and YAML formatters are written in Rust. And Vite+ hit 1.0.

Notice the qualifiers. "Up to 50%" is a best case. "Up to 18x" is a best case on large codebases. "10x" for the React Compiler is a compile-step number, and compile time is rarely the slowest part of your build. Every one of these is a real speedup on some project, and none of them tells me what happens on mine. That's not a knock on VoidZero, every vendor writes this way. It's a reminder that a benchmark from the people who wrote the tool answers "can this be fast?" and not "will this be fast for me?".

The other detail I liked is the stack argument. Oxc is the compiler, Rolldown is the bundler, Vite sits on top, Oxlint and Vitest use the same parts. When one layer gets faster, the layers above get faster for free. The logic holds up on paper, since a shared parser and shared AST mean one fix pays off in several tools, so I'm inclined to believe it.

The part I care about: type-aware linting

Linting with type information is the slow one, and it's the one that catches real bugs. Floating promises, misused async callbacks, unsafe any flowing into a function. These need the TypeScript program in memory, and that's where ESLint plus typescript-eslint spends its time.

According to the announcement, tsgolint supports 59 of the 61 typescript-eslint type-aware rules, and Oxlint can share a single TypeScript program between linting and type-checking instead of building it twice. That second part is the one I'd look at first, because most CI pipelines I've seen run tsc --noEmit and ESLint as two separate steps, and both of them pay to parse the whole project.

The config change they show is small:

import { defineConfig } from "oxlint";

export default defineConfig({
  options: {
    typeAware: true,
    typeCheck: true,
  },
});

Compare that with what I have today, which is an eslint.config.js with a parser option pointing at a tsconfig, a project service setting I had to look up twice, and a comment explaining why the slow rules are slow. Fewer moving parts is a win even if the speedup turns out to be 6x instead of 18x.

The two missing rules matter, though. If your team leans on one of the two typescript-eslint rules tsgolint doesn't cover, you'll be running both linters for a while. I don't know which two they are, and the announcement doesn't say, so that's the first thing I'd check in the docs.

Oxfmt and the Prettier question

Formatters are a religious topic, so let me keep this practical. Oxfmt claims Prettier-compatible output, and the migration is two commands:

pnpm add -D oxfmt
pnpm oxfmt --migrate prettier
pnpm oxfmt

The risk with any Prettier replacement is the diff. If the output differs on even 0.5% of lines, you get a giant formatting commit that wrecks git blame, and I've already lived through that once with a different tool (I wrote about the one commit that broke my git blame with Laravel Pint). So the plan is boring: run Oxfmt on a branch, count changed lines, and add the formatting commit to .git-blame-ignore-revs if I keep it.

Speed on a formatter is also the least interesting win for me. On a small project, formatting time is already a few seconds. I'd switch for the single toolchain, not for the seconds saved.

Vite+ 1.0 and the decision fatigue argument

Vite+ bundles Vite 8, Vitest 5, Rolldown, Oxlint, Oxfmt and task caching with defaults chosen for you. Evan You's pitch is that agents and humans both waste time on "which linter shall I use?" and that fewer choices means faster shipping. I half agree.

The half I agree with: a new project shouldn't need six config files before the first commit. The half I don't: defaults are great until the day you need to deviate, and then you're reading a unified tool's docs instead of five well-known ones. I have client projects pinned to specific ESLint plugins for framework reasons, and a "great defaults" toolchain doesn't help those. I'd use Vite+ for new projects and leave the old ones alone until there's a reason.

There's also a framing I'm skeptical of. The post says that in 2026 the mission is making developers' agents faster, because once inference is quick, a slow linter or type-checker becomes the bottleneck. That's true as far as it goes. But if your agent loop spends 40 seconds waiting on a build, the fix is often to run less, not to run the same thing faster. Scoping a lint run to the changed files beats a 10x faster full lint on every iteration. Faster tools and smarter invocations stack, so do both.

Bundled dev and the React Compiler

Two more items deserve a mention. The first is Bundled Dev, formerly Full Bundle Mode, which uses Vite's production bundler in development. It's behind an experimental flag today, and the post says Cloudflare's own dashboard already uses it for all internal developers. That's a useful data point, since a big dashboard app is the kind of project where unbundled dev servers struggle with thousands of module requests.

import { defineConfig } from "vite";

export default defineConfig({
  experimental: {
    bundledDev: true,
  },
});

The second is the Oxc React Compiler, enabled through @vitejs/plugin-react with compiler: true plus the oxc-transform-react package. I've written about how React 19.3 view transitions let me delete some hand-rolled timing code, and the compiler is the same category of change: less manual work in components. My hesitation is that a compiler is a correctness risk in a way a linter isn't. A slower linter wastes time. A wrong compile output ships a bug. I'd want a full test run and a visual check before trusting it on anything with money attached.

What I'll run before switching

Here is the checklist, in the order I'd do it on a real project. It takes about an hour, and it's the honest way to test a vendor claim.

First, time your current baseline. Run your existing lint, type-check and test commands three times each and write down the median. Without a baseline, "18x faster" is a number you can't verify.

for i in 1 2 3; do /usr/bin/time -f "%e s" pnpm eslint . ; done
for i in 1 2 3; do /usr/bin/time -f "%e s" pnpm tsc --noEmit ; done
for i in 1 2 3; do /usr/bin/time -f "%e s" pnpm vitest run ; done

Second, do the same with the new tools on a branch, with warm and cold caches. Cold-cache numbers are what CI sees, and warm-cache numbers are what you see locally. Third, diff the outputs: lint findings from both linters on the same commit, and formatter output on the same files. A faster tool that misses a class of bug is not a win. Fourth, check the two type-aware rules that tsgolint doesn't cover against your config.

If you want to try it this week, pick your slowest repo, run the baseline loop above today, and post the three medians somewhere you'll find them again. Then install Oxlint on a branch and compare. I'll be doing the same on my own projects, and I'd rather you tell me the announcement's numbers didn't hold up for you than take my word or theirs. You can see the kind of projects I'd test this on in my portfolio.

Sources for the numbers above are in the VoidZero announcement on the Cloudflare blog, and the tools themselves live at Vite and Oxc.

Originally published at abrarqasim.com. I write there about React, PHP, Rust, Go and the AI tooling around them.

Laravel Wayfinder: Typed Routes and the Deploy Bug I Hit

Qasim Parray — Thu, 01 Oct 2026 08:38:10 +0000

Three weeks ago a teammate renamed a route in a Laravel app we were shipping together, posts.show became posts.view because he hated the old name, and nothing in PHP complained. The break showed up on the frontend instead, quietly, because somebody (me, a few months earlier) had hardcoded /posts/${id} directly into a fetch call two files away from any route definition. Nobody noticed until a client clicked a broken link in production. That is the exact category of bug Laravel Wayfinder exists to make impossible, and after running it on a real Inertia project for a few weeks, it mostly delivers. Mostly, because it also handed me a new way to break a deploy that I had never hit before.

What Wayfinder actually generates

Wayfinder is a Laravel package that reads your registered routes and controllers, then generates fully typed TypeScript functions for each one. Install it with Composer and pair it with the official Vite plugin so it regenerates automatically as you work:

composer require laravel/wayfinder
npm i -D @laravel/vite-plugin-wayfinder

Add the plugin to vite.config.js, and every time you touch a controller or a route file, a fresh set of TypeScript definitions lands in resources/js/actions and resources/js/routes. You can also run it by hand:

php artisan wayfinder:generate

That command is doing something conceptually simple but tedious to write by hand: it walks the router, matches parameter bindings, resolves which controller method actually owns each route, and produces a function that knows its own URL and the shape of the arguments it expects. The HTTP method comes along for free too, which matters more than it sounds like once you're calling destroy() and show() from the same file.

Swapping hardcoded URLs for typed functions

Here's the pattern I was using before, which is probably familiar if you've built an Inertia or React frontend against a Laravel API:

// before: a string someone typed by hand, nowhere near the route definition
async function loadPost(id: number) {
  const response = await fetch(`/posts/${id}`);
  return response.json();
}

Nothing here checks that /posts/${id} still matches what's in routes/web.php. Rename the route, or swap the parameter binding from an id to a slug, and this line keeps compiling right up until it 404s in front of a user. With Wayfinder generating functions from the same PostController the route actually points to, the call becomes this instead:

import { show } from "@/actions/App/Http/Controllers/PostController";

async function loadPost(id: number) {
  const response = await fetch(show(id).url);
  return response.json();
}

If the route changes, wayfinder:generate regenerates show, and my code either keeps compiling because nothing meaningful changed, or TypeScript flags the call site because the parameters shifted. That second case is the entire point: a rename that used to fail silently in the browser now fails loudly at build time, on my machine, before anyone else sees it.

The part I didn't expect to like as much is how it handles routes that share a controller method. If two named routes point at the same action, Wayfinder can't guess which URL you mean, so it hands back a dictionary keyed by the route instead of a plain function:

import { index } from "@/actions/App/Http/Controllers/ClientPaymentsController";

// clients.payments.index and clients.payments.archive both hit ClientPaymentsController@index
index["/clients/{client}/payments"]({ client: 1 });

The first time I saw that shape in an editor autocomplete, I assumed it was a bug in the generator. It isn't. It's Wayfinder refusing to silently guess which of two ambiguous routes you meant, which is a more honest failure mode than most route helpers I've used.

How this compares to what I was doing before

Before Wayfinder, my go-to for this problem was Ziggy, which exposes a route() helper on the frontend that mirrors Laravel's own named-route syntax. Ziggy solves a chunk of the same problem: you stop hardcoding URLs, and a route rename gets picked up automatically. What it doesn't give you is typed arguments. Calling route('posts.show', { id: 'not-a-number' }) compiles fine and fails at runtime, because Ziggy's helper takes a loosely typed object and doesn't know or care what the controller expects. Wayfinder's generated functions come from the same source of truth, the router, but because they're generated per-controller-method rather than interpreted at runtime, TypeScript actually understands the parameter shape. I didn't rip Ziggy out of the project; the two coexist fine, and there are still a few places where Ziggy's simpler route() call is genuinely less code for a one-off link. But every new fetch call I write goes through Wayfinder now, because the difference between "this compiles" and "this actually matches the controller" is exactly the gap that caused the bug I opened this post with.

The gotcha nobody mentions until you hit it

The bug I actually lost an afternoon to wasn't in the generated code at all. It was in the deploy pipeline. Wayfinder reads routes from the application's live router at generation time, and our deploy script ran php artisan optimize, which caches the route table, before the frontend build step. On the release where we added a new controller action, the cached route table from the previous release was still in memory when wayfinder:generate ran during npm run build. The new action was invisible to it. Vite's build failed with an error about a module that "didn't exist," pointing at a resources/js/actions file that had simply never been generated, because the router it asked didn't know the route existed yet.

The fix, once I found where to look, is one line in the deploy script, run before the frontend build and after the code is in place:

php artisan route:clear
npm run build

Clearing the route cache before regenerating TypeScript definitions and only re-caching it afterward closed the gap. I want to be annoyed that this isn't the default behavior, but I also understand why it isn't: route caching and TypeScript generation are two features written by different people for different reasons, and the order they run in is a deploy-script decision, not a package decision. It just means you now own one more ordering constraint in a script that was already fragile.

Where it still falls short

Wayfinder only knows about routes that exist when you run the generator, so anything built dynamically at runtime, a route registered from a database-driven plugin system, for instance, won't show up no matter how carefully you order your deploy steps. I also had to opt in explicitly to generate the .form variants for plain HTML form submissions, which cost me twenty minutes of confusion before I found the flag:

php artisan wayfinder:generate --with-form

And the package itself is still labeled beta, with the maintainers warning the API can change before a 1.0 release. That's a reasonable thing to be cautious about if you're gluing generated code into a large codebase you don't want to touch twice.

What I'd do this week

If you're already running Laravel with an Inertia or React frontend and you've ever hardcoded a URL string that later broke silently, install Wayfinder on a single low-risk feature branch. Wire in the Vite plugin, then replace the fetch calls on just one page and see how the generated types feel before you touch anything else. Then check your own deploy script for the same optimize before build ordering that bit me. It takes about ten minutes to confirm, and it's a lot cheaper to fix before a release than after one. I write up more of this kind of Laravel tooling friction, alongside the Pint formatting change that broke a client's git blame, on this blog, and I take on exactly this flavor of frontend-backend integration work through my consulting practice when teams want a second set of eyes before they ship it.

Originally published at abrarqasim.com. I write there about React, PHP, Rust, Go and the AI tooling around them.

Testing the 9x Smaller Local LLM Claim on a GPU-less VPS

Qasim Parray — Wed, 30 Sep 2026 16:38:09 +0000

Last month I did something no sane person should try on a Tuesday night: I downloaded a custom fork of llama.cpp from a company I'd never heard of, just to run a 27 billion parameter model that supposedly fits in under 6 gigabytes. I'd read about it in Simon Willison's comment on the release, a ternary-quantized model called Bonsai 2 27B, pitched as "near-lossless compression in a 9x smaller footprint." Near-lossless is a big claim for something throwing away most of the bits in every weight. I wanted to know whether that phrase meant what I hoped, or whether it was the kind of number that only survives contact with a benchmark table. So instead of running it on a beefy Mac like Willison did, I pointed it at the cheapest box I own: the small Hetzner VPS that runs this very blog's publishing pipeline. Here's what actually happened.

What "ternary" buys you and what it costs

Most quantized models you download are 4-bit or 8-bit: each weight still gets a handful of possible values. Ternary quantization is far more aggressive. Every weight collapses to one of three values, roughly minus one, zero, or plus one, and the model leans on scaling factors to recover something close to the original behavior. Prism's Ternary-Bonsai-2-27B-gguf takes a 27 billion parameter model and compresses it down to a single GGUF file just under 6 gigabytes, using a PTQ1_0 format that most mainstream llama.cpp builds can't even read yet. That's why you need Prism's llama.cpp fork instead of the stock binary: the 1-bit quantization support isn't merged upstream.

The tradeoff is obvious once you say it out loud. You're asking a model to represent everything it knows using something closer to a light switch than a dial. Whether that "near-lossless" label holds up depends entirely on what you're asking it to do, and I was not about to take a marketing line at face value without running it myself.

Getting it running on a box with no GPU

Willison's setup used the macOS Apple Silicon build and Metal acceleration, and reported 20 to 44 tokens per second depending on the run. I don't have an M-series Mac sitting around for this kind of experiment, and I was more curious about the worst case anyway: what happens on a machine with no GPU at all. Prism ships CPU-only Ubuntu binaries alongside the CUDA and Metal ones, so I grabbed that instead.

curl -fL https://github.com/PrismML-Eng/llama.cpp/releases/download/prism-b10685-7dffb15/llama-prism-b10685-7dffb15-bin-ubuntu-x64.tar.gz -o bonsai-runtime.tar.gz
tar -xzf bonsai-runtime.tar.gz

curl -fL https://huggingface.co/prism-ml/Ternary-Bonsai-2-27B-gguf/resolve/main/Ternary-Bonsai-2-27B-PTQ1_0.gguf -o bonsai.gguf

./llama-prism-b10685-7dffb15/llama-server -m bonsai.gguf --port 8331 -c 8192

The download itself was the fast part, five and a half minutes on the VPS's connection for a model that would normally arrive as forty-plus gigabytes uncompressed. The server started fine and the built-in web UI came up at localhost, same as Willison described. Where it stopped being fun was throughput: without a GPU to lean on, I was getting something in the neighborhood of two to three tokens a second on simple prompts. That's the kind of speed where you start a request, go refill your coffee, and come back to find it's maybe a third done. Usable for a background batch job. Not usable for anything where a person is sitting there waiting.

I also hit a smaller version of the same oddity Willison mentioned: restarting the server sometimes changed the throughput noticeably, once by close to 40 percent, with no configuration change on my end. I don't have a clean explanation for that, and neither did the release notes.

Memory turned out to be the easier problem to reason about. The GGUF itself sits under 6 gigabytes, but once you add the context window and the server's own overhead, plan on closer to 8 or 9 gigabytes of RAM before you touch a single prompt. My VPS has 16, so there was headroom, but I've seen enough OOM-killed processes on smaller boxes to say: check free -h before you start the server, not after it silently dies mid-download.

So is it actually near lossless

Here's where I have to be honest about the limits of a one-evening test. I did not run a proper benchmark suite against the full-precision version of this model. What I did was throw a handful of the kinds of questions I actually ask models day to day: summarizing a paragraph of documentation, writing a short regex, explaining a stack trace, renaming a batch of variables to something less embarrassing. On those, the quantized model held up better than I expected for something described in bits rather than bytes. It didn't fall apart or produce garbage. But "didn't fall apart on five casual prompts" and "near-lossless" are different claims, and I'm not going to pretend I verified the second one just because the first one felt true.

What convinces me the underlying technique deserves attention, rather than dismissal, is the pace of the surrounding field this year. Willison's own year-in-review post on 2026's LLM developments makes the case that most of the meaningful progress hasn't been raw capability, it's been models crossing a threshold from "often makes mistakes" to "reliable enough to use daily" at a given size and cost. A 9x compression ratio that gets even 80 percent of the way to lossless changes which threshold a given piece of hardware can clear. That's a more interesting question than whether any single benchmark number is exactly right.

When self-hosting something like this actually makes sense

I already wrote about what this blog's own infrastructure costs to run, and the honest answer is that a hosted API call is almost always cheaper than the electricity and hardware amortization of running your own inference, unless you're doing enough volume to change that math or you have a hard requirement that the data never leaves your machine. Ternary quantization doesn't flip that equation for most people. What it does is lower the floor: a model that used to need a $2,000 GPU to run at a usable speed might now limp along, slowly, on a $5 VPS, or run at a genuinely usable speed on a laptop that couldn't fit the full-precision version in memory at all.

That's a narrow use case. If you're prototyping something that has to work entirely offline, or you're testing whether a smaller footprint model is "good enough" before committing to a paid deployment, this is worth twenty minutes of your time. If you just want a model that answers questions quickly, pay for the API and skip the custom fork.

There's also a version of this that has nothing to do with speed. If you're building something where the data genuinely can't leave a customer's premises, a compression scheme that turns a 27 billion parameter model into a file smaller than a typical Blu-ray disc is a real answer to "can we even fit this on the hardware they gave us," even before you ask how fast it runs. I've had exactly one client conversation this year where that constraint was non-negotiable, and it wasn't fast, but it worked, which mattered more than tokens per second in that specific case. Most of the client infrastructure work I take on through my consulting practice still ends up on a hosted API for exactly this reason.

What I'd actually try this week

If you want to reproduce this without the CPU-only pain, grab whichever prebuilt binary matches your own hardware from Prism's release page, not necessarily the Ubuntu CPU one I used, and time a handful of real prompts against whatever you're currently paying for. Write down the tokens per second and the answer quality side by side. That fifteen-minute comparison will tell you more about whether "near-lossless" and "9x smaller" apply to your workload than any number in a release announcement, mine included.

Originally published at abrarqasim.com. I write there about React, PHP, Rust, Go and the AI tooling around them.

How I Stopped Opening Ports With Cloudflare Tunnel

Qasim Parray — Wed, 30 Sep 2026 08:38:08 +0000

I almost opened port 3000 on this very server to show a client her staging dashboard. Old habit: spin up the app, open the port, send a link, forget about it until a scanner finds it. I caught myself, and instead spent twenty minutes wiring up a Cloudflare Tunnel, which is now how every internal tool on this box reaches the outside world. Zero open inbound ports on the firewall except SSH.

What a tunnel actually replaces

Before tunnels, exposing something self-hosted meant one of three options: open a port and hope your reverse proxy config is airtight, run a VPN and make every viewer install a client, or pay for a static IP and deal with port forwarding on top of it. The cloudflared daemon runs as an outbound-only agent on your server, holds a persistent connection to Cloudflare's edge, and routes traffic to your app through that connection instead of through anything listening on a public port. Nothing needs to accept inbound connections except cloudflared itself, and it initiates the connection, so there's nothing for a port scanner to find.

Setting it up for a real service

Here's the config I actually run for the staging dashboard, a Grafana instance living on the same Docker network:

# config.yml
tunnel: 8f2a1c9e-staging-dashboard
credentials-file: /etc/cloudflared/8f2a1c9e.json

ingress:
  - hostname: staging.clientdomain.com
    service: http://grafana:3000
  - hostname: pipeline.abrarqasim.com
    service: http://localhost:8000
  - service: http_status:404

That last catch-all rule matters more than it looks. Without it, any hostname that hits the tunnel but isn't explicitly listed falls through to cloudflared's default behavior, which in older versions meant an unhelpful blank response. An explicit 404 at the bottom means anything you haven't wired up fails obviously instead of quietly.

Running it as a Docker service instead of a bare systemd unit keeps it on the same network as the containers it's routing to, which avoids a whole class of "why can't cloudflared reach my app" debugging:

services:
  cloudflared:
    image: cloudflare/cloudflared:latest
    command: tunnel --config /etc/cloudflared/config.yml run
    volumes:
      - ./cloudflared:/etc/cloudflared
    networks:
      - app_network
    restart: unless-stopped

The DNS side is one command once the tunnel exists: cloudflared tunnel route dns 8f2a1c9e-staging-dashboard staging.clientdomain.com creates a CNAME pointing at your tunnel's unique subdomain on Cloudflare's edge, and it propagates almost immediately since you're not waiting on your own registrar. I've set up a dozen or so of these now and the DNS step has never once been the part that went wrong; it's always the ingress config or a container sitting on the wrong Docker network.

Gating it behind a login instead of a shared link

A public hostname is still a public hostname, so for anything more sensitive than a demo dashboard I put Cloudflare Access in front of the same tunnel. It's a policy layer, not a separate piece of infrastructure: you tell it which email addresses or domains are allowed, and a visitor has to click through a one-time code sent to their inbox before the ingress rule above ever forwards the request. For a client dashboard, I scope the policy to her exact email address and mine, which means the tunnel hostname can leak into a Slack message or a bookmark without becoming a real exposure. It took me longer to write this paragraph than it did to set the policy up in the dashboard.

Cloudflare Tunnel vs Tailscale, for the specific case of "show a client something"

I use both, for different jobs. Tailscale is the right tool when the audience is me and maybe one other engineer, because it puts everyone on a private mesh network and nothing is reachable from the open internet at all, full stop. That's the wrong shape for a client demo: she doesn't want to install a VPN client to look at her own dashboard. A Cloudflare Tunnel terminates at a normal HTTPS hostname anyone can open in a browser, with Access rules in front of it when I want that email gate. For anything meant for a non-technical person to click a link and see, tunnel wins. For anything meant only for me and my own machines, Tailscale wins, and I'd rather run both than force one tool to do the other's job badly.

The failure mode worth planning for

Cloudflared is a single outbound process, and if it crashes or the box reboots without it restarting, everything behind that tunnel silently goes dark from the outside, with no local symptom at all, because the app itself is still running fine on its port. I lost about forty minutes the first time this happened to me, checking Grafana's own logs and the app container's health before it occurred to me to check whether the tunnel process was even still alive. restart: unless-stopped in the compose file above is not optional, and I added a simple curl-based healthcheck that hits each tunneled hostname from an external monitor every five minutes specifically because a dead tunnel produces no error anywhere on the server itself, only silence on the client's end.

What to set up this week

If you're still opening ports for anything you self-host, the current cloudflared release installs in about ten minutes and the config above is close to a complete starting point for a single service. Start with whatever internal tool you're most tempted to expose "just for a minute," wire the ingress rule, add an Access policy if more than one person needs to see it, and check your firewall rules afterward to confirm you can actually close that port instead of just adding an unused alternative next to it. I run this exact setup on the box behind what this blog actually runs on, and the rest of the self-hosting and client infrastructure work I do is at abrarqasim.com/work.

Originally published at abrarqasim.com. I write there about React, PHP, Rust, Go and the AI tooling around them.

Coolify vs Dokploy: What Actually Differs After a Real Migration

Qasim Parray — Tue, 29 Sep 2026 16:38:05 +0000

A client asked me to stop deploying her staging environment by SSHing in and running git pull && docker compose up -d --build like it's 2019. Fair complaint. I'd been meaning to try a self-hosted PaaS instead of hand-rolled Caddy and compose files for a while, so I spun up two identical Hetzner CPX21 boxes and installed Coolify on one, Dokploy on the other, then deployed the same small Laravel app plus a Postgres database to both.

Getting either one running takes about the same four minutes

Both install with a single curl-to-bash command, which I'll admit made me nervous the first time and doesn't anymore, mostly because I've read both scripts now:

# Coolify
curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash

# Dokploy
curl -sSL https://dokploy.com/install.sh | sh

Both scripts do roughly the same thing: check Docker is installed, pull a handful of containers, wire up Traefik or their own proxy, and hand you a dashboard URL. Coolify's install finished in about three and a half minutes on my box. Dokploy's took closer to five, mostly because it also stands up Docker Swarm mode even for a single-node install, which Coolify only does once you add a second server.

Where the two actually diverge: build strategy

This is the part that matters if you deploy anything that isn't a plain Dockerfile. Coolify defaults to Railpack, its newer buildpack successor to Nixpacks, though Nixpacks is still there as a fallback. Dokploy sticks with Nixpacks and Heroku Buildpacks side by side, and lets you pick per application. For my Laravel app, both auto-detected PHP correctly and produced a working image without a Dockerfile, but Coolify's Railpack build was noticeably faster, about 40 seconds against Dokploy's Nixpacks build at just over a minute, largely because Railpack caches Composer layers more aggressively by default.

Neither win matters if you already have a Dockerfile you trust, which is what I ended up using for the client's app anyway once I needed a custom PHP extension neither buildpack shipped.

Database management is where Coolify pulls ahead for me

Coolify ships managed databases (Postgres, MySQL, MariaDB, Redis, and a handful of others) with one-click provisioning, automatic backups to S3-compatible storage, and a UI for restoring a specific backup without touching a shell. Dokploy supports the same list of engines, and its backup story is solid too, but the restore flow currently routes through the CLI rather than a full point-and-click restore in the dashboard. For a client who isn't going to SSH into anything, that's the difference between "she can restore last night's backup herself" and "she has to text me."

# the compose service definition both platforms happily imported as-is
services:
  app:
    build: .
    environment:
      APP_ENV: production
      DB_HOST: postgres
    depends_on:
      - postgres
  postgres:
    image: postgres:17
    volumes:
      - pgdata:/var/lib/postgresql/data
volumes:
  pgdata:

Networking and multi-server access work differently too

Custom domains and automatic HTTPS worked the same way on both within a couple of minutes of pointing DNS at the box, so that's a wash. The gap shows up once you add a second server. Coolify treats additional servers as first-class from the start, meaning any app can target any connected server from the same dashboard, and it layers team roles and permissions on top so I can give a client's other contractor deploy access without handing over root. Dokploy's multi-server story leans harder on Docker Swarm itself once you're past a single node, which is more powerful if you already think in Swarm terms and more friction if you don't. Coolify also ships an MCP server alongside its API and CLI, which is a strange thing to care about until you realize it means an AI coding agent can query deployment status or trigger a redeploy directly, something I've started leaning on for routine restarts instead of opening the dashboard at all.

Both projects ship faster than you can keep up with

Coolify is at v4.3.23 as I write this, four patch releases in the last two weeks alone, and it carries 62,000 GitHub stars. Dokploy is close behind on velocity at v0.30.7 with a similar two-week cadence, and sits at about 37,500 stars, roughly a year and a half younger as a project. Neither release cadence is a red flag; if anything it means real bugs get fixed in days rather than sitting in a backlog. It does mean you should read the changelog before you click update on a client's production box, the same rule I'd apply to n8n or anything else that ships this often. I got burned once treating a Coolify minor version bump as routine and losing a custom Traefik label override that a new default had quietly replaced.

What I'd actually recommend

For a single Hetzner box running two or three client apps, either tool removes real pain over hand-rolled compose and Caddy files, and I wouldn't talk anyone out of either one. I moved this specific client to Coolify, mainly for the one-click backup restore and because Railpack's build speed adds up when I'm redeploying a dozen times a day during active work. If she ever needs true multi-node Docker Swarm scaling from day one rather than as an add-on, Dokploy's Swarm-first design would be the better starting point. I wrote about the box underneath both of these in what this blog actually runs on, and if you want help picking or migrating between any of this, that's the kind of work I take on, described at abrarqasim.com/work.

If you're running either tool right now, the one thing worth doing this week regardless of which you picked: manually trigger a database restore into a throwaway app once, before you need it for real. I found Dokploy's CLI restore step only after I needed it under pressure, and that's a bad time to be reading docs for the first time.

Originally published at abrarqasim.com. I write there about React, PHP, Rust, Go and the AI tooling around them.

The n8n Workflow That Broke Silently for Six Weeks

Qasim Parray — Tue, 29 Sep 2026 06:42:45 +0000

A client asked me in July to stop forwarding her contact form leads to a spreadsheet and just handle them. Score the lead, draft a reply, ping her on Slack if it looked like a real budget, archive it if it looked like a recruiter spamming her about a job she didn't want. I built the whole thing in n8n in an afternoon. It ran clean for six weeks. Then it silently stopped tagging anything as high-priority, and nobody noticed until she asked why she hadn't heard from a promising lead in eleven days.

The workflow, roughly

Here's the shape of it, trimmed to the part that matters. A webhook catches the form submission, a Function node scores it, an If node branches on that score:

{
  "nodes": [
    { "name": "Webhook", "type": "n8n-nodes-base.webhook" },
    { "name": "Score Lead", "type": "n8n-nodes-base.function" },
    { "name": "High Priority?", "type": "n8n-nodes-base.if" },
    { "name": "Slack Alert", "type": "n8n-nodes-base.slack" },
    { "name": "Draft Reply", "type": "n8n-nodes-base.httpRequest" }
  ]
}

And the actual scoring logic, which is where the whole thing quietly broke:

const budget = $input.item.json.body.budget || "";
const message = $input.item.json.body.message || "";
const score = budget.includes("$") ? 3 : message.length > 200 ? 1 : 0;
return { json: { ...$input.item.json.body, score } };

That body.budget field existed because the form on her site sent it as a top-level key. In August she redesigned the form with a page builder plugin, and the plugin nested every field under a formData object instead of putting it at the root. The webhook still fired. The payload still arrived. $input.item.json.body.budget just quietly evaluated to undefined, "".includes("$") returned false every single time, and every lead scored zero regardless of budget. No error, no failed execution in the n8n logs, because nothing actually threw.

Why this is worse than a normal outage

A crashed workflow is loud. n8n's execution list turns red, and if you've wired up error workflows (you should, and I hadn't on this one) you get a notification within seconds. A workflow that runs to completion and produces a wrong answer is silent by design, because as far as n8n is concerned, nothing went wrong. The Function node executed, returned valid JSON, and passed it along. The bug lived entirely in an assumption about the shape of somebody else's data, which is exactly the kind of thing that survives every test you write yourself because you're the one who wrote the test data too.

I now add a one-line sanity check at the top of every scoring function that touches an external payload:

if (!("budget" in ($input.item.json.body || {}))) {
  throw new Error("payload shape changed: no budget field");
}

Cheap, ugly, and it turns a silent miscategorization into a loud failed execution that shows up in n8n's error workflow. I'd rather get paged for a broken assumption than find out from a client eleven days later.

How I actually caught it

She noticed the drought before I did, which tells you everything about how I was monitoring this thing at the time: not at all. I'd built the workflow, watched it work for a week, and moved on to the next client project, the classic freelancer mistake of treating a shipped automation like a shipped feature instead of a running service. Once she flagged it, finding the bug took ten minutes with n8n's execution history, since every run was sitting right there with its input and output JSON. Finding out it had been broken for six weeks took a client noticing a gap in her own pipeline, and that part I actually feel bad about.

What I run now on every client workflow that touches money or leads: a second, tiny n8n workflow on a daily cron that queries the main workflow's execution count for the last 24 hours through n8n's own API, and pings me on Slack if that count drops to zero or if the average score across all of yesterday's leads is suspiciously flat. A flat score distribution was exactly the fingerprint of my bug: every lead scoring 0, day after day. A simple standard-deviation check on that score would have caught it on day one instead of day forty-two. It's maybe fifteen lines of Function-node code, and it's a lot cheaper than the one honest conversation I had to have about why a warm lead went cold for over a month.

n8n's pace is part of the story here

n8n ships fast enough that "which version am I even running" is a real question worth asking before you debug anything else. Checking the n8n releases page while writing this, the project cut nine separate tagged releases across its stable and beta lines in the four days leading up to September 25 alone. If you're self-hosting via Docker and you pull n8nio/n8n:latest on a cron job the way a lot of tutorials tell you to, you can wake up to genuinely different node behavior with zero warning. I pin a specific tag now and read the changelog before bumping it, the same discipline I'd apply to any other dependency, which n8n absolutely is even though the interface makes it feel like a website you're clicking around in rather than software you're running.

Where n8n actually earns its keep over Zapier or Make

For a client on a budget, n8n's self-hosted option removes the per-task pricing that makes Zapier expensive the moment a workflow runs more than a few hundred times a month. I've moved three client automations off Zapier this year purely on cost, not features. The tradeoff is that you now own the box it runs on, the Postgres database behind it, and the debugging when a node behaves differently than the docs suggest. That's a fair trade for a workflow that runs thousands of times a month; it's a bad trade for something a client runs twice a week, where Zapier's hosted reliability is worth the per-task fee and the lack of a server to patch.

I wrote about the harder end of this same tradeoff, an automation that actively hurt a client relationship instead of just quietly under-delivering, in the refund bot that cost me a client. Silent miscategorization and an overconfident refund bot are the same root problem wearing different clothes: automation that never tells you when its assumptions stopped holding.

What to check this week if you run anything on n8n

Open your busiest workflow and look for any Function node that reaches into a nested field from a webhook, form, or third-party API payload. Add the one-line guard above to each one. Then go check whether you've actually wired an error workflow to catch failed executions, not just left the default "do nothing" behavior, because that's the notification that would have caught my lead-scoring bug in week one instead of week six. If you're doing freelance automation work for clients, this is also the kind of detail worth mentioning up front; I cover how I scope that conversation in my writeup on pricing this work honestly, and you can see the rest of what I build at abrarqasim.com.

Originally published at abrarqasim.com. I write there about React, PHP, Rust, Go and the AI tooling around them.

How I Actually Price Freelance Web Development Work

Qasim Parray — Mon, 28 Sep 2026 14:42:38 +0000

A client asked me for a "quick rate" over email three years ago, and I typed a number I'd basically made up on the spot, based on nothing more than what felt reasonable for a Tuesday. I got the job. I also spent the next six weeks resenting every hour of it, because the number I'd picked assumed a simple integration and the actual scope turned out to involve migrating a decade of legacy data out of a system nobody had documented. I didn't renegotiate. I just worked longer hours and told myself that's what freelancing meant.

It isn't. I've changed how I price work twice since then, and the current approach is the first one that's actually held up under a messy, real project instead of just looking clean on a spreadsheet.

Hourly rates aren't wrong, they're just answering the wrong question

There's nothing broken about hourly billing as a concept. The problem is what it optimizes for. If I bill hourly, I get paid more the slower I work and less the faster I solve the client's problem, which is backwards from what the client actually wants and backwards from what I want too, since efficient work is the entire reason clients hire an experienced freelancer instead of training a junior in-house. Jonathan Stark has been making this argument for years, and the part that finally landed for me wasn't the theory, it was noticing my own behavior. I caught myself, more than once, taking a slightly longer path through a problem because I knew a faster fix would mean a smaller invoice. That's not a character flaw. It's what the incentive structure produces, in me and in basically anyone billing by the hour.

The 2025 Stack Overflow Developer Survey still shows a wide compensation spread among independent and freelance developers, wider than salaried roles show, and I don't think that's purely a skill gap. A meaningful chunk of it is pricing method. Two developers with comparable skill can land in very different places depending on whether one is trading hours for dollars and the other is pricing the outcome.

What I actually quote now

For anything with a defined scope, a new feature, a migration, a redesign, I quote a fixed project price, not a rate. I still track my hours privately so I can calibrate future quotes, but the client never sees an hourly number. The quote is built from three questions I ask myself before I write it: what does this project need to actually solve for the client, what's the real risk that scope grows once I'm inside the codebase, and what would I charge if I could only send one invoice for the whole thing.

That third question changes the number more than the first two combined. When I imagine sending exactly one invoice with no do-overs, I stop lowballing the parts of the project I'm least certain about, the parts where "should take a day" has a real chance of taking four.

For ongoing work, a retainer or an indefinite maintenance relationship, I do still use a day rate rather than a project price, because the scope genuinely isn't fixed and pretending otherwise would just mean padding a fixed number to cover uncertainty I can't quantify yet. Day rate, not hourly. Clients stop watching the clock and start describing what they need, which produces better conversations than a stopwatch relationship ever did.

The discovery call is where the pricing actually happens

I used to treat the discovery call as a formality before sending a quote. It's the opposite. The call is where I find the information that makes the quote accurate instead of a guess. I ask what happens if this project is late, not because I want to threaten anyone with lateness, but because the answer tells me how much risk I'm actually taking on. "Nothing happens, we'll just launch next quarter instead" is a different project than "our biggest client renews in six weeks and this has to be live before then." Same scope, same code, genuinely different price, because the second one is buying certainty as much as it's buying software.

I also ask directly who else has quoted this and what they said, not to undercut a competitor, but because a wildly different range from another freelancer usually means we're scoping different things, and finding that mismatch before I quote saves both of us from a bad first few weeks.

Scope creep is a pricing problem wearing a project management costume

Most scope creep advice focuses on process: change orders, signed amendments, tracked hours against a budget. Useful, but it treats the symptom. The actual cause, in my experience, is that the original quote never accounted for the parts of the project that were genuinely unknown at quoting time. You can't change-order your way out of a quote that was wrong from the start; you can only patch it, and patched quotes are where resentment lives on both sides.

Now I build a specific line into every proposal: a fixed number of hours reserved for "things we find once we're inside the code that weren't visible from outside it." I call it exactly that, in plain language, not a vague buffer percentage. Clients respond well to it because it's honest about the actual nature of the work instead of pretending I can see through a black box from a kickoff call.

What I do when a client pushes back on the number

I used to fold immediately, because I hate confrontation about money more than I hate most things, and my quotes at the time were often a first offer I expected to negotiate down from anyway. Two changes fixed this. First, I stopped quoting a padded first number, so there's genuinely less room to negotiate downward without cutting the project's scope along with the price. Second, I started answering pushback with a scope question instead of a price question: "what part of this would you want to cut to hit that number?" That reframes the conversation from "convince me I'm worth this" to "let's agree on what we're actually building," which is a conversation I'm far more comfortable having, and one that usually produces a smaller, cleaner project instead of an awkward discount on the original one.

The math I actually run before I type a number

When I'm building a fixed quote, I still start from a rough hours estimate, I just don't stop there. I take my target day rate, multiply by my honest estimate of days, then apply a multiplier based on how well I understand the codebase going in. A greenfield project where I'm writing every line gets close to a 1.1x multiplier, barely any padding, because the unknowns are mine to control. A project where I'm the fourth developer to touch an unfamiliar codebase gets 1.4x or higher, because the discovery call can't show me what a previous developer left half-finished three directories deep. That multiplier isn't padding in the dishonest sense. It's pricing the actual risk I'm taking on by agreeing to a fixed number against work I can't fully see yet, and naming it explicitly, even just to myself, keeps me from either underpricing real uncertainty or overcharging a client whose codebase turns out to be cleaner than I expected.

I also stopped rounding quotes to numbers that feel comfortable, the way $5,000 feels safer to type than $5,400. A specific number reads as calculated rather than guessed, and in three years of sending both kinds, the specific ones get fewer "can we talk about the price" emails, not more.

One thing to try this week

Take the last project you quoted hourly and rewrite the quote as a single fixed number, using the "one invoice, no do-overs" question above. Don't send it anywhere. Just see what the number does to how you'd approach the work, and notice which parts of the original scope you'd suddenly want nailed down before you started. That gap between the two numbers is usually where the real pricing problem was hiding.

I wrote a longer breakdown of the actual proposal document I send after a discovery call in an earlier post on the section that wins the job, if you want the template alongside the pricing logic here. More about how I run this as a business is on my about page.

Originally published at abrarqasim.com. I write there about React, PHP, Rust, Go and the AI tooling around them.

Postgres Performance Tuning Parameters I Actually Touch

Qasim Parray — Mon, 28 Sep 2026 06:42:35 +0000

My VPS ran an autovacuum job for six straight hours last winter on a table with maybe four million rows, which is not a lot of rows, and I spent that evening convinced I'd found some exotic Postgres bug. I hadn't. I'd just never tuned autovacuum past its defaults, because the defaults work fine right up until they don't, and "fine" had quietly become "grinding through a table lock during my only maintenance window."

That's the thing about Postgres performance tuning parameters: almost nobody touches them until something hurts. I want to walk through the handful I actually adjust on every server I run, plus what caught my eye in PostgreSQL 19 Beta 4, released this week, because a couple of the changes land directly on the knobs I care about.

Autovacuum is the one that actually bites people

The default autovacuum_vacuum_cost_delay throttles vacuum aggressively so it doesn't compete with your live traffic for I/O. That's a reasonable default for a shared host you don't control. It's a bad default for a dedicated VPS where you're the only tenant and dead tuples are piling up faster than the throttled vacuum can clear them.

ALTER SYSTEM SET autovacuum_vacuum_cost_limit = 2000;
ALTER SYSTEM SET autovacuum_vacuum_cost_delay = '2ms';
ALTER SYSTEM SET autovacuum_naptime = '15s';
SELECT pg_reload_conf();

Raising the cost limit and dropping the delay lets vacuum work through more pages per cycle, which matters a lot once a table has any real write volume. autovacuum_naptime controls how often the launcher checks whether a table needs vacuuming at all; the default 60 seconds is fine for most workloads, but a table that gets bursts of updates benefits from checking more often.

PostgreSQL 19 Beta 4 actually touches this directly. The release notes mention "several fixes to the new autovacuum scoring system," which replaced the older threshold-based trigger with something that weighs tables by how urgently they need attention instead of a flat percentage. I haven't run it in production yet, betas don't belong there, but I've been testing it against a staging clone of the same table that gave me that six-hour vacuum, and the scoring system picked it up for vacuum noticeably earlier than the old threshold would have.

work_mem, and the query that taught me to stop guessing

work_mem sets how much memory a single sort or hash operation gets before it spills to disk. The default, 4MB, is conservative enough to be safe on a shared box and too small for almost any real analytical query.

EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM orders
WHERE customer_id = 4821
ORDER BY created_at DESC;

If that plan shows Sort Method: external merge Disk: 84000kB, your sort spilled to disk instead of staying in memory, and that's your signal to raise work_mem, not to add an index blindly. I used to jump straight to indexing every slow query. Sometimes the query is fine and the sort just needed more headroom.

SET work_mem = '64MB'; -- per session, test first
ALTER SYSTEM SET work_mem = '32MB'; -- global, be careful

The global setting multiplies per connection and per sort operation within a query, so a server running fifty connections each doing a two-way hash join can burn through memory fast if you set this too high. I test with a session-level SET against a copy of production data before I touch the global value.

shared_buffers is not "give Postgres all your RAM"

The advice to set shared_buffers to 25% of system RAM gets repeated everywhere, and it's a reasonable starting point, but I've seen people push it to 60 or 70% assuming more is strictly better. It isn't. Postgres relies on the operating system's page cache as a second layer, and a shared_buffers value that's too aggressive starves that cache, which can make things slower, not faster, especially on a box that's also running your application.

ALTER SYSTEM SET shared_buffers = '2GB'; -- on an 8GB box
ALTER SYSTEM SET effective_cache_size = '6GB'; -- OS cache estimate

effective_cache_size doesn't allocate anything. It's a hint to the query planner about how much data is likely already cached somewhere, and it affects whether the planner favors an index scan over a sequential scan. I set it to roughly 75% of total RAM and haven't had a reason to touch it since.

REPACK, the new command that replaces a maintenance script I've run for years

This is the change from PG19 that actually excited me. Reclaiming bloated table space has meant VACUUM FULL, which takes an exclusive lock and blocks reads and writes for the duration, or pg_repack, a well-maintained extension that does it online but still requires installing and trusting a third-party tool. PostgreSQL 19 adds REPACK as a first-party command.

REPACK TABLE orders;

Beta 4's changelog lists several fixes to REPACK specifically: crashes on invalid indexes, incorrect behavior with materialized views, and permission and error-reporting corrections. That tells me the feature is getting real testing pressure before GA, which is exactly what I want to see before I trust a command that rewrites a whole table. I'm not running it against anything that matters yet, but it's the first thing I'm testing once 19 goes stable, because it would let me delete a pg_repack cron job I've maintained across three different servers.

checkpoint_completion_target, the setting nobody mentions until a write spike hits

Postgres writes dirty pages to disk during a checkpoint, and by default it tries to finish that work quickly, which can cause a burst of I/O contention right when your application is also trying to write. checkpoint_completion_target tells Postgres how much of the interval between checkpoints it should spread that writing across.

ALTER SYSTEM SET checkpoint_completion_target = 0.9;
ALTER SYSTEM SET max_wal_size = '4GB';

Raising it toward 0.9 spreads the write load across nearly the whole checkpoint interval instead of compressing it into a spike near the end. I found this one the hard way, watching iostat during a nightly batch import and seeing disk write throughput spike in a pattern that lined up exactly with checkpoint_timeout, which defaults to five minutes. max_wal_size works alongside it; a bigger WAL budget means fewer checkpoints overall, which is the other lever if checkpoints themselves, not their spread, are the problem.

I test changes like this with pg_stat_bgwriter before and after, specifically the ratio of buffers_checkpoint to buffers_clean. A checkpoint doing most of the writing, instead of the background writer handling it gradually, is the signal that this setting needs attention on a given server.

max_connections is usually the wrong lever

When an app starts throwing "too many connections" errors, the instinct is to raise max_connections. I did this on a client project two years ago, doubled it from 100 to 200, and the server got slower, not faster. Each connection carries its own memory overhead and its own backend process, and Postgres doesn't scale linearly past a few hundred active connections on modest hardware. The actual fix was a connection pooler.

# pgbouncer.ini
[databases]
app = host=127.0.0.1 port=5432 dbname=app

[pgbouncer]
pool_mode = transaction
max_client_conn = 1000
default_pool_size = 20

PgBouncer in transaction mode lets a thousand application-side connections share twenty real Postgres backends, handing each one back to the pool the moment its transaction commits. That's a very different problem from raising max_connections, and it's the one that actually fixes the error message instead of just delaying it. I run PgBouncer on every Postgres box I manage now, even the small ones, because retrofitting it under load is a worse afternoon than setting it up in advance.

The features that got pulled, and why that's a good sign

Beta 4 also reverted a handful of things that were planned for 19: SQL/PGQ property graph query support, online toggling of data checksums, and the ALTER TABLE ... MERGE PARTITIONS and SPLIT PARTITIONS commands. Watching a release cut scope this late used to worry me, it feels like something going wrong. Reading through the Postgres project's own reasoning changed my mind: they're explicit that reliability comes before the release calendar, and features that aren't ready get pushed to a later major version instead of shipping half-finished. That's a genuinely rare property in software release culture, and it's a big part of why I still run Postgres on a VPS instead of reaching for a managed service with a bigger feature list and less of that discipline behind it.

What to actually do this week

Run EXPLAIN (ANALYZE, BUFFERS) against your three slowest queries and check for external merge Disk in the sort output before you touch work_mem. Then check pg_stat_user_tables for n_dead_tup on your largest tables; if that number is climbing faster than autovacuum is clearing it, that's your autovacuum_vacuum_cost_delay problem before it becomes a six-hour vacuum on a Tuesday night.

I've written before about a Postgres foreign key mistake that made this exact vacuum problem worse than it needed to be, worth a read if you're touching autovacuum settings anyway. The full 19 release notes are at postgresql.org/docs/19/release-19.html if you want the complete changelog, and more of the infrastructure work behind this blog is documented on my portfolio.

Originally published at abrarqasim.com. I write there about React, PHP, Rust, Go and the AI tooling around them.

LLM Pricing Comparison: The Cached-Token Math Behind the Price War

Qasim Parray — Sat, 26 Sep 2026 06:42:18 +0000

Short version for the impatient: after this week's releases, the cheapest model on the price sheet is not always the cheapest model on your invoice. Which one wins depends on how much of your input is cached, and most LLM pricing comparisons leave that column out of the conversation.

Here's how I got here. On Monday Grok 4.7 came out. On Tuesday Anthropic shipped Claude Opus 5.5, and about an hour later OpenAI shipped GPT-6 Sol and GPT-6 Luna. Simon Willison put all the new prices in one table, which saved me an evening of tab-hopping. Then I did what I suspect half of you did. I sorted by output price and started mentally moving client projects around.

I stopped myself, because I've been burned by that exact sort before. I wrote about the general problem in LLM cost optimization after the free lunch ended. This time I wanted to do the boring arithmetic first. It changed the ranking, and not in the direction I expected.

The price sheet everyone is sharing

Prices per million tokens, from Simon's table:

Model	Input	Cached input	Output
GPT-6 Luna	$0.10	$0.01	$0.50
GPT-6 Sol	$2	$0.20	$10
Grok 4.7	$2	$0.50	$6
Claude Opus 5.5	$4	$0.20	$20
Claude Fable 5.1	$10	$0.25	$50
GPT-6 Astra	$10	$1	$50

Look at only the first and last columns and two conclusions pop out. Grok 4.7 has by far the cheapest output of the mid-tier models. Fable 5.1 and GPT-6 Astra cost the same. For the work I actually bill for, both conclusions are wrong.

The Opus change is also bigger than the headline. Anthropic's Opus 5.5 page lists input and output at $4 and $20, down 20% from Opus 5's $5 and $25. The line people skim past is cache reads: $0.20 per million, down from $0.50. That's a 60% cut on the column that dominates agent workloads.

Two workloads, two different winners

I priced two request shapes, because they're the two I run most often.

The first is a plain chat call. A 2,000-token prompt with nothing cached and a 500-token answer. Think of a support-reply draft, or a classification call with a longish instruction block.

The second is one turn of an agent loop. 200,000 tokens of context, of which 180,000 are a cache hit from the previous turn, plus 8,000 tokens of output. Simon mentions that in longer agentic conversations 90% or more of input tokens go through at the cached price, so 90% felt like a fair middle guess.

Here's the tiny function I used. It ignores cache writes (Anthropic charges extra to write the cache, $5 per million on Opus 5.5), which slightly flatters the Claude numbers on the first turn of a session and makes no real difference after that.

PRICES = {  # per million tokens: input, cached input, output
    "gpt-6-luna":      (0.10, 0.01, 0.50),
    "gpt-6-sol":       (2.00, 0.20, 10.00),
    "grok-4.7":        (2.00, 0.50, 6.00),
    "claude-opus-5.5": (4.00, 0.20, 20.00),
    "claude-fable-5.1":(10.00, 0.25, 50.00),
    "gpt-6-astra":     (10.00, 1.00, 50.00),
}

def call_cost(model, input_tokens, cached_ratio, output_tokens):
    p_in, p_cached, p_out = PRICES[model]
    cached = input_tokens * cached_ratio
    fresh = input_tokens - cached
    return (fresh * p_in + cached * p_cached + output_tokens * p_out) / 1_000_000

chat  = {m: call_cost(m, 2_000, 0.0, 500) for m in PRICES}
agent = {m: call_cost(m, 200_000, 0.9, 8_000) for m in PRICES}

And the results, per call:

Model	Chat call	Agent turn
GPT-6 Luna	$0.0004	$0.0078
Grok 4.7	$0.0070	$0.1780
GPT-6 Sol	$0.0090	$0.1560
Claude Opus 5.5	$0.0180	$0.2760
Claude Fable 5.1	$0.0450	$0.6450
GPT-6 Astra	$0.0450	$0.7800

For the chat call, Grok 4.7 comes in about 22% under GPT-6 Sol. For the agent turn the order flips, and Sol is about 12% cheaper than Grok. The whole difference is the cached column. Grok charges $0.50 per million for cache hits and Sol charges $0.20, and when 180,000 tokens per turn are cache hits, that column is most of your input bill.

Fable and Astra split the same way. Identical chat cost, but on the agent turn Fable is about 17% cheaper because its cache reads cost a quarter of Astra's.

Scale it up and the gaps stop being rounding errors. At 1,000 agent turns a day for 30 days, Sol runs about $4,680 and Grok about $5,340. Opus 5.5 lands around $8,280 against roughly $11,700 for the same traffic on Opus 5 pricing. That's a 29% drop from price alone, which is more than the 20% headline. Anthropic claims 40% on typical workloads because Opus 5.5 also uses fewer tokens per task. I can't verify the token-efficiency half yet, so I'm only counting the part I can compute.

The cost nobody puts in a table: runaway output

Here's the number that worried me more than any row above. In Simon's usual pelican-on-a-bicycle test, Opus 5.5 at the "max" thinking level hit the 128,000-token output cap while still reasoning and returned nothing. He tried twice. Each failure cost $2.56 and took nearly 20 minutes.

That $2.56 is just 128,000 times $20 per million. It's the worst-case price of a single call, and you pay it for an empty response. On my agent-turn numbers above, one of those failures costs as much as about nine normal Opus 5.5 turns. The same blowout on GPT-6 Luna would cost about six cents, which is its own argument for using cheap models on anything open-ended.

I haven't run max effort on real client work, so I don't know how often this happens outside a deliberately silly prompt. One test is one test. But I don't need to know the frequency to put a ceiling on it:

def max_call_cost(model, max_output_tokens):
    _, _, p_out = PRICES[model]
    return max_output_tokens * p_out / 1_000_000

# pick the output cap from a budget, not the other way round
BUDGET_PER_CALL = 0.40
cap = int(BUDGET_PER_CALL / PRICES["claude-opus-5.5"][2] * 1_000_000)  # 20,000 tokens

If a task legitimately needs more than that, I'd rather find out from a truncated response I can inspect than from the invoice.

What I'm still unsure about

Price per token says nothing about how many turns a model needs. If a cheap model takes three tries to do what a pricier one does in one, a 3x price gap disappears. Luna is about 20 times cheaper than Sol per agent turn in my numbers, and I have no idea yet what its retry rate looks like on my workloads. The one real data point I have is secondhand: Simon moved his Datasette Agent demo to GPT-6 Luna and found it fast and competent at SQL and at building HTML and JavaScript. That's encouraging. It isn't my workload.

The other thing I'm unsure about is how long any of this holds. Simon notes GPT-5.6 has a 25% price increase scheduled for November, and Anthropic says Sonnet 5.5 and Haiku 5.5 are coming. Haiku 4.5 currently sits at $1 and $5, ten times Luna. If Haiku 5.5 lands anywhere near Luna, half of this table changes again. That's the practical argument for keeping prices in config rather than hardcoding a model name in six places.

How I'm setting this up on client projects

Every provider I use returns cached-token counts in the usage block of each response. I log those next to the model name and the feature that made the call. Then the pricing comparison stops being a guess, because the cached ratio comes from real traffic instead of a blog post (including this one).

Routing then gets simple. Short, uncached, high-volume calls go to whichever model is cheapest on fresh input and output. Long agent sessions go to whichever model is cheapest on cached input at acceptable quality. Anything open-ended gets a hard output cap derived from a per-call budget. It's the same setup I build into the AI automation work on my portfolio, and the price table is the only part that changes when a vendor ships something new.

What to do this week

Pull the last seven days of usage logs from your LLM provider. Divide cached input tokens by total input tokens, per feature, and write that ratio down. Plug your real averages into the call_cost function above and re-rank the models for each feature. Then set a max_tokens value on every call that doesn't have one, picked from a dollar budget. If the ranking doesn't change, you've lost twenty minutes. If it does, you've probably found money.

Originally published at abrarqasim.com. I write there about React, PHP, Rust, Go and the AI tooling around them.

GitHub Actions Secrets Leaked Through a Cache: The Miri Lesson

Qasim Parray — Sat, 26 Sep 2026 02:42:16 +0000

Short version for the impatient: if a CI job caches target/ and that same job can see a secret as an environment variable, assume the secret can end up in the cache. The Rust Security Response Team just published a concrete case of this with Miri, and the fix they recommend is mostly about how you write your workflow file.

I'll admit my first reaction to the headline was a bit smug. I don't run Miri in CI on most client projects, so I figured this one wasn't mine. Then I read the threat model section of the advisory and the smugness wore off. The line that got me is the warning that many tools "assume the entire environment can be written to the filesystem." That isn't a Miri quirk. That's a fair description of half the build tooling I've ever touched.

So this post is less about Miri and more about the habit that made the Miri issue exploitable: putting GitHub Actions secrets in a top-level env: block because it's convenient, and then caching build output from the same job.

What actually leaked, in plain terms

Here's the chain from the Rust blog advisory, boiled down.

cargo miri invokes Miri several times per build, and it needs to remember build-relevant environment variables between those runs. The code that did this stored every environment variable into target/. Every one. If your job had AWS_SECRET_ACCESS_KEY or a deploy token in its environment, it went into a file under target/.

On its own, that's a file on a throwaway runner. The trouble is caching. Rust projects cache target/ heavily because cold builds are slow, usually with actions/cache or Swatinem/rust-cache. A typical setup lets runs on main write the cache and lets pull requests only read it. That read-only rule stops cache poisoning. It does nothing to stop a PR from reading what main wrote.

And who can run a PR workflow? GitHub asks a maintainer to approve CI for a first-time contributor. After someone has landed one change, their later PRs run CI on every push. The advisory spells out the nasty part: a past contributor could push a commit that dumps the cached target/, grab the secret from the job output, then push a second commit over the first. GitHub sometimes hides overwritten commits in the UI, and run logs get deleted after a few months.

The team scanned public GitHub repositories and found one that was vulnerable, plus seven that didn't look vulnerable but were close enough to get a heads-up. Small numbers. I don't read that as "rare", though. The scan could only see public workflow files, and the post itself says the scan was probably imperfect.

The short-term fix, and why I wouldn't lean on it

The Miri patch narrows what gets saved: only CARGO_* variables, minus anything matching CARGO_*_TOKEN, plus OUT_DIR. The nightly dated 2026-09-22 is the first one that carries it. If you pin an older nightly in your toolchain file, you don't have the fix yet.

It's a good patch. But the advisory is blunt that Cargo, Miri and Rust in general make no promise to keep environment variables out of target/. Build scripts are arbitrary code. Any build.rs in your dependency tree can read the environment and write whatever it likes into OUT_DIR. Almost none do. You're still trusting every crate author never to do it, including the one who adds a debug dump in a patch release at 2am.

So I treat the Miri change as closing one known hole. The workflow change is the real fix.

The workflow pattern behind the leak

This is roughly what I see in a lot of Rust repos, and in a couple of my own older ones too. Secrets live at the top because some step near the end needs them, and the cache step sits at the start of the same job.

# before: every step in the job can see both secrets
name: ci
on: [push, pull_request]

env:
  SENTRY_AUTH_TOKEN: ${{ secrets.SENTRY_AUTH_TOKEN }}
  CRATES_IO_TOKEN: ${{ secrets.CRATES_IO_TOKEN }}

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: dtolnay/rust-toolchain@nightly
        with:
          components: miri
      - uses: Swatinem/rust-cache@v2
      - run: cargo test
      - run: cargo miri test
      - run: ./scripts/upload-sourcemaps.sh

Nothing in that file looks wrong at a glance, which is exactly why it spreads. The workflow-level env: block means cargo miri test inherits both tokens, and the rust-cache step saves target/ when the job finishes. GitHub's own page on using secrets in a workflow passes secrets per step in its examples. I think a lot of us skim past that detail because the top-level block is less typing.

What I'd change: split jobs, scope secrets to steps

Two rules. A job that writes a shared cache gets no secrets at all. A step that needs a secret gets it in its own env:, and no other step sees it.

# after: the cached job has no secrets
name: ci
on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: dtolnay/rust-toolchain@nightly
        with:
          components: miri
      - uses: Swatinem/rust-cache@v2
      - run: cargo test
      - run: cargo miri test

  release-artifacts:
    needs: test
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: ./scripts/upload-sourcemaps.sh
        env:
          SENTRY_AUTH_TOKEN: ${{ secrets.SENTRY_AUTH_TOKEN }}

The second job never touches the Rust cache, only runs on main, and hands one secret to one step. It'll be slower if it has to compile anything. I'd take that trade every time.

If you can't split the job today, the advisory lists quicker options: turn off caching for that job, move the secrets onto steps that don't call Miri, or switch Miri off for a while. Any of those is fine as a stopgap while you do the proper split.

There's one sneaky path the advisory mentions almost in passing: a previous step can persist a secret into the environment. The usual way is echo "TOKEN=..." >> "$GITHUB_ENV". Once that runs, every later step in the job has the value, including the one that runs Miri. So I'd grep for GITHUB_ENV as part of this audit.

# quick audit across a repo's workflows
grep -rnE 'secrets\.|GITHUB_ENV|rust-cache|actions/cache' .github/workflows/

That one command shows where secrets enter, where they get promoted to job-wide env, and which jobs cache. Cross-reference the three and you've found your risky jobs.

If you think you were exposed

Fixing the YAML doesn't remove what's already sitting in the cache. The Rust team's order is: fix the workflow, clear the cache, then consider rotating anything that might have leaked. GitHub's docs on managing caches cover deleting entries from the UI or with the gh CLI:

gh cache list --limit 100
gh cache delete --all

On rotation, I'd drop the word "consider". If a token sat in a cache that PRs could read, and you can't prove nobody read it, rotate it. Rotating a Sentry token takes five minutes. Explaining to a client why their crates.io account published a strange version takes a lot longer.

I'm less sure what to say about the logs. Old CI logs expire, so you may not be able to confirm or rule out access at all. I don't have a clever answer for that one. Rotate and move on.

This isn't really a Rust problem

I keep coming back to this. Miri got caught because someone went looking (Predrag Gruevski reported it, and the team credits him in the post). The same pattern can show up anywhere a tool writes its environment into an output directory and that directory gets cached. I'd look hard at anything that snapshots env for reproducible builds, and at Docker layer caches built with secrets passed as build args. I haven't checked specific tools for this exact behavior, and I won't pretend I have. The point is that you shouldn't need to check, because the job writing the cache shouldn't hold anything worth stealing.

I wrote about a related habit in the reusable workflows bug I fixed eleven times, where copy-pasted workflow blocks kept bringing back the same mistake. Secrets in a top-level env: spread the same way. Someone adds one for a single step, the next person copies the file into a new repo, and a year later every job in the org can see every token.

This is one of the first things I check when I take over a client's CI, and it's part of the DevOps cleanup work you'll find on my portfolio.

What to do this week

Open .github/workflows/ in your busiest repo and run the grep above. For every job with a cache step, confirm it has no secrets. reference and no GITHUB_ENV write that carries a secret. When you find one, move the secret to the single step that needs it, or into a separate job that doesn't cache. Then run gh cache delete --all and rotate the token. It's maybe half an hour of work, and I'd bet you find at least one job you'd forgotten existed.

Originally published at abrarqasim.com. I write there about React, PHP, Rust, Go and the AI tooling around them.

How to Export a Trello Board to Excel, CSV, PDF or Sheets

Qasim Parray — Fri, 25 Sep 2026 22:42:14 +0000

Someone asked me a few weeks ago whether they could get their Trello board into a spreadsheet with the card comments attached. I said yes, because I maintain a Trello export Power-Up and I assumed I had built that years ago. Then I went and checked. I hadn't. The Power-Up SDK that board add-ons run against does not hand you comments at all, so the answer was a week of work against Trello's REST API: a token flow, a rate limiter, twenty pages of card actions, and a stack of edge cases I did not want to meet.

So here is the post I wanted when I started. What Trello exports by itself, what it quietly drops, and what your options are when the built-in download is not enough. The first two thirds apply no matter what tool you end up using. I talk about my own Power-Up at the end, because I built it to fill these exact gaps, and you can judge whether that is fair.

What Trello exports on its own

Open any board, hit the board menu, and pick "Print, Export, and Share". You get two formats.

JSON is available to every board member on every plan, including free. It is the complete record of the board: cards, lists, labels, members, checklists, custom fields, and the board's most recent actions. Comments live inside those actions. Atlassian's export documentation puts the ceiling at the 1,000 most recent actions per board. On an active board you will hit that number, and whatever falls off the end is simply not in your file. The docs also say the JSON cannot be re-imported to rebuild a board, which surprises people who assume export means backup.

CSV needs a Premium workspace. It is the format most people actually want, because it opens in Excel or Google Sheets with nobody writing code. Two limits come straight from Atlassian's own page: CSV export only includes cards that are not archived, and comments are excluded from spreadsheet exports.

There is also a workspace-level export, admin only, Premium only, which can bundle raw attachment files into a ZIP instead of just linking to them. If you are leaving Trello or want a cold archive of everything, that is the one to reach for.

What the built-in CSV leaves out

I keep a list of the things people ask for that the native CSV does not carry. It has stayed stable for about two years.

Archived cards. Teams archive instead of delete, so on a year-old board half the history is invisible to the export. Every "why does my report show 40 cards when we shipped 300" question traces back to this.

Comments. The decision log of most boards lives in comments, not descriptions. They are in the JSON and not in the CSV, which is the single most annoying split in the whole product.

Movement history. When did this card enter the list it is in now? How many days has it been sitting there? Who moved it to Done? None of that is a card field. It has to be derived from the board's action feed, which you reach through the REST API. No menu will give it to you.

Checklist items as rows. A CSV gives you one row per card. If you run a board where each card holds a twelve-item checklist, and you want one row per item, you are writing a script.

Formatting. Not a data problem, but a real one. A raw CSV has no column widths, no frozen header, no label colours, no filters, and no totals. Anyone building a weekly status report ends up doing the same twenty minutes of spreadsheet work every Friday.

Exporting a Trello board to Excel

Four routes, roughly in order of effort.

Copy and paste works for one list on one board on one afternoon. It stops working the moment somebody wants it again next week.

The JSON route is the free one. Download the JSON, then parse it with Python, Power Query, or whatever you already know. This is genuinely fine for a technical user with a one-off question, and it is the only free path to comments. The cost is that you are now maintaining a script, and Trello's JSON shape is nested enough that flattening it well takes longer than you think.

Browser extensions read the board through the page you are looking at. A few have been around for years and do a decent job. The tradeoff is that an extension sees whatever your browser session can see, updates on its own schedule, and cannot run when your laptop is shut.

Power-Ups run inside Trello itself. You enable one from the board's Power-Ups menu, it appears as a button on the board, and it uses Trello's own APIs with the permissions you grant. This is the route I picked when I built mine, mostly because nothing has to be installed on the person's machine and the free tier of Trello supports Power-Ups.

Where my Power-Up fits

I run Exportly, a Trello Power-Up for exporting boards. It is the successor to an earlier export Power-Up of mine that has been sitting on a thousand-odd boards for a while, and the rewrite exists because of the gap list above. You can install it from Trello's Power-Up directory.

The short version of what it does. Excel workbooks that are already formatted, with a frozen header, coloured labels, dates that Excel treats as dates, and an optional Summary sheet with live COUNTIF formulas that keep working after you edit the file. CSV with a delimiter and date format that match your locale, which matters more than it sounds if you are in Europe and your spreadsheet keeps reading dates as text. PDF for the people who want to print a board or email a client something that is not editable. Google Sheets, pushed straight into your Drive.

On the data side it covers what the native CSV does not: archived lists and cards, comment text, the date a card entered its current list, days in list, who moved it to Done, and a checklist-item row mode where every item becomes its own row. Filters for list, label, member, and due window run before the export, so a "what is overdue this sprint" report becomes a saved preset you click once. You can export up to ten boards at once into one workbook.

The comment and history columns need you to connect Trello once, because they come from the REST API rather than the Power-Up SDK. That connection is the part that took the week I mentioned at the top, and it is also the part I would have skipped if I had known how fiddly Trello's authorisation window is inside an iframe.

Scheduling the export so you stop doing it by hand

This is the feature I use myself and the reason the product has a server at all.

You pick a board, a format, a time, and a timezone, and the export arrives by email on a schedule. Monday 08:00 in Asia/Dubai, every weekday, month-end, whatever the cron expression allows. Files above eight megabytes come as a download link instead of an attachment, and links expire after seven days.

The interesting part of building it was storage. A scheduled export needs a Trello token sitting on a server, which is a thing I did not want to be careless about, so tokens are sealed with AES-256-GCM and only ever decrypted inside the worker process that runs the exports. The API process cannot read them. It runs on a small Hetzner box, the same one I wrote about when I compared Hetzner and DigitalOcean for this blog, which has turned out to be more than enough machine for the job.

Backing up a board with its attachments

Trello's workspace export can include raw attachments, but it is Premium and admin only, and it gives you everything at once rather than the one board you care about.

Exportly has a board backup that produces a ZIP: the export file itself, every uploaded attachment sorted into folders by list and card, and a manifest CSV that records which files were included, which were skipped, and why. Link-only attachments cannot be fetched, files over fifty megabytes are skipped by design, and the manifest says so, so nobody has to guess. I added the manifest after my own first test run quietly dropped four files and I spent an hour working out which ones.

What this costs and what I would pick

Free tier is three exports a month, which is enough to decide whether the thing is useful. Then it is a fourteen day trial, and after that 6.99 US dollars a month or 49 a year. Refunds are fourteen days after any charge, no argument.

If you are on Trello Premium, you export once a quarter, and you do not care about comments or archived cards, the built-in CSV is fine. Use it and skip the rest of this.

If you are on the free plan, or you need comments, archived cards, formatted Excel, PDF, or a report that shows up in your inbox every Monday without you doing anything, a Power-Up is the shortest path. You can add Exportly to a board, run a free export, and see whether the workbook is the one you wanted before you pay for anything.

Here is the one thing to do this week, whichever way you go. Open your busiest board, run the native JSON export, and search the file for a comment you remember writing three months ago. If it is missing, you have just found the 1,000-action ceiling, and you now know why the spreadsheet you were about to build would have been wrong. I write about this kind of small, expensive detail fairly often over on my site.

Originally published at abrarqasim.com. I write there about React, PHP, Rust, Go and the AI tooling around them.