No, Your Blog Doesn't Need Kubernetes
Kubernetes is tech’s broken record: it’s been on repeat for years, and “learn this to make it in 2026” influencers keep putting it at the top of the list of must-have skills, the Holy Grail to reach. And yet, for this blog, I made a choice some might call “not sexy” today: a static site generated with Hugo, deployed via a simple GitHub Action that pushes files over FTP to a shared OVH hosting plan.
It’s a choice that might surprise you, coming from someone with experience running heavier infrastructure. Don’t read it as a lack of technical ambition β it’s an exercise in pragmatism. Before spinning up a cluster, the real question isn’t “can I build this,” it’s “does my actual need justify it.”

Start From the Need, Not the Solution¶
Call me a rationalist, but I like to start from the need before reaching for a solution. In June, I launched my freelance consulting practice, to share my industry experience and support projects with a human touch. I love learning, sharing, teaching β this blog is, for me, the ideal outlet to do that.
I’m just getting my activity off the ground, so my budget isn’t unlimited, and neither is my time. I’d rather spend it helping teams than dealing with the stress of daily infrastructure alerts (believe me, I’ve already lived through that with NuCorder ).
So the blog is designed to be as simple as possible: a static site. Text, a few images, no backend, no database, no user accounts. Traffic stays modest β well below anything that would justify thinking about load or scalability.
The stakes here aren’t technical. They’re economic and human.
Hugo: The Tool That Fits Me¶
I’m a developer at heart, and I’ve specialized in Go and DevOps for a few years now. Over that time, I’ve contributed to open source projects like Buffalo , and gotten familiar with the Go community and its flagship projects.
That’s how I came across Hugo , a batteries-included static site generator that benefits from two Go traits I’ve appreciated from day one: execution speed and packaging into a single unified binary (an absolute joy once you’ve already deployed non-compiled languages to production). As a bonus, I know the language, so I can patch it myself if needed.
A static site is a bit less flexible, since you have to redeploy on every change, but it comes with real advantages too: no application runtime to keep running, no database to secure, far fewer dependencies to maintain in production. Once deployed, the operational surface is minimal.
Hugo is my choice, then: I picked the most efficient and cost-effective tool for my situation.
A Deployment That Fits in Two Steps¶
I wanted the pipeline to be as simple as everything else: a GitHub Action runs the Hugo build, then pushes the generated files over FTP to the shared OVH hosting. Nothing exotic, just what’s needed.
name: Deploy
on:
push:
branches: [main]
workflow_dispatch:
jobs:
build-and-deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
with:
submodules: recursive
fetch-depth: 0
- name: Setup Hugo
uses: peaceiris/actions-hugo@v3
with:
hugo-version: '0.163.3'
extended: true
- name: Build
run: hugo --minify
- name: Deploy to OVH
uses: SamKirkland/FTP-Deploy-Action@v4.3.5
with:
server: ${{ secrets.OVH_FTP_SERVER }}
username: ${{ secrets.OVH_FTP_USERNAME }}
password: ${{ secrets.OVH_FTP_PASSWORD }}
protocol: ftp
local-dir: ./public/
server-dir: ${{ vars.OVH_FTP_REMOTE_DIR }}The workflow triggers on every push to main. I haven’t had to touch it since setting it up.
What It Actually Costs¶
A shared hosting plan at OVH starts at β¬3.95/month. A managed Kubernetes cluster , even stripped down to the bare minimum β two small nodes to keep a bit of redundancy β runs around β¬50/month with the same provider. These figures are accurate as of writing (August 2026): cloud pricing moves fast, and it’s been trending upward lately, with hardware costs under pressure.
Same story with AWS: their EKS control plane is billed hourly , whether you’re running zero nodes or ten, pushing the minimum bill above $103/month (about β¬95).
Either way, I’d be paying for resilience and scalability this blog simply has no use for.
What I Take Away From This¶
Learning to handle big, heavy-duty tech remains rewarding, and I keep doing it β this isn’t a knock on Kubernetes itself. But I’ve learned, through my own experience, that senior-level skill isn’t just measured by what you know how to build: it’s also measured by what you choose not to build. For decision-makers, pushing back on the sizing your technical team proposes isn’t distrust β it’s sound budgeting.
Choosing simple doesn’t mean choosing careless: version your code, back up what needs backing up somewhere other than the server itself. Ask anyone whose site went dark when a fire tore through OVH’s Strasbourg data center in 2021 β that lesson doesn’t need repeating twice.
Is Your Infrastructure Costing You More Than You Actually Need?¶
If this article got you rethinking the sizing of your own infrastructure, or if you’ve been sitting on that question without daring to settle it internally, feel free to reach out.