Short answer: all three agents deployed the app, unaided, in a sandbox with no hints and no custom instructions file. None of them failed on the platform. They all lost time on the same five rough edges in the CLI and the install script, and those are the interesting part.

We shipped the Hostim CLI this month. It was written with coding agents as first-class users, and dogfooded by deploying 30 open-source apps with it. Then I tested whether that actually works, by handing the job to agents that had never seen it.

Short answer: Traefik v3.7's kubernetesIngressNGINX provider reads Ingresses on the ingress-nginx class and translates its annotations, so the cutover itself is a load balancer IP handover — no annotation rewrite across your Ingresses, no dual-IngressClass trick. What it does not cover is the ingress-nginx controller configuration: TLS redirect, global error pages, the default certificate, auth annotations after you switch class. Those you port by hand.

We moved a production cluster on 23 August 2026: many Ingresses, multi-tenant, customer apps. Here is what we did and what it cost.

Short answer: beacon.min.js is Cloudflare's Real User Measurement script. If your domain is on a free Cloudflare plan and proxied through them (the orange cloud), Cloudflare has been injecting it into your HTML by default since September 2025 — you did not add it, it is not in your repo, and it arrives before your page reaches the browser. Paid plans are opt-in only. You turn it off in Analytics & Logs → Web Analytics → Manage Site → Advanced Options → JS Snippet injection.

Two things are worth separating here, because the thread that put this on the front page of Hacker News this week mixed them together:

1. The GDPR panic is mostly overstated. The default configuration excludes EU visitor data. Cloudflare's own words, from the thread: "we will not collect any RUM metrics from traffic that passes through our European and UK data centers."
2. The consent problem is real anyway, and it is a different problem. The beacon is injected at the edge, so it lands on the page before your consent management platform gets to run. There is nothing for your CMP to gate. That is true regardless of who the visitor is.

I run a hosting company, so treat me accordingly — I have an obvious interest in you thinking hard about what your platform does to your bytes. That is exactly why I want to be careful with the facts rather than loud about them.

Short answer: one "hello world" container with a domain and HTTPS costs about $32 per month on AWS if you set it up carefully, and about $69 per month if you follow the default AWS tutorial. The same thing on a small Hetzner Cloud server costs €5.99 per month. Bare metal is the surprising one. A Hetzner AX42-1 costs €97.30 per month, which makes it the most expensive option here, not the cheapest.

Two results are worth explaining, and neither is what people usually say:

1. Compute is not the expensive part on AWS at this size. In the realistic setup, the container is 15% of the bill. The other 85% is the load balancer and the NAT gateway. Those cost the same whether you serve one request per month or a million.
2. Bare metal is not cheap. It is cheap per app. A dedicated server only pays off when you fill it. For one container it is a bad deal.

Short answer first: at the same size (2 vCPU / 4 GB, PostgreSQL 16), Hostim had the fastest writes, about 2.5× the write throughput of AWS RDS db.t4g.medium and 2.1× a default self-hosted Postgres on Hetzner. Hetzner had the fastest reads, on raw per-core CPU speed. RDS was slowest or near-slowest on both, and its listed price is the smallest part of the real bill.

This post shows every number, the exact commands to reproduce them, and (because it changes the conclusion) what high availability actually costs on each platform.

Short answer first: the three platforms charge in three different shapes. Render adds a workspace fee for teams on top of fixed instance prices. Railway has no free tier and meters everything per second on top of a small plan fee. Fly.io is pure pay-as-you-go per second, with no base plan fee at all. The right pick depends less on the headline price and more on which of those shapes fits how you work.

This post explains each model, shows a side-by-side table, and gives the cases where each one wins.

Supabase is PostgreSQL with a backend bolted on. Every Supabase project is a real Postgres database; the difference is the layers around it — authentication, realtime websockets, file storage, edge functions and a web dashboard with an auto-generated API. Plain PostgreSQL is the database on its own.

So use Supabase if you want Postgres plus auth, realtime, storage, and a dashboard as one managed bundle. Self-host Postgres – or use a managed Postgres – if you mostly need a database and your app already handles its own auth and logic. The choice is not really "Postgres vs Supabase". It's whether you need the extra layers Supabase puts on top of Postgres.

This post gives you a clear way to decide, a side-by-side table, and the cases where each option is the right one.

Usage-based pricing always looks cheap on the signup page. "Pay only for what you use." "Starts at $5." Then a few months in, your bill is double what you guessed, and you can't really point at the one thing that did it.

I've been comparing platforms a lot lately – partly because I run one, partly because people keep emailing me to ask whether X or Y is cheaper than Hostim. So here's the actual math on why metered hosting drifts upward over time, and the honest version of when it's the better deal anyway.

If you run Kubernetes and want a wildcard TLS cert from Let's Encrypt — say *.example.com — you need a DNS-01 challenge. HTTP-01 cannot prove control over a wildcard. That single fact rules out the easy path most tutorials show.

This post is what we actually run at Hostim.dev for our shared *.region.hostim.dev wildcard. We use cert-manager for per-app certs and a plain certbot Ansible playbook for the wildcard. Two different tools for two different jobs. We will explain why, then show the code for both.

Most small teams hit the same question at some point: should we move to Kubernetes? The honest answer for the majority of them is no, but that answer alone is not very helpful. So here is the longer version, with real prices and a clear line where the answer flips to yes.