DEV Community: Pavel

Migrating a Production Cluster Off ingress-nginx to Traefik v3

Pavel — Mon, 31 Aug 2026 14:43:32 +0000

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.

Why we moved, and why we waited

ingress-nginx is retired upstream and has not received patches since March 2026. Running an unpatched component in the request path of every customer app is not a position you can hold indefinitely, so the move was going to happen.

We waited about six months anyway. Being early on a migration like this means finding the bugs yourself and writing the guide instead of reading it. There was no upside to going first: ingress-nginx kept working the whole time, and every month of waiting meant more people had hit the sharp edges before us and written them down. That trade only stops making sense once the security exposure outweighs it.

Why Traefik

Our general rule is to stay close to Kubernetes best practice rather than pick something clever. If upstream converges fully on Gateway API, we want to follow without another migration.

That is most of the reasoning:

Mature. Long track record as an ingress controller, not a recent entrant.
Supports both Ingress and Gateway API. We run Ingress today. The option to move to Gateway API later without changing controllers again is the point.

The ingress-nginx compatibility provider was a bonus we found while planning, not the reason for the choice. It did make the cutover much cheaper than it would otherwise have been.

How the cutover worked

Traefik v3.7 added providers.kubernetesIngressNGINX. It serves Ingresses whose IngressClass object names the ingress-nginx controller, and translates the nginx.ingress.kubernetes.io/* annotations itself:

providers:
  kubernetesIngressNGINX:
    enabled: true
    controllerClass: "k8s.io/ingress-nginx"
    ingressClass: "nginx"
    defaultBackendService: "traefik/default-backend"
    publishService:
      enabled: true

With that enabled, every existing Ingress — including the ones our operator generates for customer apps and cert-manager's HTTP-01 solver Ingresses — needed no edit. Deploy Traefik alongside ingress-nginx, then move the MetalLB load balancer IP from one Service to the other. That is the cutover.

It does not overlap with the normal kubernetesIngress provider: that one matches only IngressClass objects naming Traefik's controller, this one only k8s.io/ingress-nginx. We left it enabled after the migration. Turning it off means editing every Ingress in the cluster to buy nothing, and it keeps a rollback cheap.

What we ported by hand

The compatibility provider covers Ingress annotations. It does not cover what was configured on the ingress-nginx controller itself, and it stops applying to any Ingress the moment you switch that Ingress to ingressClassName: traefik. Four things needed doing.

Basic auth on platform endpoints

Our internal services were protected with:

nginx.ingress.kubernetes.io/auth-type: basic
nginx.ingress.kubernetes.io/auth-secret: internal-basic-auth

Traefik's native provider does not implement these annotations. It does not error and it does not fall back — the router is created without authentication. So the Middleware has to exist before the class flips, not after:

apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: internal-basic-auth
  namespace: internal
spec:
  basicAuth:
    secret: internal-basic-auth-traefik
    realm: "Authentication Required"

referenced from the Ingress:

annotations:
  traefik.ingress.kubernetes.io/router.middlewares: "internal-internal-basic-auth@kubernetescrd"

Two details. Traefik reads the key users, ingress-nginx reads auth. And Traefik's BasicAuth rejects a Secret with more than one key (must be single element exactly), so you cannot just add a second key to the existing Secret — we created a separate -traefik Secret and left the original intact for rollback.

Global error pages

ingress-nginx has custom-http-errors in the controller ConfigMap. Traefik has no global equivalent: errors are a Middleware, and the compatibility provider only honours the per-Ingress annotation. We serve a branded page for stopped, broken or suspended apps, and we are not going to add an annotation to every Ingress the operator generates, so the Middleware hangs off the entrypoint instead:

apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
  name: errorpage
  namespace: traefik
spec:
  errors:
    status:
      - "503"
    service:
      name: default-backend
      port: 80
    query: "/"

ports:
  web:
    http:
      middlewares:
        - traefik-errorpage@kubernetescrd
  websecure:
    http:
      middlewares:
        - traefik-errorpage@kubernetescrd

This needs providers.kubernetesCRD.allowEmptyServices: true. Without it, a Service with no endpoints returns 404 rather than 503, and the Middleware never fires.

Unknown hostnames are a separate mechanism: defaultBackendService on the compatibility provider, replacing ingress-nginx's defaultBackend.

The default certificate

ingress-nginx serves a fallback certificate via --default-ssl-certificate. We rely on it: the operator leaves the built-in app domains out of the Ingress TLS block on purpose, because a wildcard covers them.

In Traefik this is a TLSStore named default, and the Secret must live in Traefik's namespace:

tlsStore:
  default:
    defaultCertificate:
      secretName: wildcard-tls

Miss it and those hostnames are served Traefik's own self-signed certificate. Nothing in the control plane reports an error; the failure is a browser warning.

Metrics and dashboards

Metric names change completely: nginx_ingress_controller_* becomes traefik_service_* and traefik_entrypoint_*. Traefik's ServiceMonitor relabels its own service label to exported_service, so panels grouping by service have to group on that instead. Our networking dashboard was empty until it was rewritten — worth knowing in advance so nobody reads blank panels as an outage.

One setting we deliberately did not port: proxy-body-size: 50m. Traefik does not limit request body size by default.

What went wrong

ingress-nginx redirects HTTP to HTTPS by default. Traefik does not, and nothing in the cutover carried that behaviour across. Every app in the cluster answered on port 80 in cleartext. Nothing was down, no health check failed, and traffic on 443 looked normal — plain HTTP was simply being served instead of redirected.

Our monitoring caught it, because it checks for the redirect. The fix belongs at the entrypoint rather than per Ingress:

ports:
  web:
    http:
      redirections:
        entryPoint:
          to: websecure
          scheme: https
          permanent: true

It does not break certificate issuance — both Let's Encrypt and cert-manager 1.21 follow the redirect during HTTP-01 without validating the certificate at the target.

The general lesson is not about Traefik. Controller-level defaults are invisible in your manifests, so a migration diff of your Ingresses shows nothing missing. What ingress-nginx did for you by default is exactly what nobody wrote down.

Uninstalling ingress-nginx

Do it through Helm, before removing the namespace.

Its admission webhook is cluster-scoped with failurePolicy: Fail on every Ingress CREATE and UPDATE. If you delete the namespace and orphan the webhook, every Ingress and certificate change in the cluster stops working, cert-manager's included. The chart removes the webhook in the right order. kubectl delete ns does not.

Checklist

Before switching any IngressClass to traefik:

Auth annotations on that Ingress → Middleware created first, same namespace, single-key users Secret.
TLS redirect → entrypoint redirection configured.
Custom error pages → entrypoint Middleware plus allowEmptyServices: true.
Default certificate → TLSStore/default, Secret in Traefik's namespace.
Dashboards and alerts on nginx_ingress_controller_* → rewritten.
Body size and timeout tuning from the nginx ConfigMap → re-applied if you need it.

After the cutover, check the redirect and the auth explicitly rather than trusting a green rollout:

curl -sI http://app.example.com/ | head -1                       # expect 308
curl -o /dev/null -w '%{http_code}\n' https://internal.example.com/  # expect 401

And confirm the certificate served on a domain that has no TLS block of its own is your wildcard, not the controller's self-signed default.

FAQ

Is ingress-nginx dead?
Retired upstream, unpatched since March 2026. It keeps running; security fixes are not coming.

Do I have to rewrite my nginx annotations to move to Traefik?
No. Traefik v3.7+ ships providers.kubernetesIngressNGINX, which serves Ingresses on the ingress-nginx class and translates its annotations. Controller-level configuration is not covered.

What breaks when I switch an Ingress from class nginx to class traefik?
Anything relying on an annotation the native Traefik provider does not implement. Auth annotations are the one to check first: the endpoint is served without authentication rather than erroring.

Does an HTTP-to-HTTPS redirect break Let's Encrypt HTTP-01?
No. Let's Encrypt and cert-manager follow the redirect and do not validate the certificate at the target.

How do I uninstall ingress-nginx safely?
Through Helm, before deleting the namespace. Its cluster-scoped admission webhook has failurePolicy: Fail, so orphaning it blocks every Ingress change in the cluster.

If you would rather not run any of this yourself, that is the point of Hostim — you push a container, we run the ingress, the certificates and the cluster underneath. EU-hosted, flat monthly price.

👉 Deploy an app on Hostim, free 5-day trial, no card

We're building Hostim.dev to make this simpler, and we are happy to answer any questions.

Last updated: 31 August 2026. Versions: Traefik chart 41.3.0 (v3.7.11), cert-manager 1.21. Configuration snippets are from our production cluster, trimmed for readability. Check the Traefik documentation for the current list of translated ingress-nginx annotations before planning your own cutover.

What Is beacon.min.js? Cloudflare's Auto-Injected Analytics, and How to Turn It Off (2026)

Pavel — Mon, 17 Aug 2026 11:07:20 +0000

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:

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."
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.

What actually happens

Someone moved their nameservers to Cloudflare and later found a 31KB JavaScript file executing on a site they had deliberately built with no JavaScript at all — which sounds like a compromise until you read the docs and realise it is just what the free plan does.

The mechanism matters more than the outrage:

Injection happens at the edge, in Cloudflare's proxy, on the way to the visitor. Your origin server sends HTML without the script; the visitor receives HTML with it.
It only applies to proxied records — orange cloud. DNS-only records pass through untouched.
With automatic setup and no Rules configured, it goes on every page of every subdomain in the zone, not just the pages you were thinking about.
When auto-injected on a proxied domain, the beacon reports to /cdn-cgi/rum on your own domain, so it does not show up as a third-party request in the obvious place you would look for one.

That last detail is the one I would have missed. A quick scan of third-party domains in your network tab does not catch it.

Is Cloudflare's beacon a GDPR problem?

Probably not in the default configuration, and I would rather say that plainly than farm the fear.

Here is what Cloudflare stated in the discussion, verbatim: "The version of Web Analytics that will be enabled by default excludes data from EU visitors (this can be changed in the dashboard if you want)." And: "you can choose to drop requests from European and UK visitors if you so desire... we will not collect any RUM metrics from traffic that passes through our European and UK data centers."

So if you are an EU business serving mostly EU visitors, the default posture is that the measurement is not collected for them. That is a genuinely more thoughtful default than "collect everything and let the customer sort it out."

What that statement does not settle — and what I could not confirm from Cloudflare's public documentation either way — is whether the script is still served and executed in EU visitors' browsers while the metrics are discarded on Cloudflare's side. "We do not collect" and "we do not inject" are different promises, and only one of them was made. If that distinction matters for your compliance posture, check it on your own domain rather than taking my word or theirs. The command is in the next section.

The consent point stands separately from all of this. Edge injection cannot be gated by a consent banner that has not loaded yet, so any tag-governance story you tell your auditors has a hole in it while automatic injection is on.

How to check what your host injects

This is the part worth keeping regardless of which platform you are on. Ask your origin for the page, then ask the public internet for the same page, and compare.

# 1. What your server actually sends (replace with your origin IP)
curl -s --resolve example.com:443:203.0.113.10 https://example.com/ > origin.html

# 2. What a visitor actually receives
curl -s https://example.com/ > edge.html

# 3. Anything your origin never wrote
diff origin.html edge.html

For the specific case, a direct grep is enough:

curl -s https://example.com/ | grep -oE 'cloudflareinsights|beacon\.min\.js|/cdn-cgi/rum'

Empty output means nothing is being injected on that path. Any hit means something is editing your HTML between your server and your users.

Worth running against a few different paths, not just /. Rules can scope injection to a subset of pages, so the homepage being clean does not prove much on its own.

Turning it off

In the Cloudflare dashboard:

Analytics & Logs → Web Analytics
Manage Site on the domain
Expand Advanced Options
Toggle off JS Snippet injection

If you actually want the performance data — and RUM data is genuinely useful, that part of Cloudflare's argument is fine — disable the automatic injection and add the snippet yourself. Then it is a tag like any other tag: your CMP can gate it, your CSP applies to it, and it is visible in your repository where the next person can find it.

One quirk to know before you go looking: several people reported having to enable Web Analytics first in order to reach the switch that turns the injection off.

What Cloudflare collects, and for how long

Thing	Detail
Script	`beacon.min.js`, roughly 31KB, from `static.cloudflareinsights.com`
Reporting endpoint	`/cdn-cgi/rum` on your own domain when auto-injected
Default on	Free plans, since September 2025
Default on paid plans	No — opt-in only
EU/UK visitors	Excluded from collection in the default configuration
Raw data retention	Unsampled for 7 days, then aggregated down to roughly 10%
Scope with automatic setup	Every page and subdomain in the zone, unless Rules narrow it

The part I actually care about

The reason this landed on the front page is not that RUM is sinister. It is that the boundary moved without anyone noticing, and a free plan turned out to include a term nobody read.

It rhymes with the other platform stories I keep writing about — Netlify moving to credit pricing, or metered bills that drift upward month after month — in the sense that the platform changes something in the middle of your stack, the change turns out to be perfectly defensible once you go and read the docs, and you find out about it later than you would have liked. The free tier is usually where it lands first, because that is where the leverage is and where nobody is reading a contract.

I do not think Cloudflare did anything villainous here. Their EU default is more careful than most, and their engineer showed up in the thread and answered directly, which is more than most companies manage. But "on by default for the people who are not paying, opt-in for the people who are" is a choice, and it is worth seeing it clearly rather than being annoyed at it vaguely.

Since it would be cowardly to write this without stating our own position: Hostim does not modify customer response bodies. The ingress in front of your app sets one annotation, x-forwarded-proto: https, which is a request header going towards your container — no sub_filter, no snippet injection, nothing added to what you send back. You do not have to take my word for it, and you should not: run the same diff from the section above against your own Hostim app. If it ever comes back non-empty, that is a bug and I want to hear about it.

FAQ

What is beacon.min.js?
It is Cloudflare's Real User Measurement (RUM) script, about 31KB, served from static.cloudflareinsights.com. It measures page performance in real visitors' browsers and reports back to Cloudflare.

Why is beacon.min.js on my site when I never added it?
Because Cloudflare injects it at the edge. Free plans have this on by default since September 2025 for domains proxied through Cloudflare (orange cloud). It never touches your source code, so it will not appear in your repository.

How do I disable Cloudflare's automatic beacon injection?
Cloudflare dashboard → Analytics & Logs → Web Analytics → Manage Site → Advanced Options → toggle off JS Snippet injection. You may need to enable Web Analytics first before the toggle is reachable.

Does the Cloudflare beacon violate GDPR?
In the default configuration Cloudflare states it does not collect RUM metrics from traffic through its European and UK data centres, so the collection concern is largely addressed. The separate, unresolved issue is consent management: because the script is injected at the edge, it loads before your consent platform can gate it.

Is Cloudflare Web Analytics injected on paid plans too?
No. Cloudflare states all paid plans are opt-in only. The default-on behaviour applies to free plans.

How do I see what my hosting provider injects into my pages?
Fetch the page from your origin and from the public URL, then diff the two. Anything present in the second and absent in the first was added in transit. There is a copy-paste version of this above.

If you would rather your hosting provider just serve what you gave it, that is roughly the whole design philosophy behind Hostim — your container, your bytes, a flat monthly price, hosted in the EU. New projects get a free 5-day trial, no card.

👉 Deploy an app on Hostim, free 5-day trial, no card

We're building Hostim.dev to make this simpler, and we are happy to answer any questions.

Last updated: 17 August 2026. Cloudflare's quoted statements are from its engineer's replies in the Hacker News discussion on 16 August 2026; the beacon endpoint, sampling and retention details are from Cloudflare's Web Analytics documentation, checked 17 August 2026. Defaults change — verify against your own dashboard before relying on any of this.

Originally published on hostim.dev.

What Does 'Hello World' Actually Cost on AWS vs Bare Metal? (2026)

Pavel — Mon, 03 Aug 2026 15:39:51 +0000

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:

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.
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.

How I priced this

Here is the method first. Every rate below links to the vendor price list, and the arithmetic is shown, so you can check any line yourself.

The workload: one container running a web app, one replica, reachable on your own domain over HTTPS. No database, no background jobs, almost no traffic. This is the thing you deploy on day one to check that the pipeline works.

What I measured: list price for the simplest working setup on each platform, in Europe, for one month (730 hours). Not performance. Not a tuned setup, and not a setup with commitments.

What I left out: VAT, CloudWatch logs, your own time, and discounts from AWS Savings Plans. Savings Plans do lower the Fargate line. They do not apply to the Application Load Balancer or the NAT gateway, and that is where most of the AWS money goes here. A commitment lowers the small number, not the big one.

Rates are AWS eu-central-1 (Frankfurt) and Hetzner Falkenstein/Helsinki, as published on 3 August 2026. EUR to USD at 1.1535 (ECB reference rate, 3 August 2026).

What does one container cost on AWS Fargate?

Here are two versions. The difference between them is the interesting part.

The cheapest AWS setup that still works

Fargate on ARM. The task sits in a public subnet with its own public IP, so there is no NAT gateway.

Line item	Arithmetic	Monthly
Fargate ARM, 0.25 vCPU	0.25 × $0.03725 × 730	$6.80
Fargate ARM, 0.5 GB RAM	0.5 × $0.00409 × 730	$1.49
Application Load Balancer, base	$0.027 × 730	$19.71
Public IPv4 address	$0.005 × 730	$3.65
Route 53 hosted zone	flat	$0.50
Data transfer out	under the 100 GB free allowance	$0.00
ECR image storage	under the 500 MB free tier	$0.00
Total		$32.15 (about €27.87)

The container is $8.29 of that total. The load balancer alone costs more than twice as much as the container.

The setup you get from the tutorials

Fargate on x86. The task sits in a private subnet behind a NAT gateway, which is what the CDK and the console give you by default. I also added one load balancer capacity unit for real traffic.

Line item	Arithmetic	Monthly
Fargate x86, 0.25 vCPU	0.25 × $0.04656 × 730	$8.50
Fargate x86, 0.5 GB RAM	0.5 × $0.00511 × 730	$1.87
Application Load Balancer, base	$0.027 × 730	$19.71
ALB capacity units	1 LCU × $0.008 × 730	$5.84
NAT gateway, hourly	$0.045 × 730	$32.85
NAT gateway, data processing	5 GB × $0.045	$0.23
Route 53 hosted zone	flat	$0.50
Total		$69.50 (about €60.25)

The NAT gateway costs more than everything else together, including the app you want to run. Its job is to let your container reach the internet from a private subnet. For a hello world you get very little back for that money, and it is switched on by default in most getting-started guides.

Sources: AWS Price List API, AmazonECS eu-central-1 (published 7 July 2026), AWSELB eu-central-1 (20 July 2026), AmazonVPC eu-central-1 (24 July 2026), Route 53 (27 May 2026), VPC pricing, ECR pricing, EC2 on-demand pricing.

What does the same container cost on a VPS?

A Hetzner Cloud CX23 has 2 vCPU, 4 GB RAM, 40 GB disk and 20 TB of included traffic. You run Docker on it, plus Caddy for automatic TLS.

Line item	Monthly
CX23 instance	€5.49
Primary IPv4	€0.50
Total	€5.99 (about $6.91)

That is about one tenth of the realistic AWS bill, on a machine with 8 times the RAM and 8 times the vCPU count of the Fargate task. In exchange you lose managed TLS renewal, health checks and rolling deploys. You now do those yourself. For one hello world that is maybe an afternoon of Caddy config and a systemd unit.

These prices changed recently. Hetzner raised prices on 15 June 2026, and the increases were very uneven:

Plan	Old	New	Change
CX23	€3.99	€5.49	+38%
CAX11 (ARM)	€4.49	€5.99	+33%
CPX22	€7.99	€19.49	+144%
CCX13 (dedicated vCPU)	€15.99	€42.99	+169%

The cheap shared-vCPU plans went up a little. The dedicated-vCPU plans almost tripled. If you remember Hetzner prices from before June, check the specific plan again before you budget with it. Sources: Hetzner price adjustment notice (last changed 8 July 2026) and Hetzner IPv4 pricing.

Is bare metal cheaper than AWS?

For one container, no.

A Hetzner AX42-1 dedicated server costs €97.30 per month plus a €49 one-time setup fee, without IPv4 (same price list). That is €112.24 in the first month and €97.30 after that. It costs more than the $69.50 AWS bill it is supposed to beat.

Bare metal wins on density, not on price. The arithmetic is simple. At €97.30 against €5.99, a dedicated server has to replace about 16 small cloud instances before it breaks even. Below that number you pay for capacity you do not use.

So the rule is:

1 app: use a VPS, or a platform that bills per app.
A few apps: still a VPS, maybe a bigger one.
Dozens of apps, or heavy steady load: now bare metal is the cheap option, and the saving is large.

If someone tells you bare metal is cheaper without asking how many workloads you run, the number they give you is not useful.

Everything side by side

Setup	Monthly	In USD	What you manage
AWS Fargate, cheapest working setup	€27.87	$32.15	IAM, task definitions, ALB, DNS
AWS Fargate, default tutorial setup	€60.25	$69.50	the same, plus a NAT gateway
Hetzner CX23 + IPv4	€5.99	$6.91	the whole machine: OS, TLS, deploys, patching
Hetzner AX42-1 bare metal	€97.30 (+€49 setup)	$112.24 (+$56.53)	the whole machine, plus hardware failure planning
Hostim sa-1-1	€2.50	$2.88	your container

All prices exclude VAT.

Why is the AWS bill shaped like this?

Because AWS sells you separate parts, and a working web app needs about six of them. Each part is cheap on its own and does a sensible job. The load balancer is a good load balancer. The NAT gateway solves a real problem. But hello world needs all six, and the five that are not compute do not get cheaper when your traffic is zero.

That is the real lesson, and it applies no matter who you buy from. At small scale you are not paying for capacity. You are paying for fixed infrastructure. To make a small deployment cheap, do not buy that infrastructure separately. Either put it all on one machine yourself, or use a platform that spreads the cost across all its customers.

It also means the common advice to pick a smaller instance does not help here. Halving the Fargate task saves $4. Removing the NAT gateway saves $33.

We looked at the version of this problem that shows up later, when the app is real, in Cloud Rent in Action: How €50 Turns Into €200+ and Render vs Railway vs Fly.io pricing.

Frequently asked questions

Do AWS Savings Plans fix this?
They lower the Fargate line. They do not apply to the Application Load Balancer, the NAT gateway or Route 53, which together are 85% of the realistic bill. A three-year commitment changes the small number, not the big one.

Can I avoid the NAT gateway?
Yes. Put the task in a public subnet with a public IP, which is the cheapest setup in the table above. It saves about $33 per month and is fine for a stateless container. It is not the default, and most tutorials will not do it for you.

Does the AWS free tier cover this?
Partly, and only for 12 months. New accounts get 750 hours of ALB and some Fargate allowance, so the first year is cheaper. The bill above is what you pay in month 13. That is the number to plan with.

What about Lambda instead of Fargate?
For workloads that are idle most of the time, Lambda with an HTTP API gateway avoids both the ALB and the NAT gateway, and a hello world can cost close to nothing. The trade-off is a different execution model: cold starts, a 15-minute limit, and rewriting your container as a handler. Good for small services with occasional traffic. It is not a drop-in replacement for a running app.

Is €2.50 real, or is there a metered surprise?
It is flat. Hostim bills per plan, not per request, per GB or per seat. The pricing model doc has the full tables. The honest trade-off is different: it is a small, founder-led platform, so weigh the track record and the support scale, not the feature list.

The short version

One hello world on AWS costs $32 to $69 per month. 74% to 85% of that is the load balancer and the NAT gateway, not compute.
The same thing on a €6 VPS is about 10 times cheaper, and you manage the machine yourself.
Bare metal costs €97.30 per month. It is the wrong tool for one app and the right tool for sixteen.
Hetzner's June 2026 price rise hit the dedicated-vCPU plans hardest (+144% to +169%). The cheap shared plans went up much less (+33% to +38%).

What does your hello world cost? If you have a real bill that contradicts any of these lines, I would like to see it.

I run Hostim.dev, a flat-price container hosting platform in the EU. This post was originally published on our blog.

PostgreSQL Benchmark: AWS RDS vs Hostim vs Self-Hosted on Hetzner (2026)

Pavel — Tue, 07 Jul 2026 11:04:02 +0000

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.

Benchmarks run July 2026 on PostgreSQL 16, in a central-Europe region. Prices change often, so check each provider's live pricing page before you commit. The shape of the result changes far less than the exact numbers.

What we compared

Three ways to run a small production Postgres, all at 2 vCPU / 4 GB RAM, PostgreSQL 16, in a central-Europe region:

Offering	Instance	Listed price / month	Replicated (failover)?
Hostim managed Postgres	`drp-50` (2 vCPU / 4 GB)	€50	Yes, by default
AWS RDS	`db.t4g.medium` (2 vCPU / 4 GB)	~$48 (instance only)	No (single-AZ)
Self-hosted	Hetzner CPX22 (2 vCPU AMD / 4 GB, shared)	€19.49	No (single node)

The "replicated" column matters a lot for both price and performance. It gets its own section below.

Methodology

The goal was a like-for-like test, not a flattering one. The rules:

Same DB size: 2 vCPU / 4 GB on every target.
Same Postgres major version: 16.
A separate load generator per target, one network hop from the database, in the same region, never on the database box itself. Each client had 4 vCPU so the client was never the bottleneck (checked with mpstat).
Same workload: pgbench, scale factor 50 (about 750 MB, which fits in RAM so the test measures CPU and the commit path, not cold disk reads), 300-second runs.

Client setup:

sudo apt-get install -y postgresql-contrib nmap sysstat   # pgbench + nping
pgbench --version

The workload, run identically against each database:

# initialise (~750 MB)
pgbench -i -s 50

# write-heavy, TPC-B-like, 4 clients, 5 minutes
pgbench -c 4 -j 4 -T 300

# read-only, 8 clients, 5 minutes
pgbench -c 8 -j 4 -T 300 -S

# single connection, write, 1 minute (isolates commit/fsync latency)
pgbench -c 1 -T 60

Network latency was measured with a TCP ping to port 5432 (nping --tcp -p 5432) and a SELECT 1 round-trip, because ICMP is not open on every platform.

Configuration parity, stated plainly: the self-hosted Hetzner node ran stock Postgres defaults (shared_buffers 128 MB, no tuning). That is the realistic "install Postgres and go" baseline. RDS ran on its default parameter group, which AWS tunes for the instance size. Hostim runs its own managed tuning. In other words, the two managed options are tuned out of the box and the self-hosted default is not, and that difference is part of what you are comparing.

Results

All runs completed with zero failed transactions.

Write throughput (4 clients, TPC-B)

Target	TPS	Avg latency
Hostim `drp-50`	2,708	1.48 ms
Hetzner (default)	1,303	3.07 ms
AWS RDS `t4g.medium`	1,080	3.71 ms

Hostim did about 2.5× the write throughput of RDS and 2.1× the default Hetzner node.

Single-connection write latency (1 client)

This isolates the commit path. Every transaction waits for a WAL flush (synchronous_commit = on is the default), so it mostly measures storage fsync latency.

Target	TPS	Avg latency
Hostim `drp-50`	871	1.15 ms
AWS RDS `t4g.medium`	416	2.41 ms
Hetzner (default)	276	3.63 ms

Both self-hosted and RDS pay for network-attached block storage on the commit path. This is the single biggest driver of the write-throughput gap.

Read throughput (8 clients, SELECT-only)

Target	TPS	Avg latency
Hetzner (default)	20,068	0.40 ms
Hostim `drp-50`	14,333	0.56 ms
AWS RDS `t4g.medium`	13,261	0.60 ms

Reads scale with CPU, and the Hetzner box took this one on raw per-core AMD speed with no orchestration layer in the path. Hostim and RDS were close, with RDS last. Note that db.t4g.medium is a burstable instance: over a sustained 300-second run it can drop to its CPU-credit baseline, which is what the ~$48 tier is designed to provide. A workload that needs sustained CPU would move to an m-class RDS instance, which costs roughly twice as much.

Network latency

Target	TCP RTT (avg)	`SELECT 1`
Hostim `drp-50`	0.48 ms	~0.29 ms
Hetzner (default)	0.71 ms	~0.39 ms
AWS RDS `t4g.medium`	1.50 ms	~0.58 ms

The price you actually pay

This is where the listed numbers stop being useful.

AWS RDS: $48 is not the bill

The ~$48 is the instance only, single-AZ, on-demand. On top of that you pay, metered separately:

Storage: gp3 is billed per GB-month.
IOPS and throughput above the gp3 baseline: billed if you provision more.
Backups: retained backup storage beyond your volume size is billed.
Data transfer: egress and cross-AZ traffic are billed per GB.

One storage dropdown makes this concrete. Pick Provisioned IOPS SSD in the create-database wizard and RDS defaults to 3000 provisioned IOPS, billed per IOPS-month at about $300/month (io1 ≈ $0.10/IOPS, io2 ≈ $0.125/IOPS) on top of the instance and the GB storage. The gp3 default includes the same 3000 IOPS and 125 MB/s free up to 400 GB, so there it costs nothing. Same database, ~$300/month apart, from one dropdown.

A realistic single-AZ db.t4g.medium with a modest volume and normal traffic lands well above the sticker once storage, IOPS, backups, and egress are counted, and the exact figure changes month to month. Treat $48 as a floor, not a price. (We wrote about this metered-bill pattern in Cloud Rent in Action and Usage-Based Pricing.)

High availability changes the comparison

The results above are not apples-to-apples on resilience, and this is the important part.

Hostim drp-50 is replicated by default. The €50 includes a standby and automatic failover. Nothing to configure.
AWS RDS needs Multi-AZ for a standby with failover. Multi-AZ runs a second instance and roughly doubles the instance and storage cost. It also makes writes slower, because commits wait on the synchronous standby, so a fair, HA-to-HA comparison would put RDS writes below the single-AZ numbers measured above.
Self-hosted Hetzner has no failover at all on one node. To match Hostim you add a second VPS (another €20) and then build and operate the replication and failover yourself (streaming replication plus a tool like Patroni or repmgr, plus a routing layer), and you own every incident.

Normalised to "replicated Postgres with automatic failover":

Offering	Roughly what HA costs / month	Extra work
Hostim `drp-50`	€50, included	None
AWS RDS Multi-AZ	~2× instance + storage, plus egress and backups	None, but slower writes
Hetzner, 2 nodes	~€40 hardware	You build and run failover yourself

So the €50 Hostim number already includes the thing that doubles the AWS price and turns the Hetzner option into an operations project.

Caveats

db.t4g.medium is burstable ARM; sustained runs can hit the CPU-credit baseline. That is the behaviour of the price-matched tier, not a misconfiguration.
The self-hosted node used stock Postgres defaults on purpose. Tuning shared_buffers and friends would raise its numbers, but doing that is your job when you self-host.
RDS was single-AZ for the raw benchmark; Multi-AZ is slower and dearer, as noted above.
The dataset fit in RAM (scale 50), which isolates compute. A dataset larger than RAM would put more weight on storage and widen the write gaps, not close them.
Architectures differ (RDS is ARM Graviton, the others x86). This is what each provider sells at this price, so it is reported as-is.

Takeaways

For write-heavy workloads at this size, Hostim was fastest by a clear margin, mostly due to storage fsync latency on the commit path.
For read-heavy workloads, a self-hosted box had the raw per-core CPU edge, if you are willing to tune it and operate it.
AWS RDS at the price-matched tier was slowest or near-slowest on both, and its real cost (storage, IOPS, egress, and Multi-AZ for failover) is a multiple of the listed instance price.
If you want replicated Postgres without running it yourself, the flat, HA-included price is the number to compare against, not the single-node sticker.

Every number above is reproducible with the commands in the methodology section. If you are still deciding between managed and self-hosted in the first place, see Self-Host Postgres or Use Supabase? and Which Database Should You Self-Host?.

A managed, replicated Postgres at a flat price

If the parts you dislike are the climbing AWS bill and the operations work of running your own failover, that is exactly what Hostim is built to avoid. Managed Postgres is replicated by default, at a flat, predictable price: drp-50 is €50/month with the standby included. There is also a free database tier to test the fit, and new projects get a free 5-day trial with no card.

👉 Spin up a managed Postgres on Hostim, free tier, no card

Last updated: 2026-07-07. Benchmarks run 2026-07-07 on PostgreSQL 16, eu-central region.

Render vs Railway vs Fly.io: Pricing Compared (2026)

Pavel — Tue, 23 Jun 2026 05:03:13 +0000

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 shape fits how you work.

Prices are accurate as of June 2026. All three change pricing often — check the live page before you commit. The shapes change far less than the numbers.

The three shapes in one line each

Render — pick an instance size at a fixed monthly price, plus a flat workspace fee for teams. Predictable, with a real free tier that sleeps.
Railway — no free tier. A small monthly plan fee, then per-second metering of CPU, RAM, volumes, and egress on top.
Fly.io — no free tier, no seat fee. You pay per second for each running machine and for what it uses. The most "raw cloud" of the three.

Is there a free tier?

Platform	Free tier?	The catch
Render	Yes	Free web services spin down after ~15 min idle, then cold-start. Fine for demos, not production.
Railway	No	One-time $5 trial credit, no card. Then you are on a paid plan.
Fly.io	No	New accounts have no free allowance. You pay from the first running machine.

How usage metering works

Render bills fixed instance prices — choose a size (Starter ~$7/mo for 0.5 CPU/512 MB, Standard ~$25/mo for 1 CPU/2 GB) and pay it whether the app is busy or idle.

Railway and Fly.io both bill per second of actual use:

Railway meters memory, CPU, volumes, and egress on top of your plan fee. An always-on 1 GB service runs in the low tens of dollars/month past the included credit.
Fly.io bills each machine by the second. The smallest shared-cpu-1x / 256 MB is ~$2.02/mo if left on; more RAM is ~$5/GB/mo; egress in NA/EU is $0.02/GB. Stopped machines cost only their disk.

Per-second billing is cheaper for spiky or scale-to-zero workloads and harder to predict, because the bill moves with traffic.

Side-by-side

Factor	Render	Railway	Fly.io
Free tier	Yes (sleeps ~15 min)	No ($5 trial credit)	No (new accounts)
Billing model	Fixed instance price	Per-second usage + plan	Per-second usage
Workspace / team fee	$25/mo flat (Pro)	$20/mo flat (Pro)	None
Entry cost (solo)	Free or ~$7/mo	~$5–15/mo	~$2–7/mo
Best for spiky traffic	Weak (fixed size)	Good	Good
Cost predictability	High	Medium	Low–medium

When each wins

Render — predictable, fixed bills you can budget; a real free tier for demos (if you accept cold starts); simple over tunable.
Railway — clean DX with per-second billing that scales down when idle; great for spiky traffic; small enough team that the plan fee stays small.
Fly.io — lowest raw compute cost, no seat fees, multi-region or scale-to-zero, and you are fine with more configuration.

The pattern behind all three

All three start cheap and grow with usage, plan tier, or both. That is the normal SaaS shape — convenience now, a bill that climbs as you succeed. Worth paying if you use what you pay for.

If the part you dislike is the climbing bill, that is what we are building Hostim to avoid: deploy a container or git repo, pay a flat predictable price for the resources you pick. New projects get a free 5-day trial (no card), and managed Postgres/MySQL/Redis have a free tier of their own.

We're building Hostim.dev to make this simpler — happy to answer any questions.

Self-Host Postgres or Use Supabase? Here's How to Decide

Pavel — Mon, 08 Jun 2026 15:36:52 +0000

Short answer first: 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.

Supabase is not a database

Supabase runs on PostgreSQL, but it's a stack of services around it:

Postgres – the actual database
Auth – user signup, login, JWT tokens
Realtime – live updates over websockets
Storage – an S3-style file store
Edge Functions – serverless functions
Studio – dashboard + auto-generated REST/GraphQL API

So "self-host Postgres or use Supabase" compares a plain database to a full backend. The honest question: do you need those extra layers, or just the database underneath them?

A quick test:

You use Supabase Auth, Storage, and Realtime → Supabase earns its place.
You use one of them → it's replaceable.
You use none and treat it as "Postgres with a nice dashboard" → you want plain Postgres.

Side-by-side comparison

Factor	Supabase (managed)	Self-hosted Supabase	Plain Postgres (managed or self-hosted)
Database engine	PostgreSQL	PostgreSQL	PostgreSQL
Built-in auth	Yes	Yes	No (bring your own)
Realtime / websockets	Yes	Yes	No
File storage	Yes	Yes	No
Dashboard + auto API	Yes	Yes	No (use any SQL client)
Backups	Managed (limits by plan)	You manage	Managed or you manage
Cost shape	Metered, grows with usage	Server cost + your time	Database only
Self-host effort	None	High (many containers)	Low–medium
Lock-in	Medium–high	Medium	Very low

The lock-in point decides it for many teams. Your data is standard Postgres in every option (pg_dump portable). The lock-in is everything else: Auth tokens, Storage paths, Supabase-specific RLS policies, Edge Function code. The more Supabase-specific features you adopt, the harder the exit.

When each option wins

Pick managed Supabase when:

You're starting a new app and want auth, storage, and realtime working today.
You'll genuinely use at least two of those features.
You prefer to pay for convenience and not run infrastructure.

Pick self-hosted Supabase when:

You want the Supabase feature set but need full data ownership or on-prem.
You're ready to run and update a multi-container stack.
Compliance or cost at scale justifies the extra ops work.

Pick plain Postgres (managed or self-hosted) when:

You mainly need a reliable database, and your app already handles auth and logic.
You want minimal lock-in and a simple, predictable cost.
You value boring, standard Postgres you can move anywhere.

The honest summary

Supabase is a strong choice when you use its full stack. The moment you only want the database underneath it, you're paying in cost and lock-in for layers you don't run.

Need a backend → Supabase.
Need a backend you fully own → self-hosted Supabase.
Need a database → plain Postgres, managed or self-hosted.

I write about this stuff while building Hostim, a platform with managed Postgres built in. The full version of this post – with Docker Compose config and backup commands – is on the Hostim blog.

Let's Encrypt Wildcard Certs in Kubernetes: cert-manager + DNS-01 (and When We Skipped It)

Pavel — Tue, 05 May 2026 16:52:23 +0000

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.

Why two tools for one cluster?

You can do everything with cert-manager. It supports DNS-01 with a long list of providers. So why are we running a second tool?

Three reasons:

Our DNS provider (Namecheap) does not have a stable cert-manager webhook. There are community webhooks, but they break on upgrades. Maintaining one for a single cert is more work than running certbot once a quarter.
The wildcard cert covers our shared ingress, not user apps. It rotates rarely, lives in one namespace, and is read by every ingress as a TLS secret. cert-manager is built for the opposite case: many short-lived certs per Ingress.
A failed cert-manager renewal at 3 a.m. is hard to debug. A failed Ansible run on our laptop is a stack trace we can read.

For per-app domains (my-app.user.tld with cert-manager + HTTP-01), the controller-driven model wins. For the one shared wildcard, the manual model wins. Use the right tool.

Path A: cert-manager + HTTP-01 (per-app domains)

This is the standard path. Most apps want a cert for one or two hostnames. HTTP-01 is the simplest challenge: cert-manager spins up a temporary pod, the ACME server hits http://app.example.com/.well-known/acme-challenge/..., the pod responds, the cert is issued.

1. Install cert-manager

kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.16.1/cert-manager.yaml

Wait for the three pods (cert-manager, cert-manager-webhook, cert-manager-cainjector) to be ready.

2. Create a ClusterIssuer

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: you@example.com
    privateKeySecretRef:
      name: letsencrypt-prod-account
    solvers:
      - http01:
          ingress:
            class: nginx

Apply it. cert-manager will register an ACME account on first use.

3. Annotate your Ingress

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  tls:
    - hosts: ["app.example.com"]
      secretName: app-example-com-tls
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: my-app
                port:
                  number: 80

That is it. cert-manager sees the annotation, requests the cert, solves the HTTP-01 challenge, writes the cert into the app-example-com-tls secret. Renewal is automatic.

This works for any number of distinct hostnames. We do this exact thing for every user app on hostim.dev.

Path B: certbot + DNS-01 (the wildcard)

For *.region.hostim.dev, HTTP-01 cannot work — the ACME server cannot resolve every possible subdomain. We need DNS-01: prove control over the parent domain by adding a TXT record.

You can do this with cert-manager and a DNS-01 webhook for your provider. We chose not to. Here is the Ansible playbook we run instead.

The flow

Ansible writes two scripts: an auth hook (creates the TXT record) and a cleanup hook (deletes it).
certbot --manual --preferred-challenges dns runs the auth hook, waits for DNS to propagate, lets ACME verify, then runs the cleanup hook.
The resulting fullchain.pem and privkey.pem get loaded into a Kubernetes Secret of type kubernetes.io/tls.
Every ingress in the shared namespace references that secret.

The playbook (trimmed)

- name: Issue and upload wildcard TLS certificate
  hosts: localhost
  vars:
    sld: "example"
    tld: "com"
    region: "eu-center"
    wildcard_domain: "*.{{ region }}.{{ sld }}.{{ tld }}"
    local_tmp: "/tmp/wildcard-{{ region }}"
    k8s_namespace: "ingress-nginx"
    k8s_secret_name: "wildcard-{{ region }}-tls"

  tasks:
    - name: Create certbot auth hook (creates the TXT record)
      copy:
        dest: "/tmp/certbot-auth-{{ region }}.sh"
        mode: "0755"
        content: |
          #!/bin/bash
          set -e
          namecheap-cli setone \
            --sld {{ sld }} --tld {{ tld }} \
            --type TXT --name "_acme-challenge.{{ region }}" \
            --address "${CERTBOT_VALIDATION}" --ttl 60
          # Wait for DNS to propagate
          for i in {1..30}; do
            val=$(dig TXT _acme-challenge.{{ region }}.{{ sld }}.{{ tld }} @1.1.1.1 +short | tr -d '"')
            [[ "$val" == "${CERTBOT_VALIDATION}" ]] && break
            sleep 10
          done
          sleep 30  # belt and suspenders

    - name: Issue wildcard certificate
      command: >
        certbot certonly --manual --preferred-challenges dns
        --manual-auth-hook /tmp/certbot-auth-{{ region }}.sh
        --manual-cleanup-hook /tmp/certbot-cleanup-{{ region }}.sh
        --agree-tos -m you@example.com
        --server https://acme-v02.api.letsencrypt.org/directory
        -d "{{ wildcard_domain }}"
        --work-dir {{ local_tmp }} --config-dir {{ local_tmp }}
        --logs-dir {{ local_tmp }} --non-interactive

    - name: Create or update TLS Secret
      kubernetes.core.k8s:
        state: present
        namespace: "{{ k8s_namespace }}"
        definition:
          apiVersion: v1
          kind: Secret
          metadata:
            name: "{{ k8s_secret_name }}"
          type: kubernetes.io/tls
          data:
            tls.crt: "{{ lookup('file', local_tmp + '/live/.../fullchain.pem') | b64encode }}"
            tls.key: "{{ lookup('file', local_tmp + '/live/.../privkey.pem') | b64encode }}"

Reference the secret in your Ingress

spec:
  tls:
    - hosts: ["*.region.example.com"]
      secretName: wildcard-region-tls

When does it run?

We run the playbook every 60 days. Let's Encrypt certs are valid for 90 days, so 60 leaves a 30-day buffer. A simple cron on a bastion host is enough — we do not even need to automate this. The cost of a manual run twice a quarter is lower than the cost of debugging a webhook.

"Unable to locate package 'appengine'" — a real gotcha we hit

If you copy this playbook and your certbot is from your distro's package manager, you may hit:

ImportError: cannot import name 'appengine' from 'urllib3.contrib'

This is a Python env collision. System certbot (often 1.21) wants old urllib3; you have a newer one in ~/.local/lib/python3.10/site-packages. The newer version dropped appengine.

Quick fix — add PYTHONNOUSERSITE: "1" to the certbot task's environment:

- name: Issue wildcard certificate
  environment:
    PYTHONNOUSERSITE: "1"
  command: >
    certbot certonly --manual ...

Long-term fix — install certbot via snap or pipx so it has its own Python env.

Should you do it this way?

Probably not. If your DNS provider has a stable cert-manager webhook (Cloudflare, Route53, DigitalOcean, Google Cloud DNS), use cert-manager for both per-app and wildcard certs. It is simpler and renews automatically.

The hybrid model only makes sense when:

Your DNS provider has no first-party or stable cert-manager support
You have one wildcard, not many
You would rather audit a 30-line shell script than a webhook deployment

For us those three are all true. For most teams, only the first might be — and even then, switching DNS provider is often easier than maintaining a webhook.

TL;DR

Per-app domains → cert-manager + HTTP-01 + ClusterIssuer. One annotation per Ingress, automatic renewals.
Wildcards → DNS-01 is mandatory. Use cert-manager with your DNS provider's webhook if it exists. Otherwise, a 60-day Ansible run with certbot --manual and a TLS Secret.
Two tools is fine. Don't force one model onto two different problems.

Want to skip TLS entirely?

Hostim.dev does this for you. Bring a Docker image or a git repo, get a cert and a domain.

Should Small Teams Even Bother with Kubernetes?

Pavel — Sun, 26 Apr 2026 10:43:15 +0000

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.

What Kubernetes gives you

Underneath the marketing, Kubernetes is four practical things:

Declarative scheduling – you describe the desired state and a controller keeps the cluster in that state
Self-healing – crashed pods restart, dead nodes are drained, replicas come back automatically
Bin-packing – many workloads share the same nodes with CPU and memory limits
A standard API – Deployments, Services, Ingress, Jobs, Secrets, all the same on any cluster

These are real benefits. The catch is that you pay for them in money, time, or both.

What it actually costs

A realistic small-team setup looks like this: 3 services (API, worker, frontend), one Postgres, one Redis, around 50GB of storage. Here is what the same workload costs in three common shapes, all in eu-central-1 / Frankfurt.

Managed Kubernetes (AWS EKS)

EKS control plane, 0.10 USD per hour: ~67 €/mo
3× t3.medium nodes (2 vCPU / 4GB): ~92 €/mo
RDS Postgres db.t3.small, Single-AZ: ~27 €/mo
ElastiCache Redis cache.t3.micro: ~13 €/mo
ALB base plus LCU: ~15 €/mo
50GB EBS gp3 plus ~200GB egress: ~14 €/mo

Total: around 228 €/mo, before backups, observability, or any of your time.

GKE used to give you the first cluster for free. That is gone now: control plane is 0.10 USD per hour, and you get a 74.40 USD monthly billing-account credit that offsets one zonal cluster. Regional clusters pay full price.

Single Hetzner box + Docker Compose

AX42 dedicated (8-core Ryzen 7 PRO, 64GB DDR5, NVMe): from 57 €/mo (April 2026 pricing)
Postgres, Redis, app – all containers on the same machine, isolated by Compose
nginx and Let's Encrypt for HTTPS
Storage Box BX11 (1TB) for backups: ~4 €/mo

Total: around 61 €/mo. That box has enough headroom to run several more projects beside the main one.

Self-hosted Kubernetes (k3s on Hetzner Cloud)

3× CCX13 (2 dedicated vCPU / 8GB / 80GB SSD): ~48 €/mo
You run the control plane, etcd, ingress controller, cert-manager, backups and monitoring yourself

Compute is around 48 €/mo, but the real cost is the hours you put into the cluster every week.

The ops cost nobody prices in

Hosting is the cheap part. Kubernetes adds work that simply does not exist with Compose:

Cluster upgrades. A new minor lands every four months. If you skip a few, the upgrade path becomes painful.
Ingress and cert-manager. Works fine until cert-manager hits a CRD migration or your ingress controller deprecates an annotation you depend on.
CNI debugging. A misbehaving Calico or Cilium pod can take half a day to track down.
RBAC and ServiceAccounts. Required even for trivial things like letting one pod read one secret.
PVCs and storage classes. A reboot at the wrong moment can leave a volume stuck in Terminating and you reading the controller logs.
etcd. Quiet most of the time, then your cluster is suddenly read-only at 2am and you are restoring from a snapshot.

Realistic estimate: 2 to 5 hours a week of cluster maintenance for a self-hosted setup. Managed clusters cost less time but more money, as the table above shows. For a 3-person team, 2-5 hours a week is 5-12% of one engineer's time spent on infrastructure that does not ship features.

When Kubernetes is the right call

There are real cases where the cost is justified:

You run more than 20 services that need consistent deploys, secrets and networking
Multi-region or multi-tenant with hard isolation per customer
Compliance work (SOC 2, HIPAA) where audited RBAC and NetworkPolicies save weeks of paperwork
Your team already knows Kubernetes well and Compose would slow them down
Bursty workloads that genuinely benefit from horizontal autoscaling on shared nodes
You are building a platform where the Kubernetes API itself is the product (operators, CRDs)

If two or more of those apply, Kubernetes earns its keep. If none do, you are paying for capabilities you will not use.

When it is not

Most small teams have a workload that looks like this:

1 to 5 services
One Postgres, maybe a Redis
A single region
Fewer than 5 deploys a day

This fits comfortably on one Hetzner box with Docker Compose, or on a PaaS. No Kubernetes needed, much less money spent, and far less time on ops.

The "we will need it eventually" argument is mostly survivorship bias. Most projects never reach the scale where Kubernetes is actually the cheapest option, and migrating later is easier than people claim. A docker-compose.yml maps almost line-for-line to Deployments and Services when the day comes.

Quick decision table

Situation	Use
Solo dev, 1-3 services	Docker Compose on a VPS
Small team, up to ~10 services, one region	PaaS or Compose + Ansible
Multi-tenant SaaS with isolation needs	Kubernetes (managed)
Compliance-heavy, audited infrastructure	Kubernetes (managed)
Building a platform or operator	Kubernetes
"Everyone else uses it"	Not a real reason

The middle ground

A PaaS exists exactly for this gap. You get the useful parts of Kubernetes – self-healing, declarative deploys, automatic HTTPS, isolated namespaces – without running the cluster yourself.

Hostim.dev runs Kubernetes underneath, on bare metal in Germany, so you do not have to. You paste a docker-compose.yml and get a deployed app with HTTPS, Postgres, Redis, volumes, metrics and logs.

The same stack priced on Hostim:

3× shared App (2 vCPU / 2GB): 13.50 €
Postgres (10GB): 10 €
Redis (2.5GB): 5 €
50GB volume: 10 €

Total: 38.50 €/mo, with HTTPS, metrics, logs and backups included.

If you actually need Kubernetes, run Kubernetes. If you are reaching for it because it is the default answer, a PaaS or a single Hetzner box will probably serve you better, for less money and less weekend work.

👉 Try Hostim.dev

Which Database Should You Self-Host? SQLite vs MySQL vs PostgreSQL vs Redis

Pavel — Wed, 08 Apr 2026 16:38:44 +0000

When you're deploying your own app, the database choice matters more than most people think. It affects performance, ops complexity, backups, and how much memory your server needs.

There are four options you'll run into most often: SQLite, MySQL, PostgreSQL, and Redis. They're not all the same kind of database – and that's the point. Here's when each one makes sense.

SQLite – the zero-ops embedded database

Best for: small apps, prototypes, CLIs, single-user tools, edge deployments
Strengths: no server process, single file, zero config, instant setup
Weaknesses: no concurrent writes, no replication, hard to scale past one instance

SQLite is not a server – it's a library that reads and writes a single file. That makes it perfect for apps where simplicity matters more than scale. If your app has one process writing to the database and modest traffic, SQLite will outperform anything else because there's no network round-trip. The moment you need concurrent writes or multiple app replicas, you've outgrown it.

MySQL – the reliable workhorse

Best for: web apps, CMS platforms, CRUD-heavy workloads, WordPress/Laravel stacks
Strengths: fast reads, mature replication, huge ecosystem, low memory footprint
Weaknesses: weaker JSON support, less strict by default, fewer advanced types

MySQL powers a massive chunk of the internet. It's battle-tested, well-documented, and runs well even on small VPS instances. If you're running a standard web app with mostly reads and simple queries, MySQL will serve you well without hogging resources. Just be aware that its default configs are more lenient than PostgreSQL – silent truncations and implicit type casts can bite you.

PostgreSQL – the feature-rich powerhouse

Best for: complex queries, data integrity, JSON workloads, GIS, analytics
Strengths: advanced types (JSONB, arrays, hstore), strong standards compliance, extensions ecosystem
Weaknesses: higher memory usage, more tuning needed, steeper learning curve for ops

PostgreSQL is the database you pick when correctness and flexibility matter. It handles complex joins, window functions, CTEs, and full-text search natively. The extension ecosystem (PostGIS, pg_cron, pgvector) makes it a Swiss army knife. The trade-off: it's hungrier on resources and rewards careful tuning of shared_buffers, work_mem, and connection pooling.

Redis – the in-memory speed layer

Best for: caching, sessions, rate limiting, queues, pub/sub, leaderboards
Strengths: sub-millisecond reads, rich data structures (lists, sets, sorted sets, streams), built-in TTL
Weaknesses: data must fit in RAM, persistence is optional and lossy, not a primary data store

Redis isn't a replacement for a relational database – it's a complement. Use it for things that need to be fast and can tolerate occasional data loss: session tokens, cache layers, job queues. Redis Streams can even replace simple message brokers. Just don't store your source of truth here – if the server restarts between RDB snapshots, recent writes are gone.

Quick comparison

Feature	SQLite	MySQL	PostgreSQL	Redis
Type	Embedded	Relational server	Relational server	In-memory store
Ease of setup	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐
Concurrent writes	❌ Single-writer	✅ Good	✅ Excellent	✅ Very fast
Complex queries	Basic	Good	Excellent	N/A (key-value)
Memory usage	Minimal	Low–moderate	Moderate–high	High (all data in RAM)
Replication	None built-in	Mature	Mature	Built-in
Best self-host size	Single instance	Small–large	Medium–large	Any (as cache layer)
Persistence	Always (file)	Always (disk)	Always (disk)	Optional (RDB/AOF)

So which one should you choose?

Building a prototype or CLI tool? → SQLite
Running a standard web app? → MySQL
Need complex queries, JSONB, or extensions? → PostgreSQL
Need a fast cache, session store, or queue? → Redis

Most real-world apps end up using two: a relational database (MySQL or PostgreSQL) for your data, and Redis for caching and sessions. That's not overkill – it's the right tool for each job.

Self-hosting these databases

Running databases on a VPS means managing backups, updates, and disk space yourself. It's doable, but it's one more thing to maintain.

On Hostim.dev, MySQL, PostgreSQL, and Redis are built in – provisioned alongside your app with metrics and no extra config. Paste a docker-compose.yml and your database is ready.

Bastion Host & GitHub Actions on Hostim.dev

Pavel — Thu, 08 Jan 2026 19:00:09 +0000

I haven't posted updates for a while, but several core features landed on Hostim.dev recently.

Instead of shipping from a fixed roadmap, I'm following support-driven (customer-driven) development: features move to the top of the queue once users actively need them.

Over the past month, this resulted in three practical additions around Docker CI/CD, GitHub Actions deployment, and secure bastion host access.

GitHub Actions deploy for Docker apps

Hostim.dev now supports GitHub Actions deployments out of the box.

You can trigger a deploy directly from GitHub Actions using a simple API call. This works well for common Docker CI/CD setups:

Build and deploy on merge to main
Restart an app after pushing a new Docker image
Manual deploys via workflow_dispatch

There's no OAuth and no hidden logic. Your workflow controls everything — branches, conditions, environments. Hostim only executes the requested action.

This is especially useful if you already run CI/CD with Docker and just want a clean deployment target.

Bastion host for secure shell access to containers

Each project now includes a built-in SSH bastion host.

If you're unfamiliar: a bastion host is a hardened entry point used to access private infrastructure without exposing services to the public internet.

On Hostim.dev, the bastion host allows you to open a shell into running apps:

shell my-app

This answers common questions like:

What is a bastion host used for?
How do I securely SSH into containers?
How can I debug a production Docker app without public access?

Typical use cases:

Debugging production issues
Running database migrations
Inspecting environment variables
Accessing internal services safely

The bastion host is private, key-based, and isolated per project.

Custom commands for Docker apps

Apps can now override the container command.

This enables common Docker patterns such as:

One image, multiple roles (web + worker)
Background jobs using the same Docker image
CI/CD pipelines that reuse images across environments

This pairs naturally with Docker CI/CD pipelines, where images are built once and reused consistently.

Why this approach

Many platforms ship features based on assumptions.

Instead, these changes came directly from:

"How do I deploy with GitHub Actions?"
"How do I get shell access without exposing ports?"
"How do I run workers with the same image?"

Support questions shape the roadmap.

What's next

More items are planned, but user feedback decides the order.

If something feels missing, it's probably already on the list.

👉 https://hostim.dev

A Better Umami Dashboard with Grafana

Pavel — Thu, 20 Nov 2025 17:24:38 +0000

Umami is great. Lightweight, privacy-friendly, no cookies, no tracking drama.
We use it ourselves on Hostim.dev, and we ship a one-click Umami template for anyone who wants simple, privacy-focused analytics.

But once you start relying on analytics to make actual decisions, you hit the limits pretty quickly.

Why the default Umami dashboard wasn't enough

Umami intentionally keeps things minimal, but some gaps become obvious:

No clear view of when visitors peak during the day
Hard to isolate bots from real traffic
No moving averages or trend smoothing
No grouped referrers (e.g. "search", "LLM", "other")
Limited visibility into relationships between sessions and custom events

None of this is criticism — Umami is intentionally simple.
But sometimes you want more resolution.

So I took the quickest path:

Deploy Grafana → connect it to Umami's PostgreSQL → build a custom dashboard.

This took maybe ten minutes and unlocked:

Daily heatmap showing real traffic peaks
7-day moving averages for referrers
Qualified sessions (≥2 pageviews) to filter out most bots
Selectable custom events
Raw stats for the selected period

Suddenly Umami became "actionable" instead of just "nice".

How to connect Grafana to Umami's PostgreSQL

Inside Grafana:

Configuration → Data sources → Add data source → PostgreSQL

Fill in the credentials from your Umami database and save.

You can now import our dashboard:

👉 Grafana.com Dashboard

Try it yourself

If you prefer to self-host on your own VPS, here is a complete Docker Compose stack for Umami, PostgreSQL, and Grafana.

Full Docker Compose stack

services:
  postgres:
    image: postgres:15
    restart: always
    environment:
      POSTGRES_USER: umami
      POSTGRES_PASSWORD: umami_pass
      POSTGRES_DB: umami
    volumes:
      - postgres_data:/var/lib/postgresql/data

  umami:
    image: ghcr.io/umami-software/umami:postgres-latest
    restart: always
    depends_on:
      - postgres
    environment:
      DATABASE_URL: postgres://umami:umami_pass@postgres:5432/umami
      DATABASE_TYPE: postgresql
      APP_SECRET: "replace_this_with_a_random_secret"
    ports:
      - "127.0.0.1:3000:3000"

  grafana:
    image: grafana/grafana:latest
    restart: always
    depends_on:
      - postgres
    environment: GF_SERVER_DOMAIN=grafana.example.com
      GF_SERVER_ROOT_URL=https://grafana.example.com
    ports:
      - "127.0.0.1:3001:3000"
    volumes:
      - grafana_data:/var/lib/grafana

volumes:
  postgres_data:
  grafana_data:

Start everything:

docker compose up -d

Then:

Umami → http://localhost:3000
Grafana → http://localhost:3001

In Grafana, configure a PostgreSQL data source:

Host: postgres
Port: 5432
User: umami
Password: umami_pass
Database: umami

Import the dashboard using the ID from Grafana.com.

Don't want to run a server?

If you don't want to manage Docker, OS maintenance, or networking, you can deploy the same stack on Hostim.dev by simply pasting the Compose file above when creating a new project.

Choose Paste Docker Compose
Use the YAML from this section

Hostim.dev will handle HTTPS, internal networking, logs, metrics, and persistence for all three services.

👉 Try Hostim.dev — deploy the full stack without touching SSH

Already running Umami on Hostim.dev?

If you deployed Umami using the one-click template, you don't need a new project. Just:

Create a separate Grafana App in the same project
Use the grafana/grafana:latest image
Add the existing Umami PostgreSQL as a Grafana data source
Import the dashboard JSON

Both apps run on the same private project network, so they can communicate without exposing ports or adjusting firewall rules.

MetalLB on Hetzner Dedicated with vSwitch

Pavel — Tue, 28 Oct 2025 17:00:41 +0000

When running Kubernetes on Hetzner Dedicated, there is no cloud load balancer. But you can provide public LoadBalancer IPs by attaching a routed IP range to a vSwitch and letting MetalLB announce addresses over L2.

Our setup:

Calico (VXLAN + WireGuard)
kube-proxy IPVS with strictARP
ingress-nginx for ingress traffic

1. Assign a public subnet to your vSwitch

Example routed block Hetzner provides:

Subnet:     123.45.67.32/29
Gateway:    123.45.67.33
Usable:     123.45.67.34–38
Broadcast:  123.45.67.39

Attach your dedicated servers to the vSwitch (VLAN ID e.g. 4000).

2. Configure vSwitch VLAN on each node

Each node gets a /32 from the subnet – Hetzner routes the whole /29 to your server.

Important note on routing table IDs

This guide uses routing table 200 as an example.

If you are running Cilium, avoid table 200: Cilium currently flushes all routes in table 200 on startup, which breaks vSwitch routing.

For Cilium-based installations, any other unused routing table ID works (for example 201, 300, or 1001).

Reference: https://github.com/cilium/cilium/issues/38531
Create /etc/netplan/10-vlan-4000.yaml:

network:
  version: 2
  renderer: networkd
  vlans:
    vlan4000:
      id: 4000
      link: eno1
      mtu: 1400
      addresses:
        - 123.45.67.38/32 # node-specific
      routes:
        - to: 0.0.0.0/0
          via: 123.45.67.33
          on-link: true
          table: 200
        - to: 123.45.67.32/29
          scope: link
          table: 200
      routing-policy:
        - from: 123.45.67.32/29
          table: 200
          priority: 10
        - to: 123.45.67.32/29
          table: 200
          priority: 10
        - from: 123.45.67.32/29
          to: 10.233.0.0/18
          table: 254
          priority: 0
        - from: 123.45.67.32/29
          to: 10.233.64.0/18
          table: 254
          priority: 0

Apply:

netplan apply

3. Required sysctl settings

Create /etc/sysctl.d/999-metallb.conf:

net.ipv4.conf.all.arp_ignore=1
net.ipv4.conf.all.arp_announce=2
net.ipv4.conf.all.rp_filter=0
net.ipv4.conf.default.rp_filter=0

Why:

Setting	Purpose
`arp_ignore=1`	Only reply to ARP queries for an IP on the correct interface – prevents conflicting replies from Calico/VXLAN.
`arp_announce=2`	Send ARP only from the interface that owns the VIP, required when MetalLB moves VIPs between nodes.
`rp_filter=0`	Disable strict reverse-path filtering – otherwise nodes drop return traffic sourced from VIPs or remote pods.

4. kube-proxy + Calico adjustments

Enable strictARP in kube-proxy (IPVS mode):

apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
ipvs:
  strictARP: true

MTU must account for VXLAN + vSwitch + WireGuard overhead:

Calico MTU: 1280 (consistent across nodes)

5. Deploy MetalLB

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: vswitch
  namespace: metallb-system
spec:
  addresses:
    - 123.45.67.34-123.45.67.36 # free VIPs
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: l2
  namespace: metallb-system
spec:
  ipAddressPools: ["vswitch"]
  interfaces: ["vlan4000"]

Restart MetalLB speakers to pick up interface binding.

6. Ingress service configuration

For ingress-nginx:

spec:
  externalTrafficPolicy: Local

Pro:

Preserves client IP
Prevents traffic hairpin across nodes

Tradeoff:

Only one node handles a given connection (acceptable for ingress)

7. Verification

Confirm that your ingress-nginx Service received a public VIP:

kubectl get svc -n ingress-nginx ingress-nginx-controller

Expected example:

NAME                       TYPE           CLUSTER-IP      EXTERNAL-IP    PORT(S)                      AGE
ingress-nginx-controller   LoadBalancer   10.233.53.156   123.45.67.35   80:30440/TCP,443:30477/TCP   17d

Inspect the Service events to see which node currently advertises the VIP:

kubectl describe svc -n ingress-nginx ingress-nginx-controller

Look for:

Events:
  Normal  nodeAssigned  ...  metallb-speaker  announcing from node "control-plane-1" with protocol "layer2"

Then verify reachability from outside:

curl -I http://123.45.67.35

Failover test

Identify the active announcer from the above events
Shut that node down abruptly:

sudo poweroff

Re-run:

curl -I http://123.45.67.35

Expected: traffic continues within ~1–2 seconds as another node picks up the VIP.

➡️ Note: VIPs do not appear in ip addr on nodes; they are held in IPVS and advertised via ARP. That is normal.

Acknowledgment

Thanks to Oleksandr Vorona (DevOps at Dysnix) for reporting a Cilium routing table conflict and helping improve this guide.

https://dysnix.com

Wrapping up

This gives:

Public LoadBalancer IPs
Fast failover (~1-2s)
Clean separation: pod networking via VXLAN/WireGuard, external via vSwitch

Alternative approaches:

Hetzner Cloud Load Balancer (simpler, works with Dedicated too)
Cilium with L2 announcements

We run hosting infrastructure, so controlling ingress networking ourselves matters (mostly to prove the point really). Hetzner still runs the vSwitch underneath, but it's more independent than relying on the cloud LB.

And if you'd rather not handle any of this yourself – Hostim.dev is now live. You can deploy your Docker or Compose apps with built-in databases, volumes, HTTPS, and logs – all in one place, ready in minutes.