DEV Community: Ali Alp

Your GPUs Are Lying to You: The Brutal Economics of AI on Kubernetes

Ali Alp — Tue, 15 Sep 2026 17:19:24 +0000

Two numbers, same card, same moment:

100% and 0.76%

One of these numbers represents what you are charged for, while the other represents what you should be charged for.

The first number is GPU utilization, which is the figure displayed on your dashboard. The second number is SM Active, indicating the actual portion of the chip that was in use. Both numbers were obtained from an H100 on 9 September 2026, at the same moment.

Which one of the two do you think the bill follows? Hold that question in mind. I come back to it at the end.

I rented an H100 to verify my hypothesis

In July, I wrote a talk description stating: the bill arrives, three times higher than expected, and no one can explain the discrepancy. In September, I rented a card to see if I could justify that statement.

I rented it three times, for approximately four hours, at a cost of $18.71 plus German VAT. This was the most affordable part of the entire project. The invoice accurately records the duration of my rental, but it has no knowledge of how I utilized the card. Keep that receipt in mind.

Prior to renting the H100, I conducted a simple test on the gaming GPU in my own PC: running one thread on a single core out of 36. The gauge indicated that it was 100% busy. That moment confirmed that I had a talk worth giving.

Let me introduce you to Nadia. She manages GPUs that someone else pays for and has done everything correctly: benchmarked the model, sized the fleet accordingly, and her dashboard has consistently shown utilization of 90% or higher. She is not careless; she represents us.

A GPU can be thought of as a truck that is rented on an hourly basis. The term "busy" refers to the truck being in use, or on the road, and it never means the truck is full. When benchmarks are run, the trucks are utilized to their full capacity. In production, the trucks are not run full. As a result, the fleet of trucks needs to be tripled in size, prompting the person responsible for finances to inquire: you previously stated that the trucks were 90% busy, so why have we just purchased three times the number of trucks we already had?

There are three lies that stand between that dashboard and this question.

Lie #1 — the metric

What exactly does GPU utilization measure? NVIDIA has provided the answer for us:

Percent of time over the past sample period during which one or more kernels was executing on the GPU.

That's the documentation for nvidia-smi, which describes the NVML field (nvmlUtilization_t.gpu) that DCGM exports under the name DCGM_FI_DEV_GPU_UTIL. The time between samples ranges from one second to a sixth of a second, depending on the specific product.

One. Or more.

The H100 features 132 SMs, 80 GB of memory, and a very wide bus. Having one thread active on a single SM will show 100% utilization, and the same result is seen when the entire chip is fully utilized. This metric doesn't measure the extent of utilization; it's simply a yes or no inquiry that NVIDIA performs several times per second.

So I misled it by running one thread on 1 out of 132 SMs — which is less than one percent of the chip's capacity:

	GPU_UTIL	SM Active	Tensor	MFU	tok/s
spin loop	100%	0.76%	~0	~0	0

0.76% is precisely equivalent to 1/132. The dashboard provides measurements on the road. Everyone interprets it as full.

Fine, run something serious

That's a fair objection. A spinning thread is merely a toy. So, I'm using a 7B model on vLLM, handling one request at a time, on the same rented card. I say to it "Hi".

	GPU_UTIL	SM Active	Tensor	DRAM	MFU	tok/s
batch 1	90%	54.59%	1.62%	62.3%	0.23%	148

The GPU utilization is at 90%, with only 0.23% of its capacity being used for actual work.

This is because, in order to generate a single word, the chip must access the entire 15 GB model. This process is repeated for every word, and it's equivalent to taking a full trip to the loading dock for just one envelope.

Performing two operations per weight across 7.62 billion weights results in 15.2 GFLOP per token, which translates to approximately 15 microseconds of mathematical computation. However, reading 15.2 GB of weights at a rate of 2.2 TB/s takes 6.8 milliseconds. The math units are only busy for 0.015 ms out of the total 6.8 ms. This accounts for the 0.23% of the GPU's capacity being utilized for actual computations. An H100 requires around 295 operations per byte read to become compute-bound, and batch-1 decode uses each byte exactly once.

This limitation is rooted in physics, rather than inefficient coding. The fix isn't a bigger GPU, but rather optimizing the process to handle more envelopes per trip.

Batch 64

	GPU_UTIL	SM Active	Tensor	DRAM	MFU	tok/s
batch 1	90%	54.59%	1.62%	62.3%	0.23%	148
batch 64	85%	62.07%	11.18%	57.4%	11.6%	7,485

From 148 to 7,485 tokens per second, the workload is fifty times greater.

The lie-number actually decreased, dropping from 89% to 85%.

The trip and fuel remained the same, with sixty-four envelopes. The MFU shifted from 0.23% to 11.6%, which is a desirable number for inference, as the literature suggests a healthy inference workload falls within the 5–15% range, representative of a fully loaded truck, unlike most dashboards that describe an empty one.

SM Active only increases from 54.59% to 62.07% as the workload rises fifty times. Even the second-most honest metric is nearly oblivious to batching. DCGM's own documentation says why:

Note that "active" does not necessarily mean a warp is actively computing. For instance, warps waiting on memory requests are considered active.

SM Active catches the spin loop. For inference, you need to measure Tensor Core activity and MFU.

The fields that don't lie

These fields are included with DCGM, but you won't find them on the standard display. Consider a kitchen in a restaurant:

DCGM_FI_PROF_SM_ACTIVE — are cooks present at their workstations?
DCGM_FI_PROF_SM_OCCUPANCY — what's the workload for each cook in terms of concurrent tasks?
DCGM_FI_PROF_PIPE_TENSOR_ACTIVE — is the specialized cooking equipment in use?
DCGM_FI_PROF_DRAM_ACTIVE — how frequently are cooks accessing the pantry?
MFU — the ratio of actual meals served to the kitchen's theoretical hourly capacity.

Position these next to the misleading information:

# dcgm-counters.csv
# --- The lie ---
DCGM_FI_DEV_GPU_UTIL,      gauge, GPU utilization (in %) — fraction of time at least one kernel was running.
# --- The truth (Datacenter Profiling fields; need --cap-add SYS_ADMIN and a datacenter GPU) ---
DCGM_FI_PROF_SM_ACTIVE,          gauge, Ratio of cycles an SM has at least 1 warp assigned.
DCGM_FI_PROF_SM_OCCUPANCY,       gauge, Ratio of number of warps resident on an SM.
DCGM_FI_PROF_PIPE_TENSOR_ACTIVE, gauge, Ratio of cycles the tensor (HMMA) pipe is active.
DCGM_FI_PROF_DRAM_ACTIVE,        gauge, Ratio of cycles the device memory interface is active.

MFU is the metric that equates to financial cost: the actual work performed, divided by the theoretical work the GPU could perform within the same hour.

The rule. If GPU utilization exceeds 80%:

SM Active is below 10% → no work is being executed.
SM Active is high, but MFU is under 5% → a process is running, however it is not performing computations.

In terms of business: financial losses are being incurred.

Lie #2 — the scheduler

NVIDIA is not the only one in this situation. Kubernetes has also provided its response on the "Schedule GPUs" page:

Containers (and Pods) do not share GPUs. There's no overcommitting of GPUs. Each container can request one or more GPUs. It is not possible to request a fraction of a GPU.

The two sentences about sharing were later dropped from the page. The behaviour remained unchanged.

resources:
  limits:
    nvidia.com/gpu: 1     # integer. request == limit. no fractions. no overcommit.

A whole number. A pod that requires 1% of a card takes the card.

Observe the process. pod-a runs one spinning thread and gets the GPU. pod-b is an exact duplicate and requests one:

pod-a   Running
pod-b   Pending    0/1 nodes are available: Insufficient nvidia.com/gpu

The node indicates that nvidia.com/gpu 1/1 is allocated. The card is utilized at 1% busy.

It is 99% unutilized and 100% unavailable. One envelope has booked the entire truck.

Kubernetes did not misallocate the card's resources; it blocked the card instead. The fix involves setting one configuration flag:

# device-plugin time-slicing config
version: v1
flags:
  migStrategy: none
sharing:
  timeSlicing:
    renameByDefault: false
    failRequestsGreaterThanOne: false
    resources:
      - name: nvidia.com/gpu
        replicas: 4

The README for the device plugin explains precisely what it does:

The NVIDIA device plugin allows oversubscription of GPUs through a set of extended options in its configuration file. […] If this configuration were applied to a node with 8 GPUs on it, the plugin would now advertise 80 nvidia.com/gpu resources to Kubernetes instead of 8.

The node is now advertising nvidia.com/gpu: 4. The status of pod-b changes from Pending to Running in about ten seconds. The card and pod are the same, with no other changes made.

Three honest ways to share a card

Time-slicing. Workloads alternate. There is no isolation - one workload can cause delays for the others, and there is nothing to prevent this. This method is suitable for development and bursty work.

MPS. Multiple workloads share one context. Since there are no barriers, a single problematic tenant can affect all others. This option should not be oversold.

MIG. Actual barriers are implemented in hardware. This method is rigid, requiring the node to be drained to re-partition, and it is limited to A100/H100-class only. On the card I rented, it was divided into seven slices, and the node advertised them:

nvidia.com/mig-1g.10gb: 7

All three options require explicit enrollment. The standard configuration is one pod and one card.

The direction of this development is as follows: DRA became generally available in Kubernetes 1.34, while partitionable devices and consumable capacity remain in beta, and NVIDIA contributed its DRA driver to CNCF at KubeCon EU 2026, indicating the path forward, although not for the current quarter.

In commercial terms, by default, you are buying it twice. Kubernetes is concerned with the number of trucks, without examining their contents.

Lie #3 — the bill

This particular statement is factual, which poses a problem.

Recall the invoice? My longest test lasted 2 hours 30 minutes, utilizing one H100, and cost $11.01, which translates to $4.41 per hour.

Cloud billing calculations are based on the duration and cost. There is no provision for accounting for actual usage.

Consider the batch-1 hour. The dashboard reported 90% GPU utilization. However, the genuine metric for the same hour was 0.23% MFU.

$4.41 per hour
= $0.01 that did work
+ $4.40 that bought idle silicon     (99.8%)

One H100 operating continuously costs approximately $3,200 per month. For batch 1, this translates to $7 spent on actual work and $3,193 spent on unused processing power. This is what the extra GPUs would buy. Now, multiply this by the number of cards you have.

Here is the detailed version of the billed hour, recorded from 15:45–16:45 UTC, which includes half of batch 1 and half of batch 64.

"the_lie":   { "gpu_util_pct_avg": 86.2 },
"the_truth": { "sm_active_pct_avg": 57.9, "tensor_active_pct_avg": 6.8, "mfu_pct": 5.89 },
"the_bill":  { "cost_usd": 4.42, "cost_that_did_work_usd": 0.26,
               "cost_of_idle_silicon_usd": 4.16, "idle_pct": 94.1,
               "tokens_generated": 13791321, "usd_per_1m_tokens": 0.32 }

86% is displayed on the dashboard. The MFU is 5.89%. Of that hour, $0.26 was spent on actual work and $4.16 was spent on idle silicon. I conducted this measurement twice, using two separate droplets, and obtained 5.9% both times.

You might argue that I'm not configuring them correctly, or that your workload is unique and you have a better understanding of how to optimize resources.

Maybe. However, consider Cast AI's report, which covers the period from January 2025 to April 2026 and encompasses approximately 23,000 Kubernetes clusters. The average GPU utilization is 5%.

This figure is based on the dashboard number, and the actual values are even lower.

Which metric does the bill follow?

Neither of them.

The bill is based on hours, not work. It provides an honest but useless measure, as it only indicates what was spent without revealing what was achieved.

In business terms, it is impossible to prove that any of the expenses were justified.

Why does this issue persist in 2026?

The metric is not flawed; it is simply answering a question from 2007.

At that time, a GPU could only run one task at a time, and determining whether it was busy was the only relevant consideration. However, as the chip evolved to 132 cores, the question was never updated.

Kubernetes counts entire units as a single entity for a similar reason: the fact that GPUs lack a native operating system. CPUs have had sixty years of development in schedulers, preemption, and isolation, while GPUs have only had a driver. Time-sharing was introduced in 1961, but hardware partitioning on a GPU was not available until 2020. Time-slicing, MPS, and MIG are essentially the missing OS, arriving late to the scene.

While the CPU has spent fifty years evolving, the GPU has been primarily focused on gaming.

What to do on Monday

Plot MFU alongside GPU utilization on the same dashboard, on the same panel if you can. The instant the two lines diverge, you will have a specific value to take action on.

Scale on queue depth, never on utilization. The utilization level is 90% regardless of whether the truck is full or empty, which means autoscaling based on this metric will either result in perpetual scaling or none at all. Using KEDA with vllm:num_requests_waiting adds a truck only when there are actually envelopes waiting, ensuring that the trucks you are already paying for are utilized to their full capacity first. If autoscaling is not an option, cap and batch instead. In a continuous batching setup, a queue represents the truck filling up, rather than a failure. The added latency cost per token is minimal — ranging from 6.8 ms to 8.6 ms when increasing the batch size from 1 to 64.

Stop relying on the default scheduler settings. Choose time-slicing, MPS, or MIG based on the actual isolation requirements.

Price inference per million tokens, not per GPU-hour, and present this number to the person responsible for signing the checks. For the same silicon and hour, my calculation is:

	$ per million tokens
batch 1	$8.28
batch 64	$0.16

The price is fifty times higher. The silicon is the same. The gauge remains unchanged.

Or, as it goes in German: Zeit ist Geld, aber das Finanzamt will trotzdem beides.

The last thing

The dashboard never lied to you with the intention of hurting you, and neither did the benchmark. They both provided honest answers to their respective questions — is the GPU busy? and what can this chip do when it's full? However, neither of these questions was what I was actually paying for, which was is the GPU doing my work?

Utilization does not equate to work.

GPUs are in the process of evolving to meet our current demands, but this development has only just begun. The immature aspect is not the silicon itself, but rather the software that surrounds it. Additionally, these cards consume a significant amount of power, resulting in wasted resources beyond just financial costs.

If you get it right, you will receive a 98% discount. If you get it wrong, you will incur costs that are 50× higher, and you will also have a negative impact on the environment as an added consequence.

You must measure the question that you are actually paying for.

HTTP QUERY: Everything a Developer Needs to Know About HTTP's Newest Method

Ali Alp — Sun, 16 Aug 2026 15:17:59 +0000

For as long as most of us have been writing APIs, there has been one awkward question with no good answer: where do I put a complex search query?

In June 2026 the IETF finally answered it. RFC 10008 defines a new HTTP method, QUERY: safe and idempotent like GET, cacheable like GET, but with a request body like POST. It's the first new general-purpose method HTTP has gained in about twenty years.

The problem: GET vs POST was always a bad trade

Say you're building a product search endpoint. You have two classic options, and both are compromises.

The first is GET with a query string:

GET /products?category=books&maxPrice=30&sort=rating&fields=title,price HTTP/1.1

You get safety, idempotency, caching, bookmarks. You also get practical URL length limits; servers and proxies commonly cap URLs somewhere between 2 KB and 8 KB, which starts to hurt once your filter UI grows or you need to pass a long list of IDs. The whole query also lands in access logs and browser history, bad news if it contains personal data. And no, you can't just put a body on the GET instead: the spec gives a GET body no defined semantics, so servers and intermediaries do unpredictable things with it.

The second option is POST with a body:

POST /products/search HTTP/1.1
Content-Type: application/json

{ "category": "books", "maxPrice": 30, "sort": "rating" }

Now there are no size limits and nothing sensitive in the URL. But POST is neither safe nor idempotent by definition. Caches have to assume it changes state, so responses can't be reused. A client that hits a network failure can't retry automatically, because it has no way to know whether that's safe. And the message itself no longer says "this is just a read".

Every REST API that grew a /search POST endpoint made this trade. QUERY exists so you don't have to.

Meet QUERY

From RFC 10008, the QUERY method:

"requests that the request target process the enclosed content in a safe and idempotent manner and then respond with the result of that processing."

Unpacked: safe means the client neither requests nor expects any state change on the target resource. It's a read. Idempotent means it can be repeated or retried, say after a connection failure, with no concern about partial state changes. Cacheable means a cache MAY use the response to satisfy later equivalent QUERY requests. And unlike GET, the query itself travels in the request body, in whatever media type the resource supports.

Here is a minimal exchange (adapted from the RFC's own example):

QUERY /contacts HTTP/1.1
Host: example.org
Content-Type: application/x-www-form-urlencoded
Accept: application/json

select=surname,givenname,email&limit=10&match="email=*@example.*"

HTTP/1.1 200 OK
Content-Type: application/json

[
  { "surname": "Smith",  "givenname": "John",   "email": "smith@example.org" },
  { "surname": "Jones",  "givenname": "Sally",  "email": "sally.jones@example.com" },
  { "surname": "Dubois", "givenname": "Camille","email": "camille.dubois@example.net" }
]

The body isn't limited to form encoding. The RFC's examples use application/x-www-form-urlencoded, JSONPath, SQL and even XSLT as query languages. The media type defines what the query means; the resource defines what it's evaluated against.

GET vs QUERY vs POST at a glance

Property	GET	QUERY	POST
Safe	yes	yes	potentially no
Idempotent	yes	yes	potentially no
Request body	no defined semantics	expected	expected
Cacheable response	yes	yes	only for future GET/HEAD
Automatic retry OK	yes	yes	no
URI for the query itself	yes, by definition	optional (`Location`)	no
URI for the result	optional (`Content-Location`)	optional (`Content-Location`)	optional (`Content-Location`)

The rules of the road

A few things the RFC is strict about.

Content-Type is mandatory. Servers must fail a QUERY request whose Content-Type is missing or inconsistent with the actual content. No content sniffing.

Error signaling is well defined:

Situation	Status
Missing media type	`400 Bad Request`
Media type not supported for queries	`415 Unsupported Media Type`
Content doesn't match its declared type	`400 Bad Request`
Query parses but is semantically invalid	`422 Unprocessable Content`
Server can't produce a response type the client accepts	`406 Not Acceptable`
Server doesn't support QUERY at all	`405 Method Not Allowed` (with an `Allow` header)

And the URI's query string still exists. QUERY /contacts?active=true is legal; the query component still participates in identifying the resource, while the body carries the query content. How the two combine is up to the resource.

Discovery: `Allow` and the new `Accept-Query` header

RFC 10008 also registers a new response header, Accept-Query, which advertises the media types a resource accepts for QUERY bodies. It uses Structured Fields syntax:

HEAD /contacts HTTP/1.1
Host: example.org

HTTP/1.1 200 OK
Accept-Query: application/x-www-form-urlencoded, "application/sql"

There are two more discovery paths. Send OPTIONS /contacts and look for QUERY in the Allow response header. Or just try it: an unsupported method gets you a 405 with Allow, and an unsupported query format gets you a 415, ideally with Accept-Query telling you what would have worked.

One subtlety: Accept-Query applies to every URI on the server that shares the same path. The URI's query component is ignored for its scope.

Caching: the killer feature

This is the part that makes QUERY an actual improvement over tunneling reads through POST.

Because QUERY is safe, its responses are cacheable. Unlike GET, though, the URL alone isn't enough to identify a response, so the RFC requires:

The cache key for a QUERY request must incorporate the request content and related metadata (like Content-Type).

In other words: same URL plus same query body (plus the relevant headers) equals a cache hit. A CDN or shared proxy can serve your repeated dashboard query without ever touching the origin, which was structurally impossible with POST-based search.

Caches are also allowed to normalize the request content when building the key, for example by stripping content encodings or applying known conventions of the format (JSON's insignificant whitespace, say), so trivially different bodies can still hit the same cache entry. Normalization only ever affects the cache key; the request itself is left untouched. The RFC warns caches to be conservative here, because bad normalization means wrong responses served. Clients can send Cache-Control: no-transform to discourage it, though the directive is advisory.

The practical takeaway for API authors: emit the same caching headers on QUERY responses that you would on GET (Cache-Control, ETag, Last-Modified, Vary) and you get HTTP caching on complex searches for free as caches roll out support.

`Location`, `Content-Location`, and the "equivalent resource"

The RFC introduces a concept called the equivalent resource: the hypothetical resource that would answer a GET with the results of this exact query. Servers may give that resource a real URI, and two response headers let them tell you about it.

Location on a 2xx response means: you can GET this URI later to re-run the query without resending the body. Think saved queries. Content-Location means: you can GET this URI to retrieve this specific result snapshot, which may be temporary.

HTTP/1.1 200 OK
Content-Type: application/json
Location: /contacts/stored-queries/42          (re-runs the query)
Content-Location: /contacts/stored-results/17  (this specific result set)

[ ...results... ]

A server can even respond 303 See Other with a Location, meaning the answer to your query is available as a plain GET over there. That's a useful pattern for expensive queries: QUERY once, then poll or share a cheap, cacheable GET URL.

Conditional requests work too

Because QUERY is a read, the whole conditional-request machinery from RFC 9110 applies. Send If-None-Match or If-Modified-Since with a repeated QUERY and the server can answer 304 Not Modified, skipping both the query execution and the response body. For heavy analytical queries over slowly changing data, that's a big deal.

Redirects

Worth knowing because this differs from POST's legacy behavior. On 301, 308, 302 and 307, the client resends the QUERY, body included, to the new URI; the old browser habit of demoting redirected POSTs to GETs explicitly does not apply. On 303 See Other, the client performs a GET on the Location URI instead.

Using it today

QUERY is just an HTTP method token, and most HTTP stacks can carry it already. What varies is framework sugar and intermediary awareness.

curl

curl --request QUERY https://api.example.org/products \
  --header "Content-Type: application/json" \
  --header "Accept: application/json" \
  --data '{ "category": "books", "maxPrice": 30 }'

JavaScript (fetch)

The Fetch Standard forbids only CONNECT, TRACE, and TRACK, so QUERY is allowed:

const res = await fetch("/products", {
  method: "QUERY", // uppercase: only the classic six methods are auto-normalized
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ category: "books", maxPrice: 30 }),
});
const products = await res.json();

Two caveats. Cross-origin QUERY always triggers a CORS preflight, since it's not a safelisted method. And browser and runtime support has been landing gradually through 2026, so verify in your targets before shipping.

.NET 10 / ASP.NET Core 10

.NET 10 shipped support on both sides:

// client
using var request = new HttpRequestMessage(HttpMethod.Query, "https://api.example.org/products")
{
    Content = JsonContent.Create(new ProductFilter("books", MaxPrice: 30))
};
using var response = await httpClient.SendAsync(request);

// server (minimal APIs; use MapMethods, there's no MapQuery yet)
app.MapMethods("/products", new[] { HttpMethods.Query }, async (HttpContext ctx, ICatalog catalog) =>
{
    var filter = await ctx.Request.ReadFromJsonAsync<ProductFilter>();
    return filter is null ? Results.BadRequest() : Results.Ok(await catalog.SearchAsync(filter));
});

Node.js / Express

Routing frameworks generally expose custom methods once the underlying HTTP parser accepts them. Check your Node version's method allowlist, then route with something like:

app.all("/products", (req, res, next) => {
  if (req.method !== "QUERY") return next();
  // req body = the query
});

Graceful fallback

During the transition, attempt QUERY and fall back to your existing POST search endpoint when you get a 405 Method Not Allowed or a blocked request. Both can share the same handler server-side.

Gotchas and sharp edges

WAFs, load balancers and API gateways with method allowlists may reject or mangle QUERY. Audit your edge before rolling it out.
The semantics allow shared caches and CDNs to cache QUERY, but the products need body-aware cache keys first. Treat CDN-level QUERY caching as a roadmap item for now.
Every cross-origin browser use pays a CORS preflight. Cache it with Access-Control-Max-Age.
OpenAPI can't describe QUERY endpoints yet; ASP.NET Core 10, for instance, simply omits them from generated specs. Document them manually for now.
Moving query parameters out of URLs is a privacy win, since less leaks into logs and history. But if your server mints Location or Content-Location URIs for queries, the RFC says those URIs SHOULD NOT embed sensitive parts of the query content. Don't undo the win.
Idempotence is a promise you make. Marking an endpoint QUERY tells every client and intermediary "retry me freely, cache me". If the handler secretly writes state, you'll get all the classic broken-cache and double-execution bugs. Reads only.

When to reach for QUERY

Use it when a read doesn't fit comfortably in a URL:

complex filter and search endpoints (the /search POST you already have)
queries written in a real query language (JSONPath, SQL subsets, GraphQL documents)
lookups with large ID lists ("give me these 5,000 SKUs")
reads whose parameters are sensitive and shouldn't live in URLs and logs

Keep plain GET for anything that fits in a URL; bookmarks and universal caching are still unbeatable. Keep POST for what it always meant: requests that change state.

Wrap-up

QUERY closes a twenty-year-old gap in HTTP's vocabulary: a read with a body. The parts beyond that headline are what make it worth adopting, especially the body-aware caching and the stored-query pattern via Location.

The ecosystem is still catching up. Middleboxes and CDN cache keys will take a while, and OpenAPI has no way to describe QUERY endpoints yet. But the standard is done and the first frameworks have shipped, and keeping a POST fallback around costs almost nothing. Next time you're about to add a POST /search endpoint, try QUERY first.

References

RFC 10008 — The HTTP QUERY Method (Proposed Standard, June 2026)
IETF datatracker history — draft-ietf-httpbis-safe-method-w-body
RFC 9110 — HTTP Semantics (method properties, conditional requests)
RFC 9651 — Structured Field Values (the Accept-Query syntax)

"Where.Was.I" — a task board built around the moment you switch

Ali Alp — Mon, 20 Jul 2026 13:06:16 +0000

Live app: https://alicommit-malp.github.io/wherewasi/ · Source: https://github.com/alicommit-malp/wherewasi

Most task apps are built around what you have to do. wherewasi is built around a different moment: the one where you stop doing one thing and start doing another, and your entire mental context evaporates. It answers exactly one question, and it answers it fast — where was I?

Watch the same clip as MP4 — 40 seconds, no audio.

The problem it solves

You have five things in flight. You're deep in one of them when something interrupts you. Two days later you come back and spend fifteen minutes reconstructing what you'd already figured out: what you'd finished, what you were blocked on, what the next move was going to be.

That reconstruction is pure waste, and it's avoidable — the knowledge existed in your head at the moment you left. wherewasi is a place to dump it in five seconds, and to find it again instantly.

Three rules define the whole app:

Exactly one task is active at a time. Not a philosophy about focus — just an honest record of where your attention actually is.
Every task carries a stack of short notes. Newest first. "renewed the cert", "waiting on DNS", "next: draft the outline". Free text, no schema, no ceremony.
Switching is instant. One click or one keystroke. No dialog, no prompt, no "are you sure" — because anything that adds friction to switching means you'll stop recording your switches, and then the app is worthless.

What it deliberately does not do

Design is mostly subtraction, and this app had a lot subtracted:

No timers, no time tracking. The first draft measured how long each task was active. It got cut, because the value was in restoring context, not producing timesheets — and a running clock creates a low-grade obligation to "start" and "stop" things correctly.
No tags or categories. An earlier version tagged each note as did / waiting / next. In practice the tag was one more decision at the exact moment you want zero decisions. Plain text carries the same meaning: just type "waiting on DNS".
No forced note on switch. The original design popped a modal on every switch asking what happened. It was correct in theory and unbearable in practice.
No accounts, no server, no network. Your data never leaves your browser.

Each of those removals came from actually using the thing and noticing the friction.

Using it

The board

One narrow column. Each row is a task: a dot, the title, and its three most recent notes underneath in muted text. The active task is highlighted and is the only row with a note input. That's the whole interface.

Clicking a task title switches to it instantly and moves it to the top of the list, so the board self-sorts by recency: what you're on is first, what you just left is right below it, and stale work sinks to the bottom on its own.

Naming the workspace

Click the wherewasi title in the header to give the board a name — wherewasi — work, wherewasi — side project, whatever. It also becomes the browser-tab title, so if you keep separate boards in separate browser profiles they stay easy to tell apart. Leave it blank and the header is just wherewasi.

Writing notes

The active task's input says What happened?. Type, press Enter, done. Notes stack newest-first, each with a small timestamp so you can see whether a thought is from ten minutes ago or last week.

Click any note to edit it inline (Enter saves, Escape cancels). If a task has more than three notes, a +N more link expands the full history — and that expansion collapses automatically the moment you switch tasks, so the board never grows cluttered behind your back.

Undo, because instant shouldn't mean irreversible

Archiving a task or deleting a note happens with no confirmation dialog — but neither is a dead end. Both drop a five-second Undo toast (click it, or press u), and undo restores the item exactly where it was: an archived task returns to its old board position rather than the bottom, and a deleted note slots back into its original place in the stack. It fits the whole design: act instantly, take it back if you didn't mean it. Let the five seconds lapse and it's committed.

Staying in sync across tabs

Open wherewasi in two tabs and they stay consistent — a change in one appears in the other within a moment, because every tab reads and writes the same local database and pings its siblings to refresh. No stale second tab quietly overwriting your work.

Keyboard

The app is fully keyboard-driven; press ? at any time for this list.

Key	Action
`↓`/`j`, `↑`/`k`	Move the selection
`Enter`	Switch to selected — on the active task, jump into the note input
`a`	Write a note on the active task, from anywhere
`n`	New task
`e`	Rename selected task
`d`	Done — archive selected task
`u`	Undo the last archive or note deletion (while the prompt shows)
`Space` / `m`	Expand / collapse selected task's notes
`v`	Toggle the archive
`/`	Search (in the archive)
`Esc`	Leave input / close view / clear selection

The fastest possible loop is j j Enter to land on a task, then Enter again to start typing what happened. Single-letter shortcuts are suppressed while you're typing, so notes never trigger commands.

On a phone

It's desktop-first, but it works on touch: the per-row actions (archive, rename, delete) are always visible instead of hiding behind hover, and it installs as a real PWA — proper maskable and Apple-touch icons, so the home-screen tile looks right on both Android and iOS, and it runs fully offline once installed.

Finishing and finding things

Pressing d (or clicking the ✓ that appears on the row) archives a task. It leaves the board but keeps its entire note stack, browsable under Archive and reopenable at any time. The archive has full-text search across both task titles and note contents — so months later, searching "headcount" surfaces the task where you wrote "travel numbers in, headcount still missing", even if the title never mentioned it.

How it's built

A deliberately small stack, chosen so the whole app stays readable in one sitting:

Vite 8 + Svelte 5 (runes) + TypeScript — small bundle, minimal boilerplate
Dexie 4 over IndexedDB — typed local persistence
vite-plugin-pwa — generated service worker and manifest; installable and fully offline
GitHub Actions → GitHub Pages — every push to main builds and publishes

The data model

Three tables, all with UUIDs and timestamps:

Task     { id, title, status: 'open' | 'archived', createdAt, archivedAt?, sortOrder }
Note     { id, taskId, text, createdAt }
AppState { id: 'app', activeTaskId: string | null, title?: string }   // exactly one row

The most important detail is the smallest one: "one active task" is a single pointer in AppState, not a boolean flag on each task. Two tasks being active simultaneously isn't a bug that has to be prevented — it's unrepresentable. Whole classes of state-sync bugs simply don't exist.

sortOrder is what makes switching bubble a task to the top: activating a task rewrites its order to just below the current minimum, and that reordering is persisted like everything else. That same persisted order is why undo can drop an un-archived task back into its exact former place.

State flow

A single store class (src/lib/store.svelte.ts) holds $state runes, hydrated from IndexedDB once at startup. Every mutation writes to Dexie first, then updates in-memory state, then broadcasts a one-line "changed" ping to any other open tabs. There is no memory-only state anywhere, so a refresh, a crash, or a closed laptop lid loses nothing. Empty titles and empty notes throw rather than silently no-op.

The UI is a handful of small components — the board, a task row, the note form, and a help overlay — none of which own any persistent state of their own.

Local-first, on purpose

Everything lives in your browser's IndexedDB. No account, no sync server, no telemetry, no network calls at all. On load the app calls navigator.storage.persist() to ask the browser not to evict the board under storage pressure. That local-first choice has real consequences worth being honest about:

It's single-device. Tabs in the same browser stay in sync, but a different machine is a different board. The data model was built sync-ready (UUIDs and timestamps everywhere), so a sync layer can be added later without remodeling.
Browser storage still isn't a vault. Persistent storage makes eviction far less likely, but clearing site data wipes it. A JSON export is the obvious next hardening step.

For a tool whose whole job is holding your working context, that trade is deliberate: zero setup, zero latency, and nothing to trust.

Where it goes next

Already shipped since the first cut: five-second undo for archiving and note deletion; multi-tab consistency via BroadcastChannel; persistent storage via navigator.storage.persist(); a nameable workspace; and clean PWA installation on iOS and Android with maskable and Apple-touch icons.

Still ahead, roughly in priority order:

JSON export / import — the rest of durability: a backup you own and can move.
Sync — a self-hosted backend (PocketBase or CouchDB/PouchDB) the static frontend talks to, giving multi-device use without handing task contents to a third party.
Tests — the store's invariants (one active task, archiving clears the pointer, switching reorders, undo restores in place) are exactly the logic worth pinning down with Vitest and fake-indexeddb.

Try it

https://alicommit-malp.github.io/wherewasi/ — it installs as a PWA from the browser menu and works with the network off. Add a couple of the things you're juggling right now, switch between them, and leave yourself a note on the way out. The payoff arrives the next time you come back.

[Boost]

Ali Alp — Mon, 06 Jul 2026 20:37:33 +0000

Ali Alp

Jul 6

Why Event-Driven Architecture Isn’t About Speed (and When You Actually Need It)

#architecture #devops #microservices #systemdesign

3 min read

Why Event-Driven Architecture Isn’t About Speed (and When You Actually Need It)

Ali Alp — Mon, 06 Jul 2026 20:37:16 +0000

We’ve all seen it happen. A engineering team wants to feel like they belong in the "cool kids" club, so they grab Apache Kafka or a massive event broker, throw it at a straightforward CRUD application, and suddenly a simple database write is wrapped in a complex web of event producers, consumers, and brokers.

Before you introduce that level of massive operational overhead into your stack, we need to talk about what Event-Driven Architecture (EDA) actually delivers—and what it charges you in return.

I recently sat down for a panel discussion on the reality of building real-time enterprises. If you want to skip the hype and hear the unvarnished truth about architectural trade-offs from practicing architects, you can watch the full panel discussion on YouTube here.

Here is the breakdown of the core architectural realities we discussed.

1. "Real-Time" is a Spectrum, Not Pure Speed

When stakeholders or product managers say they want "real-time data," they usually just mean they want their system to feel fast. But real-time isn't a single setting; it's a massive spectrum.

Hard Real-Time: Think medical instrumentation, radar tracking, or high-frequency trading systems. Milliseconds or microseconds dictate success, and missing a deadline means total system failure.
Soft Real-Time: A Grafana metrics dashboard or an activity feed. If an update takes an extra two seconds to show up, the business survives.

Here is the hard truth that catches many off guard: EDA does not give you more speed. Every broker, event log, network hop, and serialization boundary you insert adds infrastructure complexity and transport latency. You don't adopt EDA for raw single-stream performance; you adopt it for decoupling. If your system cannot tolerate eventual consistency, forcing an EDA into your core transaction loop is the wrong choice.

2. The Overkill Trap: When to Actually Deploy EDA

Architectural patterns should evolve organically based on hard constraints, not because you want to copy LinkedIn’s or Netflix's infrastructure blogs. Attempting to build a brand-new service around a heavy event broker on day one is the definition of over-engineering.

So, when is it actually time to shift to an event-driven model?

The Litmus Test: You need EDA the moment your system emits a single fact (e.g., OrderPlaced) that multiple, completely independent business domains need to natively consume and react to at the same time.

If an order placement requires immediate, distinct actions from Shipping, Billing, Inventory management, and Fraud Detection—all handled by different microservices or separate teams—EDA rescues you from tight coupling and nasty orchestration bottlenecks. If it’s just one service talking directly to another, stick to a simple, synchronous API call or a lightweight point-to-point queue until the system forces you to change.

3. Conway’s Law Wins Every Time

Software architecture is socio-technical. You can design the most elegant, fully decoupled event-driven ecosystem on a whiteboard, but if your organization is managed by a rigid, top-down hierarchy where every cross-team decision requires centralized synchronization and global locks, your technical architecture will rot.

Before rewriting your stack to use events, look at your org chart:

Do your individual teams have the actual operational autonomy to own micro-domains?
Can your engineers shift their mental model from immediate, synchronous database states to handling asynchronous flows, retries, and out-of-order events?

If the organizational maturity isn't there to support decentralized data ownership, forcing EDA into the codebase will only create technical friction and team frustration.

4. Why AI and EDA Are Perfect Partners

While human developers often struggle to reason through sprawling, asynchronous event loops, artificial intelligence thrives in them.

Parallelism is baked into the very DNA of modern AI orchestration. If you are building multi-agent AI frameworks, those autonomous agents spend a massive amount of time executing parallel background tasks, waiting on inputs from collaborator agents, and reacting to changing context states. Because an AI ecosystem is inherently asynchronous and distributed, an event-driven backbone is one of the most effective ways to cleanly coordinate intelligent systems without blocking execution threads.

Cut Through the Noise

Architecture is always a game of trade-offs. EDA gives you incredible flexibility, system resilience, and structural decoupling, but it taxes you heavily in complexity and latency. Make sure your business domain actually requires what it's selling before you sign the check.

For the deeper, unfiltered debate on these concepts—including how data governance and organizational maturity factor into the mix—check out the full session here:

How I built one Manifest V3 extension that runs on Chrome, Edge, and Firefox

Ali Alp — Thu, 14 May 2026 10:54:12 +0000

I built a browser extension called Silenzio that blurs or blacks out videos and images, mutes audio, and lets me set rules about where and when it applies. The motivation is a bit personal: scrolling feeds, search results, and "people you may know" lists kept stealing minutes I didn't actually want to spend. A blurred feed turns out to be a surprisingly effective speed bump.

The technically interesting part is that the whole thing — Chrome, Edge, and Firefox — runs from a single source folder. No build step, no per-browser variants, no Webpack. Here's how that works, plus a handful of MV3-specific tricks I had to find along the way.

What it does

Two independent toggles — videos and images — each with Off / Blur / Blackout. Audio follows the video toggle. Three more knobs on top: an allowlist or blocklist of sites, per-site or global pause timers, and an optional "working hours" schedule so the whole thing only runs during a daily window you pick.

One manifest, three engines

Manifest V3 is technically the same across Chrome, Edge, and Firefox 115+. In practice you can write a single manifest.json that all three load, because:

Chromium engines ignore unknown manifest fields.
The MV3 fields Silenzio actually uses (content_scripts, host_permissions, action, options_page, permissions) are part of the standard that Firefox now implements.

The Firefox-specific block goes at the bottom and Chromium ignores it:

"browser_specific_settings": {
  "gecko": {
    "id": "silenzio@silenzio.local",
    "strict_min_version": "115.0"
  }
}

That's it. The same files load in three browsers with zero conditional code.

The one gotcha you can't solve in the manifest is that Firefox MV3 treats <all_urls> host permissions as user-granted post-install. After temporary-loading the add-on, you have to click the toolbar icon → puzzle-piece menu → Silenzio → "Always allow on all websites" once. Until then, the content script won't actually inject. Easy to miss the first time.

Catching short-form feeds

The hard case for a media-filtering extension is short-form video — Shorts, Reels, the LinkedIn feed. Those surfaces aggressively mount and unmount <video> elements as you scroll. A naive document.querySelectorAll("video") at load time finds nothing useful, because most of the videos haven't been mounted yet.

The fix is a MutationObserver rooted at document.documentElement, started at document_start:

const observer = new MutationObserver((mutations) => {
  const eff = effectiveModes();
  for (const m of mutations) {
    for (const node of m.addedNodes) {
      if (node.nodeType !== 1) continue;
      if (node.matches?.(SELECTOR)) applyTo(node, eff);
      node.querySelectorAll?.(SELECTOR).forEach((el) => applyTo(el, eff));
    }
  }
});
observer.observe(document.documentElement, { childList: true, subtree: true });

Because the manifest sets "run_at": "document_start", the observer is in place before the body even exists. Newly-mounted videos and images get the filter class within a tick of being inserted.

There's a small but important detail in the order: I start the observer before loading the saved config from chrome.storage.local. Storage is asynchronous, and the round trip easily takes long enough for an autoplay video to mount and start playing. So the observer runs with defaults immediately, then re-applies once storage resolves. The visible result is that pages never flash an unblurred frame.

One CSS path for videos and images

The CSS for the blur and blackout is dumb on purpose:

.silenzio-blur { filter: blur(40px) !important; }
.silenzio-blackout { filter: brightness(0) !important; }

filter is an element-level property. It applies to whatever the box renders — video frames, image content, even async-loaded image bytes that arrive after the class is set. That means <video> and <img> share exactly one apply path. The element-type dispatch happens once, in modeFor:

function modeFor(el, eff) {
  if (el instanceof HTMLVideoElement) return eff.video;
  if (el instanceof HTMLImageElement) return eff.image;
  if (el instanceof HTMLMediaElement) return eff.video; // <audio> follows video
  return "off";
}

Adding new media types later is a two-line change in this function and one selector update. The CSS doesn't need to know anything.

Re-muting hostile sites

el.muted = true is fine 90% of the time. The 10% case is sites that programmatically unmute on a player event, or swap the src on the same element when you scroll to the next short. So I attach two capture-phase listeners on document:

document.addEventListener("volumechange", (e) => {
  if (effectiveModes().video !== "off" &&
      e.target instanceof HTMLMediaElement &&
      !e.target.muted) {
    e.target.muted = true;
  }
}, true);

document.addEventListener("play", (e) => {
  if (e.target instanceof HTMLMediaElement) applyTo(e.target, effectiveModes());
}, true);

Capture phase matters here. By the time volumechange bubbles to the document the site's own handler has already run; capture-phase intercepts before. This is enough to keep YouTube, LinkedIn, and Reels muted reliably.

The decision flow

Every time the extension applies a mode it goes through effectiveModes():

Scope — if the current hostname doesn't match the user's allowlist or blocklist, both modes return off. Match is exact-or-suffix, so adding youtube.com covers www.youtube.com and m.youtube.com.
Pause — if there's a global or site-specific pause active right now, both modes return off.
Schedule — if working hours are enabled and the current time is outside the window, both modes return off.
Otherwise return the user's configured { video, image } modes.

This is the only place precedence is decided, and the order matters: I want a one-click pause to override the user's other rules without needing to think about them.

Time-based state is re-checked via a single setTimeout per page that targets the next relevant boundary — the exact pause expiry, or the next minute boundary if a schedule is active. Doing exact schedule-edge math with days-of-week and midnight crossings is fussy; minute granularity is more than enough for a "working hours" feature and avoids a category of bugs.

What I didn't (yet) solve

Three known gaps, all on the someday list:

CSS background-image — many avatars and decorative banners are painted via background-image rather than <img>. Filtering them requires walking computed styles and either injecting per-element CSS or patching stylesheets. I skipped it for v1.
Inline <svg> — mostly icons, rarely worth blurring. (<img src="*.svg"> is filtered because the selector catches <img>.)
Web Audio API graphs — HTMLMediaElement.muted doesn't stop a Web Audio graph that pulls samples directly. Ordinary playback on YouTube, LinkedIn, etc. uses HTMLMediaElement and is muted correctly; some games and audio editors aren't.

Each is solvable, just not at v1 scope.

Try it

Silenzio is on the Chrome Web Store — works in Edge too. The source, including the Firefox load instructions, lives at github.com/alicommit-malp/silenzio. No build step — Load unpacked and go.

If you've built a cross-browser MV3 extension and have a cleaner answer for Firefox's host-permission UX, the Web Audio mute, or background-image filtering, I'd love to hear it.

Did you ever wondered to see your whole life in one page calendar ?

Ali Alp — Thu, 07 May 2026 20:36:38 +0000

Ali Alp

May 7

I built a 'life in weeks' poster generator in one HTML file

#productivity #javascript #life

4 min read

I built a 'life in weeks' poster generator in one HTML file

Ali Alp — Thu, 07 May 2026 20:35:24 +0000

I made a tool that draws every week of your life on a single sheet of paper.

A long human life is roughly 5,200 weeks. That's a 100-row × 52-column grid — small enough to fit on one A4 page, big enough that you instinctively try to count them. The tool fills in the weeks you've already lived, leaves the rest empty, and exports a PDF you can print.

Live: https://alicommit-malp.github.io/life-in-weeks/
Source: https://github.com/alicommit-malp/life-in-weeks

It's also a quiet experiment in restraint:

One file (index.html — HTML, CSS, JS, all of it)
No framework, no bundler, no package.json
Two CDN deps: jsPDF and Google Fonts
No backend, no analytics, no localStorage
$0 hosting, $0 forever

This post is about the design decisions. There's just enough code to show what's interesting; the rest is on GitHub.

Why one file?

Because the surface area is small. The whole product is "type your name and birthdate, click two buttons." A build step buys nothing — and "no build step" buys something real: anyone can clone the repo, double-click index.html, and run it offline. No npm install, no Node version mismatch, no broken Vite plugin two years from now.

This wasn't dogma. I genuinely tried to imagine a v2 that needed React. I couldn't justify it.

Drawing 5,200 circles fast

The naive approach is <circle> × 5,200. It works, but that's a lot of DOM nodes.

The trick: two <path> elements, one for filled circles and one for empty ones. Build the path data as a single string of moveto + arc commands.

function circlePath(cx, cy, r) {
  return `M${cx},${cy} m${-r},0 a${r},${r} 0 1,0 ${2*r},0 a${r},${r} 0 1,0 ${-2*r},0 `;
}

let filledD = "", emptyD = "";
for (let r = 0; r < YEARS; r++) {
  const cy = gridTop + (r + 0.5) * ROW_H;
  for (let w = 0; w < WEEKS; w++) {
    const cx = leftX + (w + 0.5) * CELL;
    const idx = r * WEEKS + w;
    if (idx < totalWeeks) filledD += circlePath(cx, cy, CIRCLE_R);
    else emptyD += circlePath(cx, cy, CIRCLE_R);
  }
}

The M cx,cy m -r,0 a r,r 0 1,0 2r,0 a r,r 0 1,0 -2r,0 pattern draws a circle as two half-arcs from a moveto point. Subsequent M commands inside the same d attribute start a new disconnected subpath, so one <path> element ends up containing 5,000+ circles.

Two DOM nodes instead of 5,200. Render is instant.

Keeping the PDF honest

The on-screen preview is SVG. The download is a real PDF, generated by jsPDF from circle(), line(), and text() primitives. They have to look identical — if the preview lies, the user feels cheated the moment they hit "Download."

The fix is shared coordinate math. jsPDF in pt units uses A4 = 595.27 × 841.89, top-left origin, y growing down — exactly like SVG. So both renderers consume the same constants:

const PAGE_W = 595.27;
const PAGE_H = 841.89;
const MM = 2.83465; // 1 mm in pt

function computeLayout(years) {
  const cellWMax = (PAGE_W - LEFT_M - RIGHT_M) / 52;
  const cellHMax = (PAGE_H - TOP_M - BOTTOM_M) / years;
  const cell = Math.min(cellWMax, cellHMax);
  // ... gridW, gridH, leftX, gridTop, circleR, font sizes, tick step
}

Both renderSVG() and renderPDF() call computeLayout(years) and then walk identical loops. Change a margin in one place, both renderers update. No divergence.

The layout is height-constrained — and that's a feature

100 rows × 52 columns of square circles on a single A4 page means cell size is capped by page height, not width. The grid ends up about 135 mm wide — there are ~24 mm of empty margin on the left and right. People keep wanting to "fix" this.

Earlier iterations tried:

Two-page A4 — wider circles, but you have to tape the pages together
Landscape A4 — counterintuitively gives smaller circles, because height becomes the new constraint
Stretched ovals — looks bad

The empty side margins are correct. They're the price of the proportions. I kept them.

Adding pets

Recently I added a Human / Dog / Cat selector. Dogs get 20 rows × 52 columns; cats, 25. For shorter spans, the cell size becomes width-constrained instead, so circles get bigger, and the tick axis switches from a 10-year step to a 5-year step:

const SPECIES = {
  human: { years: 100, placeholder: "e.g. Ali" },
  dog:   { years: 20,  placeholder: "e.g. Spot" },
  cat:   { years: 25,  placeholder: "e.g. Mochi" },
};

// inside computeLayout:
const tickStep = years <= 30 ? 5 : 10;

Because all the layout state went through one function, adding species was a small diff plus a CSS segmented control. I didn't have to touch the rendering loops at all.

Going against the SaaS look

Most "free tool" landing pages use the same recipe: Inter, gradient backgrounds, rounded cards with shadows, a Lucide icon next to every heading. Safe and forgettable.

I went the other way:

Fraunces for the display serif (italic accent on in weeks)
JetBrains Mono for everything else
Warm off-white paper background with a faint radial-gradient grain
One emphasis color — terracotta — used sparingly
A magazine-style masthead bar at the top
Inputs are typewriter-style: serif text, single underline, no boxed fields

It looks more like a printed thing than a webapp. Which is the point — the output is a printed thing.

Privacy is the simple kind

There's no backend, no fetch to any server I control, no analytics, no cookies, no localStorage. Your name and birthdate never leave the browser tab.

The only network requests are Google Fonts and jsPDF from cdnjs. Neither receives the form data.

I didn't need a privacy policy because there's nothing to disclose.

Cost

GitHub Pages serves the file. The fonts are free. jsPDF is MIT. Total monthly cost: $0. I expect it to keep being.

Try it

Live: https://alicommit-malp.github.io/life-in-weeks/
Source: https://github.com/alicommit-malp/life-in-weeks (MIT)

Fork it, print it, gift it.

Introducing Tunnel Whisperer: Surgical Connectivity for Networks That Say "No"

Ali Alp — Fri, 06 Mar 2026 15:54:27 +0000

Your MRI scanner needs to talk to a cloud AI platform. Your vendor needs to reach a single maintenance port on a factory-floor PLC. Your data scientist needs to query an on-premise database from a cloud notebook. The firewall says no to all of them.

Tunnel Whisperer says yes.

Github page

The Problem Nobody Talks About

Enterprise networks are getting stricter. Firewalls block everything except port 443. Deep Packet Inspection kills anything that doesn't look like genuine HTTPS. Legacy devices — hospital scanners, industrial controllers, aging servers — can't run modern VPN clients. And even if you could install one, IT won't open a single inbound port.

This is the Connectivity Gap: the space between what your applications need and what your network allows.

Traditional solutions don't fit:

VPNs (WireGuard, Tailscale) require UDP ports or custom protocols — blocked by DPI.
Reverse proxies (ngrok) expose services to the public internet — a non-starter for healthcare and manufacturing.
SSH tunnels get flagged and dropped by next-gen firewalls.

We built Tunnel Whisperer to close this gap.

What Is Tunnel Whisperer?

Tunnel Whisperer is an open-source tool that creates resilient, port-to-port bridges across separated private networks. It wraps your TCP traffic inside a genuine TLS-encrypted HTTPS stream using Xray's VLESS+XHTTP protocol. To the network, it looks exactly like someone browsing a website.

Client Network             Public Cloud               Server Network
+--------------+        +------------------+        +--------------+
|  tw connect  |--443-->|     Relay VM     |<--443--|   tw serve   |
|              |  HTTPS |  Caddy + Xray    |  HTTPS |              |
| local ports  |        |  (reverse proxy) |        | SSH server   |
| :5432 :3389  |        |  Firewall: 80+443|        | port fwd     |
+--------------+        +------------------+        +--------------+

Your PostgreSQL client connects to localhost:5432. Your RDP client connects to localhost:3389. The traffic flows through an HTTPS tunnel to the server network, where it reaches the actual services. The applications on both ends have no idea a tunnel exists.

Why We Built It

We kept running into the same scenario: a customer with a legitimate connectivity need, a network that blocks everything, and no tool that threads the needle between "too broad" (VPN) and "too public" (ngrok).

Tunnel Whisperer is designed around three principles:

1. Surgical access, not broad connectivity. Each user gets access to exactly the ports they need — nothing more. No host-to-host networking, no route tables, no exposure of adjacent services.

2. Invisible to the network. The traffic is indistinguishable from regular HTTPS. No special ports, no unusual protocols, no signatures for DPI to flag.

3. Zero trust at the relay. The relay VM is a dumb pipe. It stores no SSH keys, no passwords, no application data. If it gets compromised, the attacker gets nothing useful — all plaintext remains encrypted by the SSH layer inside the tunnel.

How It Works: Three Layers of Encryption

Tunnel Whisperer stacks three encryption layers, each serving a different purpose:

Layer	What It Does
TLS 1.3 (outer)	Makes the traffic look like HTTPS. Caddy handles automatic Let's Encrypt certificates on the relay.
Xray VLESS + XHTTP (middle)	Routes users by UUID through the relay. XHTTP splits data into standard HTTP requests for resilience against connection timeouts.
SSH Ed25519 (inner)	End-to-end encryption between client and server. Public-key only — no passwords, no brute-force surface. Per-user `permitopen` restrictions lock each client to specific ports.

The relay terminates TLS but never sees the SSH-encrypted payload. Even if someone owns the relay, they can't read your data.

Real-World Use Cases

Healthcare: DICOM Through a Firewall

A hospital's MRI scanner needs to send images to a cloud AI platform for analysis. The scanner speaks DICOM on port 104 and can't install any software. Tunnel Whisperer runs on a gateway machine on the scanner's LAN, forwarding port 104 through the HTTPS tunnel to the cloud. The scanner sends to localhost:104 as if the AI platform were next door.

Manufacturing: Vendor Access to a Single Port

A machine vendor needs remote access to a PLC's maintenance port for diagnostics. Instead of a VPN that exposes the entire factory network, Tunnel Whisperer gives them access to exactly one port on one device. When the job is done, revoke the key — access gone.

Data Science: Cloud Notebook to On-Premise Database

A data scientist running Jupyter in the cloud needs to query a PostgreSQL database behind a corporate firewall. With Tunnel Whisperer, they connect to localhost:5432 and run queries as if the database were local. No VPN client, no firewall exceptions, no IT tickets.

Getting Started in 5 Minutes

Tunnel Whisperer ships as a single binary for Linux, Windows, and macOS. Build from source with Go 1.25+:

make build          # builds bin/tw

Server Side

tw dashboard                # open the web UI
tw create relay-server      # 8-step wizard: provision a relay VM
tw create user              # 5-step wizard: create a client with port restrictions
tw serve                    # start the server

The relay provisioning wizard handles everything: spinning up a VM on Hetzner, DigitalOcean, or AWS, configuring Caddy for TLS, installing Xray, and locking down the firewall to ports 80 and 443 only.

Client Side

The server admin sends you a config bundle (a zip file with your config and SSH keys). Then:

tw dashboard                # drag-and-drop the zip file
tw connect                  # you're in

That's it. Your configured ports are now available on localhost with automatic reconnection if the connection drops.

The Web Dashboard

Both server and client modes come with a browser-based dashboard for managing everything visually:

Server dashboard — create users, provision relays, monitor connected clients, stream logs in real-time, and open an interactive SSH terminal to the relay — all from the browser.

Client dashboard — upload config bundles, connect/disconnect with one click, and see your active tunnels with bandwidth stats.

No separate web app to deploy. The dashboard is embedded in the same tw binary.

Per-User Access Control

Every user gets:

A unique Xray UUID for relay routing
An Ed25519 key pair for SSH authentication
A permitopen directive restricting them to specific ports

# authorized_keys (auto-generated)
permitopen="127.0.0.1:5432",permitopen="127.0.0.1:3389" ssh-ed25519 AAAA... alice
permitopen="127.0.0.1:104" ssh-ed25519 AAAA... vendor-dicom

Alice can reach PostgreSQL and RDP. The vendor can reach the DICOM port. Neither can reach anything else. Revoking access is instant — remove the key from authorized_keys and the UUID from the relay config. No server restart needed.

Built for Resilience

Connections drop. Networks hiccup. Tunnel Whisperer handles it:

Auto-reconnection with exponential backoff (2s up to 30s max)
SSH keepalive every 15 seconds to detect dead connections early
XHTTP transport splits data into HTTP requests, surviving connection resets that would kill WebSocket-based tunnels
System service mode (tw service install) for auto-start on boot — Linux systemd, Windows SCM, or macOS launchd

Performance

We won't pretend there's zero overhead. Two relay hops and three encryption layers have a cost. Here are real numbers from our benchmarks (relay on Hetzner, ~30ms RTT):

Metric	Direct SSH	Tunnel Whisperer
Throughput (100 MB transfer)	112 MB/s	21 MB/s (~168 Mbps)
Database TPS (pgbench, 50 clients)	~1,790	~80-95
Database latency	~28 ms	~530-630 ms

Tunnel Whisperer excels at bulk transfers, streaming, and interactive sessions where human-speed interaction or continuous data flow hides the latency. For high-frequency RPC workloads with many small round-trips, you'll want to use connection pooling and place the relay geographically close to both endpoints.

The tradeoff is clear: you lose raw speed, but you gain connectivity where no other tool can get through.

How It Compares

	Tunnel Whisperer	VPNs (Tailscale/WireGuard)	Reverse Proxies (ngrok)
Scope	Surgical (port-to-port)	Broad (host-to-host)	Public (port-to-web)
DPI Resistance	High (genuine HTTPS)	Low (custom protocols)	Medium (standard HTTPS)
Deployment	Gateway/sidecar	Agent on every host	Dev/test
Infrastructure	Self-hosted	SaaS/hybrid	SaaS
Relay Compromise	No credential exposure	Varies	Provider-dependent

What's Next

Tunnel Whisperer is currently in alpha. The core tunnel, user management, dashboard, and multi-cloud relay provisioning are all working. Here's where we're heading:

UDP support for protocols that need it
Multi-relay topologies for geographic distribution
Observability — OpenTelemetry-format logging is already in progress
Pre-built binaries and package manager distribution

Get Involved

Tunnel Whisperer is MIT-licensed and open source.

GitHub: github.com/Tunnel-Whisperer/Tunnel-Whisperer
Documentation: tunnel-whisperer.github.io/Tunnel-Whisperer
Video Tutorial: Watch the walkthrough on YouTube

If you've ever stared at a firewall rule that blocks everything and thought "there has to be a better way" — give Tunnel Whisperer a try. We'd love your feedback, bug reports, and contributions.

Tunnel Whisperer — because sometimes the only way through is to whisper.

A practical, governance-first framework for turning your CI/CD pipeline into a secure, reproducible, and audit-defensible supply chain control point.

Ali Alp — Fri, 13 Feb 2026 13:56:25 +0000

SCRIPTED CI: Governing Your Build Pipeline as Critical Infrastructure

Ali Alp ・ Feb 13

#devops #cicd #security #productivity

SCRIPTED CI: Governing Your Build Pipeline as Critical Infrastructure

Ali Alp — Fri, 13 Feb 2026 13:50:52 +0000

CI/CD pipelines are amazing.

They build, test, package, sign, and ship our software in minutes. They automate what used to take days. They make modern development possible.

They also sit at one of the most dangerous control points in your entire system.

If you build regulated, safety-critical, or security-sensitive software, your CI pipeline is not “just automation.” It executes code, holds secrets, produces artifacts, and pushes to production.

That makes it part of your product’s trust boundary.

So the real question isn’t:

Is our application secure?

It’s this:

Is our build system defensible?

That’s where SCRIPTED CI comes in.

Why CI Is a Supply Chain Control Point

Most teams spend their security energy on:

Application security testing
API authentication
Infrastructure hardening
Runtime monitoring

All important.

But CI pipelines quietly:

Execute third-party code (GitHub Actions, plugins, integrations)
Access privileged credentials (cloud roles, signing keys, tokens)
Produce signed release artifacts
Modify repository state
Pull dependencies dynamically

If an attacker compromises your CI, they don’t need to break your runtime.

They can modify your build.

And if your build is compromised, your product is compromised.

That’s a supply chain problem.

The SCRIPTED Model

SCRIPTED is a governance-first way to think about CI security.
It turns abstract “best practices” into enforceable controls.

Letter	Principle	What It Means
S	Secure Secrets	Minimize and scope credentials in CI
C	Control Execution	Only run approved, immutable code
R	Repeatable Builds	Make builds deterministic
I	Isolated Runtime	Harden where builds execute
P	Policy Enforcement	Automate guardrails
T	Traceability	Make artifacts verifiable
E	Evidence	Be able to prove your controls
D	Defensible Design	Encode security in the system, not the process

Let’s walk through it.

S — Secure Secrets

CI pipelines often accumulate powerful credentials:

GITHUB_TOKEN with write access
Cloud deployment roles
Container registry credentials
Code signing certificates

The default mistake? Over-permissioned tokens.

Instead of this:

permissions: write-all

Do this:

permissions:
  contents: read
  packages: write

Other guardrails:

Don’t expose secrets to fork-based PR workflows
Use short-lived identities (OIDC) instead of static cloud keys
Separate build credentials from deployment credentials
Audit token usage regularly

If a job doesn’t need a permission, it shouldn’t have it.

Simple. Structural. Defensible.

C — Control Execution

CI runs code. Sometimes that code is yours. Sometimes it’s not.

Marketplace actions and plugins are convenient. They’re also external code entering your trust boundary.

This is unsafe:

uses: actions/checkout@v4

Why? Because tags can move.

This is safer:

uses: actions/checkout@8f4b7f84864484a7bf31766abe9204da3cbe65b3

Pin to a commit SHA.

That makes the reference immutable.

Stronger moves:

Mirror critical actions into your own org
Vendor high-risk actions locally
Maintain an allowlist of approved actions
Automatically fail builds that reference unpinned actions

Immutable references eliminate silent drift.

R — Repeatable Builds

If you rebuild a release from two years ago, do you get the same binary?

If not, you don’t have reproducibility.

And without reproducibility, you don’t have defensibility.

Instead of:

FROM node:latest

Use:

FROM node@sha256:...

Also:

Enforce lockfiles (go.sum, package-lock.json, etc.)
Pin toolchain versions
Eliminate dynamic dependency resolution
Avoid runtime internet downloads during build

Deterministic inputs must produce deterministic outputs.

Anything else is guesswork.

I — Isolated Runtime

Where your CI runs matters.

Public runners are convenient, but they are shared infrastructure.

For higher-assurance systems:

Use self-hosted runners
Make them ephemeral (destroy after each job)
Restrict outbound network access
Segregate runners by trust boundary

Treat CI runners as production infrastructure.

Because they are.

P — Policy Enforcement

Here’s a hard truth:

Guidelines are not controls.

A control that does not automatically fail is not a control.

If you say:

“All actions must be SHA pinned.”

Then enforce it.

Add a validation step that fails when:

An action is not pinned
Permissions are too broad
An unapproved marketplace action is referenced

Combine this with:

Branch protection
Required status checks
Policy-as-Code (OPA, Conftest, etc.)

Security must be encoded into the pipeline itself.

Otherwise, it will erode.

T — Traceability

For every artifact deployed to production, you should be able to answer:

What source commit built this?
What dependencies were included?
What toolchain was used?
Has it been modified since creation?

If you can’t answer those questions, incident response becomes speculation.

To fix that:

Generate an SBOM for every build
Produce cryptographic provenance (SLSA-style attestations)
Sign artifacts (Sigstore/Cosign)
Keep immutable build logs

This turns builds from opaque processes into verifiable records.

E — Evidence

Security that cannot be demonstrated does not exist.

In regulated environments, you will be asked to show:

How you control third-party execution
How you manage credentials
How you ensure reproducibility
How you maintain artifact lineage

So keep:

Architecture diagrams
Policy definitions
SBOM archives
Signature records
Audit logs

Evidence is not paperwork.
It’s proof of structural control.

D — Defensible Design

This is the outcome.

Not “we follow best practices.”

Not “we trust our team.”

Not “it should be fine.”

But:

Controls are enforced technically
Third-party execution is bounded
Privileges are minimized
Builds are deterministic
Artifacts are verifiable

You replace process-based assurances with structural guarantees.

That’s defensibility.

Phased Adoption (Don’t Boil the Ocean)

You don’t need to do everything at once.

Phase 1 — Baseline Risk Reduction (Weeks 1–4)

Pin all actions to SHAs
Reduce token permissions
Enable branch protection
Add basic workflow linting

Low effort. Immediate risk reduction.

Phase 2 — Structural Governance (Months 1–3)

Mirror critical actions internally
Introduce “Golden Workflows”
Enforce Policy-as-Code validation
Deploy ephemeral runners

Medium effort. Major risk reduction.

Phase 3 — Regulatory-Grade Assurance (Months 3–6)

Hermetic builds (no external network dependency)
SBOM for every artifact
Signed provenance attestations
Hardware-backed signing for releases

High effort. Audit-ready posture.

Why This Matters

CI pipelines:

Execute external code
Hold powerful secrets
Produce signed artifacts
Sit between source and production

They are part of your threat model.

In modern systems, the integrity of your product is inseparable from the integrity of its build process.

SCRIPTED CI isn’t about paranoia.

It’s about recognizing that the build is no longer a convenience layer.

It’s infrastructure.

And infrastructure must be governed.

If you’re operating in regulated environments, or just want to level up your supply chain security, I’d be curious:

Which part of SCRIPTED would be hardest to implement in your organization?

[Boost]

Ali Alp — Mon, 12 Jan 2026 17:39:36 +0000

A technical documentation to ultimate freedom in life

Ali Alp ・ Jan 12

#freedom

DEV Community: Ali Alp

Your GPUs Are Lying to You: The Brutal Economics of AI on Kubernetes

I rented an H100 to verify my hypothesis

Lie #1 — the metric

Fine, run something serious

Batch 64

The fields that don't lie

Lie #2 — the scheduler

Three honest ways to share a card

Lie #3 — the bill

Which metric does the bill follow?

Why does this issue persist in 2026?

What to do on Monday

The last thing

HTTP QUERY: Everything a Developer Needs to Know About HTTP's Newest Method

The problem: GET vs POST was always a bad trade

Meet QUERY

GET vs QUERY vs POST at a glance

The rules of the road

Discovery: Allow and the new Accept-Query header

Caching: the killer feature

Location, Content-Location, and the "equivalent resource"

Conditional requests work too

Redirects

Using it today

curl

JavaScript (fetch)

.NET 10 / ASP.NET Core 10

Node.js / Express

Graceful fallback

Gotchas and sharp edges

When to reach for QUERY

Wrap-up

References

"Where.Was.I" — a task board built around the moment you switch

The problem it solves

What it deliberately does not do

Using it

The board

Naming the workspace

Writing notes

Undo, because instant shouldn't mean irreversible

Staying in sync across tabs

Keyboard

On a phone

Finishing and finding things

How it's built

The data model

State flow

Local-first, on purpose

Where it goes next

Try it

[Boost]

Why Event-Driven Architecture Isn’t About Speed (and When You Actually Need It)

Why Event-Driven Architecture Isn’t About Speed (and When You Actually Need It)

1. "Real-Time" is a Spectrum, Not Pure Speed

2. The Overkill Trap: When to Actually Deploy EDA

3. Conway’s Law Wins Every Time

4. Why AI and EDA Are Perfect Partners

Cut Through the Noise

How I built one Manifest V3 extension that runs on Chrome, Edge, and Firefox

What it does

One manifest, three engines

Catching short-form feeds

One CSS path for videos and images

Re-muting hostile sites

The decision flow

What I didn't (yet) solve

Try it

Did you ever wondered to see your whole life in one page calendar ?

I built a 'life in weeks' poster generator in one HTML file

I built a 'life in weeks' poster generator in one HTML file

Why one file?

Drawing 5,200 circles fast

Keeping the PDF honest

The layout is height-constrained — and that's a feature

Adding pets

Going against the SaaS look

Privacy is the simple kind

Cost

Discovery: `Allow` and the new `Accept-Query` header

`Location`, `Content-Location`, and the "equivalent resource"