Beyond the Stack · EN

UGREEN Uno Qi2 charger — a little robot with a useful job

Mon, 26 Oct 2026 10:18:21 +0100

The UGREEN Uno 2-in-1 Magnetic Wireless Charger gets 8/10 from me. A charger is usually something you hide behind a desk. This one has enough personality to deserve a place on it. The robot shape and expressive display are the immediate attraction, but the more interesting question is whether the design serves an everyday purpose. With a magnetic phone stand and a second wireless charging area for earbuds, there is a practical idea behind the little face.

A design that makes me smile

The robot styling is what I like most about the Uno. The small face gives a familiar accessory a sense of character, while the grey and black finish keeps the overall appearance tidy. It feels like the sort of gadget that belongs beside a monitor: visible, useful and a little fun.

The screen also provides visual charging feedback. That gives the playful design a purpose beyond decoration. I appreciate accessories that make an ordinary routine more enjoyable without demanding a whole new routine of their own.

Magnetic charging with a useful stand

UGREEN specifies Qi2 wireless phone charging at up to 15W. The magnetic attachment helps position a compatible phone over the charging coil, while the raised stand leaves the screen available for checking notifications or keeping a clock in view. That combination is the main appeal for a desk.

The adjustable head adds flexibility to the viewing angle. Being able to position the phone for portrait or landscape use makes the stand useful beyond simply holding a device while its battery fills. Compatibility still matters: the phone and case need to suit the magnetic charging setup. A thick or unsuitable case can get in the way.

UGREEN — Uno Qi2 — product details

Phone and earbuds in one place

The second wireless charging area supports compatible earbud cases at up to 5W. Giving the phone and earbuds a regular place to sit is a small convenience that can make a desk feel more organised. It also means the stand offers more than a single phone charging surface.

There is a side USB-C output for connecting a separate Apple Watch charger. The distinction is worth making clear: the Uno does not contain a built-in Apple Watch charging puck. If watch charging is part of the plan, that accessory is an additional requirement.

UGREEN — Uno Qi2 — product details

What I would keep in mind

The 15W figure is a maximum supported wireless phone charging rate. Actual charging depends on the phone, its software, battery level, temperature and power supply. I see this as a convenient place to leave a phone during the day, rather than a reason to expect the quickest possible top-up. No timed charging measurements are presented here.

The stand also needs an external USB-C power supply; it is not a battery-powered charging station. Check the adapter requirements and the contents of the particular bundle before buying, since a cable and a wall adapter are different things. The robot design is appealing, but the practical match with your devices matters more than the face on the front.

Why it earns my 8/10

What wins me over is the combination of personality and purpose. The Uno gives a phone a useful viewing position, brings compatible earbuds into the same charging spot and adds a little character to the desk. Those are modest improvements, but they are improvements to something used every day.

My rating is 8/10. The wireless charging ceiling and the separate watch charger requirement keep expectations grounded. For someone who likes the design and has compatible devices, this is an appealing way to make charging feel less like a collection of loose cables.

Features checked against UGREEN’s product information. Charging rates are manufacturer maxima; no measured charging times or temperature tests are claimed.

8/10

My verdict

8/10. An appealing combination of robot personality, a magnetic phone stand and earbud charging. A cheerful desk accessory, provided its 15W phone charging and device compatibility fit your needs.

— Desly

Yamaha RX-V683 — an Atmos receiver with room to grow

Mon, 26 Oct 2026 10:18:21 +0100

The Yamaha RX-V683 gets 8/10 from me. What appeals to me is the idea of a proper home-cinema hub: one component that brings your sources, speakers and room setup together, while leaving you choices about how the system develops. Dolby Atmos is the headline attraction, but the broader flexibility matters just as much. This is a receiver built for people who want to put together a system around their own room.

Atmos with a clear channel limit

The RX-V683 has seven amplified channels and supports Dolby Atmos and DTS:X. For an Atmos layout, the useful configuration to understand is 5.1.2: five conventional speakers, a subwoofer and two height channels. It can also serve a conventional 7.1 layout. Those are alternative uses of its amplification; it cannot power a full 7.1.2 arrangement at the same time.

That distinction makes its strengths easier to appreciate. The attraction is the opportunity to build an immersive system with actual speakers placed around the room and height effects above the listening position. The results depend on the speakers, their layout, the content and the room. Atmos decoding is the starting point, and taking care with the physical setup is what gives it a chance to work well.

Yamaha — Speaker configurations

YPAO makes setup more approachable

Yamaha’s YPAO R.S.C. automatic calibration is one of the features I value in this kind of receiver. A surround system involves more than connecting the right wires. Levels, distance settings and the room’s effect on the sound all need attention. Having a guided calibration process gives the owner a practical starting point.

I would still treat calibration as a starting point rather than a substitute for sensible placement. Get the speakers into suitable positions, use the microphone as directed and check the result. The positive is having a receiver that offers tools for the room you actually have, rather than expecting every living space to behave like an ideal listening room.

Yamaha — RX-V683

More than a movie-only component

MusicCast, network playback, AirPlay and Bluetooth give the RX-V683 a broader role than simply switching film sources. A phono input also makes it relevant to a compatible turntable setup. That range is part of its appeal: a home-cinema receiver can be the centre of music listening as well as movie nights.

There is value in having different ways to use the same speaker system. Wired inputs, network sources and everyday wireless playback cover different situations. I would check the current availability of any particular online music service before relying on it, since regional access and third-party services can change. The physical connections remain an important part of the receiver’s versatility.

Yamaha — RX-V683

Connections that give a system options

Six HDMI inputs and one HDMI output give you space for several sources and a main display. There are also analogue and digital audio inputs, plus two mono subwoofer outputs. A receiver like this makes sense when you want one place to manage a collection of equipment instead of repeatedly moving cables between devices.

Powered Zone 2 and bi-amping are useful configuration options, but they share the available amplifier channels. I would plan the main-room layout before assigning those channels elsewhere. The number of speaker terminals on the back does not mean every possible combination can play at once. Knowing that makes the flexibility genuinely useful rather than confusing.

Yamaha — Owner’s manual

The limits to understand today

The video specification belongs to the 4K/60 generation. Yamaha lists HDR10, Dolby Vision and HLG compatibility, which covers an important range of film and television sources. It is not a 4K/120 video-switching receiver, so a modern high-refresh-rate console or PC setup needs a different connection plan.

It is also a substantial component: Yamaha lists a width of 435 mm, a height of 171 mm, a depth of 378 mm and a weight of 10 kg. Allow suitable shelf space and ventilation rather than treating it like a small streaming box. A receiver is the centre of a wired system, and the equipment space and cable planning are part of that choice.

Yamaha — Specifications

Why it earns my 8/10

The RX-V683 brings together the things that make an AV receiver worth considering: Atmos and DTS:X decoding, useful calibration, several kinds of input and the ability to choose your own speakers. Its appeal is that the system can be built around your priorities rather than being fixed inside one all-in-one product.

My rating is 8/10. It is a capable, flexible foundation for a sensibly planned home cinema. I would judge it on those strengths while being realistic about its seven-channel amplification and older video capabilities. Match the receiver to the room, sources and speaker layout you want, and its purpose is easy to understand.

Feature information is checked against Yamaha’s documentation. This review discusses the receiver’s capabilities; it does not present room-specific listening tests or measurements.

8/10

My verdict

8/10. A versatile home-cinema receiver with Dolby Atmos, DTS:X and useful setup tools. Particularly appealing for a planned 5.1.2 system, provided its channel count and 4K/60 video capabilities fit your needs.

— Desly

Bose SoundTouch 20 — a compact speaker with lasting appeal

Mon, 26 Oct 2026 09:53:05 +0100

The Bose SoundTouch 20 gets a 9/10 from me. What I value about it is the combination: a compact speaker built around music, a design that feels comfortable in a home, and controls you can understand without turning listening into a project. Its appeal goes beyond a list of connected features. A speaker can be satisfying because the basic idea is right.

A lot of music in a modest space

The main attraction is room-filling sound from a single, compact enclosure. That is how Bose described the SoundTouch 20 Series III at launch, and it captures what makes this speaker appealing: a proper home-music system without a rack of equipment or separate speaker stands. There is an elegance to giving music a dedicated place while keeping the setup manageable.

For me, the positive here is the balance between presence and practicality. A speaker should make you want to put music on. The SoundTouch 20’s straightforward, music-first approach is a big part of why I rate it so highly. It is a different proposition from building a carefully positioned hi-fi system, and that simplicity has a value of its own.

Bose — SoundTouch introduction

A design that belongs in the room

The restrained cabinet, front grille and central display give it an identity without demanding all the attention. It looks like a home speaker, with the information and controls where you expect them. I like that sense of purpose: the design serves the music rather than becoming another thing to manage.

The Series III’s published dimensions are approximately 18.8 × 31.4 × 10.4 cm. That gives a useful idea of its footprint: wide enough to feel substantial, but compact enough to consider for a shelf or sideboard. This is a mains-powered home system, so its strength is fitting into a room rather than being a battery-powered travel companion.

Physical controls are still a good idea

One of the nicest parts of the SoundTouch design is that interaction does not begin and end with a phone screen. The top-panel buttons and remote provide direct access to everyday controls, and the front display makes the system’s state visible. There is something reassuring about being able to reach for a volume button or a remote.

The six numbered preset buttons were a distinctive part of the original SoundTouch idea. They show how much thought went into making a connected speaker feel familiar. Their current usefulness depends on the service changes described below, but the broader design lesson still holds: convenient hardware controls make a speaker more approachable.

Useful connections give the hardware a longer life

The 3.5 mm AUX input is an important positive. A wired audio path keeps the speaker useful with a compatible external source, without requiring every listening session to depend on the original streaming platform. It is a simple connection, but simple connections often age well.

Generation matters when discussing wireless features. Bluetooth is available on the SoundTouch 20 Series III; earlier SoundTouch 20 models should not automatically be assumed to have the same feature set. Check the exact version when matching a speaker to a phone or streamer. That distinction leaves the review fair to the whole SoundTouch 20 family.

Bose — SoundTouch 20 Series III owner’s guide

The current SoundTouch situation

Bose ended SoundTouch cloud services on 6 May 2026. The updated app retains local setup, control and grouping, but in-app music browsing is gone, presets are limited, and security updates have ended. AUX and supported Bluetooth remain useful. This changes the connected experience, so I would check the current Bose guidance before buying a used unit.

Bose — SoundTouch service guidance

Why I still give it 9/10

The SoundTouch 20’s strongest qualities are easy to appreciate: a compact home-friendly design, the promise of substantial music from one box, a visible display, physical controls and a wired input that keeps its usefulness from being entirely tied to cloud services. Those are practical strengths, not just features for a specification sheet.

My 9/10 reflects how positively I feel about the speaker itself. The software story deserves an honest mention, but it does not erase the appeal of the hardware. I like products with a clear purpose, and the SoundTouch 20 has one: make listening to music at home feel welcoming and uncomplicated.

Product information: Bose launch announcement and Series III owner’s guide. Current service status: Bose SoundTouch guidance. Connectivity differs by generation.

9/10

My verdict

9/10. A compact, thoughtfully designed home speaker with strong everyday appeal. Its music-first approach and direct controls are the positives I value most; check the exact series and current service support when considering one today.

— Desly

Dorothy — Karthik Subbaraj does it again

Sat, 24 Oct 2026 15:20:43 +0200

Spoiler-free review.

Karthik Subbaraj has done it again. Dorothy left me with that feeling of having watched a filmmaker return to something that matters deeply to him. There is a force to the film that makes me want to talk about it afterwards, and a large part of my response comes from the people inside its rough, unforgiving world. This is a 9/10 film for me.

The feeling of Iraivi

The film brought back something of the feeling of Iraivi, which remains one of the best films Karthik Subbaraj has made. It is a comparison I mean as a compliment. What connects them for me is the discomfort around men, the power they assume they have, and the damage that can follow when pride becomes more important than another person.

Dorothy is set around Madurai in the 1990s and follows the friendship between Subbu and Karthi. Their lives take shape in a community governed by caste divisions, family authority and rigid expectations of masculinity. That setting gives the friendship a difficult question to carry: how much room is there for someone you love to become a person you did not expect?

This is where the Iraivi feeling stayed with me. The attraction is not simply to a dark story or to characters making terrible choices. It is to a filmmaker looking closely at the ideas people inherit and the cost of refusing to question them. I like Karthik Subbaraj most when the drama gives those ideas a human consequence. Dorothy belongs in that conversation for me.

Why this subject matters now

The subject feels relevant well beyond the period in which the film is set. Caste prejudice, the policing of masculinity, and the belief that a family can decide how someone must live are not comfortably distant problems. A change of decade does not automatically change those attitudes. That is why the film’s questions about identity and acceptance matter to me now: they concern the freedom to live with dignity, without having to earn it through obedience.

For me, the difficult question is what acceptance looks like when it asks something of us. It is easy to support the idea of compassion while still expecting another person to fit our familiar categories. Can we listen when their experience unsettles those expectations? Can affection survive the loss of control? I value Dorothy for bringing that discomfort into a film people will watch and argue about together. A film cannot settle these issues, but it can make avoiding them harder.

Sananth and Rishikanth feel like one of us

Sananth and Rishikanth give the subject a personal weight. As Subbu, Sananth has to make vulnerability feel like part of a whole person, rather than a quality attached to an argument. Rishikanth’s Karthi carries the strain of trying to reconcile affection with what he has been taught to believe. Their performances give the friendship its emotional stakes. I wanted to stay with these people even when the relationship became uncomfortable.

There is another reason I felt close to the leads: they feel like one of us. Watching them take on these roles brought the satisfaction of seeing people who have kept trying finally get a part that lets them show what they can do. I am rooting for them as actors as well as following their characters. Their performances deserve recognition on their own, and knowing something of the road behind them makes that recognition feel more personal.

That feeling has a real background. In their interview with The News Minute, both actors spoke about years of short-film work, patience and waiting for a breakthrough. Rishikanth also described his roughly fifteen-year journey from Thanjavur to leading roles in The Hollywood Reporter India. Those accounts help explain my sense of connection. A career built over years can look sudden from the audience’s side; I am glad Dorothy gives their work this visibility.

Keerthy Suresh plays Dorothy, whose presence introduces compassion into this harsh household. Her role is important to the way the film sets tenderness against the rules surrounding its characters. It also helps explain why the story needs more than violence to make its point. The possibility of care has to exist within the world that is trying to crush it.

Vettai Muthukumar’s Whistle Veeraiyya

Vettai Muthukumar was a real surprise for me as Whistle Veeraiyya. He is the performance I particularly wanted to mention after watching the film. The character’s attachment to authority and family pride gives the role a threatening weight, and Muthukumar makes that presence difficult to dismiss. I was struck by how strongly he came through in a film with so much else going on.

A role like this matters because the pressure on the central characters needs a human face. Whistle Veeraiyya represents a way of thinking that treats obedience as a duty and difference as a challenge to power. Muthukumar’s portrayal gave me a strong reason to pay attention to the supporting cast as well as the leads. It is one of the things I will remember about Dorothy.

Ilaiyaraaja gives the emotion its music

Ilaiyaraaja’s music is one of the things I loved about Dorothy. His score brings an emotional depth that sits beautifully alongside the performances. There is tenderness in it, but also the weight this harsh world needs. The music makes room for the characters’ vulnerability and gives their relationships another way to reach us.

What I appreciate most is how the score connects the film’s roughness with its compassion. The tension matters, but so do the moments when we are allowed to feel close to these people. Ilaiyaraaja gives those feelings a musical life of their own. His contribution is a major part of why Dorothy’s emotional pull stays with me after the film is over.

I would also love to experience Dorothy with Santhosh Narayanan’s music. That is an additional version I would be curious to watch, because I enjoy his musical connection with Karthik Subbaraj. It takes nothing away from my admiration for Ilaiyaraaja’s work here; I can love this score and still be excited by what another composer might bring to the same film.

Why it is a 9/10 for me

The film’s visual approach also gives it a distinct identity, with colour and monochrome separating different parts of the story. I will leave the larger narrative turns alone; this is a film I would rather discuss in detail after someone has watched it. My strongest response is already clear: the Iraivi connection, the central friendship, and Muthukumar’s surprising presence give me plenty to return to.

9/10. Dorothy reminded me why I keep looking forward to Karthik Subbaraj’s work. The leads make the central relationship matter, Vettai Muthukumar is a striking surprise, and Ilaiyaraaja’s music deepens the feeling throughout. Alongside its relevant subject and the connection I felt to Iraivi, those are the reasons I recommend it so enthusiastically.

Background reading: Scroll — Nandini Ramnath · The Times of India — M Suganth · Rediff — Sreeju Sudhakaran · The Indian Express — Anandu Suresh · The News Minute — interview with Sananth and Rishikanth · The Hollywood Reporter India — Rishikanth interview

2026 · Tamil. Film details · Poster source · Artwork © its respective rights holders.

9/10

My verdict

Karthik Subbaraj does it again. The feeling of Iraivi, Vettai Muthukumar’s surprising Whistle Veeraiyya, and Ilaiyaraaja’s deeply moving music make Dorothy a film that stays with me. 9/10.

— Desly

Building an internal developer platform without a big team

Tue, 20 Oct 2026 23:10:30 +0200

When people hear "internal developer platform", they picture something huge. A shiny portal, dozens of integrations, a team of twenty, a year-long roadmap. No wonder smaller companies think it isn't for them.

I think that picture is wrong. A platform isn't a portal. It's whatever makes it easy for developers to get their code into production safely, without opening a ticket. That can start very small.

What a platform actually is (and isn't)

An internal developer platform is a set of tools, templates and automation that lets developers serve themselves. Typical building blocks:

A way to create new services from a template, with a repo, pipeline and basic config already wired up.
CI/CD that works the same way for every service.
Environments that can be created and destroyed without asking anyone.
Observability that is on by default: logs, metrics and traces without extra work.
A catalog that answers "who owns this service, and where does it run?"

What a platform isn't: a tool you install. Buying Backstage or any other portal doesn't give you a platform, just like buying a gym membership doesn't make you fit.

The smallest platform that's still useful

If I had to start from zero with a small team, I'd begin with one thing: a golden path for the most common type of service in the company.

Say most of your services are small HTTP APIs in one language. The golden path could be:

A repository template with the code skeleton, a Dockerfile and a health endpoint.
A shared pipeline that builds, tests, scans and deploys it.
A Helm chart or Kustomize base with sane defaults for resources, probes and security.
Dashboards and alerts that appear automatically when the service is deployed.

That's it. No portal yet. A developer runs one command or clicks "use this template" on GitHub, and twenty minutes later their service is running in a test environment with monitoring.

A platform is successful when developers choose it because it's easier, not because they're forced to.

Build or buy: Backstage, Port and friends

Once the golden path works and you have more than one, a portal starts to make sense. It gives the templates a home and adds a catalog.

Backstage is open source and very flexible. It's also real software you have to run, upgrade and extend, often with TypeScript.
Port, Cortex, OpsLevel and others are SaaS. Faster to start, less control, monthly bill.
A simple wiki page plus GitHub templates is a perfectly fine first version. Seriously.

My rule: don't introduce a portal until you have something worth putting in it.

How I'd measure if anyone uses it

A platform is a product, and products need feedback. A few numbers I'd track:

Time to first deploy for a new service. Days becoming minutes is the headline win.
Adoption: how many services use the golden path versus custom setups.
Tickets to the ops team for routine requests. This should drop.
Developer satisfaction: a short survey every quarter. Ask what's annoying, not just what's good.

And talk to developers. Sit with someone while they create a new service. Every place they hesitate or ask a question is a bug in your platform.

What I'd tell someone starting today

Start with the most painful, most frequent task. Automate that properly. Make it so good that people ask for more. Then pick the next thing.

Don't try to cover every edge case. Keep an escape hatch so teams with unusual needs can still do their own thing. A platform that blocks people becomes the new wall DevOps was supposed to tear down.

So, can a small team do it?

Yes. A small team can't build everything, but it doesn't need to. One golden path that really works beats a portal full of half-finished features.

My take: start with one road, pave it well, and let people's footsteps tell you where to build the next one.

— Desly

I set up Backstage. Here's what happened

Tue, 20 Oct 2026 23:10:30 +0200

Backstage comes up in almost every conversation about platform engineering. Spotify built it, open-sourced it, donated it to the CNCF, and now it's the default answer to "how do we build a developer portal?"

I wanted to know what it's really like to get running, beyond the conference demos. So I set it up from scratch with a realistic goal: a service catalog, one software template, and documentation in the same place.

Why I tried it

The problem Backstage solves is very real. In most companies, nobody can answer simple questions quickly. Who owns this service? Where is its documentation? Which pipeline deploys it? What does it depend on?

The answers are scattered across wikis, spreadsheets, Slack threads and people's memory. Backstage promises one place to find all of it.

Getting the catalog running

Getting a local instance up is easy. You need Node.js and Yarn, then:

npx @backstage/create-app@latest
cd my-backstage-app
yarn start

A few minutes later there's a portal on localhost:3000. The first surprise: what you've created isn't a product you configure. It's an application you own. You'll be maintaining a TypeScript codebase from now on.

The catalog works by reading a small YAML file from each repository:

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: shop-api
  description: Handles orders and payments
  annotations:
    github.com/project-slug: my-org/shop-api
spec:
  type: service
  lifecycle: production
  owner: team-checkout

Add this catalog-info.yaml to each repo, point Backstage at your GitHub organisation, and services start appearing. This part felt genuinely good. Seeing every service, its owner and its links in one list is already useful.

My first software template

Templates are where Backstage becomes a platform instead of a directory. A template is a form plus a set of steps: ask the developer a few questions, copy a skeleton, fill in the values, create a repository, register it in the catalog.

The template YAML takes some getting used to, but the result is great: a developer fills in a name and a team, clicks "Create", and gets a new repo with a pipeline and a catalog entry. That's the golden path in action.

The plugins worth installing

The plugin ecosystem is large. The ones I'd add first:

Kubernetes: shows the pods and deployments for each service.
GitHub Actions (or your CI): recent pipeline runs right on the service page.
TechDocs: Markdown docs from the repo, rendered inside Backstage.
Search: makes the whole thing usable once you have more than a handful of services.

Backstage is less like installing an app and more like adopting a pet. It's lovely, but it needs feeding every week.

What annoyed me

It's a framework, not a product. Anything beyond the basics means writing TypeScript and React. If your team has no frontend skills, plan for that.

Upgrades take effort. Backstage moves fast. Keeping up with releases, and the migration to its newer backend and frontend systems, is ongoing work.

The catalog drifts. Owners change, services get retired, YAML files go stale. Without someone caring about data quality, the catalog slowly becomes the next out-of-date wiki.

Authentication and permissions need real configuration before you can roll it out beyond a demo.

Would I recommend it?

For a company with many teams and dozens of services, yes. Once it's set up, it's a strong foundation, and nothing else open source comes close.

For a small team with ten services, probably not yet. A good README template and a list of services in your wiki might give you 80% of the value for 5% of the effort. And if you want a portal without running one, look at the SaaS options.

My take: Backstage is a great platform for building your portal, not a portal you just switch on. Go in knowing that, and it's worth it.

— Desly

A fresh environment for every pull request

Tue, 20 Oct 2026 23:10:30 +0200

Almost every team I've worked with has had a "staging" environment. And almost every team has had the same conversation in Slack: "Who deployed to staging? My changes are gone." "Can you not deploy for an hour, I'm testing something?" "Staging is broken again, does anyone know why?"

One shared environment for many developers creates a bottleneck. Preview environments eliminate that bottleneck.

Why shared staging hurts

Changes collide. Two feature branches deployed to the same place overwrite each other.
It's always slightly broken. Someone's half-finished change is always there.
Feedback is slow. Reviewers, testers and product managers can't see a change until it's merged.
Nobody trusts it. And an environment nobody trusts is an environment nobody tests in properly.

How preview environments work

The idea is simple. When a pull request is opened, the pipeline creates a temporary copy of the application just for that branch, with its own URL like pr-142.preview.example.com. When the pull request is merged or closed, the environment is deleted.

On Kubernetes, there are a few common ways to build this:

A namespace per pull request. The simplest approach. The pipeline creates a namespace, deploys the Helm chart with the branch's image tag, and sets up an ingress or HTTPRoute for the preview hostname.

Argo CD ApplicationSets with the pull request generator. Argo CD watches your repository and automatically creates an Application for every open pull request, and removes it when the PR closes. No custom scripts.

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: shop-previews
spec:
  generators:
  - pullRequest:
      github:
        owner: my-org
        repo: shop
      requeueAfterSeconds: 120
  template:
    metadata:
      name: 'shop-pr-{{number}}'
    spec:
      project: previews
      source:
        repoURL: https://github.com/my-org/shop
        targetRevision: '{{head_sha}}'
        path: deploy/chart
        helm:
          parameters:
          - name: image.tag
            value: '{{head_sha}}'
          - name: ingress.host
            value: 'pr-{{number}}.preview.example.com'
      destination:
        server: https://kubernetes.default.svc
        namespace: 'shop-pr-{{number}}'
      syncPolicy:
        automated: { prune: true }
        syncOptions: [CreateNamespace=true]

Virtual clusters (vCluster). When teams need cluster-level resources like CRDs, a virtual cluster per pull request gives full isolation without paying for a real cluster each time.

The best review comment is "I clicked through it and it works", and preview environments make that possible before merging.

Data and secrets: the hard part

Deploying the app is the easy bit. The tricky questions:

Databases. Options range from a small database container seeded with test data, to a shared database with a separate schema per PR, to snapshots of an anonymised dataset. Never copy production data with personal information into previews.
External services. Payment providers, email, third-party APIs. Use sandbox accounts or mocks.
Secrets. Previews should get their own limited credentials, ideally through External Secrets or your secret manager, not copies of staging secrets.
Wildcard DNS and TLS. A wildcard record like *.preview.example.com and a wildcard certificate (cert-manager handles this) make new hostnames work instantly.

Cleaning up so the bill stays small

Preview environments can quietly become expensive. Fifty open pull requests means fifty copies of your app.

What helps:

Delete on close, always. ApplicationSets do this automatically. With scripts, make sure the cleanup job runs even when the pipeline fails.
Time-to-live. Delete previews that haven't been updated for a few days, even if the PR is still open.
Small resources. Previews don't need production sizing. One replica, low requests.
Spot or preemptible nodes for the preview node pool.
Scale to zero at night with a simple scheduled job, or with tools that wake environments up on the first request.

So, is it worth it?

For teams with more than a few developers working in parallel, yes. Reviews get better, testing happens earlier, and the "who broke staging" messages disappear. Start with a namespace per PR, add data and cleanup properly, and grow from there.

My take: give every change its own little world. It's cheaper than the time your team loses waiting for staging.

— Desly

Kubernetes as a control plane for everything: Crossplane v2

Tue, 20 Oct 2026 23:10:30 +0200

Here's a common situation. A developer needs a database for a new service. They open a ticket. Someone on the ops team writes some Terraform, opens a pull request, waits for review, applies it, and sends back the connection details. Two days later, the developer can finally start.

Crossplane asks a different question: what if the developer could just write a small YAML file, the same way they deploy their app, and get a properly configured database a few minutes later?

The idea in one paragraph

Kubernetes is very good at one thing: you describe what you want, and controllers keep working until reality matches. Crossplane extends that idea beyond containers. It adds controllers that create and manage cloud resources: databases, buckets, queues, networks, DNS records. You write YAML, Crossplane talks to AWS, Azure or Google Cloud, and keeps the resource in the state you described.

The really interesting part isn't managing raw cloud resources. It's building your own APIs on top of them.

Compositions: your own platform API

With Crossplane, the platform team defines a simple, company-specific resource, for example Database, with only the fields developers should care about:

apiVersion: platform.example.com/v1alpha1
kind: Database
metadata:
  name: orders-db
  namespace: shop
spec:
  engine: postgres
  size: small

Behind the scenes, a Composition turns that into everything the company requires: an RDS instance with the right version, encryption, backups, a subnet group, security group rules, monitoring, and a Kubernetes secret with the connection details. The developer sees five lines. The platform team controls the other two hundred.

The schema of that custom resource is defined in a CompositeResourceDefinition (XRD). That's where you set what's allowed: maybe only small, medium and large, maybe only Postgres.

Crossplane lets the platform team turn "how we do databases here" into an API instead of a wiki page.

What changed in v2

Crossplane v2 simplified the model in a few important ways:

Namespaced resources by default. In v1, you usually needed a cluster-scoped composite resource plus a namespaced "claim". v2 lets composite resources live directly in a team's namespace, so the claim layer mostly goes away.
Compose anything. Compositions can now include any Kubernetes resource, not just Crossplane-managed cloud resources. You can bundle a Deployment, a Service and a cloud database into one higher-level "App" API.
Composition functions are the standard way to write the logic, in YAML templates, Go, Python or KCL, instead of the old patch-and-transform style.

If you tried Crossplane a few years ago and found it heavy, v2 is worth a second look.

Crossplane or Terraform?

This question always comes up, and the honest answer is: they're good at different things.

Terraform (or OpenTofu) is great for infrastructure that the platform team owns and changes deliberately: networks, clusters, accounts. It runs when you run it, shows a plan, and stops.

Crossplane is great for self-service resources that many teams need, many times: databases, buckets, queues per service. It runs continuously, fixes drift automatically, and fits into GitOps with Argo CD or Flux.

Many teams use both. Terraform builds the foundation, including the cluster that runs Crossplane. Crossplane offers the self-service layer on top.

Building a "give me a database" API

If I were trying Crossplane for the first time, I'd keep the scope tiny:

Install Crossplane with Helm into a test cluster.
Install the provider for your cloud, and give it credentials through workload identity rather than static keys.
Write an XRD for a Database with two fields.
Write a Composition that creates a small managed database and a connection secret.
Create one Database in a namespace and watch it appear in your cloud console.

Then show it to a developer and ask whether it's useful. That conversation is more valuable than any architecture diagram.

What to watch out for

Debugging is harder than reading a Terraform plan. Learn kubectl describe and Crossplane's trace tooling early.
Deletion is real. Deleting the YAML deletes the database. Use deletion policies and protect production resources.
Provider size. Some providers install hundreds of CRDs. Use the smaller "family" providers for only the services you need.

My take: Crossplane shines when you treat it as a way to build your own platform API, not just another way to write infrastructure.

— Desly

AI agents in my pipeline: what actually works

Tue, 20 Oct 2026 23:10:30 +0200

In Will AI take my DevOps job? I wrote that AI is like a very fast junior engineer who never gets tired and never quite knows when it's wrong. I also said a new part of my job would be building guardrails for AI agents.

This post is the practical follow-up. Not "will AI change DevOps", but: which tasks can you hand to an agent today, and how do you set it up so a mistake stays small?

What changed

A year or two ago, AI in DevOps mostly meant autocomplete in the editor, or pasting an error into a chat window. Useful, but you were always in the driver's seat.

Agents are different. Tools like Claude Code, GitHub Copilot's coding agent, Cursor's background agents and others can take a task, read the repository, run commands, look at the results, try again, and open a pull request. They work in a loop, not a single answer.

That makes them much more useful, and much more important to control.

Tasks I'm comfortable handing to agents

The pattern is: well-defined, easy to verify, and reviewed before it reaches production.

Fixing a failing build. "The pipeline fails on this test, find out why and propose a fix." The agent reads the logs, reproduces the failure, and suggests a change. A human reviews the pull request.

Dependency upgrades that need code changes. Renovate opens the upgrade, the tests fail because an API changed, the agent updates the call sites.

Boring infrastructure changes. Adding a new environment variable across services, updating resource requests in Helm values, renaming a label everywhere.

Writing first drafts. A new pipeline, a Dockerfile, a Terraform module skeleton, a runbook from an incident timeline.

Explaining and documenting. "What does this old script do?" turned into a README.

The permissions I give them (and don't)

This is the part that matters most. My rules:

Agents work on branches, never on main. Every change goes through a pull request and normal review.
No production credentials. Ever. Agents run in CI or a sandbox with access to the repository and test environments only.
Short-lived, narrow tokens. A GitHub token that can push to branches and open pull requests, not one that can change repository settings or approve its own PRs.
Branch protection does the enforcement. Required reviews and required checks apply to agents exactly like they apply to people.
Network limits where possible. An agent fixing a unit test doesn't need to reach the whole internet.
Everything is logged. What the agent ran, what it changed, who started it.

Treat an AI agent like a new contractor on their first day: helpful, eager, and with exactly the access the task needs, nothing more.

Where they still fail

Agents are impressive, but I see the same failure patterns again and again:

Making the test pass instead of fixing the bug. Sometimes the "fix" is changing the test's expectation. Read the diff carefully.
Missing context. The agent doesn't know that setting exists because of an outage three years ago. It will happily "clean it up".
Overly broad permissions in generated IAM policies or Kubernetes RBAC. * is always tempting.
Prompt injection. An agent reading issues, logs or web pages can be tricked by text written to manipulate it. Never give an agent that reads untrusted input the power to do something irreversible.
Confidence. It always sounds sure. That's not the same as being right.

My setup, step by step

If you want to try this on your team, here's a safe starting point:

Pick one repository with good test coverage.
Create a dedicated bot identity with branch-only push rights.
Run the agent in CI (or a container) triggered by a label or comment, for example adding agent:fix to a failing PR.
Give it a clear instructions file in the repo: how to build, how to test, what not to touch.
Require human review for every pull request it opens.
Track results for a month: how many PRs merged, how many needed rework, how many were wrong.

After a month you'll know where it actually saves time on your team, which beats any vendor benchmark.

So, is it worth it?

Yes, for the right tasks. Agents remove a lot of small, annoying work, and they're getting better quickly. But the value depends entirely on the guardrails around them. Good tests, good reviews and narrow permissions turn an agent from a risk into a very productive teammate.

My take: let agents propose, let pipelines check, and let humans decide. Same rule as before, now with real tools behind it.

— Desly

Can AI help at 3 a.m.? AI in incident response

Tue, 20 Oct 2026 23:10:30 +0200

In Will AI take my DevOps job? I said two things about incidents. AI is very good at reading logs. And humans still have to own the decision. This post goes deeper into what that looks like in practice, step by step through an incident.

A typical incident, with AI in the loop

Let's walk through a realistic scenario. Error rates on the checkout service jump at 03:12. The on-call engineer gets paged.

Minute 0 to 5: understanding what's happening. Without AI, this means opening dashboards, checking recent deployments, grepping logs. With an AI assistant connected to observability tools (through MCP or a vendor integration), you can ask: "What changed in the checkout service in the last hour, and what do the error logs say?"

A good assistant will come back with something like: a deployment at 03:05, a new error appearing at 03:11 (connection timeouts to the payments database), and a spike in database connection count. In a few seconds, it did what used to take ten minutes of clicking.

Minute 5 to 15: forming a hypothesis. The AI suggests the new release changed the connection pool settings. It points to the diff. That's useful, and it might be right.

Minute 15: the decision. Roll back the release, or increase the database connection limit? Wake up the database team? Tell customers? This is where the human takes over. The AI can list options and their risks. It can't take responsibility for choosing.

AI shortens the time to understand an incident. It doesn't shorten the time it takes to be accountable for the fix.

What AI is genuinely good at during incidents

Summarising huge amounts of data. Thousands of log lines, dozens of alerts, multiple dashboards, condensed into "here's what's unusual".
Correlating with changes. Linking errors to recent deployments, config changes or feature flag flips.
Searching past incidents. "Have we seen this error before?" across old postmortems and tickets.
Keeping the timeline. Recording what happened, who did what, and when, while people focus on fixing.
Drafting status updates. A clear, calm customer-facing message, ready for a human to approve.

What it gets wrong

I've seen AI make the same kinds of mistakes in incident scenarios:

Blaming the most recent change even when it's a coincidence. Correlation is not cause.
Missing the real cause outside its view. If it can only see application logs, it won't notice the cloud provider's network issue.
Hallucinating details: a config value or a metric that doesn't exist.
Sounding certain when the evidence is thin.

So the rule for on-call engineers: treat AI conclusions as hypotheses to verify, not answers to act on. Ask it to show the evidence: the log line, the metric, the diff.

Checking AI's conclusions

A simple routine that works well:

Ask the AI what it thinks happened.
Ask it for the specific evidence behind each claim.
Check that evidence yourself in the original tool.
Ask it what else could explain the same symptoms.

That fourth question is underrated. It helps you avoid locking onto the first theory, which is a classic human mistake during incidents too.

Writing the postmortem together

After the incident, AI is a big help with the part nobody enjoys: writing it up.

Give it the incident channel, the timeline and the relevant graphs, and ask for a first draft of a blameless postmortem: summary, impact, timeline, root cause, contributing factors, action items. Then edit it properly. The AI gives you structure, but the insights about why the system allowed this to happen need human thinking.

Tools worth a look

Many incident and observability platforms now include AI features: incident.io, Rootly, PagerDuty, Datadog, Grafana, New Relic and others. There's also a new wave of "AI SRE" products that investigate alerts on their own. Try them on past incidents first: replay an old incident and see whether the AI would have found the cause.

So, can AI help at 3 a.m.?

Yes, a lot. It makes the first fifteen minutes of an incident much faster and less stressful. But the person holding the pager still makes the calls, and that's how it should be.

My take: let AI do the reading, and keep the deciding for yourself. Especially at 3 a.m.

— Desly

From a container to Kubernetes: serving models for real

Tue, 20 Oct 2026 23:10:30 +0200

In AI & MLOps, from the ground up, I described my 24-week plan: a notebook, then a tested package, a tracked pipeline, an API with FastAPI, a container, and eventually a deployment in the cloud with monitoring.

A container is a great milestone. But a single container on a laptop isn't how models run in production. This post looks at the next step: what changes when you move model serving onto Kubernetes, and what's different when the model is a large language model that needs GPUs.

Where my project stands

The plan's core project is a classic machine learning model: scikit-learn, served by FastAPI, packaged with Docker. For that kind of model, Kubernetes deployment is close to any other web service. A Deployment, a Service, health checks, resource requests, and a HorizontalPodAutoscaler.

LLMs are a different world. The model files are gigabytes, they need GPUs, they load slowly, and one request can take seconds. That's where the interesting DevOps problems are.

Why Docker alone isn't enough anymore

A single container can't:

Scale with traffic, up or down.
Restart itself on another machine if the machine dies.
Roll out a new model version gradually and roll back if quality drops.
Share expensive GPU machines between workloads.

Kubernetes handles all of that. The model becomes just another workload, using the same pipelines, monitoring and security as everything else.

vLLM, KServe and the other options

The serving stack for LLMs on Kubernetes usually has two layers.

The inference engine actually runs the model:

vLLM is the most popular open-source engine. It's fast thanks to clever memory management and batching, and exposes an OpenAI-compatible API.
Hugging Face TGI, SGLang and NVIDIA Triton / TensorRT-LLM are alternatives with different strengths.
Ollama is great on a laptop and for small setups, less so for heavy production traffic.

The serving platform manages the engine on Kubernetes:

KServe gives you an InferenceService resource: you describe the model and runtime, and it handles deployment, scaling and routing, including scale to zero.
llm-d is a newer project focused on distributed LLM inference on Kubernetes, with smart routing that sends requests to the replica most likely to have the right data cached.
Or just a plain Deployment running vLLM, which is a perfectly fine way to start.

A minimal vLLM deployment looks like this:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: llm
spec:
  replicas: 1
  selector:
    matchLabels: { app: llm }
  template:
    metadata:
      labels: { app: llm }
    spec:
      containers:
      - name: vllm
        image: vllm/vllm-openai:latest   # pin a specific version in real use
        args: ["--model", "Qwen/Qwen2.5-1.5B-Instruct"]
        ports:
        - containerPort: 8000
        resources:
          limits:
            nvidia.com/gpu: 1
        readinessProbe:
          httpGet: { path: /health, port: 8000 }
          initialDelaySeconds: 60

Serving a model is the easy demo. Serving it reliably, cheaply and at scale is the actual MLOps job.

GPUs: scheduling and cost

GPUs change how you run Kubernetes:

Device plugins / GPU Operator. The NVIDIA GPU Operator installs drivers and the device plugin so pods can request nvidia.com/gpu.
Dedicated node pools with taints, so only GPU workloads land on expensive GPU nodes.
Sharing GPUs with MIG (splitting one GPU into isolated slices) or time-slicing for smaller models.
Dynamic Resource Allocation (DRA), now stable in Kubernetes, gives a more flexible way to request specific kinds of GPUs and devices.

And cost: an idle GPU node can cost more per day than an entire small web application per month. Monitoring GPU utilisation (the DCGM exporter for Prometheus) is not optional.

Scaling on demand

CPU-based autoscaling doesn't work well for LLMs. A GPU can be fully busy while the CPU is idle. Better signals:

Queue length or pending requests in the inference engine.
Tokens per second or time to first token.
KEDA can scale on these metrics from Prometheus.

Also plan for slow starts. Downloading and loading a model can take minutes. Caching model files on a persistent volume or node-local storage, and keeping at least one warm replica, makes scaling far less painful.

What's next in the series

Next on my list: monitoring the model in production, including the quality of its answers, not just its uptime. That's where tools like Prometheus, Grafana and Evidently come in.

My take: Kubernetes doesn't make AI simple, but it makes AI workloads look like the rest of your infrastructure. And that's half the battle.

— Desly

I asked AI to write my Terraform. A reality check

Tue, 20 Oct 2026 23:10:30 +0200

In Will AI take my DevOps job? I warned that AI writes configuration that looks perfect and is subtly broken. A permission that's far too open. A setting that works in testing and falls over under real traffic.

It's easy to say. This post shows what it actually looks like and the workflow I use to stop it from getting into production.

The prompt

Here's the kind of request I'd give an AI assistant on an average day:

"Write Terraform for an AWS PostgreSQL database for a small web app, plus a security group so the app can connect."

Short, realistic, and missing a lot of context. Which is exactly how most of us write prompts.

What came back

The answer is usually a clean, well-formatted block of Terraform. It creates an RDS instance, a security group, and some variables. It probably works on the first try. But it often includes several of these issues:

resource "aws_security_group" "db" {
  name = "db-sg"

  ingress {
    from_port   = 5432
    to_port     = 5432
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]   # anyone on the internet
  }
}

resource "aws_db_instance" "main" {
  engine              = "postgres"
  instance_class      = "db.t3.micro"
  allocated_storage   = 20
  username            = "admin"
  password            = "ChangeMe123!"   # hardcoded secret
  publicly_accessible = true
  skip_final_snapshot = true
}

Nothing here is a syntax error. terraform plan is happy. And yet:

The mistakes, one by one

The database is reachable from the whole internet. 0.0.0.0/0 on port 5432, plus publicly_accessible = true. The app needed access, not the world.
A hardcoded password that will end up in Git and in the Terraform state.
No encryption at rest (storage_encrypted is missing).
No backups to speak of. No retention period set, and skip_final_snapshot = true means deleting the resource deletes your data with no snapshot.
No deletion protection. One wrong terraform destroy and it's gone.
No version pinned for the engine or the provider, so the next run might behave differently.
No tags, so cost tracking and ownership are unclear.

To be fair, if you ask the AI "is this secure?", it will usually find most of these problems. But that's the point: it gave you the insecure version first, and confidently.

AI writes Terraform the way a tutorial does: optimised to work on the first try, not to survive an audit.

What the linters catch

This is where boring tools earn their place. I ran this kind of code through:

terraform validate and terraform fmt: syntax and formatting. Necessary, but they catch none of the security problems above.
tflint with the AWS ruleset: invalid instance types, deprecated arguments, missing best practices.
Checkov or Trivy (config scanning): these catch the important ones. Open ingress, public database, missing encryption, missing backups, hardcoded secrets.
Secret scanning (gitleaks, GitHub push protection): catches the password before it's even pushed.

What they don't catch is whether the design fits your company's needs. Should this be Aurora instead? Will db.t3.micro handle real traffic? Does it belong in this VPC? That still needs a human who knows the context.

My workflow: generate, lint, test, review

Generate with context. Give the AI your conventions: "use our module X, never public, always encrypted, secrets from AWS Secrets Manager, tag with owner and cost-center." A rules file in the repo helps a lot here, so you don't have to repeat it every time.
Lint automatically. Pre-commit hooks for fmt, validate, tflint and Checkov, and the same checks in CI as required status checks.
Plan in CI and read the plan, not just the code.
Test where it matters: terraform test or a policy test for the rules that must never be broken.
Human review focused on design and intent, since the tools already checked the patterns.

Even better: point the AI at your existing, reviewed modules instead of letting it write raw resources. "Use our rds-postgres module" produces far safer results than "write me a database".

So, should you use AI for Terraform?

Yes. It's a big time saver for boilerplate, refactoring and explaining unfamiliar code. Just never treat its output as finished. Put it through the same pipeline you'd put a new colleague's first pull request through, because that's roughly what it is.

My take: AI is a great first draft writer for infrastructure. Your linters, your policies and your review are the editors, and in infrastructure, the editor matters most.

— Desly

Watching an AI app in production

Tue, 20 Oct 2026 23:10:30 +0200

My MLOps learning plan ends with monitoring dashboards, using Prometheus, Grafana and Evidently. When I wrote that plan, I thought of monitoring the way I do in DevOps: is it up, is it fast, is it throwing errors?

The more I learn, the clearer it gets that AI systems need a second layer. A model can be up, fast and error-free, and still give terrible answers. This post is about watching that second layer.

What to watch in an AI system

I think of it in three levels.

1. The usual service health. Everything we already monitor: request rate, error rate, latency, resource use. An AI service is still a service.

2. Model-specific operations. For LLM applications especially:

Tokens in and out per request
Cost per request, per user, per feature
Time to first token and total response time
Which model and which prompt version handled each request
Tool calls made by agents, and whether they succeeded

3. Quality. The hard one:

Are the answers correct and helpful?
For classic ML models: is the input data drifting away from what the model was trained on? Are predictions shifting?
For LLMs: hallucinations, refusals, off-topic answers, unsafe content.

For normal software, "no errors" means it's working. For AI, "no errors" just means it's confidently doing something.

Tracing an LLM request

A single request to an AI feature can involve many steps: retrieving documents, building a prompt, calling a model, calling tools, calling the model again. When the answer is bad, you need to see every step.

That's exactly what distributed tracing does. Each step becomes a span, with the inputs, outputs, tokens, cost and timing attached. When a user complains, you can open the trace and see that, for example, the retrieval step returned the wrong documents.

OpenTelemetry for AI

OpenTelemetry, which many of us already use for normal services, has semantic conventions for generative AI: standard attribute names for things like the model used, token counts and operation type. Libraries like OpenLLMetry add automatic instrumentation for popular LLM SDKs and frameworks.

The benefit: AI traces can flow into the same backend as the rest of your traces (Tempo, Jaeger, Datadog, Honeycomb and so on), so you see the AI step inside the full user request.

One important warning: prompts and responses can contain personal data. Decide carefully what you record, mask sensitive fields, and set retention limits.

Tools I'd look at

Besides general observability tools, there's a group of tools built for LLM applications:

Langfuse: open source, can be self-hosted. Traces, prompt management, cost tracking and evaluations.
Arize Phoenix: open source, strong on tracing and evaluation, built on OpenTelemetry.
Evidently: for classic ML, strong on data drift and model quality reports, and it now covers LLM evaluations too.
Many APM vendors now have LLM features built in.

For my learning project, I'd start with Evidently for the classic model (it's already in the plan) and try Langfuse or Phoenix once an LLM is involved.

Evaluations in CI

Monitoring tells you about problems after users see them. Evaluations try to catch them before.

The idea: keep a set of test questions with good expected answers. Every time you change a prompt, a model or the retrieval logic, run the set and score the results, automatically or with another model as a judge. If quality drops, the pipeline fails, just like a failing unit test.

It's not perfect, because "good answer" is fuzzy. But a basic evaluation set catches a surprising number of regressions, especially when switching models.

What's next in the series

With monitoring in place, the loop is complete: build, test, deploy, watch, improve. Next, I want to look at what to do when monitoring shows drift: retraining, versioning and safe rollouts of new model versions.

My take: monitor AI systems twice. Once like any service, and once like a new colleague whose work you still need to check.

— Desly

Scaling on Kubernetes: HPA, VPA, KEDA and Karpenter

Tue, 20 Oct 2026 23:10:30 +0200

"Kubernetes scales automatically" is one of those sentences that's true and misleading at the same time. Kubernetes can scale automatically, but only if you set it up, and there are several different autoscalers that do very different things.

Here's how I explain them, and how they fit together.

Pods vs nodes

The first thing to understand: there are two levels of scaling.

Pod scaling: running more copies of your app (horizontal) or giving each copy more resources (vertical).
Node scaling: adding or removing machines so there's room for the pods.

You usually need both. The pod autoscaler creates pods, but if there's no room for them, they stay Pending until a node autoscaler adds capacity.

HPA: more copies when it gets busy

The Horizontal Pod Autoscaler is built into Kubernetes. It watches a metric and changes the number of replicas.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: shop-api
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: shop-api
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

CPU-based scaling works well for stateless web services. Two things to know:

Utilisation is measured relative to the pod's CPU request. Without requests, HPA can't work.
You can scale on custom metrics (requests per second, latency) with a metrics adapter, but that needs extra setup.

VPA: the right size for each pod

The Vertical Pod Autoscaler watches actual resource use and recommends, or sets, better requests and limits.

It's very useful in recommendation mode: run it for a week and it tells you what your pods actually need. In automatic mode it historically had to restart pods to change their resources. With in-place pod resize now stable in Kubernetes, that's getting much less disruptive.

Important: don't use VPA and HPA on the same CPU metric for the same workload. They'll fight each other.

KEDA: scaling on events

KEDA (Kubernetes Event-Driven Autoscaling) is a CNCF project that extends HPA with dozens of event sources: queue length in RabbitMQ, Kafka lag, SQS messages, Prometheus queries, cron schedules, and many more.

Its killer feature: scaling to zero. A worker that processes a queue can have zero pods when the queue is empty, and scale up when messages arrive.

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: order-worker
spec:
  scaleTargetRef:
    name: order-worker
  minReplicaCount: 0
  maxReplicaCount: 30
  triggers:
  - type: rabbitmq
    metadata:
      queueName: orders
      mode: QueueLength
      value: "20"
    authenticationRef:
      name: rabbitmq-auth

For background workers, KEDA is almost always a better fit than CPU-based HPA. CPU tells you how busy the workers are. Queue length tells you how much work is waiting.

Scale on the signal that represents the work, not the side effect of doing it.

Cluster Autoscaler vs Karpenter

For nodes, there are two main options.

Cluster Autoscaler is the classic. It works with node groups you define in advance. When pods are pending, it adds a node to a matching group. When nodes are underused, it removes them. Reliable, supported almost everywhere.

Karpenter started at AWS and is now a Kubernetes SIG project, with support for AWS and Azure. Instead of fixed node groups, it looks at the pending pods and picks the best instance type for them on the spot. It's faster, often cheaper, and good at consolidation: moving pods around so it can remove underused nodes or replace them with cheaper ones. It also handles Spot instances nicely.

On AWS, I'd choose Karpenter today. Elsewhere, use what your provider supports best, often their managed autoscaler.

Stopping the flapping

Autoscaling can oscillate: scale up, scale down, scale up again. Ways to calm it:

Stabilisation windows in the HPA behavior section, especially for scale-down (five minutes is a common start).
Sensible min replicas. At least two for anything user-facing.
Correct resource requests. Wrong requests make every autoscaler make wrong decisions.
PodDisruptionBudgets, so node consolidation doesn't take down all replicas at once.
Readiness probes that really reflect readiness, so new pods only get traffic when they can handle it.

Putting it together

A setup I like for a typical cluster:

HPA on CPU or requests per second for web services.
KEDA for queue workers and scheduled jobs, with scale to zero.
VPA in recommendation mode to keep requests honest.
Karpenter or Cluster Autoscaler to add and remove nodes as needed.

My take: autoscaling is a team sport. Get the requests right first, choose the right signal for each workload, and let the node autoscaler handle the rest.

— Desly

Requests and limits: the settings everyone gets wrong

Tue, 20 Oct 2026 23:10:30 +0200

If I had to pick the one Kubernetes setting that causes the most confusion, it would be resource requests and limits. They look simple: a few numbers in a YAML file. But they decide where your pod runs, how fast it is, whether it gets killed, and how much your cluster costs.

Let's go through what they actually do.

What requests and limits mean

resources:
  requests:
    cpu: 250m
    memory: 256Mi
  limits:
    cpu: "1"
    memory: 512Mi

Requests are what the pod is guaranteed. The scheduler uses them to decide which node has room. A node with 4 CPUs can fit pods whose CPU requests add up to about 4, regardless of how much they actually use.

Limits are the maximum the pod is allowed to use.

The key insight: CPU and memory behave completely differently when you hit the limit.

What actually happens when you hit a limit

CPU is compressible. If a container tries to use more CPU than its limit, it gets throttled. It doesn't crash, it just slows down. The kernel only lets it run for a certain share of each time slice. This shows up as mysterious latency spikes, often without high average CPU usage.

Memory is not compressible. If a container uses more memory than its limit, the kernel kills it. That's the famous OOMKilled status. The pod restarts, and if it keeps happening, you see CrashLoopBackOff.

kubectl describe pod shop-api-7d9f
# Last State: Terminated
#   Reason:   OOMKilled
#   Exit Code: 137

There's also eviction: if a node runs out of memory overall, the kubelet evicts pods, starting with those using the most beyond their requests.

QoS classes, simply

Kubernetes puts every pod in one of three Quality of Service classes, based on its requests and limits:

Guaranteed: requests equal limits for CPU and memory in every container. Last to be evicted.
Burstable: requests are set but lower than limits (or only some are set). The most common class.
BestEffort: no requests or limits at all. First to be evicted when the node is under pressure.

For important services, avoid BestEffort. For critical workloads, consider Guaranteed for memory at least.

Requests decide where your pod lives. Limits decide how it dies.

The CPU limits debate

This is where engineers argue. Should you set CPU limits at all?

The case against CPU limits: throttling hurts latency, sometimes even when the node has plenty of idle CPU. Without a limit, a pod can use spare CPU when it's available, and requests still guarantee everyone their fair share under contention. Many experienced teams set CPU requests but no CPU limits.

The case for CPU limits: predictability. In multi-tenant clusters, or when you need to prevent one noisy workload from hogging everything, limits give hard boundaries. Some runtimes and licensing models also depend on them.

My default: always set CPU requests, set memory requests and memory limits, and only set CPU limits when there's a specific reason. For memory, I usually set the limit equal to the request, or close to it, so pods don't get surprise-evicted.

Finding the right numbers

Guessing is how most teams start, and it's usually wrong in both directions: some pods starve, others reserve resources they never use (and you pay for that).

Better approaches:

Look at real usage in Prometheus or your monitoring tool over at least a week. A common starting point: requests near typical usage (for example the 90th percentile), memory limit with some headroom above the peak.
VPA in recommendation mode calculates suggestions for you.
Goldilocks (from Fairwinds) runs VPA in recommendation mode and shows the results per namespace in a dashboard.
Check for throttling with the container_cpu_cfs_throttled_periods_total metric. High throttling with low average usage is a sign the CPU limit is too tight.
Language runtimes matter. Java, Node.js and Go each have their own relationship with container memory and CPU limits. Make sure your runtime knows its limits (modern JVMs detect container limits automatically, for example).

Guardrails for the whole cluster

To stop pods without any settings from sneaking in:

LimitRange sets default requests and limits per namespace.
ResourceQuota caps the total a namespace can request.
Policy tools like Kyverno can require requests on every pod.

So, what should you do today?

Check which of your workloads have no requests at all. Fix those first. Then look at OOMKills and throttling metrics, and adjust based on real data instead of guesses.

My take: set requests honestly, treat memory limits with respect, and think twice before throttling your own CPU.

— Desly

Kubernetes errors I see every week, and how I fix them

Tue, 20 Oct 2026 23:10:30 +0200

Kubernetes error messages have a special talent: they tell you that something is wrong, in capital letters, without telling you why. CrashLoopBackOff. ImagePullBackOff. Pending. If you work with Kubernetes, you'll see these every week.

The good news: the same few causes explain most of these errors. Here's my usual debugging process and the fixes I try first.

My debugging routine

Whatever the error, I start with the same three commands:

kubectl get pods -n shop                 # what state is it in?
kubectl describe pod <pod> -n shop       # events at the bottom tell the story
kubectl logs <pod> -n shop --previous    # logs from the crashed container

The Events section at the bottom of kubectl describe is the most underrated debugging tool in Kubernetes. Nine times out of ten, the answer is there.

For the bigger picture:

kubectl get events -n shop --sort-by=.lastTimestamp

The usual suspects, one by one

CrashLoopBackOff

The container starts, crashes, Kubernetes restarts it, it crashes again, and Kubernetes waits longer and longer between attempts.

Common causes: - The application itself fails at startup: missing config, wrong environment variable, can't reach the database. - A missing secret or ConfigMap key. - Liveness probe kills the container before it finishes starting. - Out of memory at startup (check for OOMKilled).

Fix: kubectl logs --previous shows why the last run died. If the logs are empty, the process probably crashed before logging anything: check the command, the entrypoint, and the image.

ImagePullBackOff / ErrImagePull

Kubernetes can't download the container image.

Common causes: - Typo in the image name or tag. - The tag doesn't exist (it was never pushed, or was deleted). - Private registry without an imagePullSecret, or an expired one. - Rate limits from the registry. - The node can't reach the registry (network, proxy, firewall).

Fix: the event message usually says exactly which one: "not found", "unauthorized", or "toomanyrequests".

Pending

The pod was created but no node will run it.

Common causes: - Not enough CPU or memory on any node for the pod's requests. - Node selectors, affinity rules or taints that no node matches. - A PersistentVolumeClaim that can't be bound (wrong StorageClass, wrong zone). - The cluster autoscaler hasn't added a node yet, or can't.

Fix: kubectl describe pod shows a message like "0/5 nodes are available: 3 Insufficient memory, 2 node(s) had untolerated taint". That tells you exactly what to change.

OOMKilled

The container used more memory than its limit and was killed. Exit code 137.

Fix: check actual memory usage, then either raise the limit or fix the leak. Make sure the language runtime knows about the container's memory limit.

Evicted

The node ran low on memory or disk and removed pods to protect itself.

Fix: set proper memory requests, check for pods writing huge logs or temporary files, and look at node disk usage. Clean up old evicted pods with kubectl delete pod --field-selector=status.phase=Failed.

CreateContainerConfigError

Usually a referenced Secret or ConfigMap (or a key inside it) doesn't exist. The event names it.

Readiness probe failed / 0/1 Ready

The container runs but Kubernetes doesn't send traffic to it.

Fix: check the probe path and port, and test it from inside the pod. Make sure the probe doesn't depend on external services that might be slow.

Kubernetes almost always tells you what's wrong. It just puts the answer at the bottom of kubectl describe.

When it's the network

"It works in the pod but not through the service" is its own category.

# Does the Service have endpoints?
kubectl get endpointslices -n shop -l kubernetes.io/service-name=shop-api

# Test from inside the cluster
kubectl run tmp --rm -it --image=busybox:1.36 -- sh
# then: wget -qO- http://shop-api.shop.svc.cluster.local:8080/health

Common causes: - No endpoints: the Service selector doesn't match the pod labels. Very common after a rename. - Wrong port: port vs targetPort mix-up. - NetworkPolicy blocking traffic. If any policy selects a pod, everything not explicitly allowed is denied. - DNS: check that CoreDNS pods are healthy, and use the full service name across namespaces.

Debugging tools worth knowing

kubectl debug starts an ephemeral debug container in a running pod, even if the image has no shell. Essential for distroless images.
kubectl exec for images that do have a shell.
kubectl port-forward to test a service from your laptop.
k9s for a fast terminal UI over everything.
stern for following logs from many pods at once.

The cheat sheet

Status	First thing to check
CrashLoopBackOff	`kubectl logs --previous`
ImagePullBackOff	Event message: name, tag, credentials, rate limit
Pending	`describe` events: resources, taints, PVC
OOMKilled	Memory usage vs limit
Evicted	Node memory/disk pressure, missing requests
CreateContainerConfigError	Missing Secret/ConfigMap or key
Not Ready	Readiness probe path, port and dependencies
Service unreachable	Endpoints, selector labels, ports, NetworkPolicy, DNS

My take: learn to read events and previous logs, and most Kubernetes mysteries solve themselves in minutes.

— Desly

Smaller, safer container images

Tue, 20 Oct 2026 23:10:30 +0200

Run docker images on almost any project and you'll find images of 800 MB, 1 GB, sometimes more, for an application whose actual code is a few megabytes. The rest is a full operating system, compilers, package managers, shells, debugging tools and leftover files.

Big images take longer to build, pull and start. Plus, every extra package adds a security risk. Here's how I make mine smaller and safer.

Multi-stage builds

The biggest win, by far. Use one stage with all the build tools to compile your app, then copy only the result into a minimal final image.

# Build stage
FROM golang:1.25 AS build
WORKDIR /src
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 go build -o /app ./cmd/server

# Final stage
FROM gcr.io/distroless/static-debian12:nonroot
COPY --from=build /app /app
USER nonroot
ENTRYPOINT ["/app"]

The final image contains the binary and almost nothing else. No shell, no package manager, no compiler. For a Go app, that can mean going from around a gigabyte to around twenty megabytes.

The same pattern works for other languages: build with the full SDK image, run with a slim runtime image.

Choosing a base image

The base image decides most of your image's size and its vulnerability count.

Full distro images (ubuntu, debian, node, python): convenient, big, lots of packages you don't need.
Slim variants (python:3.13-slim, node:22-slim): a good middle ground.
Alpine: very small, but uses musl instead of glibc, which occasionally causes subtle compatibility or performance issues.
Distroless (Google): only your app and its runtime dependencies. No shell.
Hardened minimal images: Chainguard Images (built on Wolfi), Docker Hardened Images and similar offerings are rebuilt frequently and aim for zero or near-zero known vulnerabilities.

A note on Bitnami: many teams relied on Bitnami's free container images and Helm charts. In 2025, Broadcom changed the free catalogue significantly, moving most versioned images to a legacy repository that no longer gets updates. If your charts or Dockerfiles still reference Bitnami images, check them now and move to supported alternatives.

Every package in your image is a package you'll have to patch. The easiest vulnerability to fix is the one you never shipped.

Faster builds with caching

Docker builds layers in order, and reuses cached layers until something changes. So order matters:

Copy dependency files first (package.json, go.mod, requirements.txt), install dependencies, then copy the rest of the code. Code changes then don't invalidate the dependency layer.
Use a .dockerignore to keep node_modules, .git, test data and local secrets out of the build context.
Use BuildKit cache mounts for package manager caches:

RUN --mount=type=cache,target=/root/.cache/pip \
    pip install -r requirements.txt

Use registry caching in CI (--cache-to and --cache-from with docker buildx), so pipelines reuse layers from earlier builds.

Hardening checklist

Run as a non-root user. Set USER in the Dockerfile and runAsNonRoot: true in Kubernetes.
Pin base images by version, ideally by digest, and let Renovate update them.
No secrets in images. Use build secrets (--mount=type=secret) for anything needed at build time.
Read-only root file system in Kubernetes where possible.
Drop Linux capabilities you don't need.
Add labels for source, version and maintainer (OCI annotations).

Scanning before shipping

Scan images in CI and fail the build on serious, fixable vulnerabilities:

trivy image --severity HIGH,CRITICAL --ignore-unfixed \
  --exit-code 1 registry.example.com/shop-api:1.4.2

Trivy and Grype are both excellent open-source scanners. Docker Scout and most registries also scan automatically.

Two tips: use --ignore-unfixed (or similar) so you're not blocked by vulnerabilities nobody can fix yet, and rescan images regularly, not just at build time, because new vulnerabilities are found in old images every day.

So, where do I start?

Take your biggest image. Add a multi-stage build and a slim or distroless base. Run Trivy before and after. The difference in size and security is usually so big that the rest of the team will want it too.

My take: ship your app, not a whole operating system. Smaller images are faster, cheaper and safer, all at once.

— Desly

Kubernetes at home: Talos, k3s and a homelab

Tue, 20 Oct 2026 23:10:30 +0200

At work, Kubernetes usually comes pre-built. A managed service, a platform team, a few clicks or a Terraform module, and the cluster exists. That's great for productivity, and terrible for learning how things actually work underneath.

A homelab fixes that. A few small machines on a shelf, a cluster you built yourself, and nobody to blame but you when it breaks. It's one of the best learning investments I know.

Why build a homelab

You learn the layers managed services hide: networking, storage, certificates, the control plane, upgrades.
You can break things freely. No change tickets, no customers.
You can try tools before proposing them at work: GitOps, service meshes, observability stacks, policy engines.
It's genuinely useful. Many people run their home services (media, backups, home automation, password managers) on it.
It looks good on a CV, especially when you write about it.

What hardware?

You don't need much:

Mini PCs (Intel NUC style or similar) are the most popular choice: quiet, efficient, x86, enough RAM.
Raspberry Pi boards work well with lightweight distributions, but ARM and SD card storage add some quirks.
One old laptop or desktop with virtual machines is a perfectly fine start.

Three nodes is a good target: enough to learn high availability and what happens when a node dies. Plan for at least 8 GB of RAM per node, and use SSDs rather than SD cards for anything you care about.

Talos vs k3s

Two distributions stand out for homelabs, and they have very different philosophies.

k3s is a lightweight, fully compliant Kubernetes distribution from Rancher (SUSE). A single binary, installed on a normal Linux system with one command:

curl -sfL https://get.k3s.io | sh -

It comes with sensible defaults built in: a container runtime, networking, a local storage provisioner and an ingress controller. It's the fastest way to a working cluster, and very forgiving.

Talos Linux takes a radical approach: it's an operating system built only to run Kubernetes. No SSH, no shell, no package manager. Everything is configured through an API with talosctl and a YAML machine configuration. The OS is immutable, so nodes can't drift, and upgrades are atomic.

talosctl gen config homelab https://192.168.1.10:6443
talosctl apply-config --insecure --nodes 192.168.1.10 --file controlplane.yaml
talosctl bootstrap --nodes 192.168.1.10

My take: k3s if you want to learn Kubernetes quickly, Talos if you want to learn how production-grade, immutable infrastructure feels. Talos is stricter and has a steeper start, but once it clicks, it's hard to go back to SSH-ing into nodes.

Other options worth knowing: k0s, MicroK8s, and plain kubeadm if you want to do everything the hard way at least once.

A homelab teaches you more in one broken weekend than a managed cluster teaches you in a year.

A stack worth building

Once the cluster runs, here's a learning path that mirrors real production setups:

GitOps with Argo CD or Flux. Everything in Git from day one.
Networking with Cilium, and MetalLB or Cilium's own load balancer support to get real IPs for services at home.
Gateway API with cert-manager and Let's Encrypt for HTTPS.
Storage with Longhorn or a simple NFS provisioner.
Observability: Prometheus, Grafana, Loki.
Secrets with External Secrets or SOPS.
Backups with Velero to an external disk or cloud storage.

Each step teaches something you'll use at work.

Lessons for real work

The things a homelab taught me that managed clusters never did:

Networking is most of the difficulty. IP ranges, DNS, load balancers, MTU problems.
Storage is the hardest part of reliability. Losing a disk in a homelab makes backups very real.
Upgrades need practice. Doing them regularly on your own cluster makes production upgrades much less scary.
Immutable infrastructure is worth it. Rebuilding a node from config beats fixing it by hand.
Write things down. Future you will not remember why that one setting exists.

So, is it worth it?

If you work with Kubernetes, or want to, absolutely. It costs a few hundred euros, or nothing if you reuse old hardware, and some evenings. In return you get a deep understanding of the system you work with every day.

My take: build it yourself at least once. You'll understand every managed cluster you touch afterwards a little better.

— Desly

Locking down GitHub Actions after real attacks

Tue, 20 Oct 2026 23:10:30 +0200

For a long time, I treated GitHub Actions workflows as plumbing. Copy a workflow from a README, add uses: some-org/some-action@v3, and move on. Most of us did.

In March 2025, the popular tj-actions/changed-files action was hacked. Attackers changed its version tags to point at malicious code that leaked CI secrets into build logs. Thousands of repos used it. Many had public logs. It was a wake-up call: our pipelines run third-party code with access to our most sensitive credentials, and we rarely think about it.

Here's what I changed, and what I'd recommend to anyone using Actions.

What happened, simply

When you write uses: tj-actions/changed-files@v45, v45 is a Git tag. Tags can be moved. If an attacker gets write access to the action's repository, they can point existing tags at a malicious commit. Every workflow using that tag runs the new code on its next run, without any change in your repository.

The investigation later showed the hack was itself linked to another compromised action. Supply chain attacks chain.

Your pipeline is only as trustworthy as the least trustworthy action it runs.

1. Pin actions to a full commit SHA

Instead of a tag, reference the exact commit:

# Before
- uses: actions/checkout@v4

# After
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2

A commit SHA can't be moved. Keep the version as a comment so humans can read it, and let Dependabot or Renovate update the SHA (and the comment) when a new version is released, through a normal pull request you can review.

GitHub also lets organisations enforce SHA pinning in their allowed actions policy, so unpinned actions fail.

2. Restrict the GITHUB_TOKEN

Every workflow gets an automatic GITHUB_TOKEN. Its default permissions depend on your settings, and in older repositories they're often far too broad.

Set the organisation or repository default to read-only, and grant only what each workflow needs:

permissions:
  contents: read

jobs:
  release:
    permissions:
      contents: write   # only this job can push tags

A leaked read-only token is a much smaller problem than a leaked write token.

3. Stop storing long-lived cloud keys

The secrets that leaked in these attacks were often cloud access keys that are valid until someone rotates them. Replace them with OIDC: the workflow requests a short-lived token from GitHub, and your cloud provider exchanges it for temporary credentials, but only for the specific repository and branch you allow.

permissions:
  id-token: write
  contents: read

steps:
  - uses: aws-actions/configure-aws-credentials@<sha> # v4
    with:
      role-to-assume: arn:aws:iam::123456789012:role/deploy-shop
      aws-region: eu-central-1

AWS, Azure, Google Cloud, HashiCorp Vault and many others support this. No secret to steal, and the token expires in minutes.

4. Be careful with dangerous triggers

pull_request_target and workflow_run run with access to secrets, even for pull requests from forks. Combined with checking out the untrusted code from the pull request, they're a classic way for attackers to steal secrets. Avoid them unless you really understand the risk.

Also watch out for script injection: using untrusted input like a pull request title directly in a run: step.

# Dangerous: the title can contain shell commands
- run: echo "${{ github.event.pull_request.title }}"

# Safer: pass it through an environment variable
- env:
    TITLE: ${{ github.event.pull_request.title }}
  run: echo "$TITLE"

5. Limit which actions can run at all

In organisation settings, allow only:

Actions created by GitHub
Actions from verified creators
A specific allow list of actions you've reviewed

Fewer third-party actions means fewer things that can be compromised. For simple tasks, a few lines of shell are often safer than an action.

6. Use tools that check your workflows

zizmor: a static analysis tool for GitHub Actions that finds unpinned actions, injection risks, dangerous triggers and excessive permissions.
OpenSSF Scorecard: rates your repository's security practices, including workflow hygiene.
StepSecurity Harden-Runner: monitors and can restrict network access from your runners, which would have blocked many exfiltration attempts.
Dependabot / Renovate for keeping pinned actions up to date.

Add zizmor to your CI and fix what it finds. It's an eye-opening first run.

7. Protect the runners

Prefer GitHub-hosted or ephemeral self-hosted runners (a fresh VM or container per job). Persistent self-hosted runners can be poisoned by one malicious job and affect the next.
Never use self-hosted runners for public repositories where anyone can open a pull request.

So, where do I start?

If you only do three things this week: set the default token to read-only, pin your third-party actions to SHAs with Renovate updating them, and replace one long-lived cloud key with OIDC. Then run zizmor and work through the list.

My take: CI pipelines hold the keys to everything. Treat every uses: line like a dependency, because that's exactly what it is.

— Desly

My CI/CD pipeline, from commit to production

Tue, 20 Oct 2026 23:10:30 +0200

Ask ten DevOps engineers to draw a CI/CD pipeline and you'll get ten different drawings. But underneath, good pipelines share the same shape. They give fast feedback, they catch problems early, and they make deploying boring.

Here's the pipeline I'd use for a typical containerised web service, step by step, with a working example in GitHub Actions.

The stages and why

Lint and unit tests. Fast checks first. If these fail, there's no point doing anything else.
Build. Create the container image once, tagged with the commit SHA.
Scan. Check dependencies, the image and the infrastructure code for known problems.
Integration tests. Test the built image with its real dependencies.
Publish. Push the image to the registry, signed.
Deploy to staging. Automatically, on every merge to main.
Verify. Smoke tests against staging.
Deploy to production. Same artifact, after approval or automatically, with a gradual rollout.
Verify again. Watch metrics and roll back if they get worse.

The most important principle hides in step 2: build once, deploy the same artifact everywhere. Never rebuild for production. What you tested is what you ship.

A good pipeline makes the right thing automatic and the risky thing visible.

The full example

A trimmed-down version of what this looks like in GitHub Actions:

name: ci-cd

on:
  pull_request:
  push:
    branches: [main]

permissions:
  contents: read

env:
  IMAGE: ghcr.io/my-org/shop-api

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@<sha> # v4
      - uses: actions/setup-go@<sha> # v5
        with:
          go-version-file: go.mod
          cache: true
      - run: go vet ./...
      - run: go test ./... -race -coverprofile=coverage.out

  build:
    needs: test
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
      id-token: write          # for keyless signing
    outputs:
      digest: ${{ steps.push.outputs.digest }}
    steps:
      - uses: actions/checkout@<sha> # v4
      - uses: docker/setup-buildx-action@<sha> # v3
      - uses: docker/login-action@<sha> # v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - id: push
        uses: docker/build-push-action@<sha> # v6
        with:
          push: ${{ github.event_name == 'push' }}
          tags: ${{ env.IMAGE }}:${{ github.sha }}
          cache-from: type=gha
          cache-to: type=gha,mode=max
      - name: Scan image
        uses: aquasecurity/trivy-action@<sha>
        with:
          image-ref: ${{ env.IMAGE }}:${{ github.sha }}
          severity: HIGH,CRITICAL
          ignore-unfixed: true
          exit-code: "1"

  deploy-staging:
    if: github.event_name == 'push'
    needs: build
    runs-on: ubuntu-latest
    environment: staging
    steps:
      - run: echo "Update the staging GitOps repo to ${{ github.sha }}"
      - run: ./scripts/smoke-test.sh https://staging.example.com

  deploy-production:
    needs: deploy-staging
    runs-on: ubuntu-latest
    environment: production      # requires approval in repo settings
    steps:
      - run: echo "Update the production GitOps repo to ${{ github.sha }}"

(Replace <sha> with pinned commit SHAs, as described in my post on locking down GitHub Actions.)

A few details worth noticing:

Environments (staging, production) can require approvals and hold their own secrets.
Deployment updates a GitOps repo rather than calling kubectl directly. Argo CD or Flux applies the change, which keeps credentials out of CI.
Pull requests run tests and build but don't push or deploy.

Making it fast

Slow pipelines make developers lose trust. A few habits keep things moving quickly:

Run the fastest checks first and in parallel.
Cache dependencies and Docker layers (the cache-from / cache-to lines above).
Only run what changed in monorepos, using path filters.
Keep integration tests focused. Test the important paths, not everything.
Aim for under ten minutes from push to "ready to merge".

How I roll back

A rollback should be as easy as a deployment, and practised:

With GitOps, a rollback is a revert commit in the deployment repo. Argo CD and Flux apply it like any other change.
Progressive delivery tools like Argo Rollouts or Flagger can roll back automatically when metrics get worse.
Database changes need to be backward compatible (expand and contract), so rolling back the app doesn't break on the new schema.
Feature flags let you turn off a broken feature without redeploying at all.

So, what's the minimum?

If your pipeline does nothing else, make it do this: run tests on every pull request, build one image per commit, scan it, deploy that exact image to staging automatically, and promote the same image to production. Everything else is improvement on top.

My take: build once, test early, deploy the same thing everywhere, and always know how to go back.

— Desly

Releasing without fear: canary, blue-green and feature flags

Tue, 20 Oct 2026 23:10:30 +0200

There's a particular kind of silence in a team chat right after a big production deployment. Everyone's watching dashboards. Nobody wants to be the first to say "is it just me, or are errors going up?"

Progressive delivery replaces that silence with a plan: release to a few users first, track what happens, and only then decide whether to continue. If something's wrong, only a small group notices, and the system can undo the change automatically.

The strategies compared

Rolling update. Kubernetes' default: replace pods a few at a time. Simple, but once the rollout starts, new and old versions mix and you have little control over who sees what.

Blue-green. Run the new version (green) next to the old one (blue). Test green, then switch all traffic at once. Rolling back is just switching back. The cost: double resources during the switch, and a "big bang" moment for users.

Canary. Send a small percentage of traffic to the new version, for example 5%, then 25%, then 50%, then 100%, checking metrics at each step. Slower, but the safest way to catch problems that only appear under real traffic.

Feature flags. Deploy code with the new feature switched off, then turn it on for specific users, a percentage, or everyone, without deploying again. This separates deploying (getting code into production) from releasing (letting users see it).

	Rolling	Blue-green	Canary	Feature flags
Control over exposure	Low	All or nothing	Gradual by traffic	Very fine, by user
Rollback speed	Slow	Instant	Fast	Instant
Extra infrastructure	None	Double during switch	Some	Flag service
Best for	Low-risk changes	Big switches	Risky backend changes	Product features

Deploying should be boring. Releasing should be a decision.

Argo Rollouts in practice

On Kubernetes, Argo Rollouts (and Flagger, its counterpart in the Flux ecosystem) adds canary and blue-green strategies with automatic analysis.

A Rollout replaces a Deployment:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: shop-api
spec:
  replicas: 10
  strategy:
    canary:
      steps:
      - setWeight: 5
      - pause: { duration: 5m }
      - analysis:
          templates:
          - templateName: error-rate
      - setWeight: 25
      - pause: { duration: 10m }
      - setWeight: 50
      - pause: { duration: 10m }
  selector:
    matchLabels: { app: shop-api }
  template:
    # same pod template as a Deployment

The analysis step runs a Prometheus query, for example the error rate of the canary, and compares it with a threshold:

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: error-rate
spec:
  metrics:
  - name: error-rate
    interval: 1m
    count: 5
    successCondition: result[0] < 0.01
    provider:
      prometheus:
        address: http://prometheus.monitoring:9090
        query: |
          sum(rate(http_requests_total{app="shop-api",version="canary",code=~"5.."}[2m]))
          /
          sum(rate(http_requests_total{app="shop-api",version="canary"}[2m]))

If the error rate goes above 1%, the rollout is aborted and traffic goes back to the stable version. Nobody had to be awake.

For precise traffic percentages, Rollouts integrates with Gateway API implementations, service meshes and ingress controllers. Without them, it approximates weights using replica counts.

Feature flags with OpenFeature

Feature flags used to mean either a homemade if statement reading an environment variable, or a commercial service with its own SDK everywhere. OpenFeature, a CNCF project, standardises the API: your code uses one SDK, and you can plug in different flag providers behind it (flagd, LaunchDarkly, Flagsmith, Unleash, GrowthBook and others).

enabled, _ := client.BooleanValue(ctx, "new-checkout", false, evalCtx)
if enabled {
    return newCheckout(w, r)
}
return oldCheckout(w, r)

Good flag habits:

Give every flag an owner and an expiry date. Old flags become technical debt fast.
Clean up once a feature is fully released.
Keep flags out of critical paths where the flag service being down would break things, or use sensible defaults.

Automatic rollback on SLO breach

The best setups link releases to your service level objectives. If a new version uses up the error budget faster than normal, the rollout stops and reverses. That turns "watch the dashboards nervously" into an automatic safety net based on what users actually experience.

So, which should you use?

Start with feature flags for product changes, they're the easiest win. Add canary releases with automatic analysis for your most important services. Use blue-green when you need a clean switch, like a major version change. And keep rolling updates for everything low-risk.

My take: release in small steps, let metrics make the first decision, and make sure going back is always one click away.

— Desly

Faster CI pipelines: from 40 minutes to 8

Tue, 20 Oct 2026 23:10:30 +0200

A slow pipeline costs more than compute time. Developers switch to something else while waiting, lose focus, batch up changes to avoid waiting again, and start merging with "it'll probably pass". A forty-minute pipeline quietly makes everything worse: bigger changes, slower reviews, more risk.

Most projects can cut their pipeline time from around forty minutes to under ten. Here are the techniques that make the biggest difference, roughly in the order I'd try them.

Finding the slow parts

Don't optimise blindly. First, measure:

Look at the duration of each job and step over the last few weeks. GitHub Actions, GitLab and most CI tools show this.
Find the critical path: the chain of jobs that determines total time. Speeding up a job that runs in parallel with a slower one changes nothing.
Check how much time goes into setup: installing tools, downloading dependencies, pulling images. It's often a surprisingly large share.

Usually, three or four steps take most of the time. Focus there.

Caching everything that can be cached

The biggest win for most pipelines.

Dependency caches. Package downloads (npm, pip, Maven, Go modules) shouldn't happen from scratch every run. Most setup actions have a built-in cache option keyed on the lock file:

- uses: actions/setup-node@<sha> # v4
  with:
    node-version: 22
    cache: npm

Docker layer caching. With BuildKit, cache layers between runs, in the CI provider's cache or a registry:

- uses: docker/build-push-action@<sha> # v6
  with:
    cache-from: type=registry,ref=ghcr.io/my-org/shop-api:buildcache
    cache-to: type=registry,ref=ghcr.io/my-org/shop-api:buildcache,mode=max

Combined with a well-ordered Dockerfile (dependencies first, code last), image builds often drop from many minutes to well under one.

Build caches. Tools like Gradle, Bazel, Nx and Turborepo can cache build and test outputs remotely, so unchanged modules aren't rebuilt or retested at all.

The fastest work is the work your pipeline doesn't have to do again.

Running in parallel

Many pipelines run steps one after another out of habit. Look for independent work:

Lint, unit tests, and security scans can usually run at the same time.
Use a matrix to test multiple versions or components in parallel.
Start the image build while slower test suites are still running, if your process allows it.

Splitting tests and quarantining flaky ones

Tests are often the longest step. Two techniques:

Test splitting. Divide the test suite across several parallel jobs, ideally based on historical timing so each job takes about the same time. Many test frameworks and CI tools support this, either natively or with small helper tools.

Flaky test quarantine. A test that fails randomly forces reruns of the whole pipeline. That's pure waste. Track flaky tests, move them to a separate non-blocking job, and fix them with a deadline. Never just add automatic retries everywhere and forget about it.

Also ask: does every test need to run on every commit? Long end-to-end suites can run on merge to main or nightly, while pull requests run a focused subset.

Only running what changed

In monorepos, rebuilding and retesting everything for a one-line change is the biggest source of waste:

Path filters trigger jobs only when relevant folders change.
Affected-only builds with Nx, Turborepo, Bazel or Pants use the dependency graph to find exactly which projects a change touches.

Better runners

Sometimes the machine is the bottleneck:

Bigger runners with more CPU and memory can be cheaper overall if they cut time significantly. Measure cost per pipeline, not cost per minute.
Self-hosted ephemeral runners, for example with Actions Runner Controller on Kubernetes, give you control over machine size and keep caches close to the runners. Make them ephemeral, one job per runner, for security.
Faster third-party runner services exist too, often with better caching built in.

Smaller wins that add up

Shallow Git clones (fetch-depth: 1) unless you need history.
Pre-built CI images with your tools already installed.
Cancelling outdated runs when a new commit is pushed to the same branch (concurrency with cancel-in-progress).
Removing steps nobody looks at anymore.

So, what's a good target?

Under ten minutes from push to a green check for a pull request is a good goal for most services. Under five feels fantastic. Start by measuring, add caching, parallelise, deal with flaky tests, and you'll be surprised how much time disappears.

My take: treat pipeline speed as a feature. Every minute you save is saved again by every developer, on every commit.

— Desly

Pipelines in real code with Dagger

Tue, 20 Oct 2026 23:10:30 +0200

Here's a loop every DevOps engineer knows. Change the pipeline YAML. Commit. Push. Wait for CI. It fails on a typo. Fix. Commit "fix ci". Push. Wait. Fail. "fix ci again". Twenty commits later, it works, and the Git history looks like a cry for help.

The main issue is that most pipelines can only run inside the CI system. You can't run them on your laptop, debug them properly, or reuse logic without copying YAML. Dagger tries to fix that.

The YAML problem

CI YAML has grown into a programming language nobody designed as one. Conditions, loops, variables, templating, expressions inside strings. But without a debugger, tests, type checking or a decent way to share code.

And every CI system has its own dialect. A pipeline written for GitHub Actions doesn't run on GitLab, Jenkins or your laptop.

What Dagger does

Dagger, created by some of the original Docker team, lets you write pipelines as code in a real programming language: Go, Python, TypeScript, and others. Every step runs in a container, using a BuildKit-based engine. The same pipeline runs identically on your laptop and in any CI system.

Your CI configuration shrinks to "install Dagger, run this function".

My first Dagger pipeline

A small example in Go: build and test an app, then build a container image.

package main

import (
    "context"
    "dagger/shop/internal/dagger"
)

type Shop struct{}

// Run the tests
func (m *Shop) Test(ctx context.Context, source *dagger.Directory) (string, error) {
    return dag.Container().
        From("golang:1.25").
        WithMountedCache("/go/pkg/mod", dag.CacheVolume("go-mod")).
        WithDirectory("/src", source).
        WithWorkdir("/src").
        WithExec([]string{"go", "test", "./..."}).
        Stdout(ctx)
}

// Build the production image
func (m *Shop) Build(source *dagger.Directory) *dagger.Container {
    binary := dag.Container().
        From("golang:1.25").
        WithDirectory("/src", source).
        WithWorkdir("/src").
        WithEnvVariable("CGO_ENABLED", "0").
        WithExec([]string{"go", "build", "-o", "/app", "./cmd/server"}).
        File("/app")

    return dag.Container().
        From("gcr.io/distroless/static-debian12:nonroot").
        WithFile("/app", binary).
        WithEntrypoint([]string{"/app"})
}

Then, from your terminal:

dagger call test --source=.
dagger call build --source=. publish --address=ghcr.io/my-org/shop-api:dev

It's normal Go code. You get autocompletion, types, functions, loops, error handling, and you can test your pipeline logic like any other code.

The best CI pipeline is one you can run, debug and fix on your own machine before anyone else sees it.

Same pipeline locally and in CI

In GitHub Actions, the workflow becomes tiny:

- uses: dagger/dagger-for-github@<sha>
  with:
    verb: call
    args: test --source=.

Move to GitLab or Jenkins tomorrow, and only those few lines change. The pipeline itself stays the same.

Caching is built in: every step is cached by its inputs, so unchanged steps are skipped, locally and in CI (if the CI runner keeps the cache or uses Dagger's cloud caching).

Reusing modules

Dagger has a module system. You can call modules others have written (for example for linting, scanning or deploying) or share your own across your organisation. That's a much nicer way to share pipeline logic than copying YAML snippets between repositories.

When it's overkill

Dagger isn't for every project:

Simple pipelines: if your pipeline is "run tests, build image, push", plain CI YAML is fine and easier for everyone to understand.
Team skills: everyone who touches the pipeline needs to be comfortable with the chosen language.
Another tool to learn and run: the Dagger engine needs to be available wherever pipelines run, and it's still evolving.
CI-native features like matrix builds, environments and approvals still come from your CI system, so you'll use both.

Where it shines: complex pipelines, monorepos with many components, teams tired of "fix ci" commits, and organisations using more than one CI system.

So, is it worth trying?

If your pipelines have grown into hundreds of lines of YAML that nobody wants to touch, yes. Start by moving one complex job into a Dagger function and run it locally. If the "push and pray" loop disappears, you'll know.

My take: pipelines are software. Dagger lets you finally treat them that way, with the tools we use for every other piece of code.

— Desly

Database changes that don't break deployments

Tue, 20 Oct 2026 23:10:30 +0200

Most of the scariest deployments I can think of had one thing in common: a database change. The code part was fine. You can roll code back in seconds. But once you've dropped a column, renamed a table, or migrated a million rows, there's no quick undo.

Database changes need their own spot in your delivery process. Here's how to make them routine.

Why migrations break things

A few classic ways schema changes cause outages:

The new code expects a column that doesn't exist yet, because the migration ran after the deploy, or failed.
The old code breaks on the new schema, because during a rolling update both versions run at the same time.
A rollback of the code leaves the database in the new shape, and the old code doesn't understand it.
A long-running migration locks a table, and everything waiting on it times out.
Someone changed the database by hand, and the migration fails because reality doesn't match expectations.

The common theme: code and database change at different moments, and for a while, both old and new versions of the code talk to the same database.

Expand, then contract

The single most useful pattern for safe database changes is expand and contract (also called parallel change). Instead of one breaking change, you make a series of compatible ones.

Example: renaming a column from name to full_name.

Expand: add the new column full_name. Old code ignores it.
Write to both: deploy code that writes to both name and full_name, and reads from name.
Backfill: copy existing data from name to full_name, in batches.
Switch reads: deploy code that reads from full_name.
Stop writing the old column: deploy code that only uses full_name.
Contract: later, once you're confident, drop the name column.

More steps, sure. But at every stage, both the current and previous code versions work, so every deployment can be undone safely.

Never make a database change that the previous version of your code can't survive.

Rules of thumb

Additive changes are safe: new tables, new nullable columns, new indexes (created concurrently where your database supports it).
Destructive changes need a waiting period: dropping or renaming columns and tables only after no running code uses them.
Avoid long locks: big data migrations in batches, not one giant transaction. Know which operations lock tables in your database.
Separate schema changes from data migrations where possible.
Migrations are forward-only in production. "Down" migrations are useful in development, but in production, fix forward with a new migration.

Tools: Atlas, Flyway, Liquibase

You need a tool that applies migrations in order and records what's been applied:

Flyway: simple, SQL-file based, widely used, especially in the Java world.
Liquibase: changesets in SQL, XML, YAML or JSON, with rich features for enterprises.
Atlas: a newer tool with a declarative approach. You describe the desired schema, and Atlas plans the migration, like Terraform for databases. It also lints migrations for dangerous changes, like dropping a column or adding a non-nullable column without a default.
Framework tools: Django migrations, Rails migrations, Alembic, Prisma, EF Core. Fine to use if your app framework has them.

When to run migrations

Common options in a Kubernetes world:

A Kubernetes Job before the deployment, for example a Helm pre-upgrade hook or an Argo CD sync wave / pre-sync hook. The deployment only continues if the migration succeeds.
An init container in the app pod. Simple, but with many replicas, several may try to migrate at once. Use a tool with locking.
A separate pipeline step before deploying the new version.

Whichever you choose, the migration must succeed before the new code needs it, and must not break the old code still running.

Testing migrations in CI

Run all migrations from scratch on a fresh database in CI, to make sure the chain works.
Run new migrations against a copy of production-like data (anonymised) to catch performance problems and locks.
Lint migrations for risky operations (Atlas, squawk for PostgreSQL, and similar tools).
Test both code versions against the new schema if you can.

So, how do you make database changes boring?

Use a migration tool, make every change backward compatible with expand and contract, run migrations automatically before the code that needs them, and test them in CI with realistic data. It's more steps, but each step is small and safe.

My take: databases have long memories. Change them slowly, in small compatible steps, and they'll forgive you.

— Desly

Version numbers and changelogs on autopilot

Tue, 20 Oct 2026 23:10:30 +0200

Releasing used to involve a little ritual. Someone decides it's time. They look through the commits since the last release, try to remember what changed, guess whether it's a minor or major version, write a changelog by hand, tag it, and hope they didn't forget anything.

Automating that process usually gives better results than what we managed by hand.

Semantic versioning, simply

Most projects use Semantic Versioning (SemVer): MAJOR.MINOR.PATCH, like 2.4.1.

PATCH (2.4.1 → 2.4.2): bug fixes, nothing new, nothing broken.
MINOR (2.4.1 → 2.5.0): new features, backward compatible.
MAJOR (2.4.1 → 3.0.0): breaking changes. Users may need to change something.

The version number is a promise to your users. A minor upgrade should be safe. A major one deserves attention.

Conventional Commits

The trick to automating versions is making commit messages machine-readable. Conventional Commits is a simple convention:

feat: add Apple Pay to checkout
fix: handle empty cart in order summary
docs: explain retry configuration
chore: update dependencies
feat!: remove deprecated v1 payment API

feat means a new feature, so a minor bump.
fix means a bug fix, so a patch bump.
! or a BREAKING CHANGE: footer means a major bump.
Other types (docs, chore, refactor, test, ci) don't trigger a release by themselves.

You can add a scope too: fix(api): ..., feat(ui): ....

To keep everyone consistent, add commitlint as a check, or use squash merges where the pull request title follows the convention, which is often easier for teams.

If your commit history is clear enough for a machine to understand, it's clear enough for your future self too.

release-please in action

release-please, from Google, is my favourite tool for this. It watches your main branch and keeps an open "release pull request" that contains:

The next version number, calculated from the commits since the last release.
An updated CHANGELOG.md, grouped into features, bug fixes and breaking changes.
Version bumps in files like package.json, pyproject.toml or a Helm Chart.yaml.

When you're ready to release, you merge that pull request. release-please creates the Git tag and the GitHub release. Your normal pipeline sees the tag and builds and publishes the artifacts.

name: release-please
on:
  push:
    branches: [main]

permissions:
  contents: write
  pull-requests: write

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: googleapis/release-please-action@<sha> # v4
        with:
          release-type: go

What I like: a human still decides when to release, by merging the PR. The tool just does all the bookkeeping.

semantic-release is a popular alternative that releases fully automatically on every merge. Great for libraries with frequent small releases, a bit too eager for some applications.

Changelogs people actually read

Generated changelogs are only as good as your commit messages. A few tips:

Write commit (or PR) titles for users, not for yourself: "fix: show correct price for discounted items", not "fix bug".
Mark breaking changes clearly and explain migration steps in the commit body.
Edit the release PR's changelog before merging if something needs more explanation. It's just a file.

Trunk-based or GitFlow?

Automated versioning works best with trunk-based development: short-lived branches, merged often into main, with main always releasable. Releases are just tags on main.

GitFlow, with long-lived develop, release and hotfix branches, was designed for a world of infrequent, big releases. It still makes sense for some products (like software shipped to customers who install specific versions), but for most web services it adds complexity without much benefit.

So, where do I start?

Agree on Conventional Commits for pull request titles, enforce it with a simple check, and add release-please to one repository. After a few releases, nobody will want to go back to writing changelogs by hand.

My take: let the robot count and write. Keep the humans for deciding when it's time to ship.

— Desly

Keeping dependencies up to date without the pain

Tue, 20 Oct 2026 23:10:30 +0200

Every project starts with fresh dependencies. A year later, half of them are outdated. Two years later, upgrading one library requires upgrading five others, the framework, and the language version, and suddenly a "small update" is a three-week project.

The fix isn't heroic upgrade sprints. It's small, constant, automated updates. Renovate and Dependabot make that possible, if you set them up so they help instead of flooding you with pull requests.

Why updates pile up

Nobody owns them. Updates are important but never urgent, until a vulnerability makes them urgent.
Fear of breaking things. Without good tests, every update feels risky.
Too many at once. Turning on a bot in an old repo produces fifty pull requests on day one, and people just ignore them all.

Dependabot vs Renovate

Dependabot is built into GitHub. Easy to switch on, handles security alerts and version updates for the most common ecosystems. Good enough for many projects.

Renovate (by Mend, open source) is more powerful and flexible:

Supports far more package managers and file types: Dockerfiles, Helm charts, Kubernetes manifests, Terraform, GitHub Actions, and custom regex-based matching for almost anything.
Very flexible grouping, scheduling and automerge rules.
A Dependency Dashboard issue showing everything pending.
Works on GitHub, GitLab, Bitbucket, Azure DevOps and more.

For infrastructure-heavy repositories, I prefer Renovate, because it can update image tags, chart versions and pinned action SHAs too.

My Renovate config

A calm starting configuration:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:recommended", ":dependencyDashboard"],
  "schedule": ["before 7am on monday"],
  "timezone": "Europe/Berlin",
  "prConcurrentLimit": 5,
  "minimumReleaseAge": "3 days",
  "packageRules": [
    {
      "matchUpdateTypes": ["patch", "minor"],
      "matchCurrentVersion": "!/^0/",
      "groupName": "non-major dependencies",
      "automerge": true
    },
    {
      "matchManagers": ["github-actions"],
      "groupName": "github actions",
      "pinDigests": true
    },
    {
      "matchDatasources": ["docker"],
      "pinDigests": true
    }
  ],
  "vulnerabilityAlerts": {
    "schedule": ["at any time"],
    "labels": ["security"]
  }
}

What this does:

Weekly schedule so updates arrive in one batch, not all week long.
A limit of five open PRs so nobody gets flooded.
minimumReleaseAge waits a few days after a release before proposing it. Many malicious package versions are discovered and removed within days, and so are many broken releases.
Groups non-major updates into one PR, and automerges them if all checks pass.
Pins GitHub Actions and Docker images to digests, and keeps those digests updated.
Security fixes skip the schedule and arrive immediately.

Small updates every week are boring. A giant upgrade every two years is a project. Choose boring.

Automerge, safely

Automerging dependency updates might sound risky, but it's what keeps the process manageable. The rules are:

Good tests that run on every PR. Automerge without tests is gambling.
Required status checks in branch protection, so nothing merges unless CI is green.
Only for low-risk updates: patch and minor versions of stable (1.0+) packages, dev dependencies, linters.
Never automerge major versions. Those get a human review.

Handling breaking changes

Major updates need attention:

Renovate includes release notes in the PR. Read them.
Update one major at a time, not five together.
For big frameworks, set up a separate group and schedule time for it, like any other piece of work.
AI coding agents are increasingly useful here: when an upgrade breaks the build because an API changed, an agent can propose the code changes in the same PR.

Images and charts too

Application dependencies are only part of the story. Infrastructure has dependencies as well:

Base images in Dockerfiles
Helm chart versions in your GitOps repos
Container image tags in Kubernetes manifests
Terraform providers and modules
GitHub Actions versions

Renovate handles all of these. Keeping base images current is one of the easiest ways to reduce vulnerabilities in your containers.

So, where do I start?

Turn on Renovate (or Dependabot) in one repository with a weekly schedule and a PR limit. Enable automerge for patch updates once you trust your tests. Expand to minor updates, then to infrastructure files. Within a month, staying up to date becomes background noise instead of a project.

My take: dependencies go off like milk, not wine. Let a bot keep them fresh, a little every week.

— Desly

How I structure Terraform projects

Tue, 20 Oct 2026 23:10:30 +0200

Every Terraform project starts clean. One folder, a main.tf, a few resources. Then a second environment arrives. Then a few more services, a shared network, a second region. Two years later, there's a 3,000-line main.tf, a state file nobody dares to touch, and a plan that takes ten minutes.

Structure makes the difference between infrastructure code that grows smoothly and code that becomes everyone's least favourite part of the repo. This is the layout I keep using. (Everything here works for OpenTofu too.)

The principles

Small state files. Split infrastructure into independent pieces, each with its own state. Smaller blast radius, faster plans, fewer people blocking each other.
Separate by lifecycle. Things that change rarely (networks, accounts) shouldn't share state with things that change daily (app resources).
Environments look the same. Staging and production should use the same code with different inputs, not copied folders that slowly drift apart.
Reusable logic lives in modules.

A layout that works

infrastructure/
  modules/
    network/
    eks-cluster/
    rds-postgres/
  live/
    staging/
      network/
        main.tf
        backend.tf
        terraform.tfvars
      cluster/
      databases/
    production/
      network/
      cluster/
      databases/

modules/ contains reusable building blocks with no environment-specific values.
live/ contains the actual deployments. Each folder is one state file, calling modules with environment-specific inputs.
Each live folder is small and focused: the network, the cluster, the databases.

Later components can read outputs from earlier ones with terraform_remote_state or, better, by looking up resources with data sources or a shared parameter store.

Folders vs workspaces

Terraform has workspaces, which let one configuration have multiple states. It's tempting to use them for environments: terraform workspace select production.

I prefer separate folders for environments:

It's visible in the code which environment you're working on.
Production can have its own backend, its own permissions and its own pipeline.
Accidentally applying to the wrong workspace is a classic and painful mistake.

Workspaces are still handy for making many identical copies of the same thing, like a stack for each customer or for preview environments.

If you have to run a command to find out which environment you're about to change, the structure is working against you.

Remote state and locking

Never keep state on a laptop. Use a remote backend with locking:

terraform {
  backend "s3" {
    bucket       = "acme-terraform-state"
    key          = "production/network/terraform.tfstate"
    region       = "eu-central-1"
    encrypt      = true
    use_lockfile = true
  }
}

The S3 backend now supports native locking with a lock file, so the separate DynamoDB table is no longer required. Azure Storage and Google Cloud Storage backends lock natively too.

Protect the state bucket: versioning on, encryption on, access limited to the people and pipelines that need it. State often contains secrets.

Terragrunt or Stacks?

The folder layout above has one annoying side effect: lots of repeated boilerplate. Every folder needs its backend config and provider config.

Tools that help:

Terragrunt (from Gruntwork) keeps configurations DRY: backend and provider settings are defined once and inherited, and you can run commands across many folders with dependencies between them. Very popular for exactly this layout.
Terraform Stacks (HashiCorp, with HCP Terraform) is the official answer for orchestrating many components and deployments together.
OpenTofu's early variable evaluation removes some of the need for wrappers, since variables can now be used in backend configuration.
Infrastructure automation platforms (Spacelift, env0, Scalr, HCP Terraform) manage stacks and dependencies in their own way.

For a small team, plain folders with a bit of repetition are fine. Once you have dozens of components, Terragrunt or a platform pays off.

Naming and tags

Small things that save a lot of confusion:

Consistent resource names: <env>-<service>-<purpose>, like prod-shop-db.
Default tags in the provider block, so every resource gets them automatically:

provider "aws" {
  region = "eu-central-1"
  default_tags {
    tags = {
      environment = "production"
      owner       = "team-platform"
      managed_by  = "terraform"
      repository  = "acme/infrastructure"
    }
  }
}

Pin provider and module versions, and commit the .terraform.lock.hcl file.
Format and validate in CI (terraform fmt -check, terraform validate, tflint).

So, what's the most important thing?

Keep state files small and separated by lifecycle and environment. Almost every other problem, slow plans, scary applies, merge conflicts, people blocking each other, gets easier once that's in place.

My take: structure your Terraform for the person who joins next year. If they can find their way around, you did it right.

— Desly

Testing infrastructure code

Tue, 20 Oct 2026 23:10:30 +0200

Ask a developer whether they'd merge application code without tests, and they'll look at you strangely. Ask the same about Terraform, and many teams shrug: "we run plan and look at it."

Reading a plan is useful, but it's not the same as testing. It doesn't show if the module works as intended, if a change breaks something else, or if security rules are followed. Infrastructure code needs tests too, just a different kind.

The testing pyramid for infrastructure

Like application testing, infrastructure testing has layers, from cheap and fast to slow and expensive:

Static checks: formatting, validation, linting, security scanning. Seconds, no cloud needed.
Policy tests: rules that every plan must follow. Seconds, using the plan output.
Unit-style tests: checking module logic against a plan, or with mocked providers. Fast.
Integration tests: actually creating real resources in a test account, checking them, and destroying them. Minutes, costs money.

Most of the value comes from the first two layers. The last one is worth it for important shared modules.

Cheap checks first

These tests should run with every commit, preferably as pre-commit hooks and in CI:

terraform fmt -check -recursive
terraform validate
tflint --recursive
checkov -d .          # or: trivy config .

fmt and validate catch syntax and formatting issues.
tflint catches provider-specific mistakes: invalid instance types, deprecated arguments, missing tags.
Checkov or Trivy catch security misconfigurations: public buckets, open security groups, missing encryption.

They're fast, free and catch a surprising number of real problems.

The best infrastructure bug is the one caught before terraform plan ever talks to your cloud.

terraform test

Since version 1.6, Terraform has a built-in testing framework (OpenTofu has an equivalent with tofu test). Tests are written in HCL, in .tftest.hcl files:

# tests/bucket.tftest.hcl
variables {
  name        = "acme-test-logs"
  environment = "staging"
}

run "bucket_is_private_and_encrypted" {
  command = plan

  assert {
    condition     = aws_s3_bucket_public_access_block.this.block_public_acls == true
    error_message = "Bucket must block public ACLs."
  }

  assert {
    condition     = aws_s3_bucket.this.tags["environment"] == "staging"
    error_message = "Bucket must be tagged with its environment."
  }
}

With command = plan, tests run against the plan, without creating anything. With command = apply, they create real resources and destroy them afterwards. You can also mock providers, which makes unit-style tests fast and free.

For module authors, this is the easiest way to start testing. No new language, no extra tools.

Terratest

Terratest, from Gruntwork, is a Go library for integration testing. It deploys real infrastructure, runs checks against it (HTTP requests, SSH commands, API calls), and tears it down.

func TestWebModule(t *testing.T) {
    opts := &terraform.Options{TerraformDir: "../examples/web"}
    defer terraform.Destroy(t, opts)
    terraform.InitAndApply(t, opts)

    url := terraform.Output(t, opts, "url")
    http_helper.HttpGetWithRetry(t, url, nil, 200, "OK", 30, 10*time.Second)
}

It's powerful because it tests whether the infrastructure actually works, not just whether it's configured correctly. It's also slower, needs Go knowledge, and costs real money for every run.

Policy tests

Policies answer "is this allowed?" for every change, regardless of who wrote it:

OPA / Conftest with policies written in Rego, run against the plan in JSON format.
Checkov custom policies in Python or YAML.
Sentinel in HCP Terraform, or OPA integration in other platforms.

Example rules: no public S3 buckets, all resources must have an owner tag, only approved instance types, production databases must have deletion protection.

terraform plan -out=plan.out
terraform show -json plan.out > plan.json
conftest test plan.json --policy policies/

Paying for test environments

Integration tests cost money. Ways to keep it under control:

A dedicated test account with budgets and alerts.
Always destroy after tests, and run a nightly cleanup job (tools like cloud-nuke or aws-nuke) for anything left behind.
Small, cheap resource sizes in test examples.
Run integration tests on merge or nightly, not on every commit.
Test modules, not whole environments.

So, where do I start?

Add static checks to CI today. Write a few terraform test assertions for your most-used module. Add one or two policies for your most important rules. Only add Terratest when a module is critical enough to justify the time and cost.

My take: infrastructure fails in expensive ways. A few cheap tests now save a very expensive lesson later.

— Desly

Pulumi, Terraform or CDK?

Tue, 20 Oct 2026 23:10:30 +0200

Infrastructure as code has split into two camps. One says infrastructure should be described in a declarative configuration language, like Terraform's HCL. The other says: we already have great programming languages, why not use them? That's the idea behind Pulumi and the AWS CDK.

The best way to compare them is to write the same thing in all three. So here's a simple S3 bucket with versioning, in each.

Terraform (HCL)

resource "aws_s3_bucket" "assets" {
  bucket = "acme-assets-prod"
  tags   = { environment = "production" }
}

resource "aws_s3_bucket_versioning" "assets" {
  bucket = aws_s3_bucket.assets.id
  versioning_configuration {
    status = "Enabled"
  }
}

output "bucket_name" {
  value = aws_s3_bucket.assets.bucket
}

Pulumi (TypeScript)

import * as aws from "@pulumi/aws";

const assets = new aws.s3.BucketV2("assets", {
    bucket: "acme-assets-prod",
    tags: { environment: "production" },
});

new aws.s3.BucketVersioningV2("assets", {
    bucket: assets.id,
    versioningConfiguration: { status: "Enabled" },
});

export const bucketName = assets.bucket;

AWS CDK (TypeScript)

import { Stack, StackProps, Tags, CfnOutput } from "aws-cdk-lib";
import * as s3 from "aws-cdk-lib/aws-s3";
import { Construct } from "constructs";

export class AssetsStack extends Stack {
  constructor(scope: Construct, id: string, props?: StackProps) {
    super(scope, id, props);

    const assets = new s3.Bucket(this, "Assets", {
      bucketName: "acme-assets-prod",
      versioned: true,
      encryption: s3.BucketEncryption.S3_MANAGED,
      blockPublicAccess: s3.BlockPublicAccess.BLOCK_ALL,
    });

    Tags.of(assets).add("environment", "production");
    new CfnOutput(this, "BucketName", { value: assets.bucketName });
  }
}

HCL vs real languages

The examples look similar for a single bucket. The differences show up as things grow.

HCL (Terraform, OpenTofu) is deliberately limited. Loops and conditions exist (for_each, count, ternaries), but it's not a full programming language. That's a feature: configurations are easy to read, even for people who aren't developers, and there's less room for clever code nobody understands.

Pulumi lets you use TypeScript, Python, Go, C#, Java or YAML. You get real loops, functions, classes, packages, IDE autocompletion and unit tests with familiar frameworks. Great for complex logic, and for developers who don't want to learn another language. The risk: infrastructure code that's too clever.

AWS CDK also uses real languages, but its strength is constructs: high-level building blocks with good defaults. Notice how the CDK bucket above got encryption and blocked public access almost for free. Higher-level constructs can create a whole load-balanced container service in a few lines. It generates CloudFormation underneath and is AWS only.

HCL limits what you can write. Real languages limit nothing, which is both their strength and their danger.

State, compared

Terraform/OpenTofu: state file in a backend you manage (S3, GCS, Azure Storage) or in HCP Terraform and other platforms.
Pulumi: state in Pulumi Cloud by default, or self-managed in an object storage bucket.
CDK: no separate state file. CloudFormation tracks the stack's state in AWS. Simpler, but you inherit CloudFormation's speed and limitations.

What fits which team

Choose Terraform or OpenTofu if: - You work across multiple clouds and SaaS providers (the provider ecosystem is the largest). - Your team includes ops people who aren't primarily developers. - You want the most widely known tool, with the most examples and hiring options.

Choose Pulumi if: - Your team is developer-heavy and prefers TypeScript, Python or Go. - Your infrastructure has complex logic that's painful in HCL. - You want to test infrastructure code with normal unit testing tools.

Choose AWS CDK if: - You're all-in on AWS and plan to stay there. - You like high-level constructs with good defaults. - Your team already knows CloudFormation, or is happy to rely on it.

What I learned

Writing the same infrastructure three times made one thing clear: the language matters less than the discipline. Good module or component design, small state boundaries, consistent naming, tests and reviews matter in all three.

For most teams I work with, Terraform or OpenTofu remains the default because of its ecosystem and readability. But for developer-led teams, I've seen Pulumi make infrastructure feel much more approachable.

My take: pick the tool your team will read and maintain happily. Infrastructure code is read far more often than it's written.

— Desly

Someone clicked in the console: fixing drift

Tue, 20 Oct 2026 23:10:30 +0200

It's 4 p.m. on a Friday. Production is slow. Someone opens the cloud console and bumps the database instance size, just to get through the weekend. It works. Everyone goes home relieved.

Three weeks later, someone runs terraform apply for an unrelated change. Terraform sees the database is bigger than the code says, and helpfully shrinks it back. Production slows down again, and nobody understands why.

That's drift: the difference between what your infrastructure code says and what actually exists.

Where drift comes from

Manual hotfixes in the console during incidents.
Quick experiments that were supposed to be temporary.
Other tools changing the same resources: autoscalers, cloud-managed defaults, security tools adding tags.
People who don't know a resource is managed by code.
Failed or partial applies that left things half-changed.

Some drift is harmless. Some is dangerous: a security group opened "temporarily", an encryption setting turned off for debugging.

Drift isn't a technical problem. It's a gap between how people work under pressure and how your process expects them to work.

Finding it

Scheduled plans. The simplest approach: run terraform plan on a schedule (nightly is common) for every state, and alert if it shows changes. Use the exit code:

terraform plan -detailed-exitcode -lock=false
# exit code 0 = no changes
# exit code 1 = error
# exit code 2 = changes detected (drift, or unapplied code)

A small CI job that runs this across your stacks and posts to Slack is often enough.

Refresh-only plans. terraform plan -refresh-only shows only what changed in the real world, without mixing in changes from your code.

Platforms. HCP Terraform, Spacelift, env0, Scalr and others have drift detection built in, with dashboards and scheduled checks.

Cloud-native tools. AWS Config, Azure Policy and similar services can flag changes to resources and non-compliant configurations, including resources that aren't managed by code at all.

Fixing it

When you find drift, there are two directions:

Code wins: the manual change was a mistake. Run apply to restore the declared state.
Reality wins: the manual change was right (like the bigger database). Update the code to match, then apply shows no changes.

The important part is deciding deliberately. Never just run apply blindly on a drifted stack without understanding what will change. Read the plan.

For resources created entirely by hand, bring them under management with import blocks:

import {
  to = aws_s3_bucket.legacy_logs
  id = "acme-legacy-logs"
}

Then terraform plan -generate-config-out=generated.tf can even write a first draft of the configuration for you.

Preventing it

Detection is good. Prevention is better:

Read-only console access by default. Most people don't need write access in production consoles. Use break-glass roles for emergencies, with logging and alerts.
A fast path for urgent changes. If changing code and applying takes an hour, people will use the console. Make the code path fast enough for incidents.
Follow up after incidents. If someone made a manual fix, the postmortem includes "update the code".
Tag managed resources (managed_by = terraform) so people know not to touch them.
Policies with AWS SCPs, Azure Policy or similar to block the most dangerous manual changes entirely.
Use ignore_changes carefully for attributes that other systems legitimately manage, like an autoscaling group's desired capacity.

lifecycle {
  ignore_changes = [desired_capacity]
}

So, how much drift is acceptable?

Some drift will always happen, especially during incidents. The goal isn't zero drift. It's knowing about it within a day, and resolving it deliberately. A nightly drift check plus a habit of updating code after manual fixes gets you most of the way.

My take: the console isn't the enemy. Forgetting what you did in it is. Detect drift early and make the code the place where the truth lives.

— Desly

Terraform state, explained

Tue, 20 Oct 2026 23:10:30 +0200

When people start with Terraform, they focus on the .tf files. The resources, the modules, the variables. The state file is just something that appears after the first apply, and most people don't think about it until something goes wrong.

And something always goes wrong eventually. A lost state file, a corrupted one, two people applying at once, a secret leaked through state. Understanding state is what separates using Terraform from trusting it. (OpenTofu works the same way.)

What state actually is

Terraform's state is a JSON file that maps your code to real-world resources.

When you write resource "aws_s3_bucket" "logs", Terraform needs to remember that this particular block corresponds to the bucket with ID acme-logs-prod in your AWS account. That mapping, plus the last known attributes of every resource, is the state.

Terraform uses it to:

Know what exists, so it can update or delete the right resources.
Calculate the plan by comparing code, state and reality.
Track dependencies and outputs between resources.
Speed things up, by not looking up everything from scratch every time.

Without state, Terraform doesn't know which resources it manages. Delete the state file, and Terraform will try to create everything again, while the old resources keep running, unmanaged.

Remote state, always

For anything beyond a personal experiment, keep state in a remote backend with locking:

S3 (with native lock files), Google Cloud Storage, Azure Blob Storage
HCP Terraform or other infrastructure automation platforms

Locking prevents two people (or pipelines) from applying at the same time and corrupting state. Versioning on the bucket gives you history to recover from mistakes.

Your state file is the memory of your infrastructure. Lose it, and Terraform wakes up with amnesia in a house full of strangers.

Keeping it secret

State files often include secrets in plain text: database passwords, private keys, tokens, or anything a resource returns as an attribute. Even if you mark a variable as sensitive, it's hidden in the plan output, not in the state file.

Protect state like you protect secrets:

Encryption at rest on the storage bucket.
Strict access control: only the pipeline and a few admins can read production state.
Never commit state to Git. Add *.tfstate and *.tfstate.backup to .gitignore.
OpenTofu's client-side state encryption encrypts the state before it leaves your machine or pipeline, using a KMS key.
Terraform's ephemeral resources and write-only arguments keep certain secret values out of state entirely.
Generate secrets outside Terraform where possible, in a secret manager, and only pass references around.

Moving and refactoring

Renaming a resource or moving it into a module changes its address. Without telling Terraform, it would destroy the old resource and create a new one. For a database, that's a disaster.

Modern Terraform handles this in code with moved blocks:

moved {
  from = aws_s3_bucket.logs
  to   = module.logging.aws_s3_bucket.this
}

The plan shows a move instead of destroy-and-create. Because it's in code, it's reviewed and works across every environment. Much safer than the older terraform state mv command.

Importing existing resources

To bring a manually created resource under Terraform's management, use import blocks:

import {
  to = aws_s3_bucket.legacy
  id = "acme-legacy-bucket"
}

Run terraform plan -generate-config-out=generated.tf and Terraform even writes a first draft of the resource configuration. Clean it up, plan again, and apply.

Removing resources from management

Sometimes you want Terraform to stop managing a resource without deleting it, for example when handing it over to another stack. Use a removed block:

removed {
  from = aws_s3_bucket.handover

  lifecycle {
    destroy = false
  }
}

The resource stays in the cloud. Terraform just forgets about it.

When it breaks

A few situations and what to do:

Stale lock after a crashed pipeline: terraform force-unlock <lock-id>, but only after checking that nothing is actually running.
Corrupted or wrong state: restore a previous version from the bucket's version history. This is why versioning matters.
State out of sync with reality: terraform plan -refresh-only shows the differences, and terraform apply -refresh-only updates state to match reality without changing infrastructure.
Need to inspect state: terraform state list and terraform state show <address> are safe, read-only ways to look inside.

Avoid editing the JSON by hand. If you really must, take a backup first, and know that you're on your own.

So, what should you check today?

Is every state file remote, locked, versioned, and encrypted? Who has access to production state? Are you still using state mv commands instead of moved blocks? Those three questions cover most of the risk.

My take: treat state as the most sensitive file in your infrastructure. Protect it, version it, and never let it live on a laptop.

— Desly

Terraform in CI: plan on PR, apply on merge

Tue, 20 Oct 2026 23:10:30 +0200

In many teams, Terraform is still run from someone's laptop. They pull the latest code, run plan, look at it, run apply. It works, until it doesn't: someone applies an old branch, two people apply at once, the laptop has different provider versions, or the only person with production credentials is on holiday.

The fix is a simple, well-known workflow: plan on pull request, apply on merge. Here's how I set it up.

The workflow

A developer changes infrastructure code on a branch and opens a pull request.
CI runs terraform plan and posts the plan as a comment on the pull request.
Reviewers look at both the code and the plan.
After approval, the pull request is merged.
CI runs terraform apply with the plan, from the main branch.

Everything is reviewed, everything is logged, nobody needs production credentials on their laptop, and the main branch always reflects what's deployed.

The plan is the real change. Review the plan as carefully as the code.

Option 1: Atlantis

Atlantis is an open-source server built exactly for this workflow. It listens to pull request events, and you control it with comments:

Open a PR, and Atlantis automatically runs plan and comments the output.
Comment atlantis apply and it applies, then comments the result.
It locks the affected directories so two PRs can't change the same state at the same time.

Atlantis runs in your own infrastructure (often on Kubernetes), so credentials never leave your environment. It's simple, battle-tested and free. You do have to host and maintain it.

Option 2: GitHub Actions (or any CI)

You can build the same workflow in your normal CI. A simplified GitHub Actions version:

name: terraform

on:
  pull_request:
    paths: ["infrastructure/**"]
  push:
    branches: [main]
    paths: ["infrastructure/**"]

permissions:
  contents: read
  id-token: write
  pull-requests: write

jobs:
  terraform:
    runs-on: ubuntu-latest
    defaults:
      run:
        working-directory: infrastructure/live/production/network
    steps:
      - uses: actions/checkout@<sha> # v4
      - uses: hashicorp/setup-terraform@<sha> # v3
      - uses: aws-actions/configure-aws-credentials@<sha> # v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/terraform-${{ github.event_name == 'push' && 'apply' || 'plan' }}
          aws-region: eu-central-1
      - run: terraform init -input=false
      - run: terraform plan -input=false -out=tfplan
      - if: github.event_name == 'pull_request'
        run: terraform show -no-color tfplan > plan.txt
        # post plan.txt as a PR comment with your preferred action
      - if: github.event_name == 'push'
        run: terraform apply -input=false tfplan

Things to notice:

Two different IAM roles: a read-only role for plans on pull requests, and a role with write access only for applies from main. The trust policy restricts which branch can assume which role.
OIDC, no stored cloud keys.
Use GitHub environments with required reviewers for production applies if you want an extra approval step.

One subtlety: the plan on the pull request and the apply after merge can differ if main changed in between. Re-planning on merge (as above) and applying that plan is the safe way.

Option 3: TACOS

"TACOS" (Terraform Automation and Collaboration Software) is the nickname for platforms built for this: HCP Terraform, Spacelift, env0, Scalr, Harness IaCM and others. They add:

Policy as code (OPA or Sentinel) on every plan.
Drift detection and scheduled runs.
Stack dependencies, cost estimation, approvals, audit logs.
Self-service and RBAC for many teams.

They cost money, but save a lot of building and maintaining for larger organisations.

Approvals

Who can approve infrastructure changes? Some practical rules:

CODEOWNERS so the right team reviews changes to their part of the infrastructure.
Required reviews in branch protection.
Extra approval for production applies, through CI environments or the platform.
Plans visible to reviewers, ideally summarised: number of resources added, changed and destroyed. A "destroy" in production should stand out.

Secrets and OIDC authentication

Never store long-lived cloud keys in CI for Terraform. Use OIDC with every major cloud, and scope the roles tightly. Combine that with remote, encrypted, locked state, and the most sensitive parts of your setup never touch a developer's laptop.

So, how do I start?

Pick one Terraform stack, ideally a low-risk one. Set up plan-on-PR with a read-only role first, so the team gets used to reviewing plans. Then add apply-on-merge with a separate role. Once it works, roll it out to the other stacks and take away production write access from laptops.

My take: infrastructure changes deserve the same pipeline discipline as application code. Review the plan, merge, and let the robot apply.

— Desly

Terraform modules others actually want to use

Tue, 20 Oct 2026 23:10:30 +0200

Every platform team eventually builds a set of internal Terraform modules. A standard way to create a database, a bucket, a network, a cluster. The idea is great: encode the company's best practices once, and let everyone reuse them.

In practice, many internal modules end up either ignored (teams copy resources instead) or hated (so many options that nobody understands them). Here's what makes a module people actually want to use.

Start with a clear purpose

A good module does one thing well, with an opinion. Not "a wrapper around every argument of aws_db_instance", but "a PostgreSQL database configured the way we run databases here": encrypted, backed up, monitored, in the right network, with the right tags.

If the module just passes through every argument of the underlying resource, it adds no value. Teams might as well use the resource directly.

A good module removes decisions. A bad module just moves them to a different file.

A clean structure

modules/rds-postgres/
  main.tf
  variables.tf
  outputs.tf
  versions.tf
  README.md
  examples/
    basic/
      main.tf
  tests/
    defaults.tftest.hcl

versions.tf pins the required Terraform version and provider versions.
examples/ shows real usage, and doubles as a test fixture.
tests/ with terraform test files.

Inputs, outputs and validation

Few required inputs, good defaults for the rest. The basic example should need only a handful of lines:

module "orders_db" {
  source      = "git::https://github.com/acme/terraform-modules.git//rds-postgres?ref=v2.3.0"
  name        = "orders"
  environment = "production"
  size        = "medium"
}

Validate inputs so mistakes fail early with a clear message:

variable "size" {
  description = "Database size: small, medium or large."
  type        = string
  default     = "small"

  validation {
    condition     = contains(["small", "medium", "large"], var.size)
    error_message = "size must be one of: small, medium, large."
  }
}

Translating size = "medium" into a specific instance class inside the module also means you can change the underlying instance type later without every team changing their code.

Useful outputs: IDs, endpoints, ARNs, security group IDs, the name of the secret holding credentials. Think about what the next resource will need.

Use precise types: object({...}) with optional attributes instead of a generic map(any).

Versioning and a private registry

Modules change. Users need stability. So:

Tag releases with semantic versions: v1.4.0, v2.0.0.
Always reference a version (?ref=v2.3.0 for Git, or version = "~> 2.3" for a registry). Never point at main.
Write a changelog, and mark breaking changes clearly. A breaking change means a new major version.
Publish to a private registry if you can: HCP Terraform, GitLab, Artifactory, Spacelift and others offer them. It gives you version constraints, discovery and documentation in one place.
Let Renovate update module versions in consuming repositories.

Docs that write themselves

Nobody wants to maintain a README by hand. terraform-docs generates the inputs and outputs tables from your code:

terraform-docs markdown table --output-file README.md --output-mode inject .

Run it in a pre-commit hook or CI, and the documentation stays in sync. Add a short human-written section on top: what the module is for, what it does by default, and a minimal example.

Testing modules

Even a few tests help a lot:

Plan-based tests with terraform test to check defaults: encryption on, deletion protection on, tags present.
Validation tests that check bad inputs are rejected.
An apply test in a sandbox account for critical modules, run on release rather than every commit.
Static checks (tflint, Checkov) on the module itself.

When to stop abstracting

The most common mistake I see: modules wrapping modules wrapping modules, with dozens of variables, feature flags for every possible use case, and count tricks everywhere.

Signs you've gone too far:

The module has more variables than the resources it creates have arguments.
Nobody can explain what happens when you set a particular flag.
Teams fork the module because changing it is too scary.

It's fine for a module to say no. If a team has a genuinely unusual need, they can use the resource directly or you can create a second, separate module. Not every use case belongs in the same one.

So, what makes a great module?

A clear opinion, few required inputs, validated variables, useful outputs, generated docs, real versions and a few tests. Built for the common case, with the humility to not cover everything.

My take: build modules that make the right way short and obvious. If people copy resources instead, the module isn't helping them yet.

— Desly

Servers you never patch: golden images with Packer

Tue, 20 Oct 2026 23:10:30 +0200

There's an old way to run servers that many of us grew up with. You set up a machine, install your software, and then keep it alive for years. Patch it, tweak it, fix it by hand when something breaks. Over time, every server becomes slightly different, and nobody knows exactly what's on them. People call those servers "pets".

You never change a running server. When something needs to change, you build a new image, start new servers from it, and throw the old ones away.

Pets vs cattle, revisited

The famous analogy:

Pets have names, are unique, and get nursed back to health when sick.
Cattle have numbers, are identical, and get replaced when sick.

Containers made the cattle model normal for applications. But plenty of workloads still run on virtual machines: Kubernetes nodes themselves, databases, legacy apps, CI runners, appliances. Golden images bring the same idea to VMs.

What a golden image is

A golden image is a pre-built machine image (an AMI on AWS, a managed image on Azure, a custom image on Google Cloud, a template on VMware or Proxmox) that already contains:

An up-to-date, hardened operating system
Your monitoring and logging agents
Security tools and configuration
Sometimes the application itself

A new server starts from it in seconds, already configured. No long setup scripts at boot, no drift between machines.

If a server needs fixing, don't fix it. Fix the image, and replace the server.

Building images with Packer

Packer, from HashiCorp, is the most common tool for building images. You describe the image in HCL, and Packer starts a temporary machine, runs your setup steps, and saves the result as an image.

packer {
  required_plugins {
    amazon = {
      source  = "github.com/hashicorp/amazon"
      version = "~> 1.3"
    }
  }
}

source "amazon-ebs" "base" {
  region        = "eu-central-1"
  instance_type = "t3.small"
  ssh_username  = "ubuntu"
  ami_name      = "acme-base-{{timestamp}}"

  source_ami_filter {
    filters = {
      name                = "ubuntu/images/hvm-ssd-gp3/ubuntu-noble-24.04-amd64-server-*"
      virtualization-type = "hvm"
    }
    owners      = ["099720109477"] # Canonical
    most_recent = true
  }
}

build {
  sources = ["source.amazon-ebs.base"]

  provisioner "shell" {
    inline = [
      "sudo apt-get update",
      "sudo apt-get -y upgrade",
      "sudo apt-get -y install unattended-upgrades auditd"
    ]
  }

  provisioner "ansible" {
    playbook_file = "./playbooks/harden.yml"
  }
}

The same template can build images for several clouds at once. Provisioners can be shell scripts, Ansible playbooks, or other tools.

Image pipelines

Building images by hand defeats the purpose. Put it in a pipeline:

Build the image on a schedule (weekly is common) and whenever the template changes.
Test it: boot an instance, run checks (services running, ports closed, hardening applied). Tools like Goss or InSpec help.
Scan it for vulnerabilities.
Publish it, tagged with a version and date, and share it with the accounts that need it.
Roll it out by updating the image ID in your infrastructure code.
Clean up old images after a retention period.

Cloud providers also offer managed services for this, like EC2 Image Builder on AWS and Azure VM Image Builder.

How often I rebuild

Security patches are released constantly. With immutable infrastructure, patching means rebuilding the image and replacing servers.

A weekly rebuild keeps images close to current. For critical vulnerabilities, trigger an extra build right away. The beauty of this model: patching is the same routine as any other change, fully automated and tested, instead of a stressful manual patch night.

Pairing with autoscaling

Golden images work best with autoscaling groups (or VM scale sets, or managed instance groups):

Build a new image.
Update the launch template with the new image ID.
Trigger a rolling instance refresh: the group replaces old instances with new ones, a few at a time, waiting for health checks.
If something's wrong, roll back to the previous launch template version.

Kubernetes node pools work similarly: managed node groups can be updated to a new image with a rolling replacement. Tools like Karpenter go even further, regularly replacing nodes to keep them fresh.

What to watch out for

Don't bake secrets into images. Fetch them at boot from a secret manager.
Keep environment-specific config out of the image too. Use instance metadata, tags or a config service at startup.
Stateful data must live on separate volumes or services, so replacing a server doesn't lose anything.
Image sprawl: set a retention policy and clean up old images regularly.

So, is it worth it?

For any fleet of VMs that you run for more than a few weeks, yes. Fewer surprises, faster scaling, easier patching, and you always know exactly what's running.

My take: stop nursing servers. Build them right once, replace them often, and let the image carry the knowledge.

— Desly

Stop putting secrets in CI variables

Tue, 20 Oct 2026 23:10:30 +0200

Ask a team where their secrets are, and the honest answer is often "everywhere". Some in CI variables. Some in a .env file that gets passed around. Some in Kubernetes secrets created by hand. A few in a password manager. At least one in a Git repository's history, from three years ago.

Secrets sprawl is one of the most common security problems I see, and one of the easiest to fix.

Where secrets leak

Git history. Committed once, deleted later, still there forever unless the history is rewritten.
CI logs. A debug echo, a verbose command, a compromised action printing environment variables.
CI variables with broad access: anyone who can edit a workflow can often read them.
Kubernetes secrets in plain YAML in Git. Base64 isn't encryption.
Terraform state containing database passwords.
Chat and tickets. "Here's the password, delete this message after."

The common thread: secrets are copied into many places, and every copy is a place they can leak from.

The goal: one source of truth

The better approach: keep secrets in one central secret store, and have every consumer (apps, pipelines, people) fetch them from there with their own identity, only when needed. Ideally, secrets are short-lived or rotated automatically, so a leak expires quickly.

The options compared

HashiCorp Vault is the most well-known. It stores secrets, but also generates them dynamically: database credentials created on demand, cloud credentials that expire after an hour, certificates from its own PKI. Very powerful, and real work to run well (high availability, unsealing, upgrades). Since 2023 it's under the Business Source License.

OpenBao is the community fork of Vault from before the license change, now under the Linux Foundation. API-compatible with Vault for most use cases, open-source licensed, and developing its own features.

Cloud secret managers: AWS Secrets Manager, Azure Key Vault, Google Secret Manager. Fully managed, integrated with cloud IAM, easy to start with. Less flexible than Vault for dynamic secrets across many systems, but perfectly enough for many teams.

Encrypted files in Git: SOPS (with age or a cloud KMS) encrypts values inside YAML or JSON files, so you can commit them safely. Good for GitOps setups and small teams.

The best secret is one that doesn't exist yet, gets created when you need it, and expires before anyone can steal it.

Getting secrets into Kubernetes

Applications in Kubernetes usually expect secrets as environment variables or files. Ways to get them there from a central store:

External Secrets Operator (ESO) syncs secrets from Vault, OpenBao, cloud secret managers and others into regular Kubernetes Secrets:

apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: orders-db
  namespace: shop
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secrets-manager
    kind: ClusterSecretStore
  target:
    name: orders-db-credentials
  data:
  - secretKey: password
    remoteRef:
      key: prod/shop/orders-db
      property: password

Your Git repository only contains a reference, never the secret itself. Apps keep reading a normal Kubernetes Secret.

Secrets Store CSI Driver mounts secrets directly from the external store as files, optionally without creating a Kubernetes Secret at all.

Vault Agent / OpenBao Agent injection runs a sidecar that fetches and renews secrets for the pod.

Whichever you choose, make sure Kubernetes Secrets are encrypted at rest in etcd (managed clusters usually support KMS encryption), and limit who can read them with RBAC.

In CI pipelines

Use OIDC to authenticate pipelines to your cloud and to Vault/OpenBao, instead of storing long-lived credentials.
Fetch secrets at runtime, only in the jobs that need them.
Mask secrets in logs, and avoid printing environment variables.
Scope CI secrets to protected branches and environments.

Rotation and dynamic secrets

A secret that never changes is a secret that eventually leaks. Options, from simple to advanced:

Scheduled rotation of static secrets (cloud secret managers can rotate database passwords automatically).
Dynamic secrets from Vault/OpenBao: each app instance gets its own credentials, valid for hours.
Workload identity: no secret at all. Pods authenticate to cloud services using their Kubernetes service account identity.

Find what already leaked

Before building the perfect system, scan for what's already out there:

gitleaks or TruffleHog across your repositories, including history.
GitHub secret scanning with push protection enabled.
Rotate everything you find. Deleting the commit isn't enough.

So, where do I start?

Pick a central store: your cloud's secret manager is the easiest start. Install External Secrets Operator. Move one application's secrets there, remove them from CI variables and Git, and rotate them. Then repeat, service by service.

My take: secrets should be fetched, not copied. Every copy is a future incident waiting for its date.

— Desly

Security in the pipeline, not after it

Tue, 20 Oct 2026 23:10:30 +0200

For a long time, security worked like this: the team builds something for months, then a security review or penetration test happens just before launch, finds a list of problems, and everyone panics. Fixing things at the end is slow, expensive and stressful.

"Shift left" means moving security checks earlier, into the developer's workflow and the CI pipeline. Problems are found minutes after they're introduced, when they're cheapest to fix. That's the heart of DevSecOps.

The scanner types, simply

There's an alphabet soup of security scanning. Here's what each one does:

SAST (Static Application Security Testing): reads your source code looking for insecure patterns. SQL injection, hardcoded secrets, unsafe functions.
SCA (Software Composition Analysis): checks your dependencies for known vulnerabilities and license issues.
Secret scanning: looks for passwords, API keys and tokens in code and history.
IaC scanning: checks Terraform, Kubernetes manifests, Helm charts and Dockerfiles for misconfigurations.
Container image scanning: finds vulnerable packages in your images.
DAST (Dynamic Application Security Testing): attacks a running application from the outside, like a (polite) hacker would.

The tools I use

You don't need expensive tools to start. Excellent open-source options:

Type	Open-source tools	Notes
SAST	Semgrep, CodeQL	CodeQL is free for public repos on GitHub
SCA	Trivy, Grype, OSV-Scanner, Dependabot	Dependabot is built into GitHub
Secrets	gitleaks, TruffleHog, GitHub push protection	Scan history once, then every push
IaC	Checkov, Trivy, KICS	Trivy covers images, deps and IaC in one tool
Images	Trivy, Grype	Scan in CI and continuously in the registry
DAST	OWASP ZAP	Run against staging or preview environments

Commercial platforms (Snyk, GitHub Advanced Security, GitLab Ultimate, Wiz, Aikido and many others) bundle these with dashboards, prioritisation and fix suggestions.

A pipeline with security built in

A sensible layout:

Pre-commit (on the developer's machine): secret scanning, fast linting. Catch the obvious before it's even pushed.
Pull request: SAST, SCA, IaC scanning, with results as comments on the PR.
Build: image scanning, SBOM generation, signing.
Staging / preview: DAST against the running app.
Continuously: rescan images and SBOMs in production for newly discovered vulnerabilities.

Trivy alone covers a surprising amount:

trivy fs --scanners vuln,secret,misconfig .
trivy image --severity HIGH,CRITICAL --ignore-unfixed registry.example.com/shop-api:1.4.2

Security findings are like bugs. The sooner you find them, the cheaper they are, and the less anyone panics.

Handling false alarms

This is where most DevSecOps efforts fail. Turn on five scanners with default settings, and developers drown in hundreds of findings. Many are low-risk, unreachable or false positives. After a week, people ignore all of them.

What helps:

Start with high and critical findings only. Expand later.
Ignore unfixable vulnerabilities for now (there's no patch yet), but track them.
Use reachability where tools support it: is the vulnerable function actually called?
Tune rules and suppress false positives with a documented reason, in code (like .trivyignore or inline comments).
Show only new findings in pull requests, not the whole backlog. Fix the backlog separately.
One place for results: GitHub Code Scanning, GitLab's security dashboard, or DefectDojo, instead of five different reports.

Block or just report?

Should security findings fail the pipeline?

My approach:

Block on things that are clear-cut and fixable: committed secrets, critical vulnerabilities with a fix available, severe misconfigurations like public buckets or privileged containers.
Report everything else, with visibility and a deadline for fixing.
Start in report-only mode for new scanners, tune them, then switch to blocking for the most important rules.

Also give developers a way to accept a risk temporarily, with a reason and an expiry date. A hard block with no escape just leads to people disabling the scanner.

Make it a team habit

Tools are half the story. The other half:

Security champions in each team who care a bit more and help others.
Fix suggestions in the pull request, so developers know what to do.
Celebrate fixes, not just count findings.

So, where do I start?

Add secret scanning with push protection, Trivy for dependencies and images, and Semgrep or CodeQL for code. Report only high and critical issues at first. Once the noise is under control, start blocking on the most important ones.

My take: security works best when it's just another check in the pipeline, as normal as a failing test, and just as quick to fix.

— Desly

My Kubernetes security checklist

Tue, 20 Oct 2026 23:10:30 +0200

Kubernetes isn't insecure, but it isn't secure by default either. A fresh cluster lets pods run as root, talk to every other pod, and mount the host's file system if you ask. Most clusters I review have at least a few of these doors open.

This is the order I check things on every cluster, from most important to less urgent.

1. Who can do what (RBAC)

No shared admin kubeconfigs. People log in with SSO and get roles based on groups.
Nobody uses cluster-admin day to day. Keep it for break-glass access, logged and alerted.
Least privilege for service accounts. Most applications don't need to talk to the Kubernetes API at all. Set automountServiceAccountToken: false for those.
Watch for dangerous permissions: access to secrets across namespaces, pods/exec, creating pods in kube-system, escalate and bind verbs, and wildcards (*).
Review regularly. Tools like kubectl auth can-i --list, rbac-tool or KubiScan help find over-privileged accounts.

2. Locking down pods

Kubernetes has a built-in mechanism for this: Pod Security Admission, with three levels: privileged, baseline and restricted. Enable it per namespace with labels:

apiVersion: v1
kind: Namespace
metadata:
  name: shop
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/warn: restricted

The restricted level requires pods to follow best practices. A compliant pod's security context looks like:

securityContext:
  runAsNonRoot: true
  seccompProfile:
    type: RuntimeDefault
containers:
- name: app
  securityContext:
    allowPrivilegeEscalation: false
    readOnlyRootFilesystem: true
    capabilities:
      drop: ["ALL"]

Aim for restricted on all application namespaces. Keep privileged only for system components that genuinely need it (CNI, storage drivers, monitoring agents), in their own namespaces.

A container running as root with every capability is one vulnerability away from owning the node.

3. Network policies

By default, every pod can talk to every other pod in the cluster. If an attacker gets into one, they can reach everything.

Start with a default deny in each namespace, then allow what's needed:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: shop
spec:
  podSelector: {}
  policyTypes: ["Ingress", "Egress"]

Then add policies allowing, for example, the gateway to reach the API, the API to reach its database, and everything to reach DNS. Remember: network policies only work if your CNI supports them (Cilium, Calico and most modern CNIs do).

Restricting egress (outgoing traffic) is just as valuable: a compromised pod that can't reach the internet can't download tools or send data out easily.

4. Secrets

Encrypt secrets at rest in etcd, using KMS on managed clusters.
Don't store secrets in Git in plain YAML. Use External Secrets, Sealed Secrets or SOPS.
Limit get and list on secrets in RBAC. Listing secrets in a namespace reveals all of them.
Prefer workload identity over static cloud credentials in secrets.

5. Image policy

Only allow images from trusted registries.
No latest tags. Pin versions, ideally digests.
Require signed images (Cosign) for production.
Scan images in CI and continuously in the registry.

These are enforced with an admission policy engine like Kyverno or OPA Gatekeeper, or with Kubernetes' built-in ValidatingAdmissionPolicy for simpler rules.

6. Watching what runs (runtime security)

Preventive controls can be bypassed. Runtime security detects suspicious behaviour as it happens:

Falco (CNCF) watches system calls and alerts on things like a shell spawned in a container, unexpected outbound connections, or writes to sensitive directories.
Tetragon (from the Cilium project) uses eBPF for observability and can also enforce policies, like killing a process that does something forbidden.

Send their alerts to the same place as your other alerts, and tune them, or they'll become noise.

7. The control plane and nodes

API server not publicly exposed, or at least restricted to known IP ranges.
Audit logging enabled, and logs shipped somewhere central.
Keep Kubernetes up to date. Security fixes only land in supported versions.
Hardened node images, minimal OS (like Bottlerocket, Talos or Container-Optimized OS), regularly replaced.
Block access to cloud metadata endpoints from pods that don't need it, or enforce IMDSv2 on AWS.

8. Benchmarks

CIS Kubernetes Benchmark: a detailed set of recommendations. kube-bench checks a cluster against it.
Kubescape and Trivy (trivy k8s) scan clusters for misconfigurations and map them to frameworks like NSA/CISA hardening guidance.

Run them regularly. Don't aim for 100%, aim for understanding every finding.

So, where do I start?

If you can only do three things: switch people to SSO with least-privilege RBAC, enforce Pod Security restricted on application namespaces, and add default-deny network policies. That closes the biggest security gaps in most clusters.

My take: Kubernetes gives you all the locks you need. They just come unlocked in the box.

— Desly

Rules as code: OPA, Kyverno and built-in policies

Tue, 20 Oct 2026 23:10:30 +0200

Every organisation has rules. Containers must not run as root. Every deployment needs an owner label. Images must come from our registry. Production needs at least two replicas. Usually these rules live in a wiki page, and they're followed exactly as well as wiki pages are read.

Policy as code turns those rules into something a computer enforces, on every change, without anyone having to remember them.

Why rules belong in code

Consistent. The rule applies to everyone, every time, including at 3 a.m.
Fast feedback. Developers learn about a problem the moment they try to deploy, with a clear message, not weeks later in an audit.
Versioned and reviewed. Policies live in Git, go through pull requests, and have a history.
Testable. You can write tests for your policies like any other code.
Auditable. You can show exactly which rules apply and prove they're enforced.

Three ways to write them in Kubernetes

Kubernetes has admission control: every create or update request can be checked (validated) or modified (mutated) before it's stored. Policy engines plug in there.

Kyverno: policies as Kubernetes YAML

Kyverno, a CNCF project, lets you write policies as Kubernetes resources. If you can read a Deployment, you can read a Kyverno policy:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-latest-tag
spec:
  validationFailureAction: Enforce
  rules:
  - name: require-image-tag
    match:
      any:
      - resources:
          kinds: ["Pod"]
    validate:
      message: "Images must use a specific version tag, not 'latest'."
      pattern:
        spec:
          containers:
          - image: "!*:latest"

Kyverno can also mutate (add default labels or security settings), generate resources (create a default NetworkPolicy in every new namespace), and verify image signatures.

OPA Gatekeeper: policies in Rego

Open Policy Agent (OPA), also a CNCF project, is a general-purpose policy engine using a language called Rego. Gatekeeper integrates it with Kubernetes. Rego is very powerful and works far beyond Kubernetes (APIs, Terraform plans, CI pipelines), but it has a learning curve.

package k8srequiredlabels

violation[{"msg": msg}] {
  required := {"owner", "app"}
  provided := {label | input.review.object.metadata.labels[label]}
  missing := required - provided
  count(missing) > 0
  msg := sprintf("Missing required labels: %v", [missing])
}

ValidatingAdmissionPolicy: built into Kubernetes

Kubernetes now has its own policy mechanism, ValidatingAdmissionPolicy, stable since version 1.30. Rules are written in CEL (Common Expression Language) and run inside the API server, with no extra component to install:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: require-replicas-in-prod
spec:
  matchConstraints:
    resourceRules:
    - apiGroups: ["apps"]
      apiVersions: ["v1"]
      operations: ["CREATE", "UPDATE"]
      resources: ["deployments"]
  validations:
  - expression: "object.spec.replicas >= 2"
    message: "Production deployments need at least 2 replicas."

(A ValidatingAdmissionPolicyBinding then applies it to specific namespaces.)

It's perfect for simple validation rules. For mutation, generation, image verification and reporting, Kyverno or Gatekeeper still offer more. Both engines are also adopting CEL themselves.

A rule in a wiki is a suggestion. A rule in an admission policy is a guarantee.

Policies I always add

A good starter set for most clusters:

No latest image tags.
Images only from approved registries.
Required labels: owner, app, maybe cost-center.
Resource requests required on every container.
No privileged containers, no host networking, no host path mounts (outside system namespaces).
Run as non-root.
Liveness and readiness probes on deployments.
Signed images in production.

Many of these are available ready-made in the Kyverno policy library and the Gatekeeper library.

Rolling out without breaking things

The fastest way to make enemies is to switch on twenty policies in enforce mode on a Friday. Instead:

Start in audit mode. Kyverno's Audit, Gatekeeper's dryrun or warn, or Warn/Audit actions for ValidatingAdmissionPolicy. Violations are reported, nothing is blocked.
Look at the reports. Kyverno creates PolicyReports, Gatekeeper records violations. Fix existing workloads.
Communicate. Tell teams which rules are coming, why, and how to comply.
Enforce gradually, rule by rule, namespace by namespace.
Allow documented exceptions, with an owner and an expiry date.

Testing policies

Kyverno has a CLI (kyverno test) to run policies against sample resources.
OPA has opa test for Rego unit tests.
Run the same policies in CI against your manifests, so developers find out before they even reach the cluster.

So, which engine?

For most teams starting out, Kyverno is the easiest: YAML policies, a big library, mutation and image verification included. Use ValidatingAdmissionPolicy for simple rules where you don't want another component. Choose OPA when you want one policy language across Kubernetes, Terraform, APIs and more.

My take: write the rules down once, in code, and let the cluster remember them for you.

— Desly

Audits without screenshots: compliance as code

Tue, 20 Oct 2026 23:10:30 +0200

If you've been through a SOC 2 or ISO 27001 audit, you know the routine. Weeks before the audit, someone sends a spreadsheet of controls. Engineers stop their work to take screenshots: here's our MFA setting, here's our backup policy, here's proof we reviewed access in March. The auditor asks for more screenshots. Everyone is relieved when it's over, until next year.

There's a better way: treat compliance like any other requirement. Express it in code, check it continuously, and generate evidence automatically.

Controls become checks

A compliance framework is a list of controls. Many of them are actually technical statements that can be checked automatically:

Control (simplified)	Automated check
Data is encrypted at rest	All storage, databases and volumes have encryption enabled
Access requires MFA	Identity provider enforces MFA for all users
Changes are reviewed	Branch protection requires approvals on production repos
Systems are patched	Images rebuilt weekly, no critical vulnerabilities older than X days
Backups exist and are tested	Backup jobs succeed, restore tests run monthly
Logs are retained	Audit logs enabled and retained for the required period
Least privilege	No users with admin rights outside an approved group

Once written as checks, they can run every day instead of once a year.

If a control can be checked by a script, it shouldn't be checked by a screenshot.

The tools I use

For cloud configuration: - AWS Config, Azure Policy, Google Cloud Security Command Center: continuous checks of cloud resources, with built-in rule packs for many frameworks. - Prowler: open-source security and compliance scanner for AWS, Azure, GCP and Kubernetes, with mappings to CIS, SOC 2, ISO 27001, PCI DSS and more. - Cloud Custodian: rules written in YAML that can find and even fix non-compliant resources automatically (for example, tag or stop untagged instances).

For infrastructure code: - Checkov, Trivy, OPA/Conftest to block non-compliant changes before they're applied.

For Kubernetes: - Kyverno or Gatekeeper policies, and Kubescape for framework-based scans.

For the bigger picture: - Compliance automation platforms like Vanta, Drata and Secureframe connect to your cloud, identity provider, HR system and code hosting, map everything to controls, and collect evidence continuously. Very useful for smaller companies going through their first audit.

Prevent, detect, prove

I think about it in three layers:

Prevent: policies in CI and admission control stop non-compliant changes from ever being deployed. An unencrypted bucket never gets created.
Detect: continuous scanning finds anything that slipped through, or changed manually.
Prove: evidence is collected automatically and stored, ready for the auditor.

Prevention is the cheapest. Detection is the safety net. Proof is what the audit needs.

Git and CI as evidence

A huge amount of evidence already exists in your tools, if you set them up properly:

Change management: every production change is a pull request with an approval and a passing pipeline. Git history plus branch protection settings are the evidence.
Deployment records: your CI/CD and GitOps tools log who deployed what, when.
Infrastructure state: Terraform plans and applies, logged in CI.
Access reviews: if group membership is managed as code (for example in Terraform or your identity provider's API), reviews become pull requests.

Auditors increasingly accept this kind of system-generated evidence, and often prefer it to screenshots, because it's complete and harder to fake.

Continuous compliance dashboards

Bring results together in one view: which controls pass, which fail, and since when. Share it with security, engineering and management. The conversation changes from "are we ready for the audit?" to "this control has been failing for three days, who's fixing it?"

What can't be automated

Not everything is technical. Policies need writing, people need training, risk assessments need human judgement, vendors need reviewing. Compliance as code doesn't remove that work. It removes the repetitive, error-prone part, so people can focus on the parts that need thinking.

So, where do I start?

Take the control list from your last audit. Find the five technical controls that required the most screenshot work. Use your cloud's built-in tools or Prowler to automate checks for those. Next time, you'll show a dashboard instead of a folder full of images.

My take: compliance shouldn't be a yearly fire drill. Write the rules as code, check them every day, and let the audit become a formality.

— Desly

OpenTelemetry from the ground up

Tue, 20 Oct 2026 23:10:30 +0200

For years, observability meant choosing a vendor and installing their agent everywhere. Then their SDK in your code. Then their query language in your head. Switching vendors meant re-instrumenting everything, so nobody switched, and prices went up.

OpenTelemetry changed that. It's now the second most active CNCF project after Kubernetes, and the standard way to collect telemetry. If you're starting with observability today, start here.

Why OpenTelemetry

OpenTelemetry (often shortened to OTel) is a set of open standards, SDKs and tools for generating and collecting telemetry data. The key idea: instrument once, send anywhere.

Your code and infrastructure produce data in a standard format. Where that data goes, Prometheus, Grafana, Jaeger, Datadog, Honeycomb, New Relic, Elastic or anything else, is just configuration. Change the backend, keep the instrumentation.

The four signals

Traces follow a single request through your system. A trace is made of spans, one per operation: the HTTP request, the database query, the call to another service. Traces answer "where did the time go?" and "where did it fail?"

Metrics are numbers over time: request rate, error rate, latency percentiles, CPU usage, queue length. Cheap to store, great for dashboards and alerts.

Logs are timestamped events. OpenTelemetry can attach trace IDs to logs, so you can jump from a log line to the full trace of the request that produced it.

Profiles show which code is using CPU and memory. This is the newest signal in OpenTelemetry, still maturing.

The magic happens when they're connected: a spike in a latency metric, linked to example traces, linked to the logs of the slow requests.

Metrics tell you something is wrong. Traces tell you where. Logs tell you why.

The building blocks

API and SDKs for each language (Java, Go, Python, JavaScript, .NET, Ruby, PHP, Rust and more) to create telemetry from code.
Auto-instrumentation that captures common libraries (HTTP frameworks, database drivers, messaging clients) without code changes.
OTLP, the OpenTelemetry Protocol, the standard wire format for sending data.
The Collector, a standalone service that receives, processes and exports telemetry.
Semantic conventions: standard names for attributes like http.request.method or db.system, so data looks the same everywhere.

My first traces

The fastest way to see OpenTelemetry in action is auto-instrumentation. For a Python app:

pip install opentelemetry-distro opentelemetry-exporter-otlp
opentelemetry-bootstrap -a install

export OTEL_SERVICE_NAME=shop-api
export OTEL_EXPORTER_OTLP_ENDPOINT=http://otel-collector:4317
opentelemetry-instrument python app.py

For Java, attach the agent with -javaagent:opentelemetry-javaagent.jar. For Node.js, load the auto-instrumentation package at startup. On Kubernetes, the OpenTelemetry Operator can even inject auto-instrumentation into pods with a single annotation.

Within minutes, every incoming request, outgoing HTTP call and database query becomes a span.

Then add a few manual spans for important business operations:

from opentelemetry import trace

tracer = trace.get_tracer("shop")

def place_order(order):
    with tracer.start_as_current_span("place_order") as span:
        span.set_attribute("order.items", len(order.items))
        # ... business logic

The Collector: the heart of the setup

I always send telemetry to a Collector first, rather than directly from apps to a backend. It decouples apps from vendors and lets you process data centrally.

receivers:
  otlp:
    protocols:
      grpc:
      http:

processors:
  memory_limiter:
    check_interval: 1s
    limit_percentage: 80
  batch:
  attributes:
    actions:
      - key: user.email
        action: delete      # don't ship personal data

exporters:
  otlp/tempo:
    endpoint: tempo:4317
    tls:
      insecure: true
  prometheusremotewrite:
    endpoint: http://prometheus:9090/api/v1/write

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, attributes, batch]
      exporters: [otlp/tempo]
    metrics:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [prometheusremotewrite]

A common pattern on Kubernetes: a Collector as a DaemonSet on every node (receiving from local pods and collecting node data), sending to a central gateway Collector that handles sampling, filtering and exporting.

Sending data anywhere

With the Collector in the middle, changing or adding a backend is a configuration change. Popular open-source destinations:

Prometheus or Mimir for metrics
Tempo or Jaeger for traces
Loki for logs
Grafana on top of all of them

Or any commercial vendor that accepts OTLP, which today is almost all of them.

Tips from getting started

Set service.name on everything. Without it, your data is a mess.
Use resource attributes for environment, version and cluster.
Start with auto-instrumentation, then add manual spans where business logic matters.
Mind the volume: tracing every request in a busy system is expensive. Plan sampling early.
Keep personal data out, using Collector processors to drop or mask sensitive attributes.

So, is it worth it?

Absolutely. OpenTelemetry is where the whole industry is going. Instrumenting with it today means you'll never have to re-instrument just because you changed vendors, and you get traces, metrics and logs that finally talk to each other.

My take: instrument once, with an open standard, and keep the freedom to change your mind about everything else.

— Desly

A monitoring stack with Prometheus 3 and Grafana

Tue, 20 Oct 2026 23:10:30 +0200

Prometheus has been the backbone of Kubernetes monitoring for almost a decade. It was the second project to join the CNCF after Kubernetes itself. Then, in late 2024, came Prometheus 3.0, the first major version in seven years.

Here's what changed, and the monitoring stack I'd build today for a typical Kubernetes setup.

What's new in Prometheus 3

A new web UI. Rebuilt from scratch, with a modern query editor, better autocompletion, and a "explain" view that breaks down PromQL queries. It finally feels like a tool from this decade.

OpenTelemetry support. Prometheus can now receive metrics over OTLP directly. Apps instrumented with OpenTelemetry can push metrics to Prometheus without an extra translation layer.

UTF-8 metric and label names. Prometheus used to allow only a limited set of characters in names. Now dots and other characters are allowed, which matters for OpenTelemetry's naming conventions like http.server.request.duration.

Native histograms. A more efficient and precise way to store latency distributions, without having to choose bucket boundaries in advance. They've been maturing over the 3.x releases and are well worth using for latency metrics.

Remote Write 2.0. A more efficient protocol for sending data to long-term storage systems.

Breaking changes were kept small, but a few defaults changed (for example around scrape protocols and some flags). Read the migration guide before upgrading.

Setting it up

On Kubernetes, the easiest way to get a full stack is the kube-prometheus-stack Helm chart:

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install monitoring prometheus-community/kube-prometheus-stack \
  --namespace monitoring --create-namespace

It installs:

Prometheus Operator, which manages Prometheus with Kubernetes resources
Prometheus itself
Alertmanager for routing alerts
Grafana with ready-made dashboards
node-exporter for node metrics and kube-state-metrics for Kubernetes object state
A large set of default alerting rules

Then, to scrape your own apps, add a ServiceMonitor or PodMonitor:

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: shop-api
  namespace: shop
  labels:
    release: monitoring
spec:
  selector:
    matchLabels:
      app: shop-api
  endpoints:
  - port: http
    path: /metrics
    interval: 30s

The operator picks it up and configures Prometheus automatically. No editing of a central config file.

Prometheus is simple on purpose. It scrapes, stores and alerts, and it does those three things extremely well.

Keeping data longer

A single Prometheus server keeps data locally, usually for a few weeks. It's not designed for long-term storage or for a global view across many clusters. For that, there are three popular options:

Thanos: adds a sidecar to Prometheus that uploads data to object storage, plus components for querying across many Prometheus servers. Good if you already run Prometheus everywhere.
Grafana Mimir: a horizontally scalable metrics backend. Prometheus servers (or OTel Collectors) send data via remote write. Good for large, multi-tenant setups.
VictoriaMetrics: known for efficiency and low resource use, with a simple single-binary option and a cluster version.

For a single small cluster, plain Prometheus with a few weeks of retention is perfectly fine. Add one of these when you need months of history or many clusters in one view.

Dashboards I actually look at

Grafana lets you make hundreds of dashboards, but most people never look at them again. The ones I actually use are:

Service overview (RED): Rate, Errors and Duration for each service. One row per service, linked to details.
Cluster capacity: CPU and memory requests vs allocatable vs actual usage, per node pool. Shows both waste and pressure.
SLO dashboard: current error budget and burn rate for the most important services.
Kubernetes workloads: restarts, OOMKills, pending pods, failing deployments.
Dependencies: databases, queues and caches, their latency and saturation.

Keep dashboards in Git (Grafana supports provisioning dashboards from files, and there's a Grafana Operator for Kubernetes), so they're versioned and reviewed like code.

Alerts that matter

The kube-prometheus-stack comes with many alerts. Some are excellent, some will be noise in your environment. Go through them, keep what's actionable, and add alerts based on symptoms (error rates, latency, SLO burn rates) for your own services.

Route them through Alertmanager with grouping (one notification for related alerts), inhibition (don't alert on everything when a whole cluster is down) and different receivers for different severities.

So, where do I start?

Install kube-prometheus-stack in a test cluster, add a ServiceMonitor for one of your apps, and build a single RED dashboard for it. Upgrade to Prometheus 3 if you haven't already, and try the new UI. Long-term storage can wait until you actually need it.

My take: Prometheus 3 keeps everything that made Prometheus great, and finally speaks OpenTelemetry. It's still the best place to start.

— Desly

When the monitoring bill beats the server bill

Tue, 20 Oct 2026 23:10:30 +0200

There's a moment many companies reach: someone in finance asks why the observability invoice is bigger than the compute bill for the systems being observed. It sounds absurd, but it happens a lot. Observability costs have quietly become one of the biggest line items in many infrastructure budgets.

Most of that data isn't actually used. Cutting it doesn't mean losing sight of what's happening. It means being selective about what you keep.

Why it gets so expensive

Logs everywhere. Debug logging left on in production, verbose frameworks, health check logs, the same information logged by five layers.
Metric cardinality. A metric with labels like user_id, request_id or full URLs creates a separate time series for every unique value. Millions of series, each one billed.
Tracing everything. 100% of requests traced in a high-traffic system produces enormous volumes, most of them identical successful requests.
Long retention by default. Keeping everything for months, "just in case".
Per-host or per-container pricing combined with autoscaling and many small containers.
Duplicate data. The same logs sent to two tools, metrics collected by two agents.

Know where the money goes

Before cutting anything, measure:

Which services produce the most logs, metrics and traces?
Which metrics have the highest cardinality? (Prometheus has a TSDB status page showing this, and most vendors show usage per metric.)
Which data is actually queried? Many tools can show which dashboards, alerts and queries use which data.

You'll almost always find that a handful of services and metrics account for most of the bill.

The cheapest telemetry is the telemetry you decided not to collect, because you knew nobody would miss it.

Sampling traces

You don't need every trace. You need the interesting ones.

Head sampling decides at the start of a request whether to keep it, for example 10% of requests. Simple and cheap, but it might throw away the one failed request you needed.

Tail sampling decides after the trace is complete, so it can keep all errors, all slow requests, and only a small percentage of normal ones. The OpenTelemetry Collector supports this:

processors:
  tail_sampling:
    decision_wait: 10s
    policies:
      - name: keep-errors
        type: status_code
        status_code: { status_codes: [ERROR] }
      - name: keep-slow
        type: latency
        latency: { threshold_ms: 1000 }
      - name: sample-the-rest
        type: probabilistic
        probabilistic: { sampling_percentage: 5 }

You keep everything useful for debugging, and drop 90%+ of the volume.

Filtering logs

Drop noise at the source: health checks, readiness probes, successful static file requests.
Set sensible log levels: info or warn in production, debug only when investigating, ideally switchable at runtime.
Structured logs compress better and are cheaper to query.
Filter in the pipeline: the OTel Collector, Vector or Fluent Bit can drop, sample or truncate logs before they reach the expensive backend.
Turn repeated logs into metrics. If you only ever count a log line, make it a counter instead.
Tiered storage: recent logs in fast, expensive storage, older logs in cheap object storage (or deleted).

Taming metric cardinality

Never use unbounded values as labels: user IDs, request IDs, email addresses, full URLs, timestamps.
Normalise paths: /orders/{id} instead of /orders/12345.
Drop unused metrics with relabelling rules in Prometheus or the Collector. Many exporters expose hundreds of metrics, and you use ten.
Aggregate before storing with recording rules, keeping detailed data for a short time and aggregated data for longer.
Review new metrics in code review: what labels does it have, and how many values could each take?

Open source vs SaaS

Commercial platforms are convenient and powerful, but pricing based on hosts, ingested gigabytes or custom metrics can grow quickly.

Open-source stacks (Prometheus or Mimir, Loki, Tempo, Grafana, or ClickHouse-based tools like SigNoz) can be much cheaper at scale, especially with object storage. But they need people to run them, and that's a real cost too.

Many companies end up with a mix: OpenTelemetry everywhere, the Collector routing data, high-value data to a commercial tool, bulk data to cheaper self-hosted storage. Because OTel is vendor-neutral, you can change that split whenever pricing changes.

Make cost visible

Show observability costs per team or service.
Set budgets and alerts on ingestion.
Make "what does this cost to monitor?" a normal question when launching a new service.

So, where do I start?

Find your top five data producers. Turn on tail sampling for traces, drop health check logs, and remove your highest-cardinality labels. Those three changes alone often cut the bill dramatically, and nobody notices any loss in visibility.

My take: observability should help you understand your system, not compete with it for budget. Collect with intention, keep what you use, and let the rest go.

— Desly

Where should logs live? Loki, Elasticsearch or ClickHouse

Tue, 20 Oct 2026 23:10:30 +0200

Logs are the oldest form of observability and still the one everyone reaches for first when something breaks. They're also often the most expensive part of an observability setup, because there's so much of them.

Where you store logs decides how fast you can search them, how much you pay, and how much work it is to keep the system running. Three approaches dominate today, and they're built on very different ideas.

How they differ

Elasticsearch / OpenSearch: index everything

The classic. Elasticsearch (and its open-source fork OpenSearch) builds a full-text index of every log line. Every word becomes searchable, very fast.

Strengths: powerful full-text search, rich queries and aggregations, mature ecosystem (Kibana, OpenSearch Dashboards), great for security analytics.
Weaknesses: indexing everything is expensive in storage, memory and CPU. Clusters need careful tuning (shards, replicas, heap sizes). At large volumes, cost and operational effort grow fast.

Grafana Loki: index only labels

Loki takes the opposite approach: it doesn't index the log content, only a small set of labels (like namespace, app, pod, level). The log lines themselves are compressed and stored in cheap object storage. When you search, Loki finds the right streams by label, then scans through their content.

Strengths: much cheaper storage and much simpler to run. Fits naturally with Prometheus (same label model) and Grafana. Works great for "show me logs from this service around this time".
Weaknesses: searching for a random string across all logs over a long time range is slower. High-cardinality labels (like user ID) hurt performance badly. Labels must be chosen carefully.

ClickHouse: columnar analytics

ClickHouse is a columnar analytical database, built for fast queries over huge amounts of structured data. It's become very popular for logs and traces, used directly or through tools like SigNoz, HyperDX (now part of ClickHouse), Uptrace and others.

Strengths: excellent compression, very fast aggregations and filtering on structured fields, SQL queries. Great for structured logs where you want analytics ("error rate per endpoint per customer over the last month").
Weaknesses: you need to think about schema and table design. Pure full-text search is good but not Elasticsearch-level. Running ClickHouse clusters at scale requires expertise.

Elasticsearch asks "what words are in your logs?" Loki asks "where did they come from?" ClickHouse asks "what's in each field?"

What it costs

Rough relative comparison for the same volume of logs (actual numbers depend heavily on configuration and retention):

	Elasticsearch / OpenSearch	Loki	ClickHouse
Storage cost	High (index + data)	Low (compressed, object storage)	Low (columnar compression)
Compute for ingestion	High	Low	Medium
Full-text search speed	Excellent	Fair over long ranges	Good
Aggregations / analytics	Good	Basic (LogQL metrics)	Excellent
Operational effort	High	Low to medium	Medium

Managed versions exist for all three: Elastic Cloud, Amazon OpenSearch Service, Grafana Cloud Logs, ClickHouse Cloud, and many observability vendors build on one of these underneath.

Structured logs make everything better

Whatever you choose, structured logs (JSON or logfmt) help enormously:

{"ts":"2026-10-20T09:14:02Z","level":"error","service":"shop-api","trace_id":"4bf92f3577b34da6","route":"/orders","status":500,"duration_ms":1834,"msg":"payment provider timeout"}

Fields can be filtered and aggregated directly.
trace_id links logs to traces, so you can jump from a log line to the full request.
Consistent field names across services make cross-service searches possible.
Avoid putting variable data in the message text when it can be a field.

How long to keep them

Retention drives cost more than anything else. Think in tiers:

Hot (days to a couple of weeks): fast, searchable, for debugging.
Warm or cold (weeks to months): cheaper storage, slower queries, for investigations.
Archive (months to years): object storage, for compliance only.

Check legal requirements (security logs, audit logs, financial systems), and make sure personal data in logs is minimised and deleted on schedule. GDPR applies to logs too.

My recommendations

Kubernetes-heavy team already using Grafana and Prometheus: start with Loki. Cheap, simple, integrates beautifully.
Security analytics, full-text search across everything, existing Elastic expertise: Elasticsearch or OpenSearch.
Large volumes of structured logs, analytics questions, or a unified store for logs and traces: look at ClickHouse-based tools.

And collect logs with a vendor-neutral pipeline (the OpenTelemetry Collector, Vector or Fluent Bit), so you can change the storage later without touching every application.

So, where should your logs live?

Somewhere that matches how you actually search them, at a price you're comfortable with. For most teams starting fresh on Kubernetes, that's Loki. For teams with heavy search or analytics needs, the other two earn their extra cost or effort.

My take: choose your log storage by how you ask questions, not by habit. And remember that the cheapest log is still the one you never wrote.

— Desly

Breaking things on purpose: chaos engineering

Tue, 20 Oct 2026 23:10:30 +0200

Every system has weaknesses nobody knows about. A timeout that's too long. A retry that turns a small problem into a big one. A failover that worked once in testing two years ago and never since. Usually, you discover them during a real outage, at the worst possible time.

Chaos engineering is about finding weaknesses on purpose, in a controlled way, before they cause problems.

The idea

Netflix made chaos engineering famous with Chaos Monkey, a tool that randomly terminated production servers. The idea sounded crazy, but the logic was simple: if servers will fail anyway, make sure your system handles it, by making failure a normal, everyday event.

Today the practice is more careful and scientific than random destruction:

Define steady state: what does "working normally" look like? Usually measured with metrics like error rate, latency or orders per minute.
Form a hypothesis: "If one database replica fails, error rates stay below 0.5% and the app recovers within 30 seconds."
Introduce a failure: kill the replica.
Observe: did the steady state hold?
Learn and fix: if not, you've found a weakness before it caused a real outage.

Chaos engineering isn't about breaking things. It's about proving that your system can take a hit, and finding out where it can't.

What kinds of failures?

Common experiments:

Kill pods or nodes: does Kubernetes reschedule correctly? Do clients reconnect?
Add network latency: what happens when a dependency becomes slow, not down? (Often worse than being down.)
Drop network traffic between services, or to an external API.
Fill disks or exhaust memory and CPU.
Fail a whole availability zone: does traffic shift?
Break DNS or certificates.
Make a dependency return errors.

Your first game day

A game day is a planned session where a team runs chaos experiments together. It's the best way to start.

How I'd run one:

Pick a non-production environment that's close to production, like staging.
Choose one service and one or two experiments. For example: kill one pod of the checkout service, then add 500 ms latency to its database calls.
Write down the hypothesis for each experiment before starting.
Get everyone in a room or call: the service owners, someone watching dashboards, someone running the experiment.
Run the experiment, watch the metrics, take notes.
Have a stop button: know how to end the experiment immediately.
Debrief: what did we expect, what happened, what will we fix?

The first game day often shows something unexpected: a missing alert, a dashboard that's confusing, an outdated runbook, or a retry storm. That alone makes it worth doing.

Tools to try

Chaos Mesh (CNCF): a Kubernetes-native tool with a nice UI. Experiments are Kubernetes resources: pod kill, network delay, stress, I/O faults, time skew and more.
LitmusChaos (CNCF): Kubernetes chaos with a large hub of ready-made experiments and workflows.
AWS Fault Injection Service and Azure Chaos Studio: managed services for injecting failures into cloud resources, including AZ-level disruptions.
Gremlin: a commercial platform with safety controls and a good UI.
Toxiproxy: a simple proxy for simulating network conditions in tests.

A Chaos Mesh experiment adding latency:

apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: checkout-db-latency
  namespace: shop
spec:
  action: delay
  mode: all
  selector:
    namespaces: ["shop"]
    labelSelectors:
      app: checkout
  delay:
    latency: "500ms"
    jitter: "100ms"
  direction: to
  target:
    mode: all
    selector:
      labelSelectors:
        app: orders-db
  duration: "5m"

Starting small, staying safe

Start in staging, with small blast radius: one pod, one service.
Make experiments reversible and time-limited.
Monitor closely and abort if things go further than expected.
Tell people before you run experiments, especially at first.
Move to production carefully, only once you trust your monitoring and rollback, and start with the least risky experiments during working hours.

Did it help?

Measure the effect over time:

Number of weaknesses found and fixed.
Incidents caused by failure modes you'd already tested (should go down).
Recovery time in real incidents.
Team confidence during incidents, which is hard to measure but very real.

So, should you try it?

Yes, even on a small scale. One game day on staging, with one simple experiment, teaches a team more about their system than months of reading architecture diagrams.

My take: every system has a breaking point. Better to find it on a calm Tuesday afternoon than on a busy Saturday night.

— Desly

Profiling in production: where the CPU actually goes

Tue, 20 Oct 2026 23:10:30 +0200

Here's a familiar situation. A dashboard shows a service using way more CPU than it should. Latency is creeping up. You look at the metrics: yes, CPU is high. You look at the traces: requests are slow, but inside the service, not in its dependencies. You look at the logs: nothing unusual.

What you really want to know is: which code is using all that CPU? That's what profiling answers. And continuous profiling answers it all the time, in production.

What profiling shows

A profile records where a program spends its resources, down to individual functions and lines:

CPU profiles: which functions are running on the CPU, and how much.
Memory (heap) profiles: which code allocates memory, and how much is still held.
Allocation profiles: how often memory is allocated, which drives garbage collection overhead.
Lock and goroutine/thread profiles: where code waits.

Profiles are usually shown as flame graphs: each bar is a function, its width shows how much time it took, and functions it called are stacked on top. Wide bars are where the time goes. You can see at a glance that, for example, 30% of CPU goes into JSON serialisation, or a regex compiled on every request.

Metrics tell you that your service is slow. A flame graph points at the line of code making it slow.

Why continuous profiling

Developers have profiled code for decades, but usually locally, for a few minutes, with special tools. The problem: production behaves differently. Different data, different traffic, different load.

Continuous profiling collects profiles from production all the time, with low overhead, and stores them so you can:

Look at any point in the past: "what was this service doing during yesterday's spike?"
Compare time periods or versions: "what changed in CPU usage after release 2.4?"
See the whole fleet, not just one instance.
Link profiles to traces, so a slow span shows exactly which code was running.

The tools

Grafana Pyroscope: open source, integrates with Grafana, supports many languages through SDKs and eBPF.
Parca: open source, eBPF-based, profiles everything on a node without code changes.
OpenTelemetry profiling: profiles are becoming the fourth OpenTelemetry signal, with an eBPF-based profiling agent donated to the project. Still maturing, but it's clearly where things are going.
Commercial: Datadog, Elastic, Google Cloud Profiler, Polar Signals and others.

There are two ways to collect:

eBPF-based: an agent on each node profiles every process, in any language, with no code changes. Easy to roll out widely. Best support for compiled languages, and growing support for interpreted ones.
SDK-based: a library in your application. Gives richer information for some runtimes (like memory profiles in Go or Java), at the cost of adding a dependency.

The overhead

The usual first question: does profiling slow down production? Modern continuous profilers sample, for example looking at the stack a hundred times per second, instead of tracing every function call. The overhead is typically small, often around 1% of CPU, depending on the tool and settings.

Compared to the savings it often finds, that's a very good deal. But test it on your workloads, and start with a few services.

How profiling cuts CPU costs

This is where continuous profiling pays for itself. Common findings when teams first look at fleet-wide flame graphs:

Expensive logging: string formatting and serialisation for debug logs that are never shipped.
Inefficient serialisation: JSON encoding and decoding dominating CPU in API services.
Regexes compiled repeatedly instead of once.
Unnecessary allocations causing high garbage collection overhead.
Chatty libraries: an HTTP client or ORM doing much more work than expected.
Hot loops in code nobody looked at in years.

Fixing a single wide bar in the flame graph of a service that runs on hundreds of cores can save real money. That's why profiling is increasingly part of FinOps conversations, not just performance tuning.

A simple way to start

Install an eBPF-based profiler (Pyroscope's agent, Parca, or the OTel profiling agent) on a test cluster.
Open the flame graph for your most CPU-hungry service.
Look for the widest bars that aren't your core business logic.
Pick one, fix it, deploy, and compare before and after.

That first comparison, a visibly narrower bar and a lower CPU graph, is usually what convinces the rest of the team.

So, is it worth it?

For any team running services at scale, yes. Continuous profiling fills the gap between "the service is slow" and "here's why", and it regularly finds savings that pay for the whole observability stack.

My take: don't guess where your CPU goes. Look. The flame graph is usually more honest than any of us.

— Desly

Cutting the cloud bill by a third

Tue, 20 Oct 2026 23:10:30 +0200

Cloud bills have a way of growing quietly. A test environment nobody deleted. A database sized for a launch that never needed it. Snapshots from 2022. Data transfer charges nobody understands. Each one is small. Together, they add up to a bill that makes finance ask uncomfortable questions.

Industry surveys often say that a big chunk of cloud spending—usually a quarter to a third—is wasted. From my experience, cutting a typical bill by 20 to 30% is realistic without hurting performance. Here's how.

The FinOps idea

FinOps is the practice of bringing financial accountability to cloud spending. The FinOps Foundation describes a simple cycle:

Inform: make costs visible. Who's spending what, on which service?
Optimise: reduce waste and get better prices.
Operate: make cost part of everyday decisions, continuously.

The most important idea: cost isn't just finance's problem. Engineers make the decisions that create costs, every time they choose an instance size or a storage class. So engineers need to see the numbers.

Where the money goes

Before making cuts, look at the data. Every cloud provider has cost tools (AWS Cost Explorer, Azure Cost Management, Google Cloud Billing reports). Group costs by service, account or project, and tags.

Usually, a few categories dominate:

Compute (VMs, Kubernetes nodes)
Databases
Storage (block, object, snapshots)
Data transfer (often a surprise)
Managed services like logging and monitoring

And make sure resources are tagged with owner, team, environment and service. Without tags, you can't tell who owns what, and nobody feels responsible.

A cloud bill nobody looks at is a cloud bill that only grows.

Quick wins

These usually take days, not months:

Delete unused resources: unattached disks, old snapshots, idle load balancers, unused elastic IPs, forgotten test environments.
Right-size: many VMs and databases run at 10 to 20% CPU. Cloud providers' recommendation tools (AWS Compute Optimizer, Azure Advisor, Google Recommender) point them out.
Turn off non-production at night and weekends. Development and test environments that run only during working hours cost roughly a third.
Use the right storage class: move old data to cheaper tiers with lifecycle policies (S3 Intelligent-Tiering, infrequent access, archive classes).
Upgrade to newer instance generations, which are usually cheaper for the same performance. ARM-based instances (like AWS Graviton) often give a good price-performance improvement for workloads that support them.
Clean up logs: set retention periods on log groups. "Never expire" is a common, expensive default.

Commitments and Spot

Once usage is right-sized, get better prices for what remains:

Savings Plans and Reserved Instances (AWS), reservations and savings plans (Azure), committed use discounts (Google Cloud): commit to a certain level of usage for one or three years, and get significant discounts. Best for stable, predictable baseline usage. Commit to your baseline, not your peak.

Spot instances (AWS), Spot VMs (Azure, Google Cloud): spare capacity at large discounts, but they can be taken away with short notice. Great for:

Stateless, horizontally scaled services
Batch jobs and CI runners
Kubernetes node pools for fault-tolerant workloads (Karpenter handles Spot nicely)

Not for: single-instance databases or anything that can't handle interruption.

The sneaky costs

Some costs hide well:

Data transfer between availability zones and regions. Chatty services spread across zones can generate large bills. Topology-aware routing in Kubernetes helps.
NAT gateway charges for traffic to the internet or to cloud services. VPC endpoints for services like S3 can save a lot.
Idle managed services: a managed Kafka or Elasticsearch cluster used by one small app.
Observability: logging and metrics costs, often bigger than expected (I wrote a separate post on that).

Making cost everyone's job

Quick wins fade if nothing changes in how people work:

Show costs per team in a dashboard, updated daily. Showback alone changes behaviour.
Budgets and anomaly alerts so unexpected spikes are caught in days, not at the end of the month.
Cost in pull requests: tools like Infracost show the cost impact of Terraform changes before they're merged.
Cost as a non-functional requirement for new services, like performance or security.
The FOCUS specification (FinOps Open Cost and Usage Specification) is standardising billing data across providers, making multi-cloud cost reporting much easier.

So, where do I start?

Tag everything, find your top ten most expensive resources, and check each one: is it needed, is it the right size, is it running when it doesn't have to? That exercise alone usually finds the first 10 to 20% of savings. Then commitments and Spot take you further.

My take: the cloud lets you spend money at the speed of an API call. Make sure someone is watching at the same speed.

— Desly

What does each team's Kubernetes cost?

Tue, 20 Oct 2026 23:10:30 +0200

On a cloud bill, Kubernetes looks simple: you pay for nodes. Twenty VMs, a load balancer, some disks. But who's actually using those nodes? Ten teams, fifty services, a few hundred pods, all sharing the same machines. When finance asks "how much does the search team's infrastructure cost?", the cloud bill can't answer.

That's the Kubernetes cost visibility problem. Here's how to solve it, and how to reduce the bill once you can see it.

Splitting the bill

To allocate cluster costs to teams, you need to know how much of each node each pod uses or reserves, and what that node costs.

OpenCost is a CNCF project that does exactly this. It combines:

Pod resource requests and actual usage (CPU, memory, GPU, storage).
Prices from your cloud provider's billing API (including discounts and Spot pricing) or custom prices for on-premises.
Kubernetes metadata: namespaces, labels, deployments.

The result: cost per namespace, per label (like team or app), per workload, per hour.

Kubecost (now part of IBM) builds on OpenCost with more features: savings recommendations, budgets, alerts, multi-cluster views and a polished UI. Cloud providers also have their own Kubernetes cost features, like split cost allocation for EKS in AWS, and cost allocation in GKE and AKS.

helm install opencost opencost/opencost --namespace opencost --create-namespace
kubectl port-forward -n opencost svc/opencost 9090

A few minutes later, you see costs per namespace.

The "idle" problem

One thing that surprises teams the first time: a big chunk of the cost belongs to nobody. That's idle capacity: parts of nodes that no pod requested.

If your nodes are only 50% requested on average, half the cluster is idle. You decide how to handle it: share it out proportionally, assign it to the platform team, or (best) reduce it.

You can't fix what you can't see. Once teams see their Kubernetes cost, half the optimisation happens on its own.

Labels make or break it

Cost allocation is only as good as your labels. Agree on a few standard labels for every workload:

team or owner
app or service
environment
cost-center (if finance needs it)

Enforce them with a policy (Kyverno or Gatekeeper), so new workloads can't be deployed without them.

Packing nodes tightly

Once you see the waste, reducing it usually comes down to utilisation: getting more useful work out of each node.

Right-size requests. Over-requested pods reserve capacity they never use. VPA recommendations and Goldilocks help find realistic values.
Consolidation. Karpenter continuously looks for underused nodes and moves pods so it can remove them or replace them with smaller, cheaper ones. The Cluster Autoscaler also scales down underused nodes, more conservatively.
Better instance choices. Mixed instance types, newer generations and ARM-based nodes can lower cost per CPU.
Bin-packing scheduling. The default scheduler spreads pods out. Scheduler configuration that favours fuller nodes, or Karpenter's consolidation, packs them tighter.
PodDisruptionBudgets so consolidation can move pods safely without causing outages.

Spot on Kubernetes

Spot instances can cut node costs dramatically. Kubernetes is a great fit because it reschedules pods automatically when a node disappears.

Good practice:

A separate Spot node pool (or Karpenter NodePool) for fault-tolerant workloads.
Diversify instance types, so you're not dependent on one Spot pool.
Handle interruption notices (Karpenter and the AWS Node Termination Handler do this) to drain nodes gracefully.
Multiple replicas and PDBs for anything running on Spot.
Keep stateful and critical singleton workloads on on-demand nodes.

Showback or chargeback

What do you do with the numbers?

Showback: show each team its costs. No money moves, but visibility changes behaviour. Most companies start here.
Chargeback: actually charge teams' budgets for their usage. More accountability, more arguments about fairness, especially for shared and idle costs.

I'd always start with showback: a weekly report or dashboard per team, with trends and the biggest opportunities. It's surprising how quickly teams fix their own waste when the number has their name on it.

So, where do I start?

Install OpenCost, make sure every workload has a team label, and share a cost-per-team dashboard. Then look at idle capacity, right-size the biggest over-requesters, and enable consolidation. Spot comes next, for the workloads that can handle it.

My take: Kubernetes makes sharing infrastructure easy, and sharing costs invisible. Make them visible, and teams will help you bring them down.

— Desly

When a region goes down: disaster recovery that works

Tue, 20 Oct 2026 23:10:30 +0200

Cloud regions are incredibly reliable. Until they aren't. Large outages at major providers happen every now and then, sometimes taking down a whole region's worth of services for hours. And disasters aren't only about providers: a deleted production database, a ransomware attack, a bad deployment that corrupts data, or an expired payment method that suspends an account.

Disaster recovery (DR) is about answering one question honestly: if the worst happens, how quickly can we be back, and how much data will we lose?

RPO and RTO, simply

Two numbers define your DR goals:

RPO (Recovery Point Objective): how much data can you afford to lose? If your RPO is one hour, you need backups or replication at least every hour.
RTO (Recovery Time Objective): how long can you be down? If your RTO is four hours, you must be able to restore service within four hours.

Lower numbers cost more. An RPO of zero and an RTO of minutes means active-active systems in multiple regions, which is expensive and complex. An RPO of 24 hours and an RTO of a day might be fine for an internal tool.

Set them per system, with the business. Not everything needs the same level.

Four strategies

From cheapest to most expensive:

1. Backup and restore. Regular backups stored in another region or account. In a disaster, you rebuild infrastructure (with infrastructure as code) and restore data. Cheap, but recovery takes hours. RPO depends on backup frequency.

2. Pilot light. The core components (like a replicated database) run in the second region at minimal size. Everything else is ready to be created quickly from code. Faster recovery, moderate cost.

3. Warm standby. A scaled-down but fully working copy of the system runs in the second region. In a disaster, you scale it up and switch traffic. Recovery in minutes to an hour.

4. Active-active (multi-site). The system runs fully in multiple regions at once, serving traffic. A region failure just shifts traffic. Near-zero RTO, but the most expensive and complex, especially for data consistency.

Strategy	Typical RTO	Typical RPO	Cost
Backup and restore	Hours to a day	Hours	Low
Pilot light	Tens of minutes to hours	Minutes	Medium
Warm standby	Minutes	Seconds to minutes	Higher
Active-active	Near zero	Near zero	Highest

Disaster recovery is not a document. It's a capability, and capabilities need practice.

The foundations

Whatever strategy you choose, these basics matter:

Infrastructure as code for everything. Rebuilding infrastructure by hand during a disaster is slow and error-prone.
Backups in a different region and a different account, ideally with immutability (object lock) so ransomware or a compromised admin can't delete them.
Automated, monitored backups: alert when a backup fails or is missing.
DNS and traffic management that can switch regions quickly (low TTLs, health-checked failover records, global load balancers).
Secrets, certificates and container images available in the recovery region too. A common surprise: the image registry or secret store only existed in the failed region.
Runbooks that someone other than the original author can follow.

Kubernetes backups with Velero

For Kubernetes, Velero is the standard open-source tool. It backs up Kubernetes resources (deployments, services, config) and persistent volumes (with snapshots or file-level backup) to object storage, and restores them, even into a different cluster.

# Daily backup of the shop namespace, kept for 30 days
velero schedule create shop-daily \
  --schedule="0 2 * * *" \
  --include-namespaces shop \
  --ttl 720h

# Restore into a new cluster
velero restore create --from-backup shop-daily-20261020020000

With GitOps, your Kubernetes resources are already in Git, so the critical part Velero adds is persistent data. For databases, prefer the database's own backup tools (or an operator like CloudNativePG) for consistent, point-in-time recovery, and use Velero as an extra layer.

Testing it for real

This is the part most teams skip, and the part that matters most.

Restore backups regularly into a test environment, automatically if possible. Check the data is actually usable.
Run DR drills: once or twice a year, simulate losing a region or a critical system, and actually recover. Time it. Compare with your RTO.
Start small: restore one database, then one service, then a whole environment.
Write down every surprise during a drill and fix it. There will be surprises: missing permissions, forgotten dependencies, outdated runbooks, quotas in the recovery region.
Chaos experiments like failing an availability zone help build confidence too.

So, where do I start?

Agree RPO and RTO for your three most important systems. Check that their backups exist, are in another region and account, and are immutable. Then restore one of them into a fresh environment this month, and time it. That single exercise will tell you more about your real DR readiness than any document.

My take: you don't have disaster recovery until you've recovered from a disaster, even a pretend one.

— Desly

Why one AWS account isn't enough

Tue, 20 Oct 2026 23:10:30 +0200

Most AWS journeys start the same way. Someone creates an account with a company credit card, launches a few things, and it works. Then more teams arrive, production and testing share the same account, someone has admin rights who shouldn't, and nobody can tell which resources belong to which project.

The fix is a multi-account setup, usually called a landing zone. It sounds like enterprise bureaucracy, but it's one of the best investments a growing company can make in AWS. (Azure and Google Cloud have similar concepts, which I'll cover at the end.)

Why split accounts

An AWS account is the strongest isolation boundary AWS offers. Separate accounts give you:

Security isolation. A compromised developer account can't touch production.
Blast radius limits. A runaway script or misconfiguration stays in one account.
Clear cost allocation. Each account's bill belongs to a team or environment.
Service quotas per account, so one team can't exhaust limits for everyone.
Simpler permissions. Instead of complex IAM policies separating teams in one account, you give teams access to their own accounts.
Compliance scoping. Regulated workloads (like payment processing) live in their own accounts with stricter controls, limiting what auditors need to look at.

A typical account structure

AWS Organizations lets you manage many accounts centrally and group them into Organizational Units (OUs):

Root (management account: billing and organisation only)
├── Security OU
│   ├── Log Archive      (central, immutable logs)
│   └── Security Tooling (GuardDuty, Security Hub, audit access)
├── Infrastructure OU
│   ├── Network          (Transit Gateway, shared networking, DNS)
│   └── Shared Services  (CI/CD, container registry)
├── Workloads OU
│   ├── Prod OU
│   │   ├── shop-prod
│   │   └── search-prod
│   └── Non-Prod OU
│       ├── shop-staging
│       └── shop-dev
└── Sandbox OU
    └── personal and experiment accounts (with budgets)

Key rules: don't run workloads in the management account, and keep logs in a separate account that workload teams can't modify.

Accounts are cheap. Untangling a single shared account later is very expensive.

Organizations, Control Tower and SCPs

AWS Organizations provides the hierarchy, consolidated billing and policies.

Service Control Policies (SCPs) are guardrails applied to OUs or accounts. They define the maximum permissions anyone in those accounts can have, even administrators. Examples:

Deny use of regions you don't operate in.
Deny disabling CloudTrail, GuardDuty or AWS Config.
Deny leaving the organisation.
Deny creating IAM users with long-lived access keys.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyOutsideEU",
    "Effect": "Deny",
    "NotAction": ["iam:*", "organizations:*", "sts:*", "support:*", "cloudfront:*", "route53:*"],
    "Resource": "*",
    "Condition": {
      "StringNotEquals": { "aws:RequestedRegion": ["eu-central-1", "eu-west-1"] }
    }
  }]
}

(Global services are excluded because they're served from US regions.)

AWS has also added Resource Control Policies for guardrails on resources, and declarative policies for enforcing service configurations across accounts.

AWS Control Tower automates setting up a landing zone: it creates the core accounts (log archive, audit), configures guardrails, and offers an Account Factory to create new accounts with a standard baseline. It's the quickest way to start. For more customisation, many teams use Account Factory for Terraform (AFT) or manage accounts entirely with Terraform.

Access: IAM Identity Center

Don't create IAM users in each account. Use IAM Identity Center (formerly AWS SSO) connected to your company identity provider (Entra ID, Okta, Google Workspace):

People log in once and choose which account and role to use.
Permission sets define roles like ReadOnly, Developer, Admin.
Access is granted by group, and removed automatically when people leave.
The CLI uses short-lived credentials (aws sso login).

Connecting it all

Accounts are isolated by default, so networking needs a plan:

A Network account with Transit Gateway connecting VPCs across accounts, or VPC sharing (RAM) to share subnets.
Plan IP ranges centrally (AWS IPAM helps) so VPCs don't overlap.
Centralised egress and inspection where needed, for example shared NAT or firewalls.
Route 53 private hosted zones shared across accounts for internal DNS.

Security baseline in every account

Applied automatically to every new account:

CloudTrail (organisation trail) to the Log Archive account
GuardDuty, Security Hub and AWS Config, managed from the Security Tooling account
Default EBS encryption, S3 Block Public Access
Budgets and cost alerts
Standard IAM roles for CI/CD with OIDC

Azure and GCP equivalents

Azure: management groups and subscriptions, with Azure Policy as guardrails. Microsoft's Azure landing zone reference architecture (part of the Cloud Adoption Framework) is the equivalent of Control Tower.
Google Cloud: the resource hierarchy of organisation, folders and projects, with Organization Policies. Google provides a landing zone blueprint and Terraform foundation modules.

The concepts are the same: a hierarchy, isolation per environment and team, central guardrails, central logging and identity.

So, where do I start?

If you're still in one account, set up AWS Organizations and Control Tower now, create separate production and non-production accounts, and move new workloads there. Migrate old workloads gradually. If you already have many accounts, check that SCPs, central logging and Identity Center are in place.

My take: a landing zone is the foundation of your cloud house. It's boring to build, and you'll be grateful for it every day afterwards.

— Desly

The Linux commands I use every day

Tue, 20 Oct 2026 23:10:30 +0200

Kubernetes, cloud consoles and fancy dashboards are great. But when something is really wrong, sooner or later I end up in a terminal on a Linux machine, or inside a container, typing the same handful of commands I've used for years.

You don't need to know hundreds of commands. You need to know the right twenty or thirty very well. Here are mine.

Processes and services

What's running and using resources?

top                 # live view of CPU, memory and processes (press 1 for per-CPU, M to sort by memory)
htop                # friendlier version, if installed
ps aux --sort=-%mem | head   # top memory users
ps -ef | grep nginx          # find a specific process
pgrep -a java                # same, simpler

Services with systemd:

systemctl status nginx       # is it running? recent log lines too
systemctl restart nginx
systemctl list-units --failed   # what's broken?
journalctl -u nginx -f       # follow a service's logs
journalctl -u nginx --since "1 hour ago"
journalctl -p err -b         # all errors since last boot

Stopping things:

kill <pid>          # polite request to stop (SIGTERM)
kill -9 <pid>       # force (SIGKILL), only when the polite way fails

Disks and files

Out of disk space is one of the most common problems. These find it quickly:

df -h                        # free space per filesystem
df -i                        # free inodes (yes, you can run out of these too)
du -sh /var/* | sort -h      # which folders are big?
ncdu /var                    # interactive disk usage browser, if installed
lsof +L1                     # deleted files still held open (space not freed until process restarts)

Finding and reading files:

find /var/log -name "*.log" -mtime -1      # logs modified in the last day
find / -size +1G 2>/dev/null               # files larger than 1 GB
tail -f /var/log/syslog                    # follow a log
less +F app.log                            # follow, but can scroll back (Ctrl+C, then F again)
grep -ri "error" /var/log/app/             # search recursively, case-insensitive
grep -c "500" access.log                   # count matching lines

Most production problems are boring: a full disk, a crashed process, a wrong permission, a closed port. The commands that find boring problems fast are the most valuable ones.

Memory and performance

free -h             # memory and swap usage
vmstat 1            # CPU, memory, swap, I/O every second
iostat -xz 1        # disk I/O per device (from sysstat)
uptime              # load average
dmesg -T | tail     # kernel messages, including OOM kills and hardware errors

A quick tip: free shows a lot of memory as "buff/cache". That's normal. Linux uses free memory for caching, and gives it back when needed. Look at "available" instead.

If a process is killed for using too much memory, dmesg -T | grep -i oom usually gives the details.

Network

ip a                         # IP addresses of all interfaces
ip r                         # routing table
ss -tulpn                    # which ports are listening, and by which process
ss -tan state established    # active TCP connections
curl -v https://example.com  # full HTTP request with headers and TLS info
curl -o /dev/null -s -w "%{http_code} %{time_total}\n" https://example.com   # status and timing
dig example.com +short       # DNS lookup
dig @8.8.8.8 example.com     # ask a specific DNS server
nc -zv db.internal 5432      # is the port reachable?
mtr example.com              # traceroute and ping combined
tcpdump -i any port 443 -nn  # capture packets (needs root)

ss -tulpn alone answers half of all "why can't I connect?" questions: either nothing is listening on that port, or it's listening on 127.0.0.1 instead of all interfaces.

Users, permissions and identity

whoami && id                 # who am I, what groups?
sudo -l                      # what am I allowed to run with sudo?
ls -la                       # permissions, owners, hidden files
chmod 640 file && chown app:app file
namei -l /path/to/file       # permissions of every directory along a path

namei -l is a hidden gem when a service can't read a file and you can't see why: often it's a parent directory without execute permission.

Text processing

awk '{print $1}' access.log | sort | uniq -c | sort -rn | head   # top client IPs
cut -d: -f1 /etc/passwd                                         # first field
sed -n '100,120p' big.log                                       # lines 100 to 120
jq '.items[].metadata.name'                                     # parse JSON
wc -l file                                                      # count lines

Learning awk, sort, uniq and jq turns log files into answers.

Working efficiently

Ctrl+R searches your command history.
!! repeats the last command (sudo !! when you forgot sudo).
tmux or screen keep sessions alive if your connection drops.
watch -n 2 'kubectl get pods' reruns a command every two seconds.
man and tldr for quick help with examples.

The cheat sheet

Problem	First commands
Service down	`systemctl status`, `journalctl -u <svc> -n 100`
Disk full	`df -h`, `du -sh /* \\| sort -h`, `lsof +L1`
High CPU	`top`, `ps aux --sort=-%cpu \\| head`
Out of memory	`free -h`, `dmesg -T \\| grep -i oom`
Can't connect	`ss -tulpn`, `nc -zv host port`, `curl -v`
DNS issues	`dig name`, `cat /etc/resolv.conf`
Slow disk	`iostat -xz 1`, `vmstat 1`
Permission denied	`id`, `ls -la`, `namei -l path`
What happened at boot	`journalctl -b -p err`, `dmesg -T`

My take: tools come and go, but the Linux command line is still where problems finally confess. Learn these well and you'll feel at home on any server.

— Desly

Networking basics every DevOps engineer needs

Tue, 20 Oct 2026 23:10:30 +0200

If I look back at the hardest problems I've debugged, a surprising number were networking problems in disguise. "The app is slow" turned out to be DNS. "The deployment failed" turned out to be a security group. "Kubernetes is broken" turned out to be overlapping IP ranges.

You don't need to be a network engineer to work in DevOps. But you do need a solid mental model of how packets get from A to B. Here's the version I wish I'd had at the start.

The layers that matter

You'll hear about the OSI model with seven layers. In daily DevOps work, four ideas matter most:

IP (layer 3): every machine has an address, and routers decide how packets get from one network to another.
TCP and UDP (layer 4): TCP gives reliable, ordered connections (most web traffic). UDP is fire-and-forget (DNS, video, some newer protocols like QUIC). Ports identify which application on a machine should receive the traffic.
TLS: encryption on top of TCP. It's what puts the "S" in HTTPS.
HTTP (layer 7): the application protocol most of our services speak.

When something doesn't work, I go up the layers: can I reach the IP? Is the port open? Does TLS work? Does HTTP return the right response?

IP addresses and subnets

An IP address like 10.0.12.34 belongs to a subnet, written in CIDR notation: 10.0.0.0/16 means "all addresses where the first 16 bits are 10.0", which is 65,536 addresses.

/16: 65,536 addresses
/20: 4,096
/24: 256
/28: 16

Private ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) are used inside networks and aren't reachable from the internet directly. NAT (Network Address Translation) lets machines with private addresses reach the internet through a shared public address.

The most common mistake I see: overlapping ranges. Two VPCs both using 10.0.0.0/16 can never be connected. Kubernetes pod and service ranges that overlap with your office VPN cause mysterious failures. Plan IP ranges centrally, early.

DNS

DNS translates names (shop.example.com) into addresses. It's involved in almost every request, which is why "it's always DNS" is a running joke.

Key concepts:

A / AAAA records: name to IPv4 / IPv6 address.
CNAME: an alias pointing to another name.
TTL: how long resolvers cache an answer. Low TTLs make changes fast; high TTLs reduce load and dependency on DNS.
Resolvers: the servers that look up names for you. Inside Kubernetes, that's CoreDNS.

dig shop.example.com +short
dig shop.example.com +trace     # follow the lookup from the root servers

When something works by IP but not by name, it's DNS. When it works sometimes but not always, it's probably also DNS.

TLS and certificates

TLS does two things: encrypts traffic and proves identity. The server presents a certificate, signed by a certificate authority (CA) the client trusts, saying "I am shop.example.com".

Common problems:

Expired certificates: automate renewal (cert-manager, Let's Encrypt, cloud certificate managers).
Name mismatch: the certificate is for www.example.com, but you called example.com.
Missing intermediate certificates in the chain.
Internal CAs that clients don't trust.

openssl s_client -connect shop.example.com:443 -servername shop.example.com </dev/null | openssl x509 -noout -dates -subject

Load balancers

A load balancer spreads traffic across multiple backends and hides failures:

Layer 4 (TCP/UDP) load balancers forward connections without looking inside. Fast and simple. Example: AWS Network Load Balancer.
Layer 7 (HTTP) load balancers understand requests: they can route by path or host, terminate TLS, add headers. Examples: AWS Application Load Balancer, Envoy, NGINX, Kubernetes Gateway API implementations.

They rely on health checks to know which backends are healthy. A wrong health check path is a very common reason for "all backends unhealthy".

Designing a network in the cloud

A typical VPC design:

Public subnets: for load balancers and NAT gateways. Have a route to the internet gateway.
Private subnets: for applications and Kubernetes nodes. Reach the internet through NAT, not reachable from outside directly.
Data subnets: for databases, reachable only from the application subnets.
Spread across availability zones, so one zone failing doesn't take you down.
Security groups (stateful, attached to resources) as the main firewall, and network ACLs (stateless, per subnet) only when needed.

Leave room to grow: give your VPC a large range and Kubernetes plenty of pod IPs, especially with CNIs that assign VPC addresses to pods.

My debugging tools

Question	Tool
What's my IP and route?	`ip a`, `ip r`
Does the name resolve?	`dig`, `nslookup`
Is the host reachable?	`ping`, `mtr`
Is the port open?	`nc -zv host port`
What's listening locally?	`ss -tulpn`
Does HTTP/TLS work?	`curl -v`
What's actually on the wire?	`tcpdump`, Wireshark

And one more question that saves a lot of time: from where am I testing? Your laptop, a pod, a node and a CI runner can all see very different networks.

So, where do I start?

Learn CIDR until subnetting feels natural, understand how DNS resolution works in your environment (especially in Kubernetes), and practise debugging with dig, nc, curl and ss. That foundation will save you countless hours.

My take: networking isn't magic, it's just layers. Learn to check them one at a time, and most mysteries solve themselves.

— Desly

Bash scripts that don't surprise you

Tue, 20 Oct 2026 23:10:30 +0200

Bash is everywhere in DevOps. CI pipelines, Dockerfiles, deployment scripts, cron jobs, quick automations. It's the glue that holds infrastructure together.

Bash has hidden dangers. By default, it keeps running after errors, treats undefined variables as empty, and splits words in unexpected ways. A script that works fine on your laptop might accidentally delete the wrong folder in production if a variable is empty.

Here are the habits that make my scripts boring, in the best way.

The first lines of every script

#!/usr/bin/env bash
set -euo pipefail
IFS=$'\n\t'

What they do:

set -e: stop the script when a command fails, instead of carrying on.
set -u: treat undefined variables as an error, instead of an empty string.
set -o pipefail: a pipeline fails if any command in it fails, not just the last one.
IFS=$'\n\t': split words only on newlines and tabs, not spaces. Fewer surprises with filenames containing spaces.

Why set -u matters so much, in one example:

rm -rf "$BUILD_DIR/"*

If BUILD_DIR is accidentally unset, without set -u this becomes rm -rf /*. With set -u, the script stops with an error. That single line has saved many systems.

(set -e has some well-known edge cases, like commands in conditions or subshells. It's not perfect, but it's a big improvement over the default behavior.)

Bash assumes you know what you're doing. Good scripts don't make that assumption about anyone, including their author.

ShellCheck

ShellCheck is a linter for shell scripts, and the single most useful tool for writing better Bash. It catches unquoted variables, wrong comparisons, useless cats, portability issues and many subtle bugs, with explanations for each warning.

shellcheck deploy.sh

Add it to your editor and to CI. I treat ShellCheck warnings like compiler errors.

Habits that prevent most bugs

Quote your variables. Always. "$file", not $file. Unquoted variables get split on spaces and expanded as wildcards.

Use [[ ]] for tests in Bash, not [ ]. It's safer and supports more features.

if [[ -z "${ENVIRONMENT:-}" ]]; then
  echo "ENVIRONMENT must be set" >&2
  exit 1
fi

Provide defaults and required checks with parameter expansion:

REGION="${REGION:-eu-central-1}"       # default value
: "${API_TOKEN:?API_TOKEN is required}" # fail with a message if unset

Use local in functions so variables don't leak.

Write errors to stderr (>&2) and exit with non-zero codes on failure.

Clean up with trap, even when the script fails:

tmpdir="$(mktemp -d)"
trap 'rm -rf "$tmpdir"' EXIT

Use $(...) instead of backticks for command substitution.

Avoid parsing ls. Use globs or find instead.

A template I reuse

#!/usr/bin/env bash
set -euo pipefail

usage() {
  cat <<EOF
Usage: $(basename "$0") -e <environment> [-d]
  -e  target environment (staging|production)
  -d  dry run
EOF
}

log() { printf '%s [%s] %s\n' "$(date -u +%FT%TZ)" "${1}" "${2}" >&2; }

main() {
  local env="" dry_run=false

  while getopts ":e:dh" opt; do
    case "$opt" in
      e) env="$OPTARG" ;;
      d) dry_run=true ;;
      h) usage; exit 0 ;;
      *) usage; exit 1 ;;
    esac
  done

  [[ "$env" =~ ^(staging|production)$ ]] || { usage; exit 1; }

  log INFO "Deploying to $env (dry run: $dry_run)"
  if [[ "$dry_run" == false ]]; then
    : # real work here
  fi
}

main "$@"

It has argument parsing, validation, logging with timestamps, a dry-run mode, and a main function. Copy it, delete what you don't need.

When Bash is the wrong tool

Bash is great for gluing commands together. It's bad at almost everything else. I switch to Python (or Go) when a script:

Is longer than about 100 lines.
Needs real data structures (nested data, maps of lists).
Parses JSON or YAML beyond a simple jq call.
Talks to APIs with authentication, pagination and retries.
Needs error handling more subtle than "stop on failure".
Needs tests.
Will be maintained by many people for a long time.

Python with a proper CLI library, or a small Go tool, is much easier to read, test and maintain at that point.

In CI pipelines

CI YAML often contains multi-line shell scripts. The same rules apply:

Many CI systems don't enable set -euo pipefail by default. Add it, or set the shell options for the whole job.
Move long scripts out of YAML into files in the repository, where ShellCheck can lint them and you can run them locally.

So, what's the one thing to do?

Add set -euo pipefail to the top of every script, and run ShellCheck on all of them. Those two habits prevent most of the disasters I've seen from shell scripts.

My take: Bash is a sharp knife. Use it for small cuts, keep it sharp with ShellCheck, and switch to a proper tool when the job gets bigger.

— Desly

Python for everyday automation

Tue, 20 Oct 2026 23:10:30 +0200

When a Bash script grows past a hundred lines, or needs to talk to an API, I switch to Python. It's readable, it has a library for almost everything, and colleagues can understand it without a decoding session.

You don't need to be a software engineer to write useful Python for DevOps. A few libraries and habits cover most of what you'll need.

The libraries I use

boto3: the AWS SDK. Everything in AWS is reachable from it. (Azure has azure-identity and service SDKs; Google Cloud has google-cloud-* libraries.)
kubernetes: the official Kubernetes client.
httpx or requests: calling REST APIs.
typer or click: building command-line tools with arguments and help text.
rich: nice tables, colours and progress bars in the terminal.
pydantic: validating configuration and data.
PyYAML / ruamel.yaml: reading and writing YAML.
tenacity: retries with backoff for flaky APIs.

Packaging with uv

Python packaging used to be painful: virtual environments, pip, requirements files, version conflicts. uv, from Astral, has made it dramatically simpler and faster.

uv init cloud-tools
cd cloud-tools
uv add boto3 typer rich
uv run python main.py

My favourite feature for small scripts: inline dependencies. You can declare dependencies at the top of a single file, and uv run handles the environment automatically:

# /// script
# requires-python = ">=3.12"
# dependencies = ["boto3", "typer", "rich"]
# ///

Then anyone can run uv run cleanup.py without setting anything up. Perfect for sharing small tools in a team.

The best automation script is one a colleague can run tomorrow without asking you how.

Example: finding unused cloud resources

A real-world example: find unattached EBS volumes (a classic source of waste) and optionally delete them.

# /// script
# requires-python = ">=3.12"
# dependencies = ["boto3", "typer", "rich"]
# ///
import boto3
import typer
from rich.console import Console
from rich.table import Table

app = typer.Typer()
console = Console()


@app.command()
def unattached_volumes(
    region: str = "eu-central-1",
    delete: bool = typer.Option(False, help="Actually delete the volumes"),
):
    """List (and optionally delete) unattached EBS volumes."""
    ec2 = boto3.client("ec2", region_name=region)
    paginator = ec2.get_paginator("describe_volumes")
    pages = paginator.paginate(Filters=[{"Name": "status", "Values": ["available"]}])

    table = Table("Volume ID", "Size (GiB)", "Created", "Name")
    volumes = []
    for page in pages:
        for v in page["Volumes"]:
            name = next((t["Value"] for t in v.get("Tags", []) if t["Key"] == "Name"), "-")
            table.add_row(v["VolumeId"], str(v["Size"]), v["CreateTime"].date().isoformat(), name)
            volumes.append(v["VolumeId"])

    console.print(table)
    console.print(f"[bold]{len(volumes)}[/bold] unattached volumes in {region}")

    if delete and volumes and typer.confirm("Delete all of them?"):
        for vol_id in volumes:
            ec2.delete_volume(VolumeId=vol_id)
            console.print(f"Deleted {vol_id}")


if __name__ == "__main__":
    app()

Notice a few habits:

Pagination: AWS APIs return results in pages. Always use paginators, or you'll only see the first page.
Dry run by default: it only lists unless you pass --delete, and even then asks for confirmation.
Readable output with a table.

Example: a Kubernetes report

Which pods have no resource requests? A question that comes up a lot:

from kubernetes import client, config

config.load_kube_config()  # or load_incluster_config() inside a pod
v1 = client.CoreV1Api()

for pod in v1.list_pod_for_all_namespaces().items:
    for c in pod.spec.containers:
        requests = (c.resources and c.resources.requests) or {}
        if "cpu" not in requests or "memory" not in requests:
            print(f"{pod.metadata.namespace}/{pod.metadata.name} [{c.name}] missing requests")

Ten lines, and you have a report you can run in CI every week.

Habits for automation scripts

Dry run by default for anything destructive.
Use the standard credential chain (environment, profiles, SSO, instance roles). Never hardcode credentials.
Log what you do, with enough detail to reconstruct it later.
Handle errors and retries for network calls.
Add type hints and run a linter and formatter (Ruff is fast and does both).
Write a small test for the logic that matters.
Put it in Git, with a README explaining what it does and how to run it.

From script to tool

When a script becomes something the team relies on:

Give it a proper CLI with Typer and help text.
Package it with uv so it can be installed with uv tool install.
Run it in CI or as a Kubernetes CronJob instead of from laptops.
Consider whether it should become part of your platform or an operator.

So, where do I start?

Pick one repetitive task you do every week, like cleaning up resources, generating a report or checking certificates. Write a small Python script with uv's inline dependencies. Share it. You'll be surprised how quickly the team asks for more.

My take: Python turns "I'll do it manually, it only takes ten minutes" into "it runs every night and nobody thinks about it anymore".

— Desly

HTTPS on autopilot with cert-manager

Tue, 20 Oct 2026 23:10:30 +0200

Expired certificates have caused some of the most embarrassing outages in tech history. Big companies, popular apps, even security vendors have gone down because someone forgot to renew a certificate. It's always the same story: a calendar reminder that went to someone who left, a manual process nobody remembered.

And the problem is about to get harder to ignore, because certificate lifetimes are shrinking fast.

How TLS certificates work, simply

When you visit https://shop.example.com, the server sends a certificate that says "I am shop.example.com", signed by a Certificate Authority (CA) your browser trusts. The browser checks the signature, the name and the expiry date. If all is fine, it sets up an encrypted connection.

Certificates expire on purpose. If a private key is stolen, an expiry date limits how long it can be abused. And short lifetimes force automation, which makes the whole system more agile.

Lifetimes are shrinking

The CA/Browser Forum, which sets the rules for public certificates, approved a schedule to reduce maximum certificate lifetimes from 398 days:

From March 2026: maximum 200 days
From March 2027: maximum 100 days
From March 2029: maximum 47 days

The time for which domain validation can be reused is shrinking too. Let's Encrypt, which has always issued 90-day certificates, has also started offering much shorter-lived certificates.

What this means in practice: manual certificate renewal is dying. At 47 days, renewing by hand for even a handful of certificates becomes a full-time annoyance and an outage waiting to happen.

If a human has to remember to renew a certificate, the certificate will eventually expire.

Let's Encrypt and ACME

Let's Encrypt is a free, automated CA that changed the web: it issues certificates through the ACME protocol, which lets software prove control of a domain and get a certificate without any human involved.

Two common ways to prove control:

HTTP-01: the CA asks for a file at http://yourdomain/.well-known/acme-challenge/.... Simple, but needs port 80 reachable and doesn't support wildcards.
DNS-01: you create a TXT record in DNS. Works for wildcard certificates and internal services that aren't publicly reachable. Needs API access to your DNS provider.

Other ACME CAs exist too (ZeroSSL, Google Trust Services, and many commercial CAs), and private CAs can speak ACME for internal certificates.

cert-manager setup

On Kubernetes, cert-manager (a CNCF graduated project) is the standard way to automate certificates. It requests certificates, stores them in Kubernetes secrets, and renews them well before they expire.

Install it:

helm install cert-manager oci://quay.io/jetstack/charts/cert-manager \
  --namespace cert-manager --create-namespace \
  --set crds.enabled=true

Create an issuer (here Let's Encrypt with DNS-01 on Route 53, using workload identity):

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: platform@example.com
    privateKeySecretRef:
      name: letsencrypt-account-key
    solvers:
    - dns01:
        route53:
          region: eu-central-1

Request a certificate:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: example-com
  namespace: infra
spec:
  secretName: example-com-tls
  issuerRef:
    name: letsencrypt
    kind: ClusterIssuer
  dnsNames:
  - example.com
  - "*.example.com"

cert-manager creates the secret, and renews it automatically (by default when two thirds of the lifetime have passed). Reference the secret from your Gateway or Ingress, and you're done.

It also integrates with Gateway API directly: annotate a Gateway, and cert-manager creates certificates for its listeners.

Tip: test against Let's Encrypt's staging server first. The production server has rate limits, and a misconfiguration can lock you out for a while.

Beyond Kubernetes

Cloud certificate managers (AWS Certificate Manager, Google Certificate Manager, Azure Key Vault certificates) automate certificates for their load balancers and CDNs.
Caddy and Traefik obtain and renew certificates automatically, built in.
certbot and acme.sh for traditional servers.
Internal certificates: cert-manager can act as or connect to a private CA (Vault, step-ca, cloud private CAs) for mTLS and internal services.

Monitoring certificates anyway

Automation can fail silently: DNS credentials expire, rate limits hit, a webhook breaks. Always monitor expiry:

cert-manager exposes Prometheus metrics like certmanager_certificate_expiration_timestamp_seconds. Alert when a certificate has less than, say, two weeks left.
Blackbox exporter or an external uptime tool can check the certificate actually served on each public endpoint.
Certificate Transparency logs show every public certificate issued for your domains, useful for spotting unexpected ones.

So, where do I start?

List every certificate you renew by hand today. Move them to cert-manager, a cloud certificate manager, or a server with built-in ACME. Add expiry alerts. By the time 47-day certificates arrive, you won't even notice.

My take: certificates should renew themselves like your phone updates its clock. The shorter they get, the more that's true.

— Desly

It's always DNS

Tue, 20 Oct 2026 23:10:30 +0200

There's a famous haiku among system administrators:

It's not DNS. There's no way it's DNS. It was DNS.

It's funny because it's true. Some of the biggest outages of recent years, at cloud providers and large websites, came down to DNS problems. And in daily work, a huge share of "the app can't connect" mysteries end with someone saying "oh, it's resolving to the old address".

Why does DNS cause so much trouble, and what can we do about it?

Why DNS is everywhere

Almost every network connection starts with a DNS lookup. Your browser, your app connecting to its database, a pod calling another service, a CI job pulling an image. If DNS is slow, everything is slow. If it's wrong, everything goes to the wrong place. If it's down, nothing works, even if every server is healthy.

And DNS is cached at many levels: in applications, in operating systems, in local resolvers, at your ISP. Which means problems can be inconsistent, delayed and very hard to reproduce.

Records and TTLs

The records you'll work with most:

A / AAAA: name to IPv4 / IPv6 address.
CNAME: alias to another name. (Can't be used at the zone apex like example.com; providers offer ALIAS or ANAME records for that.)
TXT: arbitrary text, used for domain verification, SPF, DKIM and ACME challenges.
MX: mail servers.
SRV: service discovery with ports.
NS / SOA: which servers are authoritative for a zone.

TTL (time to live) tells resolvers how long to cache an answer. It's the most important lever you have:

Low TTL (60 to 300 seconds): changes take effect quickly. Good for records you might need to change in an emergency, like failover endpoints.
High TTL (hours): less load on DNS, more resilience if your DNS provider has problems. Good for stable records.

A classic mistake: planning a migration, changing the record, and discovering the old TTL was 24 hours. Lower the TTL a day or two before a planned change, then raise it again afterwards.

DNS changes don't happen when you make them. They happen when the last cache in the world forgets the old answer.

DNS inside Kubernetes

Kubernetes has its own DNS, usually CoreDNS. Every service gets a name like orders.shop.svc.cluster.local.

A few things that trip people up:

Short names work only in the same namespace. orders works from the shop namespace; from elsewhere, use orders.shop or the full name.
The ndots:5 setting. By default, pods treat names with fewer than five dots as relative and try several search domains first. A lookup for api.example.com can generate several failed queries before the real one. For external names, a trailing dot (api.example.com.) or tuning ndots in the pod's dnsConfig reduces that.
CoreDNS can become a bottleneck in busy clusters. Scale it, and consider NodeLocal DNSCache, which runs a cache on every node.
Conntrack and UDP issues on some setups cause occasional slow lookups (classic five-second delays). NodeLocal DNSCache helps with those too.

ExternalDNS

Managing public DNS records by hand for every service is error-prone. ExternalDNS watches Kubernetes resources (Services, Ingresses, Gateway API routes) and creates DNS records automatically in Route 53, Cloud DNS, Azure DNS, Cloudflare and many others.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: shop
  namespace: shop
spec:
  parentRefs:
  - name: web
    namespace: infra
  hostnames: ["shop.example.com"]   # ExternalDNS creates this record
  rules:
  - backendRefs:
    - name: shop-api
      port: 8080

Configure it with a TXT registry so it only touches records it owns, and a domain filter so it can't modify zones it shouldn't.

DNS-based failover

DNS can route traffic away from failures:

Health-checked failover records (Route 53, Cloudflare, Azure Traffic Manager, and others): if the primary endpoint fails health checks, DNS starts returning the secondary.
Latency-based or geo routing: send users to the nearest region.
Weighted records: gradually shift traffic between old and new environments during migrations.

Remember the TTL: failover can only be as fast as caches expire. And some clients cache DNS much longer than the TTL says (older Java versions were famous for this).

Outages I've seen (and you probably will too)

Expired domain or a lapsed registrar payment.
Wrong TTL during migration: half the users on the old system for a day.
Deleted or overwritten records by a tool that thought it owned them.
Internal resolvers down, so every service fails at once, while the servers themselves are healthy.
Split-horizon confusion: the name resolves differently inside and outside the network, and someone tested from the wrong side.
DNSSEC misconfiguration making a domain unresolvable for validating resolvers.

My debugging routine

dig shop.example.com +short                 # what does my resolver say?
dig @1.1.1.1 shop.example.com +short        # what does a public resolver say?
dig shop.example.com +trace                 # follow it from the root
dig shop.example.com NS                     # who is authoritative?
kubectl run -it --rm dnstest --image=busybox:1.36 -- nslookup orders.shop   # from inside the cluster

Compare answers from different places. If they differ, it's caching or split-horizon. If the authoritative answer is wrong, it's the record itself.

So, how do you make DNS break less?

Manage records as code or with ExternalDNS, plan TTLs deliberately, monitor your domains and certificates, cache DNS close to workloads, and always test from where the client actually is.

My take: DNS is simple until it isn't. Treat it like critical infrastructure, because it's the first thing every request touches.

— Desly

Git tricks that saved me

Tue, 20 Oct 2026 23:10:30 +0200

Most people use about six Git commands: clone, pull, add, commit, push, and checkout (or switch). That's enough for a normal day. But sooner or later, something goes wrong. A commit on the wrong branch. A bug that appeared "sometime last week". A force push that seemed to delete everything.

That's when a few less common commands become lifesavers. In DevOps, where Git is also how we deploy infrastructure, knowing them is even more useful.

Rebase or merge?

Both combine work from two branches. They do it differently:

Merge creates a merge commit that joins the two histories. Nothing is rewritten. History shows exactly what happened, including all the branching.
Rebase replays your commits on top of the target branch, as if you'd started from there. History becomes a straight line, but your commits get new IDs.

git switch feature
git fetch origin
git rebase origin/main      # put my commits on top of the latest main

My rule of thumb: rebase your own local branches to keep them up to date and clean; don't rebase commits other people already have (shared branches like main). Many teams avoid the debate with squash merges in pull requests: the whole branch becomes one clean commit on main.

Interactive rebase lets you clean up your commits before opening a pull request: squash "fix typo" commits, reorder, reword messages.

git rebase -i origin/main

Finding a bug with bisect

"It worked last week, and now it doesn't. There are 80 commits in between." Instead of checking them one by one, let Git do a binary search:

git bisect start
git bisect bad                 # current commit is broken
git bisect good v2.3.0         # this version worked
# Git checks out a commit in the middle. Test it, then:
git bisect good                # or: git bisect bad
# ...repeat about 6-7 times for 80 commits...
git bisect reset

Even better, automate it with a test script that exits non-zero on failure:

git bisect run ./scripts/test-login.sh

Git finds the exact commit that introduced the problem, usually in minutes. It works for infrastructure repos too: "which change broke the Helm chart?"

git bisect turns "it broke sometime last week" into "it broke in this exact commit" in about seven steps.

Undoing almost anything with reflog

Here's the most comforting fact about Git: it almost never really loses committed work. Even after a bad reset, a botched rebase or a deleted branch, the commits still exist for a while. reflog shows everywhere HEAD has pointed recently:

git reflog
# a1b2c3d HEAD@{0}: reset: moving to HEAD~3
# e4f5g6h HEAD@{1}: commit: add retry logic
# ...

git reset --hard e4f5g6h      # go back to before the bad reset
# or recover a deleted branch:
git branch rescued e4f5g6h

If you ever think "I just destroyed my work", stop, breathe, and run git reflog.

Other everyday rescues

Committed to the wrong branch:

git switch correct-branch
git cherry-pick <commit>
git switch wrong-branch
git reset --hard HEAD~1       # remove it from the wrong branch (if not pushed)

Fix the last commit (message or forgotten file):

git add forgotten-file.yaml
git commit --amend

Undo a commit that's already pushed, safely, without rewriting history:

git revert <commit>

In GitOps setups, git revert is literally how you roll back a deployment.

Park unfinished work:

git stash push -m "half-done refactor"
git stash list
git stash pop

Who changed this line, and why?

git blame -L 40,60 values.yaml
git log -p -S "replicas: 1" -- deploy/   # find the commit that added or removed a string

Force push more safely, when you must:

git push --force-with-lease

Unlike --force, it refuses if someone else pushed in the meantime.

Protecting branches

In a team, the safest Git is the one where mistakes can't reach main easily:

Branch protection / rulesets: require pull requests, reviews and passing checks for main. Block force pushes and deletion.
CODEOWNERS: automatically request reviews from the right team for the right files. Especially useful for infrastructure folders.
Signed commits: sign with SSH or GPG keys (or keyless with Sigstore's gitsign), and require signatures on protected branches. It proves commits really come from who they claim.

# .github/CODEOWNERS
/infrastructure/   @acme/platform-team
/deploy/prod/      @acme/platform-team @acme/sre

A few config settings I always use

git config --global pull.rebase true          # rebase instead of merge on pull
git config --global rebase.autoStash true     # stash and unstash automatically during rebase
git config --global push.autoSetupRemote true # no more --set-upstream
git config --global rerere.enabled true       # remember conflict resolutions
git config --global init.defaultBranch main

So, what should you practise?

Try git bisect on a real bug, and do a test reset followed by a reflog recovery in a throwaway repo. Once you've rescued yourself once, Git stops being scary.

My take: Git remembers almost everything. Learn the commands that let you ask it, and you'll rarely lose work again.

— Desly

"Works on my machine," solved with Nix?

Tue, 20 Oct 2026 23:10:30 +0200

Every team has the conversation. "The build fails for me." "Works on my machine." Then twenty minutes of comparing versions: different Terraform, a newer Node, an old kubectl, a Python that came with macOS, a missing system library.

Onboarding a new team member can take a day just to get the right tools in the right versions. And CI often uses a completely different set of versions.

Reproducible development environments fix this. Nix is the most powerful way to get them, and newer tools have made it much more approachable.

The problem

Development environments drift because:

Everyone installs tools differently: Homebrew, apt, downloaded binaries, version managers.
Versions aren't pinned, or are pinned in a README nobody follows.
Tools depend on system libraries that differ between machines.
CI images are maintained separately from developer setups.

What we want: one file in the repository that defines exactly which tools (and versions) the project needs, which works the same on every developer's machine and in CI.

Nix in one paragraph

Nix is a package manager and build system built on a radical idea: every package is built in isolation from a precise description of its inputs, and stored under a unique path based on a hash of those inputs (like /nix/store/abc123-terraform-1.9.8). Multiple versions live side by side without conflict. Nothing is installed "globally". If two machines use the same Nix description, they get exactly the same software, bit for bit. The nixpkgs collection contains well over 100,000 packages, one of the largest of any package manager.

Nix flakes

Flakes are the modern way to define Nix projects, with a lock file that pins exact versions of everything. A dev shell for an infrastructure project:

{
  description = "Infrastructure dev environment";

  inputs.nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";

  outputs = { self, nixpkgs }:
    let
      systems = [ "x86_64-linux" "aarch64-linux" "aarch64-darwin" ];
      forAll = f: nixpkgs.lib.genAttrs systems (s: f nixpkgs.legacyPackages.${s});
    in {
      devShells = forAll (pkgs: {
        default = pkgs.mkShell {
          packages = with pkgs; [
            opentofu
            kubectl
            kubernetes-helm
            awscli2
            jq
            shellcheck
          ];
        };
      });
    };
}

Run nix develop, and you're in a shell with exactly those tools. The flake.lock file pins them, so everyone gets identical versions until someone deliberately updates the lock.

Honestly, Nix's language and concepts have a steep learning curve. That's where friendlier tools come in.

The goal isn't to use Nix. The goal is that "install the tools" becomes one command that always gives the same result.

devbox and devenv: Nix without the pain

devbox (from Jetify) uses Nix underneath, but you only write a simple JSON file:

{
  "packages": [
    "opentofu@1.10",
    "kubectl@1.33",
    "helm@latest",
    "awscli2@latest",
    "jq@latest"
  ],
  "shell": {
    "init_hook": ["echo 'Infra shell ready'"]
  }
}

devbox shell

No Nix knowledge needed. It can also generate Dockerfiles and dev container configs from the same file.

devenv (from Cachix) is another popular option: more Nix under the hood, but with ready-made modules for languages and services (like starting a local PostgreSQL), pre-commit hooks and scripts.

Both work great with direnv, which activates the environment automatically when you cd into the project folder.

Dev Containers instead?

The main alternative is Dev Containers: a devcontainer.json that defines a container image with all your tools, used by VS Code, JetBrains IDEs, GitHub Codespaces and others.

	Nix / devbox / devenv	Dev Containers
Runs	Natively on your machine	Inside a container
Reproducibility	Very high (locked inputs)	Depends on how the image is built
Performance on macOS	Native speed	Some overhead (file system, VM)
Learning curve	Steep (Nix), easy (devbox)	Easy if you know Docker
Editor integration	Via direnv, works everywhere	Excellent in VS Code and Codespaces
Cloud dev environments	Possible	Native in Codespaces and similar

Both are good choices. Dev Containers are more familiar to most teams. Nix-based tools are more precise and run natively. Some teams even combine them: Nix inside a dev container.

Nix in CI

The real payoff: using the same environment in CI as on laptops.

- uses: cachix/install-nix-action@<sha>
- run: nix develop --command make test

Or with devbox: devbox run test. A binary cache (Cachix, or a self-hosted one) keeps CI fast by downloading pre-built packages instead of building them.

No more "the CI image has a different Terraform version than my laptop".

So, should you try it?

If your team regularly loses time to version mismatches and slow onboarding, yes. I'd start with devbox in one repository: one JSON file, one command, no Nix knowledge needed. If people like it, go deeper with flakes or devenv. If your team already lives in VS Code, Dev Containers are an equally good path.

My take: your project's tools are part of your project. Put them in the repository, pin them, and stop debugging each other's laptops.

— Desly

Docs and runbooks people actually read

Tue, 20 Oct 2026 23:10:30 +0200

Every team says they value documentation. Then you open the wiki and find pages last updated three years ago, instructions for servers that no longer exist, and a page titled "TODO: write this" from someone who left in 2023.

Bad documentation is worse than none, because people trust it and follow it. But good documentation is one of the highest-leverage things a DevOps team can produce. It's how knowledge survives holidays, sick days and people moving on.

Here's how to write docs that stay useful.

Why docs rot

They live far from the code. A wiki nobody looks at when they change the system.
Nobody owns them. Everyone can edit, so nobody feels responsible.
They're not part of the work. Docs are "extra", done later, which means never.
They're too long. People skim, miss the important part, and stop reading.

Docs live next to the code

Docs-as-code means treating documentation like code:

Written in Markdown, stored in the same repository as the code they describe.
Changed in the same pull request as the code change.
Reviewed like code.
Published automatically by a pipeline to a nice website.

Tools that make this easy:

MkDocs with the Material theme: simple, beautiful, very popular for technical docs.
Docusaurus: React-based, great for larger documentation sites.
Backstage TechDocs: renders MkDocs docs from each repository inside your developer portal.
Plain README.md files, which GitHub and GitLab render nicely.

A pull request template with a checkbox "documentation updated (or not needed)" is a small nudge that helps a lot.

The best time to update documentation is in the same pull request that makes it wrong.

A runbook template

Runbooks are the most important docs for operations. When an alert fires at 3 a.m., the on-call engineer needs answers fast, not prose.

My template:

# Alert: CheckoutHighErrorRate

## What it means
More than 2% of checkout requests return 5xx errors over 5 minutes.

## Impact
Customers can't complete purchases. Revenue impact. Treat as SEV2 or higher.

## Check
1. Dashboard: [Checkout overview](https://grafana.example.com/d/checkout)
2. Recent deployments: `kubectl rollout history deploy/checkout -n shop`
3. Errors by endpoint: [Logs query](https://grafana.example.com/explore?...)
4. Payment provider status: https://status.paymentprovider.example

## Common causes and fixes
- **Bad deployment** → roll back: revert the commit in the GitOps repo
  (or `kubectl rollout undo deploy/checkout -n shop` in an emergency).
- **Payment provider outage** → switch to backup provider via feature flag `payments.fallback`.
- **Database connection exhaustion** → check `orders-db` connections dashboard; scale checkout down
  temporarily or restart the connection pooler.

## Escalation
- Checkout team: @checkout-oncall
- Database: @dba-oncall
- Incident commander for SEV1: use `/incident declare`

## Last reviewed
2026-09-15 by @desly

Key principles: link directly to dashboards and queries, give copy-paste commands, list common causes first, and say who to call. And link the runbook from the alert itself.

Writing down decisions

Six months after a decision, nobody remembers why it was made. "Why do we use Loki and not Elasticsearch?" "Why is this service on its own cluster?" Without a record, teams either repeat old debates or undo good decisions by accident.

Architecture Decision Records (ADRs) solve this. An ADR is a short document, usually one page, stored in the repository:

# ADR-012: Use Gateway API instead of Ingress for new services

## Status
Accepted (2026-05-04)

## Context
ingress-nginx was retired in March 2026. We need a supported way to route traffic.

## Decision
New services use Gateway API with Envoy Gateway. Existing Ingress resources
are migrated by end of Q3.

## Consequences
+ Supported, portable API with role separation.
- Teams need to learn HTTPRoute; some annotations need manual migration.

Numbered, short, never deleted (superseded ADRs are marked as such). Tools like adr-tools or Log4brains help, but a folder of Markdown files works perfectly.

Keeping it fresh

Owners: every doc or folder has an owning team (CODEOWNERS works for docs too).
"Last reviewed" dates on runbooks, with a regular review (for example, quarterly, or after every incident that used the runbook).
Update after incidents: a postmortem action item is often "update the runbook".
Delete aggressively: outdated docs are dangerous. Archive or delete them.
Keep it short: one clear page beats ten vague ones.
Make it searchable: a docs site with search, or a portal like Backstage.

A word on AI

AI tools are great at drafting documentation: summarising a codebase, turning an incident timeline into a runbook, explaining a complex config. Use them for first drafts. But a human who knows the system needs to check every step, because a wrong runbook at 3 a.m. is worse than none.

So, where do I start?

Write runbooks for your five most frequent alerts, with the template above, and link them from the alerts. Then start an ADR folder and write the first record about the next decision your team makes.

My take: documentation is a gift to your future self and your colleagues. Keep it close to the code, keep it short, and keep it true.

— Desly

Platform engineering, DevOps, SRE: what's the actual difference?

Tue, 20 Oct 2026 23:10:30 +0200

Every few months, someone asks me what I actually do. When I say "DevOps", I get a nod. When a colleague says "platform engineer", the nod is slower. When someone says "SRE", people just smile politely.

The confusing part is that inside the industry, we aren't much clearer. The same job gets posted under all three titles, and the same title can mean three different jobs. So here's my attempt to untangle it.

Why everyone suddenly says "platform"

DevOps started as an idea, not a job title. The idea was simple: the people who build software and the people who run it should stop throwing things over a wall at each other. Shared responsibility, more automation, faster feedback.

Then the idea became a role. Companies hired "DevOps engineers", and very often those people became the new wall. Every team needed something from them: a pipeline, a cluster, a database, a fix. The DevOps team turned into a ticket queue.

Platform engineering is largely a reaction to that. Instead of doing things for every team, you build a product that lets teams do things themselves. Self-service pipelines, templates, environments, all with sensible defaults.

What each role owns, in plain words

DevOps is the culture and the set of practices: automation, CI/CD, infrastructure as code, monitoring, shared ownership. As a job title, it usually means "the person who makes building, shipping and running software work".

SRE (Site Reliability Engineering) came from Google. It treats operations as a software problem. SREs care about reliability with numbers attached: SLOs, error budgets, incident response, reducing toil. Their main question is "how reliable does this need to be, and how do we get there without burning out?"

Platform engineering builds the internal product that developers use to ship software. The customers are your own developers. Their main question is "how do we make the right way the easy way?"

DevOps is the philosophy, SRE is reliability as an engineering discipline, and platform engineering is the product that makes both scale.

Where they overlap in my own work

In practice, the borders are blurry. On a normal week I might write a pipeline template (platform), tune an alert so it stops waking people up for nothing (SRE), and help a team understand why their deployment keeps failing (classic DevOps).

That's normal, especially in smaller companies. Titles describe where your focus is, not a fence around what you're allowed to touch.

The skills underneath are almost the same: Linux, networking, cloud, containers, Kubernetes, infrastructure as code, observability, scripting. What changes is the angle you look from.

Does a small team need a platform team?

Probably not yet. If you have ten developers and one or two people doing operations, you don't need a "platform team". You need a few good templates, a solid pipeline, and decent documentation.

Signs you're ready for a platform approach:

The same request lands on the ops team again and again.
Every team builds its pipelines differently, and nobody can help anyone else.
New services take days or weeks to get into production.
Developers spend more time on infrastructure than on their product.

When those pile up, a small platform team that treats the developer experience as a product starts to pay for itself.

What I'd tell someone choosing a path

Don't stress too much about the title. The foundations are the same, and you can move between these roles later.

If you love automation and building tools for other engineers, lean towards platform engineering. If you enjoy incidents, metrics and making systems hold up under pressure, SRE might be your thing. If you like a bit of everything, "DevOps engineer" is still a great place to start.

So, which one do you need?

Most teams need the DevOps mindset first. Reliability practices come next, once you have users who notice when things break. A platform team comes when you have enough developers that self-service saves more time than it costs to build.

My take: titles change every few years. Making software easy to ship and hard to break never goes out of fashion.

— Desly

Golden paths: standards that don't slow anyone down

Tue, 20 Oct 2026 23:10:30 +0200

Every company wants standards. Same pipeline structure, same security checks, same logging format, same way to deploy. And every developer has been on the receiving end of standards that felt like paperwork: a forty-page wiki, a checklist, a review board that meets on Thursdays.

The idea is that standards should feel like a shortcut, not a barrier.

Roads, guardrails and gates

I find it useful to think about three ways to guide people:

Gates stop you until someone approves. "Submit a ticket and wait for the architecture review."
Guardrails let you move freely but stop you before you fall off a cliff. "You can deploy anything, but not a container running as root."
Paved roads (golden paths) make one way so convenient that most people take it voluntarily.

Good platforms use a lot of paved roads, a few guardrails, and as few gates as possible.

If people need to be forced onto your golden path, it isn't golden. It's just a path.

A new service in ten minutes

From a developer's perspective, a good golden path looks like this:

Open the template (a GitHub template, a Backstage form, or a CLI command).
Enter a service name and owning team.
Get a repository with working code, tests, a Dockerfile and a pipeline.
Push. The pipeline builds, scans and deploys to a test environment.
Logs, metrics, dashboards and basic alerts are already there.

The developer didn't read a wiki page about logging standards. The template simply does logging the right way. They didn't configure security scanning. The pipeline includes it. The standard is baked in.

What goes into a path

The best candidates are things every service needs, that are easy to get wrong:

Build and deployment pipelines
Container base images
Health checks, resource requests and limits
Logging format, metrics and tracing setup
Security scanning and secret handling
Ownership and documentation (a catalog entry, a README skeleton)

Don't try to standardise everything. Leave the actual product code alone. Developers should choose their own libraries and architecture inside the service.

When people need to leave the path

Teams will always have unusual needs — different languages, GPU workloads, or odd databases. If your golden path is the only option, those teams will either be stuck or quietly find workarounds you don't know about.

So build escape hatches on purpose:

Allow teams to override parts of the template, not just all or nothing.
Document what they lose when they leave the path (for example, "you'll need to set up your own alerts").
Watch where people leave. If many teams leave at the same point, that's a signal to extend the path.

Keeping templates up to date

The hidden issue with templates is that once a service is created, it's a copy. If you improve the template later, older services don't automatically get those improvements.

A few ways to handle that:

Keep shared logic out of each repo: reusable pipeline workflows, shared Helm charts, base images. Services reference a version instead of copying the content.
Use Renovate or Dependabot to open pull requests when a new version of the shared pieces is released.
Version your templates and keep a short changelog so teams know what they're missing.

So, are golden paths worth it?

Very much. They're how a small platform team can raise the quality of dozens of services without reviewing every one. Developers get speed, the organisation gets consistency, and nobody has to read the forty-page wiki.

My take: make the right way the easiest way, keep a door open for the exceptions, and listen when people use it.

— Desly

Are we actually getting faster? Measuring DevOps with DORA

Tue, 20 Oct 2026 23:10:30 +0200

"We're doing DevOps now." Great. But is it working? Are we shipping faster? Breaking less? Recovering quicker? Most teams can't answer those questions with anything better than a feeling.

DORA metrics help answer those questions. They come from years of research by the DevOps Research and Assessment team (now part of Google Cloud), and they're the closest thing our industry has to a shared scoreboard.

The DORA metrics in plain words

Deployment frequency. How often do you release to production? Daily, weekly, monthly?

Lead time for changes. How long does it take for a committed change to reach production? Hours or weeks?

Change failure rate. What percentage of deployments cause a problem that needs a fix, a rollback or a hotfix?

Time to restore service. When something breaks in production, how long until it's working again?

Rework rate. The newest addition: how many deployments are unplanned, made just to fix problems from earlier deployments?

The first two measure speed. The others measure stability. The key finding behind DORA is that these don't fight each other. The best teams are both faster and more stable. Small, frequent changes are easier to test, easier to review and easier to roll back.

Speed and stability aren't a trade-off. Teams that ship small changes often tend to break less, not more.

What the latest DORA research says about AI

The recent DORA reports have focused heavily on AI-assisted development. The headline is more nuanced than the marketing: AI helps individuals write code faster, but it can also lead to bigger batches of change, and bigger batches tend to hurt stability.

The teams that benefit most from AI are the ones that already have strong foundations: good tests, small batches, fast feedback, and a solid internal platform. AI amplifies what's already there, good or bad.

Collecting them without spreadsheets

You don't need a big tool to start. Most of the data already exists:

Deployment frequency: count successful production deployments from your CI/CD system.
Lead time: time from the first commit (or merge) to the production deployment that contains it. Git plus your pipeline logs have both timestamps.
Change failure rate: tag rollbacks, hotfixes and incidents linked to a deployment.
Time to restore: from your incident tool, opened to resolved.

There are open-source options like the DORA team's Four Keys project as inspiration, and many commercial tools (LinearB, Sleuth, Swarmia, DX, GitLab and GitHub insights) that calculate them automatically.

Start rough. A weekly script that counts deployments and incidents is better than a perfect dashboard you never build.

Numbers I stopped tracking

Some metrics look good on a slide but tell you very little:

Lines of code. More code is often worse, not better.
Number of commits or pull requests per developer. Easy to game, and it turns measurement into surveillance.
Story points. Useful for a team's own planning, meaningless when compared between teams.
Uptime percentage alone. Without context, 99.9% might be great or terrible.

The DORA metrics work best at the team level, used by the team itself to improve. The moment they're used to rank individuals or punish teams, people start optimising the number instead of the system.

Beyond DORA: SPACE and DevEx

DORA measures delivery. It doesn't measure whether developers are happy, focused or burning out. Frameworks like SPACE and DevEx add that human side: satisfaction, flow, cognitive load, interruptions. A short quarterly survey is a good companion to the DORA numbers.

So, should you measure?

Yes, but with care. Pick the DORA metrics, measure them roughly, look at trends rather than absolute values, and talk about them as a team. When a number moves, ask why.

My take: measure the system, not the people. The goal is to learn where it hurts, not to win a leaderboard.

— Desly

Portals, CLIs or Git: what developers really use

Tue, 20 Oct 2026 23:10:30 +0200

When platform teams show off their work, they usually show a portal. Nice cards, service pages, a big "Create" button. It demos beautifully.

But when I watch developers actually work, they rarely live in a portal. They live in their editor, their terminal, their pull requests and their chat tool. So the question every platform team should ask is: where should the platform meet developers?

Three ways to offer a platform

A web portal (Backstage, Port and others). Great for discovery: finding services, owners, docs, and for occasional tasks like creating a new service. Less great for things you do twenty times a day.

A CLI. Developers who live in the terminal love a good command-line tool. platform create service, platform logs, platform env up. Fast, scriptable, easy to use in CI. The downside: someone has to build and maintain it, and it needs to be installed and updated everywhere.

Git as the interface (GitOps). Developers change a YAML file in a repository, open a pull request, and automation does the rest. Every change is reviewed, versioned and auditable. The downside: YAML fatigue, and less discoverable for newcomers.

None of these is "the right one". They're good at different moments.

The best platform interface is the one developers are already looking at when they need it.

What I've learned from asking developers

When you ask developers what they want from a platform, the answers are rarely "a nicer portal". More often they're things like:

"I just want to know why my deployment failed without asking someone."
"I want logs for my service without learning a query language."
"I want a test environment without opening a ticket."
"I want to know who owns the service that's breaking mine."

Notice that these are about outcomes, not interfaces. The platform team's job is to make those outcomes easy, wherever the developer happens to be.

Some practical patterns that work well:

Bring information to the pull request. Preview URLs, test results, security findings and cost changes as comments on the PR.
Bring alerts to chat with links straight to the right dashboard and runbook.
Use the portal for discovery and rare actions, not daily work.
Keep the real source of truth in Git, and let the portal and CLI read from it.

Docs are a feature

The most underrated part of any platform is documentation. A platform nobody understands is a platform nobody uses.

Good platform docs:

Start with "how do I do X" guides, not architecture diagrams.
Live next to the code (docs-as-code) and are reviewed like code.
Have copy-paste examples that actually work.
Are owned by someone and reviewed regularly.

If you only have time for one improvement this quarter, improving docs often beats adding a new feature.

Before and after numbers

Whatever interface you choose, measure whether it helps. Useful before and after comparisons:

Time from "I need a new service" to "it runs in a test environment".
Number of routine requests to the platform team.
How often developers need help to debug a failed deployment.
Survey answers to "how easy is it to ship a change?"

If the numbers don't move after launching a portal, the portal isn't the problem you needed to solve.

So, which one should you build?

Start where your developers already are. For most teams, that's Git and pull requests, with good automation behind them. Add a CLI if your developers are terminal-heavy. Add a portal when discovery becomes a real problem, usually once you have dozens of services and teams.

My take: build the platform around developers' habits, not around the demo. The demo lasts ten minutes, the habits last years.

— Desly

Less to think about: reducing cognitive load for developers

Tue, 20 Oct 2026 23:10:30 +0200

"You build it, you run it." I believe in that idea. Teams that own their services in production build better software. But somewhere along the way, "you run it" turned into "you need to understand Kubernetes, Helm, Terraform, IAM, networking, observability, security scanning and three CI systems". That's a lot to carry on top of actually building the product.

That weight has a name: cognitive load.

What cognitive load means at work

The idea comes from psychology, and the book Team Topologies made it popular in software. Every person and team has limited mental capacity. If too much of it is used on things that aren't their main job, their main job suffers.

There are roughly three kinds:

Intrinsic: the complexity of the problem itself. Building a payment system is hard. That's fine.
Extraneous: complexity that doesn't need to be there. Confusing tools, unclear processes, twelve ways to deploy.
Germane: the effort of learning things that make you better at your job.

A platform team's job is to remove as much extraneous load as possible, so developers can spend their energy on the intrinsic and germane kinds.

If your developers need to understand your whole infrastructure to change one line of code, the infrastructure is the problem.

Hiding Kubernetes, gently

Kubernetes is a perfect example. It's powerful, but a simple web service needs a Deployment, a Service, an HTTPRoute or Ingress, a ConfigMap, maybe a HorizontalPodAutoscaler, a PodDisruptionBudget, a ServiceAccount, NetworkPolicies... Most developers don't need to know all of that.

Ways to reduce it:

A shared Helm chart with good defaults. The developer's values file is fifteen lines instead of three hundred.
Higher-level specs like Score (a workload spec that describes what a service needs, not how to deploy it), or Kro and Crossplane to build your own simple App resource.
Templates that generate everything once, so developers start from something that works.

The word "gently" matters. Don't hide Kubernetes so completely that debugging becomes impossible. Make the simple path simple, and keep the details available for people who need them.

Good defaults beat good documentation

Every decision you ask a developer to make is a small piece of load. Most of them have a sensible answer that's right 90% of the time.

Bake those answers into the platform:

Logs in a structured format, shipped automatically.
Metrics and tracing set up in the base image or library.
Resource requests and probes with reasonable values.
Security settings: non-root containers, read-only file systems, dropped capabilities.
Alerts for the basics: error rate, latency, restarts.

Documentation still matters, but the best documentation is the one nobody has to read because the default is already right.

Signs your platform makes it worse

Platform teams can increase cognitive load too. Watch out for:

Another tool to learn that only the platform team really understands.
Abstractions that leak: when something breaks, developers have to understand both the abstraction and everything underneath.
Too many choices: "you can deploy with option A, B, or C" isn't self-service, it's homework.
Constant change: a new way of doing things every quarter.

Ask developers regularly what slows them down. If the platform appears on that list, take it seriously.

So, how do you start?

Pick one area where developers struggle the most, often deployment configuration or observability. Reduce the number of things they need to know there. Measure whether questions to the ops team go down. Repeat.

My take: the best platform is the one developers barely notice. They just ship, and things work.

— Desly

Monorepo or many repos?

Tue, 20 Oct 2026 23:10:30 +0200

Few topics start an argument among engineers faster than this one. Some people swear by putting everything in one giant repository. Others think that's madness and want one repository per service. Both groups point to famous companies that do it their way.

Here's how I think about it from a DevOps point of view: what it means for pipelines, ownership and day-to-day work.

What we're comparing

Monorepo: all (or most) code for many services and libraries lives in one repository.

Polyrepo: each service or library has its own repository.

There's a middle ground too: one repository per team or per product area. Many companies end up there, even if they don't call it anything.

What changes for CI

This is where the decision hurts or helps the most.

In a polyrepo world, CI is simple at first. Each repository has its own pipeline, it only builds that service, and it's fast. The pain arrives later: shared libraries need to be released, versioned and updated in every consumer. A change that touches three services means three pull requests, three reviews, three pipelines, coordinated by hand.

In a monorepo, a cross-cutting change is one pull request. Refactoring a shared library and updating all its users happens atomically. But naive CI becomes slow: if every commit builds and tests everything, pipelines take forever as the repo grows.

The fix for monorepo CI is affected-only builds: work out which projects a change actually touches, and only build and test those. That needs tooling that understands the dependency graph.

A monorepo without smart build tooling is just a very big polyrepo with slower pipelines.

Ownership and dependencies

Polyrepos make ownership obvious. This repository belongs to that team. Permissions are simple. But dependency versions drift: one service is on version 1 of the shared library, another on version 4, and nobody wants to upgrade.

Monorepos encourage everyone to stay on the latest version of internal code, because there's only one version. Ownership needs to be made explicit, usually with a CODEOWNERS file that maps folders to teams so the right people review the right changes.

Tools that make monorepos work

You'll want a build tool that understands the graph and caches results:

Nx and Turborepo: popular in the JavaScript/TypeScript world, easy to adopt, with remote caching.
Bazel: extremely powerful and language-agnostic, used at very large scale. Also a significant investment to learn and maintain.
Pants and Buck2: other graph-based build systems, strong for Python and polyglot repos.
Built-in path filters in GitHub Actions or GitLab CI: the simplest option, triggering jobs only when certain folders change. Good enough for small monorepos.

Remote caching is the real speed-up: if the same code was already built and tested by someone else's pipeline, reuse the result instead of doing it again.

Moving between the two

Migrations in both directions happen.

Polyrepo to monorepo: you can preserve history by merging repositories into subfolders. The hard part isn't Git, it's agreeing on shared tooling, build setup and CI.

Monorepo to polyrepo: tools like git filter-repo can split a folder into its own repository with history. The hard part is untangling shared code that suddenly needs versioning.

Whichever direction, migrate gradually, one service or team at a time.

So, which one?

My rough guide:

Small team, a handful of services, shared code: a monorepo is often simpler.
Many independent teams, different languages, little shared code: polyrepos are fine.
Large organisation with heavy code sharing: a monorepo can be great, but only with serious build tooling and a team that owns it.

Honestly, the structure isn't as important as the discipline around it: clear ownership, fast pipelines, and a reliable way to update shared code.

My take: choose the layout that makes your most common change easy. Then invest in tooling so the uncommon ones don't hurt.

— Desly

MCP: plugging AI into your infrastructure

Tue, 20 Oct 2026 23:10:30 +0200

For a long time, using AI for infrastructure work meant copying and pasting. Copy the error into the chat, copy the answer back into the terminal. The AI could only see what you showed it.

The Model Context Protocol, or MCP, changes that. It gives AI assistants a standard way to connect to tools and data. And for DevOps, that means an assistant that can actually look at your cluster, your pipelines and your dashboards.

What MCP is, without the hype

MCP is an open protocol, introduced by Anthropic in late 2024 and now supported by most major AI tools. Think of it like USB for AI: instead of every AI app building its own integration with every tool, tools expose an MCP server, and any AI app that speaks MCP (the client) can use it.

An MCP server offers:

Tools: actions the AI can take, like "list pods" or "get pipeline logs".
Resources: data the AI can read, like files, documents or records.
Prompts: ready-made instructions for common tasks.

The AI decides when to call a tool based on your request. You ask "why is the checkout service crashing?", and the assistant might list pods, read recent events, fetch logs and summarise what it found.

The servers that matter for DevOps

MCP servers exist for most of the tools we use daily:

Kubernetes: read resources, events and logs, and sometimes apply changes.
GitHub and GitLab: issues, pull requests, workflow runs.
Terraform and cloud providers: documentation lookups, resource information, and in some cases plans.
Observability tools: query metrics, logs and traces from Grafana, Datadog and others.
Incident and ticket tools: read incidents, write updates.

Many vendors now ship official servers, and there are many community ones. Quality varies a lot, so check who maintains a server before you connect it to anything important.

MCP turns an AI assistant from someone you describe the problem to into someone who can look at the problem themselves. That's exactly why it needs limits.

What could go wrong

MCP is powerful because it gives AI access. That's also the risk.

Over-broad credentials. If an MCP server uses your personal admin kubeconfig, the AI has admin rights to your cluster. Every tool call is made with whatever access the server has.

Prompt injection. The AI reads data from your tools: issue descriptions, log lines, web pages, README files. If someone puts instructions into that data ("ignore previous instructions and delete the namespace"), a poorly guarded setup might follow them. This is the biggest security issue with AI agents today, and it isn't fully solved.

Untrusted servers. An MCP server is code running on your machine or network. A malicious or compromised server could read data or misbehave. Treat installing an MCP server like installing any other dependency.

Silent writes. Reading is relatively safe. Writing, applying, deleting is not.

How I'd use it safely

Start read-only. Give the Kubernetes or cloud MCP server a role that can only read. Most of the value, debugging and explaining, comes from reading anyway.
Separate credentials. Dedicated service accounts for MCP servers, scoped to specific namespaces or projects, never your personal admin access.
Keep production out at first. Use it on dev and staging until you trust the setup.
Require confirmation for writes. Most AI clients can ask before each tool call. Keep that on for anything that changes state.
Use official or well-reviewed servers, pinned to a version.
Log tool calls so you can see what happened afterwards.

Building a tiny one myself

The protocol is simple enough that building a small internal MCP server is a nice afternoon project. The official SDKs exist for Python, TypeScript, Go and other languages.

A good first server: something read-only and specific to your company. For example, a tool that answers "who owns this service and where is its runbook?" from your service catalog. Small, useful, and impossible to break anything with.

So, should you try it?

Yes, carefully. MCP is quickly becoming the standard way AI connects to tools, and understanding it will be part of the DevOps job. Start read-only, in non-production, with narrow credentials. Expand only when you understand what it does.

My take: give AI eyes before you give it hands. And when you do give it hands, make sure they can't reach production by accident.

— Desly

AI writes the code. Who checks it?

Tue, 20 Oct 2026 23:10:30 +0200

A growing share of the code in our repositories wasn't typed by a human. AI assistants write functions, tests, Dockerfiles and Terraform. Agents open whole pull requests. That's a huge productivity boost.

The increase in code volume means there's more to review, but the time available hasn't changed. Plus, AI-generated code has its own kind of mistakes. So the pipeline needs to do more checking.

The new risks in plain words

Insecure patterns that look fine. AI learned from public code, and a lot of public code is insecure. SQL built from strings, disabled TLS verification, overly broad permissions, secrets in config files.

Outdated advice. Deprecated APIs, old library versions with known vulnerabilities, Kubernetes manifests using removed API versions.

Hallucinated dependencies. The AI suggests importing a package that sounds right but doesn't exist.

License problems. Generated code that closely resembles code under a restrictive license.

Bigger changes, less review. When generating code is easy, pull requests get larger, and large pull requests get worse reviews.

"Slopsquatting": installing a package an AI invented

This one deserves its own section because it's new and sneaky.

Language models sometimes invent package names. Plausible ones, like requests-oauth-helper or express-secure-session. Researchers noticed that the same invented names come up repeatedly. So attackers can register those names on npm or PyPI and fill them with malware. When a developer, or an agent, trusts the suggestion and installs the package, the attacker's code runs.

It's a twist on typosquatting, and the community nicknamed it slopsquatting.

An AI suggesting a package isn't a recommendation. It's a guess, and attackers are betting on those guesses.

The checks I'd add to the pipeline

None of this needs exotic tools. It needs the normal DevSecOps toolbox, actually switched on and enforced:

Dependency checks. Software composition analysis (Dependabot alerts, OSV-Scanner, Snyk, Trivy) for known vulnerabilities. Plus tools like Socket that flag suspicious packages: brand new, few downloads, install scripts.
A policy for new dependencies. Adding a new package should be visible in the pull request and get a human look. Some teams only allow packages from an internal proxy or registry.
Static analysis (SAST). Semgrep, CodeQL or similar to catch injection, insecure crypto and dangerous functions.
Secret scanning on every push, with push protection where available.
IaC scanning. Checkov, Trivy or tflint for Terraform and Kubernetes manifests: open security groups, privileged containers, missing encryption.
License scanning if license compliance matters to your company.
Tests, actually required. The best defence against confident wrong code is a test that fails.

Reviewing when there's too much to review

Tools catch patterns. Humans still need to catch logic. A few habits help:

Keep pull requests small, even when AI makes big ones easy. Ask the agent to split work.
Mark AI-generated changes so reviewers know to look more carefully. Some teams use a label or commit trailer.
Review the tests first. If the tests are weak, the code passing them means little.
Ask "why" for every new dependency.
Don't let AI review its own code alone. AI review tools are a useful extra pair of eyes, not a replacement for a human approval.

So, who checks it?

The pipeline checks what it can automatically, and a human checks what really matters. That's how it's always worked. AI just makes it harder because there's more code, written faster, by something that never hesitates.

My take: AI can write the code. Your pipeline and your reviewers still have to earn the right to ship it.

— Desly

Too many alerts: can AI cut the noise?

Tue, 20 Oct 2026 23:10:30 +0200

Every on-call engineer knows the feeling. Your phone buzzes. You check it: CPU at 85% on a node that's been at 85% for a year. Buzz again: a disk warning that resolves itself in two minutes. Buzz: ten alerts for the same database problem, one from each service that uses it.

After a few weeks of this, people stop reacting. The one alert that really matters then gets ignored too. That's alert fatigue, and it's dangerous.

AIOps tools promise to fix it with machine learning. Do they?

Why static thresholds fail

Most alerts are built like this: "if metric X is above Y for Z minutes, page someone." Simple and predictable. Also frequently wrong:

Normal changes over time. Traffic at 3 p.m. on Monday looks nothing like 3 a.m. on Sunday. One threshold can't fit both.
Thresholds are guesses. Someone picked 80% years ago, and nobody remembers why.
Causes, not symptoms. High CPU isn't a problem if users are happy. Slow checkout is a problem even if CPU is fine.
One failure, many alerts. A database outage triggers alerts in every dependent service.

What AIOps tools promise

"AIOps" is a broad marketing term, but it usually covers a few real features:

Anomaly detection. Instead of fixed thresholds, the tool learns what's normal for each metric, including daily and weekly patterns, and alerts on unusual behaviour.
Correlation and grouping. Related alerts from different services are grouped into one incident, ideally with a guess at the root cause.
Deduplication and suppression. Flapping alerts and duplicates are merged or muted.
Summaries. With LLMs, many tools now write a plain-language explanation of what's going on.

Datadog, Dynatrace, New Relic, Grafana, PagerDuty, BigPanda and others all offer some version of these features.

What they actually deliver

In my experience, honestly: some real value, and less magic than the sales deck.

Grouping and correlation is where I see the most benefit. Turning forty alerts into one incident with a timeline is a big improvement for whoever's on call.

Anomaly detection is useful for metrics with strong patterns, like traffic and business numbers, and noisy for everything else. "Anomalous" doesn't mean "bad". A marketing campaign is an anomaly too.

AI summaries help get oriented faster, with the usual caveat: check the evidence.

AI can sort the noise, but it can't decide what you should care about. That part is still your job.

Fixing the basics first

Before buying anything, most teams can remove half their alert noise with discipline alone:

Alert on symptoms users feel: error rate, latency, availability. Ideally based on SLOs and burn rates.
Every page must need a human action now. If not, make it a ticket or a dashboard, not a page.
Every alert has an owner and a runbook.
Group and inhibit in your alerting tool. Alertmanager can suppress downstream alerts when the upstream one is firing.
Review alerts monthly. Which ones fired? Which were useful? Delete or fix the rest.

AIOps on top of a messy alert setup just gives you organised mess.

Measuring if an alert was worth it

The metric I like most is actionability rate: of all pages last month, how many led to someone actually doing something? If it's below about half, you have a noise problem.

Other useful numbers: pages per on-call shift, pages outside working hours, and time to acknowledge. If those trend in the right direction, whatever you changed is working, with or without AI.

So, can AI cut the noise?

Partly. It's genuinely good at grouping and summarising. But the biggest wins still come from deciding, as a team, what deserves to wake someone up. Do that first, then let AI help with the rest.

My take: the quietest pager comes from good alert design. AI is a helpful filter, not a substitute for deciding what matters.

— Desly

GPUs for DevOps people

Tue, 20 Oct 2026 23:10:30 +0200

For most of my career, GPUs were something gamers and researchers worried about. The infrastructure I ran was CPUs, memory, disks and networks. Then AI happened, and suddenly teams were asking for GPU nodes, model serving and "can we run this LLM ourselves?"

If you're a DevOps engineer, GPUs are probably on your desk already, or they will be soon. Here's what I think you need to know.

Why GPUs landed on my desk

A CPU has a few very powerful cores. A GPU has thousands of smaller cores that do the same simple maths in parallel. Training and running neural networks is mostly that kind of maths: huge matrix multiplications. So a GPU can do in seconds what would take a CPU minutes.

For DevOps, that brings new questions:

How do we give workloads access to GPUs?
How do we share them so they aren't sitting idle?
How do we monitor them?
How do we stop the cloud bill from exploding?

GPU basics in five minutes

A few terms that come up constantly:

VRAM: the GPU's own memory. For LLMs, this is usually the limit. The model weights must fit, plus room for the requests being processed.
CUDA: NVIDIA's software platform. Most AI software depends on it, which is why NVIDIA dominates.
Drivers: GPUs need specific drivers on the host, matching the CUDA version your software expects. Version mismatches are a classic source of pain.
Generations: data centre GPUs like the NVIDIA A100, H100, H200 and newer, plus smaller and cheaper ones like the L4 and T4. More expensive isn't always better for your workload.

Sharing one GPU: MIG and time-slicing

A full GPU is often far more than one small model needs. Sharing options:

MIG (Multi-Instance GPU): supported on higher-end NVIDIA GPUs. Splits one GPU into several fully isolated slices, each with its own memory and compute. Good isolation, fixed sizes.
Time-slicing: multiple workloads take turns on the same GPU. More flexible, but no memory isolation, so one greedy workload can affect others.
MPS (Multi-Process Service): lets processes share a GPU more efficiently, with some limits.

For inference of small models, sharing can cut costs dramatically.

An idle GPU is the most expensive thing in your data centre doing nothing.

Running them on Kubernetes

On Kubernetes, the usual setup:

A GPU node pool with taints, so normal workloads don't land on expensive GPU nodes.
The NVIDIA GPU Operator, which installs drivers, the container toolkit, the device plugin and monitoring on GPU nodes automatically.
Pods request GPUs like any other resource:

resources:
  limits:
    nvidia.com/gpu: 1

Tolerations and node selectors so GPU pods land on the right nodes.

Kubernetes now has Dynamic Resource Allocation (DRA), which is stable and lets workloads request specific GPU models, minimum memory sizes, or slices of a GPU. More tools are likely to follow this trend.

On the cloud, managed node pools and Karpenter (on AWS) can add GPU nodes only when GPU pods are waiting, and remove them afterwards.

Monitoring GPUs

Normal node monitoring doesn't tell you much about GPUs. Add the NVIDIA DCGM exporter for Prometheus, which gives you:

GPU utilisation
Memory used
Temperature and power
Errors (yes, GPUs fail too, and some errors mean the node should be drained)

The most important dashboard: utilisation over time per workload. It shows immediately who's paying for GPUs and not using them.

Paying for GPUs that do nothing

GPU costs need active management:

Scale to zero when there's no traffic, if your startup time allows it.
Right-size: a smaller GPU, or a slice of one, is often enough for inference.
Spot or preemptible instances for training and batch jobs that can be interrupted.
Schedule experiments and batch work for off-peak hours.
Showback: make GPU costs visible per team. Behaviour changes quickly when people see the number.

So, do DevOps engineers need to learn GPUs?

If your company does anything serious with AI, yes. You don't need to understand the maths, but you need to know how to schedule, share, monitor and pay for GPUs. That knowledge is quickly becoming a core infrastructure skill.

My take: GPUs are just another resource with a very high price tag. Treat them with the same discipline as everything else, only more so.

— Desly

Will AI take my DevOps job? One year later

Tue, 20 Oct 2026 23:10:30 +0200

A year ago I wrote Will AI take my DevOps job?. My answer back then: parts of it, yes. The repetitive parts. But not the context, the responsibility, or the talking to people. I ended with "AI proposes, humans decide."

Looking back is more interesting than making predictions. Here's what actually happened.

What I predicted

In short, I said:

AI would write more of the boring configuration.
AI would get very good at reading logs.
Agents would start doing small fixes on their own.
Context, responsibility and communication would stay human.
A new part of the job would be building guardrails for AI agents.
MLOps would become more important.

What actually happened

Boring configuration: yes, completely. Writing YAML from scratch already feels old-fashioned. Reviewing it is the job now.

Reading logs: yes, and more. AI connected directly to observability tools, through MCP and vendor integrations, changed the first minutes of an incident. Instead of me searching, I ask questions and check the evidence.

Agents doing small fixes: faster than I expected. Agents that read a failing build, find the cause and open a pull request went from a demo to a normal part of the workflow for many teams. Context and responsibility: still human. I haven't seen any AI take ownership of a production decision, and I don't want to. The incidents I remember from this year were all decided by people. AI made the investigation faster, not the accountability lighter.

Guardrails: this became real work. Permissions for agents, sandboxes, review rules, deciding which tools an AI may call. This took more of my time than I expected, and it's very DevOps: building safety rails around powerful automation.

MLOps: yes. Everyone wants AI features, and someone has to deploy, monitor and pay for them. GPUs, model serving and LLM observability became normal infrastructure topics.

The job didn't shrink. It moved up a level, exactly as I hoped, but faster than I expected.

What I got wrong

I underestimated how quickly agents would improve.
I didn't expect security, especially prompt injection, to become such a big part of the AI conversation.
I thought adoption would be slower in conservative companies. In some places it was, in others it was faster than anything I've seen.

The guardrails I built

The practical lessons from building guardrails this year:

Agents work on branches, never directly on main.
No production credentials for AI tools, ever.
Narrow, short-lived tokens per task.
Branch protection and required checks apply to bots like to people.
Read-only access first, write access only where it's proven useful.
Log every action an agent takes.

None of that is new. It's least privilege and good CI, applied to a new kind of user.

What I'd tell someone starting today, updated

The advice from last year still stands: learn the fundamentals, use AI daily, practise the human skills. I'd add two things:

Learn to review well. Reading a diff critically and quickly is now one of the most valuable skills in DevOps.
Learn a bit of security. Understanding permissions, supply chain risks and prompt injection makes you the person teams trust with AI tools.

So, did AI take my job?

Not yet. It took some of my tasks, and honestly, I don't miss them. What's left is more interesting: designing systems, making decisions, and keeping AI on a safe track.

My take, one year later: AI proposes, humans decide. The proposals got much better. The deciding is still mine.

— Desly

What's new in Kubernetes, and what I'm upgrading for

Tue, 20 Oct 2026 23:10:30 +0200

Kubernetes releases a new minor version roughly three times a year. Every release comes with a long changelog, a blog post full of enhancement numbers, and a list of features moving from alpha to beta to stable. It's easy to skim it and move on.

But a few changes in each release really do affect how we run clusters. And some of them, the removals, can break things on upgrade day. Here's how I read a release, and the recent changes I think matter most.

How I read a Kubernetes release

I look at four things, in this order:

Removals and deprecations. What will break if I upgrade? This is the only section that can hurt you.
Features going stable (GA). These are safe to rely on and usually mean I can drop a workaround or an add-on.
Features going beta. Often enabled by default now, worth testing.
Everything else. Interesting, but rarely urgent.

Recent highlights worth knowing

Over the last few releases, several long-awaited features have become stable. These are the ones I see making a real difference:

Native sidecar containers. Sidecars (log shippers, proxies, agents) used to be ordinary containers with no guaranteed start or stop order. Now you can declare them as init containers with restartPolicy: Always: they start before the main container and stop after it. That fixes a whole family of annoying bugs, like jobs that never finish because the sidecar keeps running.

In-place Pod resource resize. You can change a running pod's CPU and memory requests and limits without restarting it. Great for workloads that need more resources at startup, or for vertical autoscaling without disruption.

Dynamic Resource Allocation (DRA). A flexible way to request specialised hardware, especially GPUs, with more detail than a simple count. Important for anyone running AI workloads.

Gateway API maturity. Not part of core Kubernetes releases, but tied to them in practice. With ingress-nginx retired, Gateway API is now the default way to get traffic into a cluster. I wrote about that migration in Goodbye ingress-nginx, hello Gateway API.

Removal of old foundations. The move away from cgroup v1 and older container runtime versions has continued. If your nodes run an old Linux distribution or an old containerd, check the release notes carefully before upgrading.

A Kubernetes upgrade rarely breaks because of new features. It breaks because of the old thing you forgot you were still using.

My upgrade checklist

Whatever the release, my routine is the same:

Read the deprecations and removals. All of them, even if it's boring.
Scan for deprecated APIs in the cluster and in your manifests with tools like Pluto or kubent:

pluto detect-all-in-cluster
pluto detect-files -d ./manifests

Check your add-ons. Ingress or Gateway controllers, CNI, CSI drivers, cert-manager, monitoring agents, service mesh. Each one has its own supported Kubernetes versions.
Upgrade a non-production cluster first and let it run for a while.
Upgrade the control plane, then node pools, one minor version at a time. Kubernetes doesn't support skipping minor versions for the control plane.
Watch PodDisruptionBudgets. A PDB that allows zero disruptions will block node drains.
Have a rollback plan for nodes. Control planes usually can't be downgraded, but node pools can be recreated.

How often to upgrade

Each Kubernetes minor version gets about a year of patch support upstream. Managed services like EKS, AKS and GKE have their own windows, and some charge extra for extended support of old versions.

My rule: stay within one or two versions of the latest. Upgrading regularly in small steps is much less painful than a big jump every two years, when everything is deprecated at once.

Worth upgrading now?

Usually yes, once the first patch release (x.y.1 or x.y.2) is out and your managed provider supports it. Stable features like native sidecars and in-place resize are worth having, and staying current means security fixes keep coming.

My take: read the removals first, test on a cluster you don't love, and upgrade often enough that it never becomes a project.

— Desly

Goodbye ingress-nginx, hello Gateway API

Tue, 20 Oct 2026 23:10:30 +0200

For years, the first thing I installed on almost every new Kubernetes cluster was ingress-nginx. Before the apps, before the monitoring, before anything interesting. It was the front door. Traffic came in, ingress-nginx sent it to the right place, and I rarely had to think about it.

That front door is now officially unmaintained. In November 2025, the Kubernetes project announced that ingress-nginx would be retired, with best-effort maintenance only until March 2026. That date has passed. If you're still running it, and a lot of clusters are, here's what that means and how I'd get out.

What actually happened

ingress-nginx was a community project, kept alive for years by a very small group of volunteers in their spare time. That's not a criticism. It's the uncomfortable truth behind a lot of the software we all depend on.

Security made it worse. In March 2025, a set of serious vulnerabilities nicknamed IngressNightmare showed that a bug in ingress-nginx could, in the worst case, let an attacker take over a whole cluster. Fixing that kind of thing properly takes time and people the project simply didn't have. So Kubernetes SIG Network and the Security Response Committee made the honest call: retire it. A planned successor, a project called InGate, never got far enough along and is being retired too.

Two things are easy to mix up here, so let me be clear:

The ingress-nginx controller is retired. No new releases, no bug fixes, no security patches. The repositories are read-only.
The Kubernetes Ingress API is not. The Ingress resource still works. It's just frozen: no new features are coming.
The commercial NGINX Ingress Controller from F5 is a different product. Same family name, separate code, still maintained.

Do I have to panic?

No. Your cluster didn't break when the maintenance ended. Existing installs keep running, and the images and Helm charts are still available.

But think about what this component is. It's the one thing in your cluster that faces the internet directly. It parses every request from strangers. And from now on, when the next vulnerability is found, nobody will fix it. That's not a "someday" problem. It's a "this quarter" problem.

Running unpatched software at the edge of your cluster is like leaving the front door unlocked because it has never been robbed yet.

First, find out if you're affected at all. This command, from the official announcement, lists any ingress-nginx pods across the cluster:

kubectl get pods --all-namespaces \
  --selector app.kubernetes.io/name=ingress-nginx

If that returns nothing, you can relax and maybe skip to the end. If it returns pods, keep reading.

Gateway API, in plain words

Gateway API is the official successor to Ingress. It isn't brand new, either: the core became stable back in 2023, and almost every major networking project and cloud provider supports it today.

The biggest change is that one big object becomes a few smaller ones, each owned by the right person:

GatewayClass: which implementation runs the traffic, for example Envoy Gateway or Cilium. Usually set up once by the platform team.
Gateway: the actual entry point. Which ports, which hostnames, which TLS certificates. Owned by whoever runs the cluster.
HTTPRoute: the routing rules for one app. "Send /api to this service." Owned by the app team, in their own namespace.

With Ingress, all of that was squeezed into one resource, and everything the spec didn't cover was hidden in annotations. Anyone who has seen an Ingress with fifteen nginx.ingress.kubernetes.io/... lines knows what I mean. Those annotations only worked with one controller, so "portable Kubernetes" stopped at the front door.

	Ingress	Gateway API
Structure	One resource does everything	Separate pieces for platform and app teams
Advanced features	Controller-specific annotations	Built into the spec: header matching, traffic splitting, redirects
Protocols	HTTP and HTTPS	HTTP, gRPC, TLS, and TCP/UDP with some implementations
Portability	Low once annotations creep in	Much better: the same YAML works across implementations
Future	Frozen	Where all the new work happens

Here's what it looks like in practice. First the Gateway, set up once by the platform team:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: web
  namespace: infra
spec:
  gatewayClassName: eg          # e.g. Envoy Gateway
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
    hostname: "*.example.com"
    tls:
      mode: Terminate
      certificateRefs:
      - name: example-com-tls
    allowedRoutes:
      namespaces:
        from: All               # tighten this with a label selector later

Then each app team attaches its own route, in its own namespace:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: shop
  namespace: shop
spec:
  parentRefs:
  - name: web
    namespace: infra
  hostnames: ["shop.example.com"]
  rules:
  - matches:
    - path: { type: PathPrefix, value: /api }
    backendRefs:
    - name: shop-api
      port: 8080

The app team never touches the Gateway, and the platform team never has to approve a routing change for someone else's service. That separation is what I like most. It matches how teams actually work.

Choosing what replaces it

Gateway API is only a specification. You still need something to run it. The good news is there are plenty of solid options:

Envoy Gateway: a clean, focused choice if you just want a good front door. My default suggestion for most teams.
Cilium: makes sense if you already use Cilium for cluster networking. One less component.
Istio: if you already run a service mesh, or plan to.
NGINX Gateway Fabric or Traefik: if your team wants to stay close to what it already knows.
Your cloud provider's Gateway: GKE, AWS and Azure all have managed options, which means one less thing to patch.

Don't spend weeks comparing benchmarks. For most clusters, the honest deciding question is: what does my team already understand, and what will we still enjoy maintaining in three years?

How I'd migrate, step by step

The trick is to never do a big switch-over. Run both side by side, move traffic slowly, and keep a way back.

Take stock. List every Ingress and, more importantly, every annotation in use. This one-liner gives you a quick count:

bash kubectl get ingress -A -o yaml \ | grep -o 'nginx.ingress.kubernetes.io/[a-z-]*' \ | sort | uniq -c | sort -rn

The annotations are where the real work is hiding.

Install the new implementation next to the old one. It gets its own load balancer and its own IP. Nothing changes for users yet.
Convert with ingress2gateway. The Kubernetes project's own tool reached version 1.0 in March 2026. It reads your existing Ingress resources and writes the Gateway API equivalents:

bash ingress2gateway print --providers=ingress-nginx \ --all-namespaces -o yaml > gateway-resources.yaml

Treat the output as a first draft, not the final answer. Review it like you'd review a pull request.

Fix by hand what the tool can't. Custom snippets, authentication, rate limiting, unusual rewrites and regex paths usually need manual work. Many of these become implementation-specific policies instead of annotations.
Test before DNS changes. Point requests directly at the new IP and check everything works:

bash curl --resolve shop.example.com:443:NEW_GATEWAY_IP \ https://shop.example.com/api/health

Move traffic gradually. Lower your DNS TTLs a day before, then move one hostname at a time, starting with the least important. Keep ingress-nginx running so rolling back is just a DNS change.
Clean up. Once everything has run quietly for a while, remove ingress-nginx and its Ingress resources. Don't forget the tools around it: cert-manager and ExternalDNS both support Gateway API, but they need to be configured for it.

What tends to bite

A few things are easy to underestimate:

Snippet annotations. If someone put raw NGINX configuration into configuration-snippet years ago, there's no direct translation. You first need to work out what it was even for. Sometimes the answer is "nothing anymore."
Rewrites. rewrite-target with regex capture groups doesn't map one to one. Test every rewritten path.
Small behavior differences. Default timeouts, body size limits and header handling differ between implementations. Things that "just worked" may suddenly return a 413 or a timeout.
Who owns what. The new model splits responsibility between teams. That's great, but only if you've agreed who owns the Gateway and which namespaces may attach routes to it.

What I'd tell someone starting today

If you're building a new cluster, don't install ingress-nginx, and don't write new Ingress resources either. Start with Gateway API from day one. The concepts take an afternoon to learn, and you'll never have to do this migration.

And if you're learning Kubernetes, this is a good lesson in itself. The most popular project in its category, used by almost everyone, was maintained by a handful of tired volunteers. Before you build on something, it's worth asking who is actually keeping it alive.

So, is it worth the effort?

Honestly, yes, and not only for security. Gateway API is simply the better model. Cleaner YAML, fewer magic annotations, a clear split between platform and app teams, and features that used to need hacks are now built in.

The retirement just forces a move most of us should have made anyway. Better to do it calmly now than in a hurry the day the next big vulnerability is announced.

My take: the front door changed, but the job didn't. Plan it, run both side by side, move slowly, and keep a way back.

— Desly

Helm 4: what changed

Tue, 20 Oct 2026 23:10:30 +0200

Helm 3 came out in 2019. That's ancient history in Kubernetes years. It removed Tiller, the server-side component everyone hated, and then stayed remarkably stable for six years. Millions of deployments depend on it.

Helm 4 came out in late 2025, announced at KubeCon North America. So the big question for most teams: what's different, and do I need to change anything?

What's new

Helm 4 is less of a revolution than Helm 3 was. It's more of a modernisation. The headline changes:

Server-side apply. Helm 3 applied resources with its own three-way merge logic on the client. Helm 4 can use Kubernetes' server-side apply, which is how modern tools like Argo CD and Flux increasingly work. This makes Helm play nicer with other tools touching the same resources, and handles field ownership properly.

Better waiting and status checks. The --wait behaviour has been reworked to use more modern status checking, so Helm has a better understanding of whether resources are actually ready, including custom resources.

A new plugin system. Plugins can now be written as WebAssembly modules, which makes them portable and sandboxed instead of arbitrary scripts running on your machine. Old-style plugins still work.

OCI registries are first class. Storing charts in container registries (like Docker Hub, GHCR, ECR, Harbor) was already possible in Helm 3. In Helm 4, OCI is the clear default direction, and the old index.yaml style chart repositories feel increasingly like legacy.

Modernised internals and SDK. Structured logging, cleaned-up Go APIs, and lots of internal refactoring. This matters mostly to tools built on top of Helm's libraries.

Do my old charts still work?

This is the most important question, and the good news: yes, existing charts (apiVersion v2) keep working in Helm 4. The maintainers were careful about compatibility. Release history from Helm 3 is also understood by Helm 4, so you can upgrade the CLI and keep managing your existing releases.

Where you might notice differences:

Some command-line flags were renamed or removed. Scripts and CI pipelines that call Helm directly should be tested.
Server-side apply can surface field ownership conflicts that the old client-side logic silently overwrote.
Tools that embed Helm as a library (some CI tools, older operators) may need updates for the new SDK.

My suggestion: run Helm 4 in a test pipeline against your charts and environments first. Check helm template, helm upgrade --dry-run, and a real upgrade on a non-production cluster.

Helm 4 doesn't ask you to rewrite your charts. It asks you to re-test your pipelines, which you should be doing anyway.

Chart habits worth keeping

A major version is a good excuse to clean up your charts:

Add a values.schema.json so wrong values fail fast with a clear error instead of a broken deployment.
Write chart tests (helm test) and run helm lint in CI.
Use library charts for shared templates instead of copying helpers between charts.
Publish to an OCI registry and sign charts, for example with Cosign.
Keep values files small with sensible defaults in the chart.
Pin chart versions in your deployments. Never deploy "latest".

Helm, Kustomize, or something else?

Helm remains the most common way to package Kubernetes applications, especially third-party ones. Almost every open-source project ships a Helm chart.

Kustomize is great for your own applications when you want plain YAML with overlays per environment and no templating language.
Kro, Timoni and CUE-based tools offer more structured approaches, but with much smaller ecosystems.
Many teams use both Helm and Kustomize: Helm for third-party software, Kustomize for their own apps, often managed by Argo CD or Flux.

Should you upgrade?

Yes, but without hurry. Helm 3 continues to receive security fixes for a while, so you have time. Upgrade the CLI in CI first, test your charts, then roll it out to people's machines.

My take: Helm 4 is a quiet upgrade with good foundations. Test your pipelines, clean up your charts, and enjoy not rewriting anything.

— Desly

More than one cluster

Tue, 20 Oct 2026 23:10:30 +0200

Almost every company starts with one Kubernetes cluster. Then a second one for staging. Then one in another region. Then a team needs its own for compliance reasons. Then there's the edge, the data science team, the acquisition... And suddenly someone asks "how many clusters do we have?" and nobody knows the exact answer.

Multi-cluster isn't a decision most teams make once. It's something that happens. The question is whether you manage it on purpose.

Why one cluster isn't enough

There are good reasons to run more than one:

Environment isolation. Production shouldn't share a cluster with experiments.
Blast radius. A bad upgrade, a misconfigured admission webhook or a control plane problem only affects one cluster.
Regions and latency. Users in Europe and Asia are better served by clusters near them.
Compliance and data residency. Some data must stay in a specific country or a specially controlled environment.
Team autonomy. Some teams need cluster-level permissions or special configurations.
Scale limits. Very large clusters hit practical limits on nodes, pods and API load.

And some less good reasons: every team getting its own cluster just because it was easy to click one together.

Every cluster you add is another thing to upgrade, secure, monitor and pay for. Make each one earn its place.

Managing a fleet

Once you have more than a few clusters, doing things by hand stops working. You need a fleet approach.

GitOps is the foundation. Argo CD or Flux deploy the same baseline to every cluster from Git: monitoring agents, policies, ingress or gateway controllers, cert-manager. Argo CD ApplicationSets with the cluster generator are especially useful: define an application once, and it's deployed to every cluster that matches a label.

Cluster lifecycle tools create and upgrade the clusters themselves:

Cluster API manages Kubernetes clusters with Kubernetes resources, across many providers.
Terraform or OpenTofu with managed services (EKS, AKS, GKE) is the most common approach.
Rancher, Open Cluster Management and cloud-specific fleet tools (like GKE fleets) add a central management layer.

Standardisation is what makes it scale. Clusters should be cattle, not pets: created from the same templates, with the same baseline, so any engineer can work on any cluster.

Connecting clusters

Sometimes services in different clusters need to talk to each other. Options:

Through public or internal load balancers: simple, works everywhere, but each service needs to be exposed explicitly.
Cilium Cluster Mesh: connects pod networks across clusters, with global services that load-balance across them.
Istio multi-cluster: service mesh across clusters, with mTLS and traffic policies.
Submariner and the Multi-Cluster Services API: Kubernetes-native ways to export services from one cluster to others.

My advice: avoid cross-cluster dependencies when you can. Each cluster serving a complete slice of the system (for example a region) is much simpler than services constantly calling across clusters.

Identity and secrets everywhere

With many clusters, access control gets tricky:

Single sign-on for humans, with the same groups and roles mapped in every cluster. No shared kubeconfigs.
Workload identity so pods authenticate to cloud services without static credentials.
A central secret store (Vault, OpenBao, or your cloud's secret manager) with External Secrets Operator in each cluster, instead of copying secrets around.
Policy everywhere: the same Kyverno or Gatekeeper policies deployed to every cluster through GitOps.

Observability across the fleet

Each cluster sending metrics, logs and traces to a central place is essential. Label everything with the cluster name and region. A dashboard showing all clusters side by side, with versions and health, quickly answers "is it just this cluster, or all of them?"

Also track versions: which Kubernetes version and which add-on versions each cluster runs. Version drift across a fleet is a classic source of "it works in cluster A but not B".

So, how many clusters should you have?

As few as your requirements allow, and as many as your isolation, region and compliance needs demand. Whatever the number, manage them as a fleet from day one: GitOps for everything, the same baseline everywhere, and central observability.

My take: multi-cluster is manageable when every cluster looks the same. The trouble starts the day one of them becomes special.

— Desly

Databases on Kubernetes: yes or no?

Tue, 20 Oct 2026 23:10:30 +0200

For years, the standard advice was simple: run your stateless apps on Kubernetes, and keep your databases somewhere else. Kubernetes was built for cattle, and databases are the ultimate pet.

That advice is getting old. Storage on Kubernetes has matured, and operators can now handle failover, backups and upgrades better than many hand-built setups. So the question has changed from "can you?" to "should you?"

Storage on Kubernetes, simply

A few building blocks you need to understand:

PersistentVolume (PV): a piece of storage, like a cloud disk.
PersistentVolumeClaim (PVC): a pod's request for storage: "I need 50 GB of fast disk".
StorageClass: the type of storage and how to create it automatically, for example SSD-backed cloud disks.
CSI drivers: plugins that connect Kubernetes to the actual storage system.
StatefulSet: like a Deployment, but each pod gets a stable name (db-0, db-1) and its own persistent volume that follows it.

With these, a database pod can be restarted or moved and still find its data.

But here's the catch: a StatefulSet only keeps the data attached. It knows nothing about database replication, failover, backups or upgrades. That's where operators come in.

Operators that do the hard work

An operator is software running in your cluster that knows how to run a specific database. You describe what you want, and it handles the operational details.

Some well-regarded ones:

CloudNativePG for PostgreSQL: replication, automatic failover, backups to object storage, point-in-time recovery, rolling upgrades.
Strimzi for Apache Kafka.
Percona operators for MySQL, PostgreSQL and MongoDB.
Redis/Valkey operators from several vendors and communities.

A PostgreSQL cluster with CloudNativePG looks like this:

apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: orders-db
spec:
  instances: 3
  storage:
    size: 50Gi
    storageClass: fast-ssd
  backup:
    barmanObjectStore:
      destinationPath: s3://my-backups/orders-db
      s3Credentials:
        inheritFromIAMRole: true
    retentionPolicy: "30d"

Three instances, streaming replication, automatic failover and backups, in about fifteen lines. That's impressive.

A database on Kubernetes without an operator is just a database with extra ways to break.

Backups I trust

Whatever you run, the backup is what matters. A few rules:

Use the database's own backup tools (via the operator) for consistent, point-in-time recoverable backups. Disk snapshots alone are not enough for most databases.
Store backups outside the cluster, ideally in another region or account.
Use Velero for backing up Kubernetes resources and volumes as a second layer, especially for disaster recovery of a whole cluster.
Test restores regularly. A backup you've never restored is a hope, not a backup.

The real costs

Running databases on Kubernetes means your team owns things a managed service would handle:

Upgrades of the database version and the operator.
Performance tuning, storage sizing, and dealing with full disks at 2 a.m.
Security patches.
Expertise: someone needs to really understand PostgreSQL (or whatever you run) when things go wrong.

When I'd still pick a managed database

I'd choose a managed service (RDS, Cloud SQL, Azure Database, and similar) when:

The database is business-critical and the team is small.
Nobody on the team has deep database operations experience.
You're already on a cloud provider and the managed option fits the budget.
Compliance requirements are easier to meet with a certified managed service.

When Kubernetes makes sense

And I'd run it on Kubernetes when:

You're on-premises or in a sovereign or edge environment without good managed options.
You need many small databases, for example one per preview environment or per tenant.
You want consistency across clouds.
Cost matters at scale, and you have the skills to run it.
The team already has strong Kubernetes and database experience.

So, yes or no?

It depends, but the answer is no longer "never". With a good operator, solid backups and a team that understands the database, Kubernetes is a perfectly reasonable home for state. Without those, a managed service will save you a lot of sleepless nights.

My take: the database doesn't care where it runs. It cares whether someone who understands it is looking after it.

— Desly

Argo CD or Flux?

Tue, 20 Oct 2026 23:10:30 +0200

If you run Kubernetes and deploy with GitOps, you've almost certainly met this question. Argo CD and Flux are both graduated CNCF projects, both mature, both used by thousands of companies. Both will deploy your apps from Git reliably.

It's not about which one is better. It's about which one matches how your team works.

GitOps in one paragraph

GitOps means Git is the source of truth for what runs in your cluster. Instead of a pipeline pushing changes with kubectl apply, an agent inside the cluster pulls the desired state from Git and continuously makes the cluster match it. Every change is a commit. Every rollback is a revert. Drift gets corrected automatically. The OpenGitOps project sums it up in four principles: declarative, versioned and immutable, pulled automatically, continuously reconciled.

Argo CD in short

Argo CD is an application-centric GitOps tool with a strong web UI.

The UI is a big selling point. You see every application, its resources, their health and their sync status as a live tree. Developers love being able to click into their app and see what's happening.
Applications and ApplicationSets. An Application points at a Git path and a target cluster. ApplicationSets generate many Applications from templates: one per cluster, per environment, per pull request.
Multi-cluster from a central instance. One Argo CD can manage many clusters.
Projects and RBAC for multi-team setups, with SSO integration.
Argo CD 3.x brought cleaner defaults and better performance, and the wider Argo family includes Argo Rollouts for progressive delivery and Argo Workflows.

Flux in short

Flux is a collection of Kubernetes controllers that work like native Kubernetes components.

Everything is a CRD. GitRepository, OCIRepository, Kustomization, HelmRelease. You manage Flux the same way you manage everything else.
No UI by default. Flux is CLI and API first. There are third-party UIs and integrations, but the experience is built around kubectl and the flux CLI.
Strong Helm support through the Helm controller, with automated upgrades, tests and rollbacks.
OCI artifacts as a source: you can push manifests to a container registry and have Flux pull from there.
Image automation controllers can update image tags in Git automatically when new images are pushed.
Lightweight, per-cluster model. Usually each cluster runs its own Flux and pulls its own config.

Argo CD shows you GitOps. Flux disappears into Kubernetes. Both are valid ways to love it.

Side by side

	Argo CD	Flux
Interface	Rich web UI plus CLI	CLI and CRDs, UI optional
Typical model	Central instance, many clusters	Agent per cluster
Multi-tenancy	Projects, RBAC, SSO in the UI	Kubernetes RBAC and namespaces
Helm	Renders charts into manifests	Native Helm releases via controller
Learning curve	Easy to start, UI helps	Very Kubernetes-native, steeper for beginners
Best fit	Teams wanting visibility and self-service	Platform teams wanting composable automation

How I structure the repos

Whichever tool you pick, repository structure matters more than the tool. A common layout:

platform-gitops/
  clusters/
    prod-eu/
    prod-us/
    staging/
  infrastructure/      # cert-manager, gateway, monitoring, policies
    base/
    overlays/
  apps/
    shop/
      base/
      overlays/
        staging/
        prod/

Some principles that help:

Separate app code from deployment config. The app repo builds images; the GitOps repo says which version runs where.
Use overlays (Kustomize) or values files (Helm) per environment, not copied folders.
Keep secrets out of Git, or encrypted (SOPS) or referenced via External Secrets.

Moving changes through environments

The tricky part of GitOps isn't deploying. It's promotion: moving a version from dev to staging to production in a controlled way. Updating a YAML file in three places by hand gets old quickly.

Options:

Pull requests per environment, opened by CI after each successful stage.
Flux image automation or Argo CD Image Updater for automatic tag updates in lower environments.
Kargo, a newer project from the Argo ecosystem team, built specifically for GitOps promotion across stages with verification steps in between.

So, which one?

If your developers will interact with deployments directly and value seeing what's going on, Argo CD. If your platform team wants composable, Kubernetes-native building blocks and is happy with CLIs, Flux. If you can't decide: try both on a test cluster for a week. The one your team reaches for naturally is the right one.

My take: the best GitOps tool is the one your team actually understands. Pick one, structure your repos well, and the rest follows.

— Desly

GitHub Actions, GitLab CI or Jenkins in 2026?

Tue, 20 Oct 2026 23:10:30 +0200

"Which CI tool should we use?" is one of the most common questions I get from smaller teams. The honest answer is usually "the one that lives next to your code". But there's more nuance than that, especially if you're sitting on a decade-old Jenkins server and wondering whether it's time to move.

Here's how the three big options compare today.

GitHub Actions

If your code is on GitHub, Actions is the default, and for good reasons.

Good at: - Zero setup. Add a YAML file to .github/workflows and it runs. - Huge marketplace of reusable actions for almost everything. - Tight integration with pull requests, checks, environments, deployments and security features. - OIDC to all major clouds, so no long-lived secrets. - Reusable workflows for sharing pipelines across many repositories.

Watch out for: - Third-party action risk. Supply chain attacks on popular actions are real. Pin to SHAs. - Cost at scale. Hosted runner minutes add up for private repositories with heavy pipelines. Self-hosted runners help. - YAML sprawl across hundreds of repositories if you don't standardise with reusable workflows.

GitLab CI

If your code is on GitLab, GitLab CI is equally natural, and arguably more complete as a platform.

Good at: - All-in-one platform. Repos, CI/CD, container registry, package registry, security scanning, environments and issues in one product. - Mature pipeline features: parent-child pipelines, DAG dependencies, merge trains, rules. - Self-hosting is well supported, important for regulated or air-gapped environments. - CI/CD components and a catalog for reusable pipeline building blocks.

Watch out for: - Many advanced security and compliance features are in paid tiers. - Self-hosting a large GitLab instance is real operational work.

Jenkins

Jenkins is the veteran. It's been around since 2011 (and before that as Hudson), and it still runs a huge share of the world's pipelines.

Good at: - Ultimate flexibility. If something can be scripted, Jenkins can run it. - Plugins for everything, including very old and very unusual systems. - Completely self-hosted and free, with full control. - Works with any Git host, or none.

Watch out for: - Maintenance burden. Plugins, upgrades, security patches, controller backups. Jenkins needs a caretaker. - Plugin hell. Plugins break each other, get abandoned, or have vulnerabilities. - Configuration drift unless you use Jenkinsfiles and Configuration as Code consistently. - Harder to hire for in some markets. Fewer newcomers want to learn Groovy pipelines.

Jenkins isn't bad. It's just a pet in a world that has learned to prefer cattle.

Is Jenkins still worth it?

For a new project: rarely. Unless you have unusual requirements, the integrated tools are easier, safer and cheaper to run.

For an existing Jenkins setup: it depends. If it's well-maintained, uses Jenkinsfiles, and supports systems the newer tools struggle with (legacy builds, special hardware, mainframes), there's no urgent reason to move. If it's a fragile server nobody dares to upgrade, with configuration clicked together in the UI, migration is probably worth it.

Others worth knowing

Azure Pipelines (Azure DevOps): solid, especially for Microsoft-heavy shops.
CircleCI, Buildkite: strong on performance; Buildkite runs agents on your own infrastructure.
Tekton: Kubernetes-native building blocks for CI/CD, often used inside platforms rather than directly.
Dagger: pipelines written in real code that run on any CI. More on that in a separate post.

Cost

Rough rules of thumb:

Public open-source projects: GitHub Actions is generous and usually the cheapest.
Small private teams: hosted runners on GitHub or GitLab are simplest. Watch your minutes.
Heavy pipelines at scale: self-hosted or ephemeral runners on your own cloud account often cut costs significantly.
Jenkins is free to license, not free to run. Count the engineering time.

Moving between them

Migrations are mostly about translating concepts:

Jobs, stages and steps map fairly directly between tools.
Secrets and credentials need re-creating, and it's a great moment to switch to OIDC.
Plugins and actions are the hard part: find equivalents, or replace them with simple scripts.
GitHub provides Actions Importer to help convert from Jenkins, GitLab, Azure DevOps and others.
Migrate one pipeline at a time, starting with a simple, active project.

My pick, by team size

Small team, code on GitHub: GitHub Actions. Don't overthink it.
Small team, code on GitLab: GitLab CI.
Mid-size company: whichever matches your Git host, with reusable workflows or components, and self-hosted runners for heavy jobs.
Large or regulated enterprise: GitLab (self-hosted) or GitHub Enterprise, possibly keeping Jenkins for specific legacy workloads while new work moves.

My take: CI should live next to your code and need as little babysitting as possible. In 2026, that rarely means a Jenkins server under someone's desk.

— Desly

Terraform or OpenTofu?

Tue, 20 Oct 2026 23:10:30 +0200

For about a decade, the question "which tool should we use for infrastructure as code?" had a boring answer: Terraform. Then, in 2023, things got interesting. Today there are two tools that look almost identical, share most of their history, and come from very different places.

If you're starting a new project or thinking about switching, here's how I see it.

How we got here

August 2023: HashiCorp changed Terraform's license from the open-source Mozilla Public License (MPL) to the Business Source License (BSL). In short: you can still use Terraform freely, but you can't build a competing commercial product on it. Many companies and community members felt this broke the promise of an open tool that thousands had contributed to.

September 2023: A group of companies forked the last open-source version. The fork became OpenTofu and joined the Linux Foundation, later becoming a CNCF project.

2024–2025: IBM announced it would acquire HashiCorp, and completed the acquisition in early 2025. Terraform is now an IBM product.

Since then, both tools have released new versions, and they've started to grow apart.

What's different now

The core is still very similar. Both use HCL, the same provider ecosystem, the same state format (mostly), and the same init, plan, apply workflow. Your existing code generally works in both.

But each has features the other doesn't, or implements differently.

OpenTofu highlights: - State encryption built in. Your state file, which often contains secrets, can be encrypted client-side with keys from a KMS. - Early variable evaluation: variables and locals can be used in places like module sources and backend configuration. - for_each on providers, making multi-region and multi-account setups much cleaner. - A community-driven roadmap, where many long-requested features from the Terraform issue tracker landed.

Terraform highlights: - Terraform Stacks for managing many related configurations and deployments together, tied to HCP Terraform. - Ephemeral resources and values, keeping secrets out of state and plan files. - Deep integration with HCP Terraform (the managed service) and the wider HashiCorp and IBM tooling. - Commercial support from a large vendor, which matters to some enterprises.

The code you write is still almost the same. The question is really about license, governance and which features you need.

The license question, honestly

For most companies that simply use Terraform to manage their own infrastructure, the BSL changes nothing in practice. You can keep using it for free.

It matters if:

You build a product or service that competes with HashiCorp's offerings.
Your company has a policy of only using OSI-approved open-source software.
You care about the long-term governance: a vendor-controlled tool versus a foundation-governed one.

Switching, step by step

Moving from Terraform to OpenTofu is usually straightforward, especially from Terraform 1.5 or earlier:

Back up your state.
Install OpenTofu and run tofu init in a test configuration.
Run tofu plan. If it shows no changes, you're compatible.
Check providers: OpenTofu uses its own registry, which mirrors the common providers.
Update CI to use the tofu binary.
Avoid using new features of one tool until you've decided, so you can still switch back.

The further both tools diverge, the harder moving between them becomes. Using Terraform Stacks or OpenTofu's state encryption ties you to that tool.

Where each one is heading

Terraform is focused on enterprise workflows: HCP Terraform, Stacks, integrations with IBM's portfolio, and policy and governance features.

OpenTofu is focused on community-requested features, openness, and being a neutral foundation for the ecosystem. Several infrastructure automation platforms (like Spacelift, env0, Scalr and Harness) support it actively.

Both look healthy. Neither is going away soon.

Which one I'd pick

New project, no strong vendor ties: I'd lean towards OpenTofu. Open governance, useful features like state encryption, and full compatibility with the ecosystem.
Already deep in HCP Terraform or HashiCorp's enterprise tools: stay with Terraform. Switching costs more than it saves.
Existing Terraform setup, no problems: no urgency. Keep your code compatible with both for now, and decide when a feature or policy makes the choice for you.

My take: the HCL you write matters more than the binary that runs it. Keep your code clean and portable, and the choice stays yours.

— Desly

Is Ansible still worth learning?

Tue, 20 Oct 2026 23:10:30 +0200

Ten years ago, Ansible was everywhere. Configuration management was the heart of DevOps: Puppet, Chef, Salt and Ansible battled for servers. Then containers arrived, immutable infrastructure became fashionable, Terraform took over provisioning, and Kubernetes took over running applications.

People keep asking me: is Ansible still worth learning in 2026? My answer is yes, but for different reasons than before.

Where it fits today

Think of the layers of modern infrastructure:

Terraform / OpenTofu: creates infrastructure. Networks, VMs, databases, clusters.
Kubernetes: runs containerised applications.
Ansible: configures things and runs procedures. Operating systems, network devices, software that isn't containerised, and multi-step operational tasks.

There's still a lot of that third category. Not everything runs in containers, and not every server is cattle.

What it's still great at

Configuring operating systems. Hardening Linux servers, managing users and SSH keys, installing agents, configuring time sync and logging. Especially in on-premises environments, VMs that live for years, or bare metal.

Network automation. This is where Ansible is arguably stronger than ever. Switches, routers, firewalls and load balancers from Cisco, Juniper, Arista, F5, Palo Alto and many more have Ansible collections. Network teams use it heavily.

Day-2 operations. Rolling restarts, patching servers in batches, rotating certificates on old systems, running the same command across a hundred machines. The "orchestration of procedures" that doesn't fit Terraform's declarative model.

Bootstrapping. Preparing machines before Kubernetes or another platform takes over, like building a homelab or an on-prem cluster.

Legacy and hybrid environments. Most companies have them, and they need automating too.

Terraform builds the house, Kubernetes runs the apps inside, and Ansible is still the handyman who fixes everything else.

Why people like it

Agentless. It connects over SSH (or WinRM, or APIs). Nothing to install on the managed machines.
YAML playbooks that are fairly easy to read, even for people who aren't programmers.
Huge collection of modules for almost any system.
Idempotent modules: running a playbook twice gives the same result.

A simple playbook:

- name: Harden web servers
  hosts: web
  become: true
  tasks:
    - name: Ensure unattended upgrades are installed
      ansible.builtin.apt:
        name: unattended-upgrades
        state: present

    - name: Disable SSH password login
      ansible.builtin.lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^#?PasswordAuthentication'
        line: 'PasswordAuthentication no'
      notify: Restart ssh

  handlers:
    - name: Restart ssh
      ansible.builtin.service:
        name: ssh
        state: restarted

Event-Driven Ansible

A newer addition worth knowing: Event-Driven Ansible lets you trigger playbooks automatically from events, like a monitoring alert, a webhook or a message on a queue. For example: when a disk-full alert fires, run a playbook that cleans up old logs and opens a ticket.

It's a nice bridge between observability and automation, especially in traditional IT environments.

Good habits

If you use Ansible, use it well:

Roles and collections for reusable, shareable code instead of giant playbooks.
Inventory from your cloud (dynamic inventory plugins) rather than hand-maintained host lists.
Ansible Vault or an external secret manager for secrets. Never plain text.
ansible-lint in CI.
Molecule for testing roles in containers or VMs before running them against real machines.
Fully qualified module names like ansible.builtin.copy.
Run it from CI or a controller (like AWX or Ansible Automation Platform) for production, not from laptops.

When I wouldn't use it

Provisioning cloud resources: Terraform or OpenTofu is better at tracking state.
Deploying apps to Kubernetes: use Helm, Kustomize and GitOps instead.
Configuring containers: bake configuration into images or use Kubernetes ConfigMaps.

So, should you learn it?

If you work with Linux servers, on-premises infrastructure, network devices or hybrid environments: absolutely. It's quick to learn and immediately useful. If your world is 100% cloud-native Kubernetes, it's a nice-to-have rather than a must.

My take: Ansible isn't the star anymore, but it's still the most practical tool for the messy, real-world parts of infrastructure.

— Desly

Where does your software come from? SBOM, SLSA and signing

Tue, 20 Oct 2026 23:10:30 +0200

When we talk about software security, we usually think about our own code. Is it vulnerable? Did we validate input? But most of what we ship isn't our code. It's open-source libraries, base images, build tools, CI actions, and their dependencies, and their dependencies' dependencies.

Attackers have noticed. Instead of breaking into one company, they target something thousands of companies use. The XZ Utils backdoor found in 2024, the hacked GitHub Action in 2025, and the self-spreading npm worm called Shai-Hulud: all examples of supply chain attacks.

Three ideas have become the foundation of defending against them: SBOMs, signing, and SLSA.

Why this suddenly matters

Three reasons:

Attacks are increasing, and they're getting more sophisticated.
Regulation is arriving. The EU Cyber Resilience Act, US federal requirements and industry standards increasingly expect you to know what's in your software and prove where it came from.
Customers are asking. "Can you provide an SBOM?" is now a standard question in security questionnaires.

SBOMs: an ingredient list for software

A Software Bill of Materials (SBOM) is a list of every component in your software: libraries, versions, licenses, and where they came from. Like the ingredient list on food packaging.

Why it helps: when a new vulnerability like Log4Shell is announced, you can answer "are we affected?" in minutes instead of days, by searching your SBOMs.

The two main formats are CycloneDX and SPDX. Generating one is easy:

syft registry.example.com/shop-api:1.4.2 -o cyclonedx-json > sbom.json
trivy image --format spdx-json -o sbom.spdx.json registry.example.com/shop-api:1.4.2

Generate SBOMs in CI for every release, store them alongside the artifact (or attach them to the image in the registry), and scan them regularly for new vulnerabilities.

An SBOM doesn't make your software secure. It makes your ignorance visible, and that's where security starts.

Signing with Sigstore and Cosign

An SBOM tells you what's inside. Signing tells you who built it and that nobody changed it afterwards.

Sigstore is an open-source project (under the OpenSSF) that made signing practical. Its tool Cosign signs container images and other artifacts. The clever part is keyless signing: instead of managing long-lived private keys, your CI's identity (like a GitHub Actions OIDC token) is used to get a short-lived certificate, and the signature is recorded in a public transparency log.

# In CI, with OIDC available
cosign sign registry.example.com/shop-api@sha256:abc123...

# Anywhere, to verify
cosign verify registry.example.com/shop-api@sha256:abc123... \
  --certificate-identity-regexp "https://github.com/acme/shop-api/.*" \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

The verification says: this exact image was signed by a workflow in the acme/shop-api repository. If someone pushes a different image under the same tag, verification fails.

Verifying at deploy time is where signing really pays off. Admission controllers like Kyverno, Sigstore policy-controller or Connaisseur can block unsigned or wrongly signed images from running in your Kubernetes cluster.

SLSA levels, simply

SLSA (Supply-chain Levels for Software Artifacts, pronounced "salsa") is a framework that describes how trustworthy your build process is. It focuses on provenance: a signed record of how an artifact was built, from which source, by which builder.

Simplified, the build levels are:

Level 1: provenance exists. You document how the artifact was built.
Level 2: provenance is generated and signed by a hosted build platform, not by hand.
Level 3: the build platform is hardened, so builds are isolated and provenance can't be forged even by the project's own maintainers.

GitHub Actions can generate SLSA provenance with artifact attestations (actions/attest-build-provenance), and the slsa-github-generator project provides Level 3 builders. Docker BuildKit can attach provenance to images too.

Putting it together

A practical pipeline:

Build the image in CI (hosted, ephemeral runners).
Generate an SBOM and attach it to the image.
Generate provenance (SLSA attestation).
Sign the image with Cosign, keyless.
Scan the SBOM for vulnerabilities, continuously.
Verify signatures and provenance in the cluster before anything runs.

Each step is a few lines of CI configuration today. A few years ago, this was a research project.

So, where do I start?

Generate SBOMs for your main images this week. Add keyless signing next. Then test signature verification in one non-production cluster. Once that's working, move it to production. You'll be ahead of most companies and ready for the regulations coming your way.

My take: you can't secure what you can't see, and you can't trust what you can't verify. SBOMs give you sight, signatures give you trust.

— Desly

The EU Cyber Resilience Act and DevOps

Tue, 20 Oct 2026 23:10:30 +0200

Living in Germany, I've watched GDPR change how every company handles personal data. The EU Cyber Resilience Act (CRA) is set to do something similar for software security. And unlike many regulations, it lands directly on the things DevOps teams do every day: dependencies, vulnerability handling, updates and build pipelines.

A quick disclaimer before we start: I'm an engineer, not a lawyer. This is my practical reading of what it means for teams. For your company's specific obligations, talk to your legal and compliance people.

What the law says, in plain words

The CRA sets cybersecurity requirements for "products with digital elements" sold in the EU. That covers a lot: software, apps, connected devices, firmware, and many components that end up in other products.

The core idea: if you put software on the EU market, you're responsible for its security for its whole lifetime, not just on release day. That means:

Secure by design and by default: no known exploitable vulnerabilities at release, secure default configuration, protection of data, minimised attack surface.
Vulnerability handling: a process to receive, assess and fix vulnerabilities, and provide security updates for a defined support period (generally at least five years, or the expected product lifetime if shorter).
SBOMs: document the components in your product, at least the top-level dependencies, in a machine-readable format.
Reporting: report actively exploited vulnerabilities and severe incidents to authorities within tight deadlines.
Documentation and conformity: technical documentation, and for most products a self-assessment, with stricter assessment for some critical categories. Compliant products carry the CE marking.

The dates that matter

December 2024: the CRA entered into force.
11 September 2026: reporting obligations apply. Manufacturers must report actively exploited vulnerabilities and severe incidents through ENISA's single reporting platform. Early warning within 24 hours, a fuller notification within 72 hours, and a final report later.
11 December 2027: the rest of the requirements apply, including the essential security requirements and conformity assessment.

So the reporting part is already live. The full set arrives next year.

The CRA turns "we'll patch it eventually" into a legal obligation with a deadline.

What about open source?

This was heavily debated during the drafting. The final text tries to protect open-source developers:

Open-source software developed and shared without commercial activity is generally outside the scope.
A new role, the open-source software steward (for example foundations that support projects used commercially), has lighter obligations.
Companies that use open source in their commercial products are responsible for those components as part of their product. Using a library doesn't shift responsibility to its maintainers.

That final point matters most for most of us: your dependencies are now your responsibility.

What changes in my pipeline

The nice surprise: a lot of what the CRA asks for is what good DevSecOps teams already do, or should. It just becomes mandatory and documented.

SBOM generation for every release (Syft, Trivy, CycloneDX tools), stored and versioned.
Continuous vulnerability scanning of those SBOMs, not just at build time, so newly discovered vulnerabilities in old releases are found.
A vulnerability disclosure policy and a way for researchers to report issues (a security.txt, a security contact, a SECURITY.md).
A defined support period for each product version, and the ability to ship security updates quickly during it.
Signed artifacts and build provenance, to show the integrity of what you ship.
Secure defaults in your products: no default passwords, minimal open ports, encryption on.
An incident and reporting process that can meet a 24-hour deadline for exploited vulnerabilities. Who decides? Who reports? Practise it.
Documentation of all of the above.

A checklist

Find out whether your products are in scope, and in which category (most are in the default, self-assessment category).
Generate and store SBOMs for every release.
Set up continuous vulnerability monitoring of shipped versions.
Publish a vulnerability disclosure policy and security contact.
Define and communicate support periods.
Create a process to report exploited vulnerabilities within 24 hours.
Make security updates easy to deliver, and separable from feature updates where possible.
Document your secure development practices.
Review your dependencies: unmaintained components are a liability now.

So, should DevOps teams care?

Very much. The CRA lands right in our pipelines. The teams that already automate SBOMs, scanning, signing and fast patching will find compliance relatively easy. The teams that don't have about a year to catch up.

My take: the CRA is regulation, but most of it is just good engineering written into law. Build those habits now, and compliance becomes a by-product.

— Desly

No more static passwords between services

Tue, 20 Oct 2026 23:10:30 +0200

Think about how your services authenticate to each other and to the cloud. In many companies, the answer is static credentials. An access key in an environment variable. A shared API token in a config file. A database password copied into five places. They rarely get rotated, and when one leaks, you often don't know where else it's used.

Humans moved past this a while ago: single sign-on, MFA, short-lived sessions. Workloads deserve the same.

The problem with shared secrets

Static credentials have three big weaknesses:

They're long-lived. A leaked key works until someone notices and rotates it, which can be months.
They're copyable. Anyone or anything that gets the key can use it, from anywhere.
They don't say who's calling. Five services sharing one token look identical in the logs.

Zero trust is the idea that nothing should be trusted just because it's inside your network. Every request should prove who it comes from. For workloads, that means giving every service a strong, verifiable identity.

Cloud workload identity

The easiest win: let your workloads authenticate to cloud services using their platform identity instead of keys.

On Kubernetes, every pod runs with a service account. Cloud providers can trust Kubernetes service account tokens and exchange them for short-lived cloud credentials:

AWS: IAM Roles for Service Accounts (IRSA), or the newer EKS Pod Identity.
Google Cloud: Workload Identity Federation for GKE.
Azure: Microsoft Entra Workload ID.

The setup: link a Kubernetes service account to a cloud role. Pods using that service account automatically get temporary credentials, rotated for them, scoped to that role. No secret to store, nothing to leak for long.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: orders
  namespace: shop
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/shop-orders

The same idea works in CI: OIDC federation lets GitHub Actions, GitLab CI and others get cloud credentials without stored keys.

The safest credential is the one that's issued for a few minutes, to one workload, for one job, and then simply expires.

SPIFFE, simply

Cloud workload identity solves "my pod talking to my cloud provider". But what about service-to-service calls, across clusters, clouds and on-premises machines?

SPIFFE (Secure Production Identity Framework For Everyone) is a CNCF standard for workload identity, independent of any platform. It defines:

SPIFFE ID: a unique name for a workload, written as a URI, like spiffe://acme.com/ns/shop/sa/orders.
SVID (SPIFFE Verifiable Identity Document): a short-lived document proving that identity, either an X.509 certificate or a JWT.
Workload API: a local API where workloads fetch their SVIDs, without needing any secret to start with.

SPIRE is the reference implementation. A SPIRE server issues identities, and agents on each node attest workloads: they check what the workload really is (which Kubernetes service account, which node, which process) before handing out an identity. Certificates are rotated automatically, often every hour.

Many tools speak SPIFFE: service meshes like Istio and Linkerd use SPIFFE-style identities internally, and Envoy, Cilium and various databases and proxies can use SVIDs.

mTLS between services

With identities in place, services can use mutual TLS (mTLS): both sides present certificates, so each knows exactly who it's talking to, and the traffic is encrypted.

Doing mTLS by hand in every application is painful. That's why it's usually handled by:

A service mesh (Istio, Linkerd, Cilium), which adds mTLS between all services automatically.
SPIFFE libraries (go-spiffe and others) for applications that handle it themselves.

On top of mTLS, you can write authorisation policies: "only the checkout service may call payments on /charge". That's real zero trust: identity-based access, not network-based.

Where to start

You don't need SPIRE on day one. A practical path:

Replace cloud access keys in Kubernetes with your provider's workload identity.
Replace CI cloud keys with OIDC federation.
Move remaining secrets into a secret manager with short-lived or rotated credentials.
Add mTLS between services, most easily through a service mesh.
Consider SPIFFE/SPIRE when you need one identity system across clusters, clouds and VMs.

So, is it worth the effort?

Yes. Removing static credentials eliminates one of the most common causes of breaches. The first steps, cloud workload identity and CI OIDC, are surprisingly easy and give immediate benefit.

My take: services should prove who they are every time, with credentials that expire before anyone can misuse them. Passwords are for humans, and even we're giving them up.

— Desly

When npm turns against you

Tue, 20 Oct 2026 23:10:30 +0200

A modern JavaScript project easily has over a thousand dependencies, most of them indirect. Python, Go, Rust and Java projects aren't far behind. Every one of those packages is code written by someone you've never met, running on your laptop and in your CI with access to your secrets.

For years that trust mostly worked. Recently, attackers have shown just how fragile it is.

Recent attacks

Without going into every incident, the pattern of the last couple of years is clear:

Hijacked maintainer accounts. In September 2025, attackers phished maintainers of very popular npm packages and published malicious versions of libraries downloaded billions of times per week. The code tried to steal cryptocurrency from users.
Self-spreading worms. Also in 2025, a worm nicknamed Shai-Hulud spread through npm: once installed, it stole tokens from the developer's machine or CI, and used them to publish infected versions of other packages that person maintained. Hundreds of packages were affected.
Compromised build tooling. Attackers have inserted code that searched developers' machines for secrets, and even used AI command-line tools installed locally to help find them.
Typosquatting and slopsquatting. Packages with names one letter away from popular ones, or names AI assistants tend to invent.
Long-game attacks like the XZ Utils backdoor, where an attacker spent years gaining a maintainer's trust.

What these have in common: they don't exploit a bug in your code. They exploit the trust you place in your dependencies.

Installing a package is running a stranger's code with your credentials. We just stopped thinking about it that way.

Lockfiles and private registries

The basics matter most:

Commit lockfiles (package-lock.json, pnpm-lock.yaml, poetry.lock, uv.lock, go.sum) and install with them strictly: npm ci instead of npm install in CI. That way, a new malicious version can't sneak in during a build.
Use a private registry or proxy (Artifactory, Nexus, GitHub Packages, AWS CodeArtifact, Google Artifact Registry). It caches approved packages, can block known-bad ones, and gives you a single place to control what comes in.
Scope internal packages (like @acme/...) and configure your package manager so internal names can only come from your registry. That prevents dependency confusion, where an attacker publishes a public package with the same name as your internal one.

Waiting before installing new versions

Most malicious package versions are detected and removed within hours or days. So a simple but powerful defence: don't install brand-new versions immediately.

Renovate's minimumReleaseAge waits a configurable time (for example three days) before proposing an update.
pnpm supports a minimum release age setting, so it won't resolve versions younger than the threshold.
Some registries and proxies support similar quarantine periods.

You lose a few days on new features. You gain protection against most "publish and hope" attacks.

Limiting what install scripts can do

Many attacks run during installation, through postinstall scripts.

Disable install scripts by default where possible (npm config set ignore-scripts true, pnpm's stricter defaults for dependency build scripts) and allow them only for packages that genuinely need them.
Run builds in isolated, ephemeral environments: a fresh container or CI runner per job, without long-lived credentials lying around.
Restrict network egress from CI where you can. A build that can't reach an unknown server can't send your secrets there.
Never keep publish tokens on developer machines if you can avoid it. Use trusted publishing from CI (npm and PyPI both support OIDC-based publishing), and require 2FA for maintainers.

Tools that warn me

Socket: analyses packages for suspicious behaviour (install scripts, network access, obfuscated code, new maintainers), not just known vulnerabilities.
OSV-Scanner, Trivy, Grype, npm audit: known vulnerabilities and known malicious packages.
OpenSSF Scorecard: rates how well a project follows security practices before you adopt it.
GitHub's dependency review to see new dependencies and their risks in pull requests.

And a non-tool: question new dependencies. Does this project really need a package for left-padding a string? Every dependency you don't add is one you never have to worry about.

If you were affected

When a compromised package hits your stack:

Find where it was installed (SBOMs and lockfiles make this fast).
Assume any secrets accessible during install are compromised: rotate them.
Check CI logs and machines for signs of the malicious behaviour.
Pin to a known-good version and rebuild.

So, where do I start?

Strict lockfile installs in CI, a minimum release age for updates, a private proxy registry, and no long-lived publish tokens. Those four measures would have blunted most of the recent attacks.

My take: dependencies are a gift from the open-source world. Accept them gratefully, but check what's inside before you open them in production.

— Desly

Quantum computers and today's encryption

Tue, 20 Oct 2026 23:10:30 +0200

Every few months there's a headline: "Quantum computer breaks encryption!" Usually, if you read past the headline, it's a research result on a tiny problem. Today's quantum computers are nowhere near breaking the encryption that protects the internet.

So why should DevOps engineers care now? Because the migration to quantum-safe cryptography is one of the biggest infrastructure changes of the next decade, and parts of it are already happening in the tools we use every day.

The problem in plain words

Most of the internet's security relies on public-key cryptography: RSA and elliptic curve algorithms. They're used in TLS (HTTPS), SSH, VPNs, code signing, certificates and much more. Their security rests on maths problems that are extremely hard for normal computers.

A large enough, stable quantum computer running Shor's algorithm could solve those problems efficiently. That would break RSA and elliptic curve cryptography.

Symmetric encryption like AES and hash functions like SHA-256 are much less affected. Longer keys (AES-256) are considered safe.

Nobody knows exactly when such a quantum computer will exist. Estimates range from several years to decades. But "we don't know when" is not the same as "we don't need to worry".

"Harvest now, decrypt later"

Here's the reason to act now. An attacker can record encrypted traffic today and store it. When a capable quantum computer exists, they decrypt it.

If your data needs to stay secret for ten or twenty years, like health records, financial data, government data, trade secrets or personal communications, it may already be at risk from traffic being recorded today.

That's why the focus right now is on key exchange: the part of TLS and other protocols that protects the session keys.

The data you send today needs to be safe from the computers of tomorrow.

The new standards

In August 2024, the US National Institute of Standards and Technology (NIST) published the first post-quantum cryptography standards, after years of public competition and analysis:

ML-KEM (FIPS 203, formerly known as CRYSTALS-Kyber): for key exchange / encapsulation.
ML-DSA (FIPS 204, formerly CRYSTALS-Dilithium): for digital signatures.
SLH-DSA (FIPS 205, formerly SPHINCS+): a hash-based signature scheme, as a conservative backup.

More algorithms are in progress. European agencies like Germany's BSI broadly align on these, with their own recommendations, often favouring hybrid approaches.

What's already supported

The good news: you might already be using post-quantum cryptography without knowing it.

Browsers: Chrome, Firefox and Safari support hybrid key exchange (X25519 combined with ML-KEM) in TLS 1.3.
CDNs and large providers: Cloudflare and others enable hybrid post-quantum key exchange by default, and a large share of their traffic already uses it.
OpenSSL 3.5 added support for ML-KEM, ML-DSA and SLH-DSA.
OpenSSH has used hybrid post-quantum key exchange by default for some time, and recent versions default to an ML-KEM-based hybrid.
Go, Java, BoringSSL and other libraries have added support.

"Hybrid" means combining a classical algorithm with a post-quantum one, so the connection is safe as long as either one holds. That protects against both quantum attacks and the risk that a new algorithm turns out to have weaknesses.

Crypto agility: what DevOps teams should do

The biggest lesson from past migrations (SHA-1 to SHA-256, TLS 1.0 to 1.2) is that they take years, mostly because nobody knows where all the crypto lives. So start there:

Make an inventory. Where do you use cryptography? TLS endpoints, internal mTLS, SSH, VPNs, certificates, code signing, encrypted storage, tokens, third-party libraries. Tools that scan certificates and TLS configurations help.
Prioritise long-lived secrets. What data needs to stay confidential for many years? That traffic should move to hybrid key exchange first.
Keep software up to date. Most post-quantum support arrives through library, OS, load balancer and runtime updates. Old software is the biggest blocker.
Prefer TLS 1.3 everywhere. Post-quantum key exchange is built for it.
Build crypto agility. Avoid hardcoded algorithms. Make it possible to change algorithms through configuration, not code rewrites.
Ask your vendors about their post-quantum roadmap: cloud providers, load balancers, HSMs, VPNs, certificate authorities.
Watch certificates. Post-quantum signatures in public certificates will come later and bring larger certificates and handshakes. Test performance when the time comes.

So, should you panic?

No. Your HTTPS isn't broken. But this is a slow, multi-year migration, and the teams that start with an inventory and up-to-date software will have a much easier time than those who wait for a deadline.

My take: quantum computers aren't here yet, but the migration is. Know where your crypto lives, keep your stack current, and let hybrid key exchange do the rest.

— Desly

SLOs: deciding how reliable is reliable enough

Tue, 20 Oct 2026 23:10:30 +0200

Ask any manager how reliable a service should be, and the answer is usually "100%". It sounds right. Who wants downtime?

But 100% is impossible, and chasing it is incredibly expensive. Every extra "nine" of availability costs more than the last. And your users can't tell the difference between 99.99% and 100%, because their own Wi-Fi, phone and ISP fail far more often than that.

Service Level Objectives (SLOs) are a way to decide, on purpose, how reliable is reliable enough.

SLIs, SLOs, error budgets, simply

SLI (Service Level Indicator): a measurement of how your service is doing, from the user's point of view. For example: the percentage of HTTP requests that succeed, or the percentage served in under 300 ms.

SLO (Service Level Objective): a target for that indicator over a time window. For example: 99.9% of requests succeed, measured over 30 days.

Error budget: the amount of failure the SLO allows. With a 99.9% target over 30 days, you can afford 0.1% failed requests, or roughly 43 minutes of full downtime.

SLA (Service Level Agreement): a contract with customers, usually with financial consequences. SLAs should be looser than your internal SLOs, so you notice problems before you owe anyone money.

Why error budgets are so useful

The error budget turns reliability from an argument into a shared number.

Budget left? The team can ship features, experiment, take reasonable risks.
Budget almost gone? Slow down, focus on reliability, postpone risky changes.
Budget exhausted? Freeze risky deployments and fix what's causing the failures.

Product and engineering stop arguing about "should we work on reliability or features?" The budget answers it.

An SLO isn't a promise that nothing breaks. It's an agreement about how much breaking is acceptable, and what we'll do when we go over.

Picking good SLIs

Good SLIs measure what users actually experience:

Availability: proportion of successful requests (non-5xx responses).
Latency: proportion of requests faster than a threshold.
Freshness: for data pipelines, how recent the data is.
Correctness: for some systems, whether results are right.

Measure as close to the user as possible: at the load balancer or gateway rather than deep inside the service. Avoid SLIs like "CPU below 80%": users don't care about CPU.

Picking a target

Some practical advice:

Start with your current performance. If you're at 99.5% today, a 99.99% SLO is fantasy. Set something achievable, then tighten it.
Different services, different targets. Checkout might need 99.95%. An internal report generator might be fine with 99%.
Consider dependencies. Your service can't be more reliable than the things it depends on, unless you design for their failures.
Use a 28 or 30-day rolling window to start.

SLO	Allowed downtime per 30 days
99%	about 7 hours 12 minutes
99.5%	about 3 hours 36 minutes
99.9%	about 43 minutes
99.95%	about 22 minutes
99.99%	about 4 minutes

Looking at this table usually ends the "100%" conversation quickly.

Alerting on burn rate

SLOs also make alerting much better. Instead of alerting on CPU or individual errors, alert on how fast you're burning the error budget.

Fast burn: at the current rate, you'll use the whole month's budget in hours. Page someone now.
Slow burn: you'll use it up in days. Create a ticket, look at it during working hours.

The Google SRE Workbook recommends multi-window, multi-burn-rate alerts, for example: page if you've burned 2% of the monthly budget in the last hour (and the last five minutes confirm it's still happening). That catches real incidents quickly and ignores short blips.

Tools that help

Writing these Prometheus rules by hand is tedious and error-prone. Tools generate them from a simple SLO definition:

Sloth: generates Prometheus recording and alerting rules from an SLO spec.
Pyrra: similar, with a nice UI showing budgets and burn rates.
OpenSLO: a vendor-neutral specification for defining SLOs as code.
Most commercial observability platforms (Datadog, Grafana Cloud, Honeycomb, Nobl9 and others) have SLO features built in.

# Sloth example
version: "prometheus/v1"
service: "shop-api"
slos:
  - name: "requests-availability"
    objective: 99.9
    sli:
      events:
        error_query: sum(rate(http_requests_total{job="shop-api",code=~"5.."}[{{.window}}]))
        total_query: sum(rate(http_requests_total{job="shop-api"}[{{.window}}]))
    alerting:
      page_alert:
        labels:
          severity: critical

So, where do I start?

Pick your most important user-facing service. Define one availability SLI and one latency SLI. Set targets based on the last month's real data. Add burn-rate alerts, show the budget on a dashboard, and review it as a team every couple of weeks.

My take: perfection isn't the goal. Knowing exactly how imperfect you can afford to be, and acting on it, is.

— Desly

eBPF: seeing inside Linux without touching your code

Tue, 20 Oct 2026 23:10:30 +0200

If you follow cloud-native tooling, you've seen "eBPF" everywhere. Cilium uses it for networking. Falco and Tetragon use it for security. Pixie, Grafana Beyla and others use it for observability. Cloud providers use it under the hood of their Kubernetes networking.

But what actually is it, and why does it matter for DevOps engineers who'll never write kernel code?

eBPF, simply

The Linux kernel sees everything: every network packet, every file opened, every process started, every system call. Traditionally, if you wanted to hook into that, you had two bad options: change the kernel itself (slow, risky, takes years to reach users) or write a kernel module (powerful, but one bug can crash the whole machine).

eBPF (originally "extended Berkeley Packet Filter", now just a name) is a third option. It lets you run small, sandboxed programs inside the kernel, safely, without changing kernel code or loading modules.

Before an eBPF program runs, the kernel's verifier checks it: it must terminate, it can't access memory it shouldn't, it can't crash the system. Then it's compiled to native code and runs extremely fast.

These programs attach to hooks: network events, system calls, function entries and exits in the kernel or even in applications. When the event happens, the program runs, collects data or makes a decision, and shares results with normal programs in user space.

eBPF turns the Linux kernel into a programmable platform, safely, without rebooting and without changing a line of your application.

Why it matters for DevOps

You probably won't write eBPF programs yourself. But you'll use tools built on it, and understanding what they do helps you choose and debug them.

The big advantages:

No code changes. Observe applications in any language without adding libraries or agents to them.
Low overhead. Runs in the kernel, very efficiently.
Complete visibility. Sees everything happening on the node, including things applications don't log.
Can enforce, not just observe. Drop packets, block system calls, kill processes.

The tools built on it

Networking: - Cilium: a Kubernetes CNI that uses eBPF instead of iptables for routing, load balancing and network policies. Faster and more scalable with many services, and adds features like identity-aware policies and transparent encryption. It's a CNCF graduated project and the default networking for several managed Kubernetes offerings. - Hubble: Cilium's observability layer, showing which services talk to which, with flow logs and a service map.

Security: - Falco: detects suspicious behaviour, like a shell opened inside a container or unexpected file access. - Tetragon: from the Cilium project, observes and can enforce security policies at the kernel level, for example killing a process that tries to read a sensitive file.

Observability: - Grafana Beyla: auto-instruments HTTP and gRPC services with eBPF and produces OpenTelemetry metrics and traces, without touching the application. (Its core has been contributed to the OpenTelemetry project as the eBPF instrumentation effort.) - Pixie: instant visibility into Kubernetes clusters, including request-level data, without instrumentation. - Parca and Pyroscope: continuous profiling using eBPF, showing which functions use CPU across all processes. - bpftrace and BCC tools: for hands-on Linux performance analysis.

Zero-instrumentation tracing

One of the most exciting uses: getting request metrics and basic traces from applications nobody wants to touch. Legacy services, third-party binaries, apps in languages without good OpenTelemetry support.

An eBPF-based tool watches network calls and certain functions, recognises HTTP and gRPC requests, and creates RED metrics (rate, errors, duration) and spans automatically. It's not as detailed as proper in-code instrumentation, but it gives you a solid baseline for everything, from day one.

Trying it yourself

The easiest way to feel eBPF's power on a Linux machine is bpftrace:

# Show every new process being started, system-wide
sudo bpftrace -e 'tracepoint:syscalls:sys_enter_execve { printf("%s -> %s\n", comm, str(args->filename)); }'

Run it and open a terminal: you'll see every command as it starts. That's the kernel talking to you directly.

Limitations

Kernel version matters. Modern features need reasonably recent kernels (5.x and newer, ideally 5.10+ or 6.x). Old enterprise Linux versions can be a problem.
Privileges. eBPF tools usually need elevated permissions on the node. Trust the tools you install.
Linux only, mostly. Windows has an eBPF implementation in progress, but the ecosystem is Linux-first.
Encrypted traffic is harder to inspect, though tools can hook into TLS libraries in some cases.
Debugging eBPF itself can be tricky when things go wrong.

So, should you care?

Yes, even if you never write a line of eBPF. It's quietly becoming the foundation of Kubernetes networking, runtime security and modern observability. Knowing what it is helps you understand why Cilium is faster, how Falco sees inside containers, and how tools can trace your apps without touching them.

My take: eBPF is the most important Linux technology most people never see. Learn what it does, and a lot of modern tooling suddenly makes sense.

— Desly

Alerts that deserve to wake you up

Tue, 20 Oct 2026 23:10:30 +0200

The worst kind of on-call shift isn't the one with a big outage. It's the one with forty small alerts, none of which needed anything. Disk at 81%. CPU spike that resolved itself. A pod restarted once. You acknowledge them half asleep, and by morning you're exhausted and nothing was actually wrong.

Do that for a few months, and people start ignoring alerts. Then the real one gets ignored too.

Good alerting is a design discipline. Here are the rules I follow.

Rule 1: every page needs a human action, now

Before creating any alert that pages someone, ask:

Does this need a human to do something?
Does it need to happen now, or can it wait until working hours?
Will the person receiving it know what to do?

If the answer to any of these is no, it shouldn't be a page. It can be a ticket, a chat message, a dashboard, or nothing.

A useful split:

Page: user-facing impact happening or imminent. Wake someone up.
Ticket: needs fixing, but not tonight. A disk filling slowly, a certificate expiring in two weeks.
Dashboard / log: useful context, no action needed.

An alert that doesn't need action isn't an alert. It's noise with a phone number.

Rule 2: alert on symptoms, not causes

Symptoms are what users experience: errors, slowness, unavailability. Causes are what might lead there: high CPU, a pod restart, a full queue.

Alert on symptoms. High CPU isn't a problem if requests are fast. A restarted pod isn't a problem if users didn't notice. But a 5% error rate on checkout is a problem regardless of what caused it.

Causes still matter, as context on dashboards, or as tickets when they predict future problems (like a disk that will be full in three days).

The best symptom alerts are based on SLOs and burn rates: page when the error budget is burning fast enough to matter.

Rule 3: group and route sensibly

One problem shouldn't produce twenty notifications. In Prometheus Alertmanager (and most alerting tools):

Grouping: combine related alerts (same service, same cluster) into one notification.
Inhibition: if a whole cluster is down, suppress the hundreds of service alerts it causes.
Routing: send alerts to the team that owns the service, with different channels for different severities.
Silences: mute alerts during planned maintenance.

route:
  receiver: default
  group_by: ["alertname", "cluster", "service"]
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  routes:
  - matchers: [severity="critical"]
    receiver: pagerduty-oncall
  - matchers: [severity="warning"]
    receiver: team-chat

inhibit_rules:
- source_matchers: [alertname="ClusterDown"]
  target_matchers: [severity=~"warning|critical"]
  equal: ["cluster"]

For the paging layer, tools like PagerDuty, incident.io, Grafana OnCall (and Grafana's IRM features), Opsgenie alternatives and others handle schedules, escalation and acknowledgement. (Atlassian announced Opsgenie's end of sale, so teams using it are moving elsewhere.)

Rule 4: a runbook for every alert

When an alert fires at 3 a.m., the person on call might not know that service well. Every alert should link to a runbook:

What does this alert mean?
How bad is it? Who's affected?
How do I check what's going on? (Links to dashboards, queries.)
What are the common fixes?
Who do I escalate to?

Put the runbook link directly in the alert annotations. If you can't write a runbook for an alert, that's a strong sign the alert isn't actionable.

Rule 5: review alerts regularly

Alerts rot. Services change, thresholds become wrong, owners move on. A monthly alert review with the on-call team works wonders:

Which alerts fired most often?
Which led to action? Which were ignored?
Which incidents were not caught by an alert?
Delete, tune or downgrade the noisy ones. Add missing ones.

Track a few numbers over time: pages per shift, pages outside working hours, and the actionability rate (percentage of pages that needed action).

A few more tips

Use for: durations so short blips don't page: for: 5m on most alerts.
Test your alerts: do they actually fire? Alertmanager's routing tree can be tested, and Prometheus rules can be unit tested with promtool.
Alert on the alerting pipeline: a "dead man's switch" alert that always fires, so you notice if alerting itself breaks.
Don't page on predictions alone unless they're very reliable.

So, where do I start?

List every alert that paged someone last month. For each, ask: did it need action, right then? Downgrade or delete the ones that didn't. You'll likely remove half of them, and nobody will miss them.

My take: protect your on-call engineers' sleep like it's a production system. Because it is.

— Desly

When things break: incidents and blameless postmortems

Tue, 20 Oct 2026 23:10:30 +0200

Every system breaks eventually. What separates good teams from struggling ones isn't whether they have incidents. It's how they handle them: calmly or chaotically, and whether they learn something afterwards or just move on and wait for the next one.

Here's the incident process I prefer, and how to write postmortems that actually improve things.

Before the incident: decide how you'll work

Incidents are stressful. Stress makes people bad at improvising. So decide the basics in advance:

Severity levels, with clear examples.
Who declares an incident, and how (a chat command, a button, a phone call).
Where people gather: a dedicated chat channel per incident, plus a call if needed.
Roles, so everyone knows who does what.
Communication templates, so updates go out quickly and consistently.

A simple severity scale:

Severity	Meaning	Example
SEV1	Major impact on many users or core business	Checkout down for everyone
SEV2	Significant impact, workaround exists or partial outage	Payments failing for one provider
SEV3	Minor impact, limited users	A non-critical feature broken

When in doubt, declare higher. It's easy to downgrade.

Who does what in an incident

The most important role is the Incident Commander (IC). The IC doesn't fix the problem. They coordinate: make sure the right people are involved, decisions are made, and nothing falls through the cracks.

Other common roles:

Operations / subject matter experts: the people actually investigating and fixing.
Communications lead: writes updates for stakeholders and customers, so the engineers can focus.
Scribe: keeps a timeline of what happened and what was decided. (AI tools increasingly help here.)

In a small team, one person might take on multiple roles. That's fine, as long as someone is clearly in charge.

In an incident, the most dangerous situation is five smart people all fixing things at once, without anyone knowing what the others changed.

During the incident

A few habits that make a big difference:

Mitigate first, investigate later. Roll back, fail over, scale up, turn off the feature flag. Find the root cause once users are okay.
Say what you're doing before you do it: "I'm going to restart the payment workers now." It avoids conflicting actions.
Write things down in the channel: observations, hypotheses, actions, results.
Regular updates, even when there's nothing new: "Still investigating, next update in 30 minutes."
Know when to escalate. Pulling in another team early is better than struggling alone for an hour.

A simple status update template:

[SEV2] Payment failures, investigating. Since 14:05 CET, around 10% of card payments fail. Other payment methods work. We're investigating a possible issue with our payment provider. Next update by 14:45.

After the incident: blameless postmortems

A postmortem is a written analysis of what happened and how to prevent it. Blameless means the focus is on the system, not on who made a mistake.

Why blameless? Because people make mistakes all the time, and systems should be designed to handle that. If the takeaway from an incident is "Alex should have been more careful", nothing changes, except that people start hiding mistakes. If the takeaway is "our deploy process let an untested config reach production without a check", you can fix the process.

Questions to ask:

What made this mistake easy to make?
Why didn't our tests, reviews or monitoring catch it?
What made it hard to detect, diagnose or fix?
What went well? (Always include this.)

My postmortem template

Summary: two or three sentences a manager could understand.
Impact: who was affected, how, for how long. Numbers if possible.
Timeline: key events with timestamps, from the trigger to full resolution.
Root cause and contributing factors: usually several things combined, not one single cause.
Detection: how did we find out? How could we have found out sooner?
Response: what helped, what slowed us down.
What went well.
Action items: specific, with an owner and a due date.
Lessons learned.

Making sure action items happen

The most common failure of postmortems: great analysis, a list of action items, and then nothing happens. Fixes compete with feature work and lose.

What helps:

Few, important action items instead of a long wish list.
Tracked in the normal backlog, not a separate document.
Reviewed regularly, for example in a monthly reliability meeting.
Leadership support, so fixing the cause of an incident is considered real work.

Tools that help

incident.io, Rootly, FireHydrant, PagerDuty, Jira Service Management and others automate the process: creating channels, assigning roles, keeping timelines, posting status updates and generating postmortem drafts. Useful, but the process and culture matter more than the tool.

So, where do I start?

Agree on three severity levels, the incident commander role, and a postmortem template. Run a short practice incident (a "game day") so people know the process before a real one. Then, after the next real incident, write a blameless postmortem and follow through on its actions.

My take: incidents will happen. Handle them calmly, learn from them honestly, and fix the system instead of blaming the person.

— Desly

Multi-cloud: an honest look

Tue, 20 Oct 2026 23:10:30 +0200

"We should be multi-cloud" is one of those statements that sounds smart in a strategy meeting. Avoid lock-in! Better negotiating power! Resilience if a provider goes down! Who could argue with that?

In practice, multi-cloud is often more expensive, more complex and less resilient than people expect. Sometimes it's exactly the right choice. Often it isn't. Here's how I think about it.

What people mean by "multi-cloud"

The term covers very different setups:

Different workloads on different clouds: the data team uses Google Cloud for BigQuery, the main app runs on AWS, Microsoft 365 and some Azure services for IT. This is the most common, and usually happens naturally.
The same application deployable to multiple clouds: portable, but only running on one at a time.
The same application running actively on multiple clouds at once: true multi-cloud active-active. Rare, hard and expensive.

Most companies are in the first category, whether they planned it or not. The debate is usually about the second and third.

Good reasons

Regulation and sovereignty: some customers or countries require specific providers, or a European alternative.
Mergers and acquisitions: you bought a company that runs on another cloud. Migrating isn't always worth it.
Best-of-breed services: a particular provider is clearly better for one need (AI hardware, analytics, a specific managed service).
Customer requirements: if you sell software that runs in customers' accounts, you need to support the clouds they use.
Commercial leverage: credible ability to move gives you a better position in price negotiations. But this only works if moving is actually realistic.

Weaker reasons

"Avoiding lock-in" in general. Every choice locks you into something: a database, a language, Kubernetes, Terraform. The question isn't whether you're locked in, but whether the cost of leaving is acceptable.
"Resilience against a provider outage." Large provider-wide outages do happen, but they're rare. Well-designed multi-region on one provider gives most of the resilience at a fraction of the complexity.

Multi-cloud doesn't remove lock-in. It replaces dependency on one provider with dependency on your own team's ability to run several.

The hidden costs

Lowest common denominator. To stay portable, you avoid each provider's best managed services. You run your own databases, queues and tooling instead.
Data transfer. Moving data between clouds is expensive (egress charges) and slow.
Skills. Your team needs deep knowledge of several providers' networking, IAM, security and quirks. That's much harder than mastering one.
Tooling. Security, monitoring, cost management and compliance must work everywhere.
Lost discounts. Splitting spend reduces the volume discounts and commitments you can negotiate with each provider.
More things to secure. Every additional cloud is another set of accounts, identities and configurations to get right.

What helps portability

If you do need portability, a few tools make it more realistic:

Kubernetes: a consistent runtime across clouds and on-premises. The managed services differ in details, but workloads move fairly easily.
Terraform or OpenTofu: one tool for infrastructure across providers. The code is still provider-specific, but the workflow and skills transfer.
Crossplane: a Kubernetes-based control plane that can offer the same internal APIs backed by different clouds.
OpenTelemetry: vendor-neutral observability.
Open-source data stores (PostgreSQL, Kafka, Redis/Valkey) available as managed services on every major cloud.
Standard identity (OIDC, SAML) and a cloud-neutral secret manager.

How I'd decide

Ask these questions:

Is there a concrete business, legal or customer requirement for a second cloud? If yes, plan for it properly.
What would leaving our main provider actually cost in time and money? Is that risk acceptable? Write down an exit plan, even if you never use it. Regulators, especially in financial services, increasingly expect this.
Can we get the resilience we need with multiple regions on one provider?
Do we have the people to run several clouds well?

For most companies, my recommendation is: go deep on one primary cloud, use other providers deliberately for specific needs, keep your architecture reasonably portable with Kubernetes, Terraform and open standards, and maintain a realistic exit plan.

My take: multi-cloud is a tool, not a strategy. Use it when you have a reason, not because it sounds safe.

— Desly

European cloud and digital sovereignty

Tue, 20 Oct 2026 23:10:30 +0200

Working in Germany, I've noticed a change over the last few years. Questions that used to come only from legal teams now come from CTOs, CEOs and customers: Where exactly is our data? Who can access it? What happens if a foreign government demands it? Could our cloud provider be forced to cut us off?

That's digital sovereignty. Now it's a real factor in infrastructure decisions for European companies, not just a niche topic.

Why it's in the news

A few forces are pushing it:

Legal tension. US laws like the CLOUD Act can require US companies to provide data they control, even if it's stored in Europe. That conflicts with GDPR's protections. The EU–US Data Privacy Framework currently allows transfers, but its predecessors were struck down by courts twice, and many companies don't want to bet on it lasting.
Geopolitics. Recent years have made people more aware of dependencies on foreign technology and the risk of political decisions affecting access to services.
Regulation. NIS2, DORA (for financial services), the Data Act, the Cyber Resilience Act and sector rules increasingly ask companies to manage risks from technology providers, including concentration risk and exit strategies.
Public sector requirements. Governments and public bodies in several countries prefer or require sovereign solutions.

What "sovereignty" actually means

It's a fuzzy word. It usually covers three layers:

Data sovereignty: data stays in a specific jurisdiction, and you control who accesses it.
Operational sovereignty: the people operating the infrastructure are in the EU, subject to EU law, and foreign access is technically and contractually prevented.
Technological sovereignty: you can keep running, and move, even if a provider becomes unavailable. This often means open standards and open source.

Different requirements need different levels. A small e-commerce site and a hospital have very different needs.

Sovereignty isn't about where the server stands. It's about who can switch it off, and who can look inside.

The hyperscalers' answers

The big US providers have responded with sovereign offerings:

AWS European Sovereign Cloud: a separate cloud infrastructure in the EU, starting in Germany, operated by EU-resident staff and independent from other AWS regions.
Microsoft: the EU Data Boundary, plus sovereign cloud offerings, including partnerships with European operators.
Google Cloud: sovereign options with local partners, such as offerings operated with T-Systems in Germany and with Thales (S3NS) in France.

These aim to combine the hyperscalers' service catalogue with stronger European control. Whether they fully address the legal concerns is debated, and depends on the specific setup.

The European providers

There's also a growing group of European cloud providers:

OVHcloud (France): a broad IaaS and PaaS offering, with SecNumCloud-qualified options.
Hetzner (Germany): very cost-effective servers and cloud, popular with startups and developers.
Scaleway (France): developer-friendly cloud with managed Kubernetes and AI infrastructure.
STACKIT (Germany, Schwarz Group): built for sovereign enterprise needs.
IONOS (Germany), Open Telekom Cloud (Germany), UpCloud, Exoscale and others.

Their strengths: EU jurisdiction, often lower prices for raw compute and bandwidth. The trade-offs: fewer managed services, smaller ecosystems, and sometimes less mature tooling.

Initiatives like Gaia-X and the IPCEI-CIS project aim to create common standards and federated European infrastructure, with mixed progress so far.

What changes in the architecture

If sovereignty matters to you, a few architectural choices help regardless of provider:

Kubernetes and open-source building blocks (PostgreSQL, Kafka, object storage with S3-compatible APIs) make it easier to run on European providers or move between them.
Encryption with keys you control, ideally in your own HSM or an external key manager, so the provider can't read your data.
Infrastructure as code for everything, so you can rebuild elsewhere.
Data classification: not all data needs the same protection. Put the sensitive part in a sovereign environment and keep the rest wherever it's most practical.
A tested exit plan: regulators increasingly expect it, and it's good engineering anyway.

Migration considerations

Moving from a hyperscaler to a European provider is mostly a question of managed services. Plain VMs and Kubernetes move relatively easily. Proprietary databases, serverless functions, queues and AI services don't. Expect to replace some managed services with open-source equivalents you operate yourself, or with the provider's offering.

A hybrid approach is common: sensitive workloads and data on a sovereign platform, the rest on a hyperscaler.

So, should you care?

If you're in Europe and handle sensitive data, work with the public sector, or are in a regulated industry, yes. Even if you're not, keeping your architecture portable with open standards and holding your own encryption keys is cheap insurance.

My take: sovereignty isn't about rejecting American clouds. It's about making sure you always have a choice.

— Desly

Leaving the cloud: when it makes sense

Tue, 20 Oct 2026 23:10:30 +0200

For about fifteen years, the direction was obvious: everything moves to the cloud. Data centres were closing, "cloud first" was official strategy, and running your own servers felt old-fashioned.

Then some companies started going the other way, very publicly. They moved workloads out of the public cloud and back onto their own hardware, and reported big savings. "Cloud repatriation" became a hot topic.

So is the cloud a rip-off? Not quite. But it's worth understanding when leaving makes sense.

The famous cases

The best-known example is 37signals, the company behind Basecamp and HEY. Starting in 2022, they moved their applications off AWS onto their own servers in rented data centre space, and published their reasoning and numbers along the way. They reported substantial annual savings, expected to add up to millions of dollars over several years, without growing their operations team significantly. They later also moved their storage out of S3.

Other companies have made similar moves for specific workloads: those with heavy storage needs, large and steady compute requirements, or high bandwidth costs. AI has also introduced a new angle: some companies find that buying GPUs is cheaper than renting them for workloads that run continuously.

At the same time, many more companies continue moving into the cloud. Repatriation is a real trend, but not a mass exodus.

Doing the math

The cloud's pricing model is great for some workloads and expensive for others.

The cloud is usually cheaper when: - Load is spiky or unpredictable, and you scale up and down a lot. - You're small or growing fast, and can't predict next year's needs. - You use many managed services that would require specialists to run yourself. - You need global presence quickly. - Your team is small and should focus on the product.

Your own hardware can be cheaper when: - Load is large and steady, running 24/7 at high utilisation. - You store huge amounts of data, or move a lot of it out (egress fees add up). - You need lots of GPUs constantly. - You have, or can hire, people with infrastructure and hardware skills. - You plan to keep the setup for many years.

When comparing, include everything: hardware, data centre space or colocation, power, network, spare parts, hardware refresh cycles, staff time, on-call, security, compliance, and the software you'll need to replace managed services. Also include the cost and risk of the migration itself.

The cloud charges you for flexibility. If you don't use the flexibility, you're paying for something you don't need.

It's not all or nothing

Very few companies move everything. More common patterns:

Hybrid: steady, heavy workloads on owned or rented hardware; spiky, experimental and globally distributed workloads in the cloud.
Rented dedicated servers (like Hetzner, OVHcloud and others) instead of buying hardware, a middle ground with much lower prices than cloud VMs and no data centre to manage.
Colocation: your hardware, someone else's building, power and network.
Cloud for managed data services, own hardware for compute, or the other way round.

The tools for on-prem

The tooling for running your own infrastructure is much better than ten years ago:

Kubernetes gives you a cloud-like platform on any hardware. Distributions like Talos, k3s, RKE2 and OpenShift, plus Cluster API, make it manageable.
Proxmox and other virtualisation platforms have become popular, especially after VMware's licensing changes pushed many companies to look for alternatives.
OpenStack for larger private clouds with an AWS-like API.
Ceph, MinIO and similar for storage.
Infrastructure as code and GitOps work exactly the same on your own hardware.
Bare-metal provisioning tools (like Tinkerbell, MAAS, or Talos with Omni) automate the hardware layer.

What you take on

Leaving the cloud means owning problems the cloud hid from you:

Hardware fails. Disks die, power supplies break, someone needs to replace them.
Capacity planning: you can't add a hundred servers in five minutes.
Physical security, networking, power redundancy.
Patching firmware, hypervisors and operating systems.
Replacing managed databases, queues and other services with things you operate.

If your team isn't prepared for that, the savings disappear quickly.

So, should you leave the cloud?

Probably not entirely. But if you have large, steady workloads and big bills, it's worth running the numbers honestly. The answer might be "move this one heavy workload to dedicated servers", which can save a lot without giving up the cloud's advantages for everything else.

My take: the cloud isn't always the cheapest option, just the most convenient one. Know which one you're paying for.

— Desly

Serverless or containers?

Tue, 20 Oct 2026 23:10:30 +0200

Few architecture debates have produced as many conference talks as this one. Serverless fans say servers are a distraction and you should only write business logic. Container fans say serverless is expensive, limiting and locks you in. Both have a point.

They're tools for different jobs, and the line between them has blurred a lot.

The options

Functions as a Service (FaaS): AWS Lambda, Azure Functions, Google Cloud Run functions. You upload a function, the platform runs it when an event arrives (an HTTP request, a file upload, a queue message), and you pay per invocation and execution time. No servers, no containers to think about.

Serverless containers: Google Cloud Run, AWS Fargate (with ECS), Azure Container Apps, AWS App Runner. You provide a container image, the platform runs and scales it, often down to zero. You don't manage nodes or clusters.

Kubernetes: managed (EKS, AKS, GKE) or self-hosted. You run containers on a cluster you control, with full flexibility and full responsibility.

Knative and similar projects bring serverless-style scale-to-zero and event-driven behaviour onto Kubernetes.

These form a spectrum: more control on one end, less operational work on the other.

Serverless doesn't mean there are no servers. It means they're someone else's problem, and you pay for that.

Where serverless shines

Event-driven glue: reacting to file uploads, database changes, webhooks, scheduled jobs.
Spiky or unpredictable traffic: zero cost when idle, instant scaling for bursts.
Small teams who want to ship without running infrastructure.
Prototypes and new products, where speed matters more than optimisation.
Low-traffic services, where paying for an always-on container would be wasteful.

Where containers on Kubernetes shine

Steady, high traffic: at constant high load, paying per request becomes more expensive than paying for capacity.
Long-running processes: workers, streaming, WebSockets, anything that runs longer than a function's time limit.
Complex systems with many services, service meshes, custom networking.
Special hardware: GPUs, high memory, specific instance types.
Portability across clouds and on-premises.
Teams with platform engineering capacity who can run Kubernetes well.

Cold starts and limits

The classic serverless drawbacks:

Cold starts: when a function hasn't run for a while, the first request takes longer while the platform starts a new instance. Usually small for lightweight runtimes, more noticeable for heavy ones like Java with big frameworks. Mitigations exist: provisioned concurrency, snapshot-based fast start features, minimum instances on Cloud Run.
Time limits: functions have maximum execution times (15 minutes on Lambda, for example).
Resource limits: memory, CPU, package size, temporary storage.
Statelessness: no local state between invocations. Everything goes to external storage.
Observability and debugging across many small functions can be harder.
Lock-in: function code often ends up tightly tied to provider-specific events and services.

Serverless containers like Cloud Run soften many of these: standard containers, longer request times, concurrency per instance, and much easier portability.

Where the costs cross over

Cost depends on usage pattern:

Low or bursty usage: serverless is often dramatically cheaper because you pay nothing when idle.
Moderate usage: roughly comparable, and serverless saves on operations work.
High, steady usage: containers on reserved or Spot capacity usually win on raw infrastructure cost.

Don't forget people cost. A Kubernetes platform needs engineers to run it. For a small team, serverless can be cheaper overall even if the cloud bill is higher.

Mixing both

Most mature architectures use both:

Core APIs and long-running services on Kubernetes or serverless containers.
Event handlers, scheduled jobs and glue code as functions.
Data pipelines with managed serverless services (queues, workflows, stream processing).

And the choice doesn't have to be permanent. A service can start on Cloud Run or Lambda and move to Kubernetes when traffic grows, especially if it's packaged as a standard container from the start.

So, which one?

My default advice:

Small team, new product: start serverless, ideally serverless containers. Ship fast.
Event-driven tasks: functions.
Large, steady workloads, many services, platform team in place: Kubernetes.
Not sure: package everything as containers. That keeps your options open.

My take: choose the least infrastructure you can get away with today, and keep your code portable enough to change your mind tomorrow.

— Desly

Service mesh without sidecars

Tue, 20 Oct 2026 23:10:30 +0200

A few years ago, the service mesh was the hottest topic in cloud-native. Every conference had talks about Istio, every architecture diagram had little proxies next to every service. Then reality hit: meshes were complex, resource-hungry and hard to debug. Many teams tried one and quietly removed it.

The technology has changed a lot since then. The biggest shift: you no longer need a sidecar proxy in every pod. So it's worth looking again.

What a mesh does

A service mesh handles communication between services, outside your application code. Typical features:

mTLS everywhere: encrypted traffic between services, with automatic certificate management and service identity.
Authorisation policies: "only the checkout service can call payments".
Traffic management: retries, timeouts, circuit breaking, traffic splitting for canary releases.
Observability: request metrics, traces and a map of which services talk to which, without changing code.

All of this can be built into each application with libraries, but then every team, in every language, has to do it right. A mesh does it once, for everyone.

Sidecar vs sidecarless

The sidecar model (classic Istio, Linkerd): every pod gets an extra proxy container. All traffic in and out of the pod goes through it.

Pros: strong isolation, rich per-pod features.
Cons: a proxy per pod uses CPU and memory (it adds up across thousands of pods), adds latency, complicates pod startup and shutdown, and upgrading the mesh means restarting every workload.

The sidecarless model moves the proxy out of the pod:

Istio ambient mode (generally available since Istio 1.24, late 2024) splits the mesh into two layers. A lightweight per-node proxy called ztunnel handles mTLS and basic L4 policies for all pods on the node. Optional waypoint proxies handle L7 features (HTTP routing, retries, header-based policies) only for the services that need them.
Cilium service mesh uses eBPF in the kernel for networking and L4 features, with a shared per-node Envoy for L7 features.

Benefits: much lower resource overhead, no changes to pods, upgrades without restarting applications, and you only pay for L7 processing where you use it.

The best part of the new service meshes is how much less of them there is.

The main options today

Istio: the most feature-rich, now with both sidecar and ambient modes. Large ecosystem, more complexity. A CNCF graduated project.
Linkerd: focused on simplicity and low overhead, with a very small, Rust-based proxy. Still sidecar-based, but light. Note that the creator, Buoyant, changed how stable releases are distributed, so check the current licensing and release model before adopting.
Cilium: if you already use Cilium as your CNI, its mesh features come almost for free, including mutual authentication and transparent encryption.
Cloud provider meshes: managed options on some clouds, often based on Istio.

What you get

When a mesh fits, the benefits are real:

Zero-trust networking with almost no application changes. Every service has an identity, every connection is encrypted and authorised.
Consistent reliability features (timeouts, retries) without each team implementing them.
Canary releases with precise traffic splitting.
Golden metrics (requests, errors, latency) for every service, out of the box.

What it costs to run

Even sidecarless, a mesh is a significant component:

Another control plane to install, upgrade and monitor.
Learning curve: new concepts, new resources, new failure modes.
Debugging: when a request fails, is it the app, the mesh, or the network?
Policy sprawl: authorisation policies need to be managed carefully.

Do you need a mesh?

Questions I'd ask:

Do you need mTLS between services for compliance or zero-trust requirements? A mesh is the easiest way to get it at scale.
Do you have many services in many languages, where library-based solutions would be inconsistent?
Do you need fine-grained traffic control for progressive delivery?
Do you have the team capacity to run it?

If you have a handful of services in one language, probably not. If you have dozens or hundreds of services and security requirements, probably yes, and ambient-style meshes make the decision much easier than it used to be.

Also note: Gateway API now covers some of what people used meshes for (traffic splitting, header routing at the edge), and its GAMMA initiative extends the same API to service-to-service traffic in meshes. That means less mesh-specific configuration to learn.

So, should you look again?

If you rejected service meshes a few years ago because of sidecar overhead and complexity, yes. Istio ambient and Cilium have removed the biggest pain points. Start with just mTLS and observability, add L7 features only where needed, and see if it earns its place.

My take: a mesh used to be a big commitment. Without sidecars, it's finally something you can adopt one small step at a time.

— Desly

WebAssembly on the server: hype or future?

Tue, 20 Oct 2026 23:10:30 +0200

In 2019, Docker co-founder Solomon Hykes posted something that's been quoted ever since: if WebAssembly and WASI had existed in 2008, they wouldn't have needed to create Docker. That's a big claim. Several years later, where does server-side WebAssembly actually stand?

Wasm outside the browser

WebAssembly (Wasm) started as a way to run fast, compiled code in web browsers: games, video editors, design tools. It's a compact binary format that many languages (Rust, C/C++, Go, C#, Zig, and others) can compile to, and that runs in a sandboxed virtual machine.

The properties that make it great in browsers turn out to be interesting on servers too:

Fast startup: modules start in microseconds to milliseconds, much faster than containers.
Small: modules are often kilobytes to a few megabytes.
Secure by default: a Wasm module can't access files, network or anything else unless explicitly granted. A strong sandbox.
Portable: the same module runs on any OS and CPU architecture with a Wasm runtime.

To work outside the browser, Wasm needs a way to talk to the system: files, clocks, sockets. That's WASI (WebAssembly System Interface). WASI 0.2 introduced the Component Model, which lets Wasm components written in different languages work together through well-defined interfaces. Further versions are adding async support and more.

Containers package an operating system around your app. Wasm packages just your app, and asks permission for everything else.

Running it on Kubernetes

Wasm doesn't have to replace your platform. It can run alongside containers:

containerd shims (like those from the runwasi project) let Kubernetes run Wasm workloads through a normal RuntimeClass. A pod can run a Wasm module instead of a container image.
SpinKube runs apps built with Spin (from Fermyon) on Kubernetes, with very high density and fast scaling.
wasmCloud (a CNCF incubating project) is a platform for distributed Wasm applications across clouds, edge and Kubernetes.
Wasm modules can be stored in OCI registries, just like container images.

apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: wasmtime-spin
handler: spin
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-wasm
spec:
  replicas: 3
  selector:
    matchLabels: { app: hello-wasm }
  template:
    metadata:
      labels: { app: hello-wasm }
    spec:
      runtimeClassName: wasmtime-spin
      containers:
      - name: hello
        image: ghcr.io/acme/hello-wasm:1.0.0
        command: ["/"]

Where it fits

Wasm is already in production in places you might not notice:

Edge computing: Cloudflare Workers, Fastly Compute and other edge platforms run Wasm (or similar isolates) because of fast startup and strong isolation. Code runs close to users with almost no cold start.
Plugins and extensions: Envoy proxy filters, database extensions, and tools like Helm 4's plugin system use Wasm to run third-party code safely.
Serverless functions where cold starts matter.
Multi-tenant platforms that need to run untrusted user code safely.
IoT and embedded devices with limited resources.

Where it doesn't, yet

Ecosystem maturity: many libraries, especially those relying on threads, networking or system calls, don't fully work in WASI yet. It's improving release by release.
Language support varies: Rust is excellent; other languages are good but with caveats; some popular languages still have rough edges.
Tooling and debugging are less mature than for containers.
Existing apps: rewriting or recompiling a large existing application for Wasm rarely makes sense. Containers run any Linux software today.
Long-running, heavy workloads: containers are still the natural fit.

So, hype or future?

Both, honestly. Wasm won't replace containers for most workloads any time soon. Containers solved a huge problem and they're everywhere. But Wasm is clearly the future for specific areas: edge, plugins, high-density serverless and safe execution of untrusted code. Those areas are growing.

For DevOps engineers, it's worth understanding now: how it runs on Kubernetes, how it's packaged in OCI registries, and where it might show up in your stack.

My take: Wasm isn't the next container. It's the thing you'll reach for when a container is too heavy, too slow or too trusting.

— Desly

Should DevOps engineers learn Go?

Tue, 20 Oct 2026 23:10:30 +0200

Look at the tools you use every day: Kubernetes, Docker, containerd, Terraform, OpenTofu, Helm, Prometheus, Grafana's backend, Argo CD, Flux, etcd, Vault, Trivy, k9s. Almost all of them are written in Go.

That’s not a coincidence. It’s a good reason for DevOps engineers to think about learning it.

Why Go took over infrastructure

Go was created at Google and released in 2009, designed for building reliable networked services and tools. A few properties made it the language of cloud-native infrastructure:

Single static binaries. A Go program compiles into one file with no runtime to install. Copy it anywhere and it runs. Perfect for CLIs and containers.
Easy cross-compilation. Build for Linux, macOS, Windows, ARM and x86 from one machine.
Built-in concurrency with goroutines and channels, ideal for programs that do many things at once, like controllers watching many resources.
Simple language. Deliberately small, easy to read, with one standard formatting style (gofmt). You can read someone else's Go code without decoding their personal style.
Fast compilation and good performance.
Strong standard library for HTTP, JSON, cryptography and more.

What you can do with it

As a DevOps engineer, Go opens a few doors:

Read the source of the tools you use. When Kubernetes or Terraform behaves strangely, reading the code is often the fastest way to understand why.
Build CLI tools that colleagues can install as a single binary.
Write Kubernetes operators and controllers to automate your platform.
Write Terraform providers for internal systems.
Contribute to open-source cloud-native projects.
Build small services: webhooks, exporters, admission controllers.

My first CLI

A tiny but real example: a CLI that checks when TLS certificates expire.

package main

import (
    "crypto/tls"
    "fmt"
    "os"
    "time"
)

func main() {
    if len(os.Args) < 2 {
        fmt.Fprintln(os.Stderr, "usage: certcheck <host> [host...]")
        os.Exit(1)
    }

    exitCode := 0
    for _, host := range os.Args[1:] {
        conn, err := tls.Dial("tcp", host+":443", &tls.Config{ServerName: host})
        if err != nil {
            fmt.Printf("%-30s ERROR %v\n", host, err)
            exitCode = 1
            continue
        }
        cert := conn.ConnectionState().PeerCertificates[0]
        conn.Close()

        days := int(time.Until(cert.NotAfter).Hours() / 24)
        status := "OK"
        if days < 14 {
            status = "EXPIRING"
            exitCode = 1
        }
        fmt.Printf("%-30s %-8s %d days left\n", host, status, days)
    }
    os.Exit(exitCode)
}

go build -o certcheck .
./certcheck example.com deslypeter.com
GOOS=linux GOARCH=arm64 go build -o certcheck-linux-arm64 .   # cross-compile

No dependencies beyond the standard library, one binary, works anywhere. For bigger CLIs, libraries like Cobra (used by kubectl, Helm and many others) add subcommands and flags.

Learning Go is like getting a key to the engine room of cloud-native infrastructure.

A tiny Kubernetes operator

Operators are where Go really shines for platform work. An operator watches Kubernetes resources and makes reality match what they describe.

Kubebuilder (and the Operator SDK, which builds on it) generates most of the boilerplate:

kubebuilder init --domain acme.com --repo github.com/acme/app-operator
kubebuilder create api --group platform --version v1alpha1 --kind App

You then define your custom resource's fields in Go structs and write a Reconcile function: "given this App resource, make sure the right Deployment, Service and HTTPRoute exist". The framework handles watching, caching, retries and leader election.

It's not a weekend project to build a production-quality operator, but building a toy one is the best way to understand how Kubernetes itself works. Every built-in controller follows the same pattern.

Go vs Python for DevOps

They're complementary:

Python: faster for quick scripts, data processing, glue code, and anything where a huge library ecosystem helps. Great for one-off automation.
Go: better for tools you distribute, long-running services, operators, and anything that needs to be fast, concurrent, or a single binary.

Many DevOps engineers use Python for scripts and Go for tools.

Where to start

A Tour of Go (go.dev/tour): the official interactive introduction. A few hours.
Go by Example: short, practical examples for every common task.
"Learning Go" by Jon Bodner, or "Let's Go" by Alex Edwards for web services.
The Kubebuilder Book for operators.
Then build something small you'll actually use: a CLI, an exporter for an internal system, a webhook.

So, should you learn it?

If you work with Kubernetes and want to go beyond using tools to understanding and extending them, yes. You don't need to become a Go expert. Being able to read Go code and write small tools already makes you noticeably more effective.

My take: you don't have to speak Go to work in cloud-native. But it's the language the whole neighbourhood speaks, and it helps to understand the conversation.

— Desly

Docker, Podman, containerd: what's the difference?

Tue, 20 Oct 2026 23:10:30 +0200

When people say "container", they often mean "Docker". But Docker is just one tool in a stack of layers, and in many places, Kubernetes included, Docker isn't involved at all anymore.

Understanding what's actually running your containers helps when debugging, choosing tools, and making sense of headlines like "Kubernetes removes Docker support" (which sounded scary in 2020 and turned out to be mostly harmless).

The container stack

From bottom to top:

1. The Linux kernel. Containers aren't a kernel feature called "container". They're a combination of namespaces (isolating what a process can see: processes, network, files, users) and cgroups (limiting what it can use: CPU, memory, I/O). Every container runtime uses these.

2. Low-level runtime (OCI runtime). A small program that actually creates the container process with the right namespaces and cgroups. The standard one is runc. Alternatives include crun (faster, written in C), gVisor (extra isolation with a user-space kernel) and Kata Containers (each container in a lightweight VM).

3. High-level runtime. Manages images, storage, networking and the lifecycle of containers, and calls the low-level runtime. The main ones are containerd (a CNCF graduated project) and CRI-O (built specifically for Kubernetes).

4. Tools and interfaces. What humans and platforms talk to: the Docker CLI and engine, Podman, nerdctl, and Kubernetes' kubelet (through the Container Runtime Interface, CRI).

All of this is held together by OCI standards (Open Container Initiative): a standard image format and a standard runtime specification. That's why an image built with Docker runs with Podman, containerd or CRI-O.

A container is just a Linux process with blinkers on and a budget. Everything else is tooling around that idea.

What Kubernetes actually uses

Kubernetes talks to runtimes through the CRI. Docker Engine never implemented CRI directly, so Kubernetes used an adapter called dockershim. In Kubernetes 1.24 (2022), dockershim was removed.

What that meant in practice:

Clusters now use containerd or CRI-O directly. Most managed Kubernetes services (EKS, AKS, GKE) use containerd.
Images built with Docker still work everywhere, because they're standard OCI images.
What stopped working: things that relied on the Docker socket on nodes, like some old monitoring tools or "Docker-in-Docker" builds in CI.

On a node, use crictl to inspect containers instead of docker ps:

crictl ps
crictl logs <container-id>
crictl images

Docker

Docker made containers popular and remains the most widely used developer tool for them: building images, running containers locally, Docker Compose for multi-container setups. Docker Engine itself uses containerd underneath.

Docker Desktop is the packaged app for macOS and Windows, which runs a Linux VM in the background. Since 2021, it requires a paid subscription for larger companies (more than 250 employees or more than $10 million in annual revenue). That pushed many organisations to look at alternatives.

Rootless with Podman

Podman, from Red Hat, is a Docker-compatible alternative with a few important differences:

Daemonless: no long-running background service with root privileges. Each container is a child process of the command that started it.
Rootless by default: containers run as your normal user, which reduces the risk if a container is compromised.
Docker-compatible CLI: alias docker=podman works for most commands.
Pods: can group containers like Kubernetes pods, and generate Kubernetes YAML from running containers (podman kube generate).
Quadlet: run containers as systemd services, nicely integrated with Linux servers.
Podman Desktop: a free GUI for macOS, Windows and Linux.

podman run --rm -p 8080:80 docker.io/library/nginx:1.27

Docker Desktop alternatives on the Mac

If you need containers on macOS without Docker Desktop:

OrbStack: fast, lightweight, very popular with Mac developers. Commercial for business use, but often cheaper than Docker Desktop.
Colima: open source, command-line, based on Lima. Works with the Docker CLI or containerd/nerdctl.
Rancher Desktop: open source (SUSE), includes a local Kubernetes (k3s) and lets you choose containerd or Docker Engine.
Podman Desktop: open source, with Podman underneath.
Apple has also introduced its own open-source container tool for running Linux containers on Apple silicon Macs.

All of them run a small Linux VM, because containers need a Linux kernel.

Which should you use?

Developer laptop: Docker Desktop if licensing is fine for you; otherwise OrbStack, Colima, Rancher Desktop or Podman Desktop.
Linux servers running containers directly: Podman with Quadlet is very nice, especially for rootless setups. Docker Engine also works well.
Kubernetes nodes: containerd (or CRI-O). You usually don't choose this on managed services.
CI image builds: BuildKit (via Docker or standalone), Buildah, or Kaniko-style tools for building without a privileged daemon.

So, what's the takeaway?

"Docker" is a brand, a tool and a company. Containers are a Linux feature plus open standards. Once you see the layers, the choices become simpler: use whatever tool you like to build OCI images, and know that Kubernetes will run them with containerd or CRI-O regardless.

My take: learn the layers once, and you'll never be confused by a "Docker is dead" headline again.

— Desly

How I'd learn DevOps if I started today

Tue, 20 Oct 2026 23:10:30 +0200

People often ask me how to get into DevOps. The internet's answer is usually a giant roadmap diagram with a hundred boxes: every tool, every cloud, every buzzword. It's overwhelming, and it suggests you need to learn everything before you can do anything.

You don't. Here's the path I'd take if I started from zero today: in order, with one practical project per stage, and honest time estimates.

The order that makes sense

The order matters because each step builds on the last. Kubernetes makes very little sense if you don't understand Linux, networking and containers first.

1. Linux and the command line (4–6 weeks)

Everything in DevOps runs on Linux. Learn to live in the terminal: files and permissions, processes, services with systemd, package management, logs, SSH, basic shell scripting.

Project: set up a Linux VM (or a cheap cloud server), harden SSH, install NGINX, serve a static page, and write a small Bash script that backs up its config every night with cron.

2. Networking fundamentals (2–3 weeks, alongside Linux)

IP addresses and subnets, DNS, TCP vs UDP, ports, HTTP, TLS, load balancers, firewalls. This is the knowledge that makes debugging possible later.

Project: point a real domain at your server, get a free TLS certificate with Let's Encrypt, and debug it with dig, curl -v and ss.

3. Git (1–2 weeks)

Branches, merges, rebases, pull requests, resolving conflicts. Everything in DevOps lives in Git, including infrastructure.

Project: put your server's config and scripts in a GitHub repository, and work through pull requests even if you're alone.

4. A programming language (ongoing, start now)

Python is the easiest start for automation. Later, Go is valuable for cloud-native tooling. You don't need to become a software engineer, but you need to read and write real code.

Project: a Python script that checks your website's status and certificate expiry, and sends you a message if something is wrong.

Don't try to learn the whole roadmap. Learn the next step well enough to build something, then take the next one.

5. Containers (3–4 weeks)

Docker or Podman: images, Dockerfiles, multi-stage builds, volumes, networks, Docker Compose. Understand what a container really is (a Linux process with namespaces and cgroups).

Project: containerise a small web app with a database, using Docker Compose, with a small, secure image.

6. CI/CD (2–3 weeks)

Pipelines that test, build, scan and deploy automatically. GitHub Actions is the easiest place to start.

Project: a pipeline that runs tests, builds your container image, scans it with Trivy, pushes it to a registry, and deploys it to your server.

7. A cloud provider (6–8 weeks)

Pick one: AWS, Azure or Google Cloud, whichever is most common in the jobs you want. Learn the core: identity and access (IAM), networking (VPCs, subnets, security groups), compute, storage, managed databases, and cost basics.

Project: deploy your app to the cloud with a managed database, in a private network, behind a load balancer. Set up a budget alert first.

8. Infrastructure as code (3–4 weeks)

Terraform or OpenTofu. Resources, variables, modules, state, plans. Never click in the console again for anything you want to keep.

Project: rebuild everything from step 7 in Terraform, delete it, and recreate it with one command.

9. Kubernetes (6–10 weeks)

Now Kubernetes will make sense. Pods, deployments, services, configmaps, secrets, ingress or Gateway API, Helm, resource requests, debugging.

Project: run your app on a local cluster (kind or k3s), then on a managed cluster, deployed with Helm and GitOps (Argo CD or Flux).

10. Observability (3–4 weeks)

Metrics, logs and traces. Prometheus, Grafana, Loki, OpenTelemetry. Alerts that make sense.

Project: add a dashboard and two meaningful alerts for your app, and instrument it with OpenTelemetry.

11. Security throughout

Not a separate step, but woven into every step: least privilege, secrets management, image scanning, network policies, keeping things patched.

Resources I trust

Official documentation: Kubernetes, Terraform, your cloud provider. Better than most courses.
KodeKloud and A Cloud Guru / Pluralsight for hands-on labs.
"The Phoenix Project" and "The DevOps Handbook" for the culture and the why.
Google's SRE books (free online) for reliability.
roadmap.sh/devops as a map, not a checklist.
Killercoda and iximiuz Labs for free browser-based practice environments.
And AI assistants as patient tutors: ask them to explain, not just to write things for you.

How long it really takes

Studying part-time (around 10 hours per week), getting to a junior-ready level takes roughly 9 to 15 months. Faster if you study full-time or already work in IT. It's a marathon, not a sprint, and that's fine.

Things that make it faster:

Build, don't just watch. One finished project teaches more than ten courses.
Break things and fix them. Debugging is the real skill.
Write about what you learn, on a blog or GitHub. It helps you think clearly, and it shows employers what you can do.
Find people: local meetups, online communities, a study buddy.

What about AI?

AI tools can write a lot of configuration for you now. That makes fundamentals more important, not less: you need to judge whether what the AI wrote is correct and safe. Use AI to learn faster, but make sure you understand everything you ship.

So, where should you start?

Today: install Linux in a VM, open a terminal, and set up that first web server. Everything else follows from there.

My take: DevOps isn't a list of tools. It's understanding how software gets built, shipped and kept running. Learn the foundations in order, build at every step, and the tools become easy.

— Desly

DevOps interview questions I'd ask

Tue, 20 Oct 2026 23:10:30 +0200

DevOps interviews can feel unpredictable. One company asks you to reverse a linked list, another wants you to design a global infrastructure in 45 minutes, a third asks about your favourite Kubernetes feature.

If I were interviewing someone for a DevOps role, here's what I'd ask, and, more importantly, what I'd listen for. The goal isn't memorised definitions. It's understanding, experience and how you think.

How I think about interviews

I care about three things:

Fundamentals: do you understand how things work underneath the tools?
Troubleshooting: can you find a problem methodically, without panicking?
Judgement: do you understand trade-offs, risks and when "good enough" is right?

"I don't know, but here's how I'd find out" is a great answer. Confidently making things up is not.

Linux and networking

"What happens when you type a URL into a browser and press Enter?" A classic for a reason. I'm listening for DNS resolution, TCP connection, TLS handshake, HTTP request, load balancer, application, response. Bonus points for caching, CDNs, and where things can go wrong.

"A server is slow. How do you investigate?" Good answers have a method: check load and CPU (top, uptime), memory (free, OOM kills in dmesg), disk space and I/O (df, iostat), network, then the application's own logs and metrics. Start broad, then narrow down.

"The disk is full, but du doesn't show large files. What's going on?" Deleted files still held open by a process (lsof +L1), or running out of inodes (df -i). This separates people who've debugged real systems from those who haven't.

Containers and Kubernetes

"What is a container, actually?" I want to hear about Linux namespaces and cgroups, not just "a lightweight VM". And the difference between an image and a container.

"A pod is in CrashLoopBackOff. Walk me through debugging it." kubectl describe pod (events), kubectl logs --previous, check config and secrets, resource limits (OOMKilled?), probes killing it too early, image and command. A methodical answer matters more than the specific cause.

"What's the difference between requests and limits? What happens when a container exceeds its memory limit? Its CPU limit?" Memory: OOMKilled. CPU: throttled. Requests decide scheduling. Great candidates mention QoS classes or the CPU limits debate.

"How does a request from the internet reach a pod?" DNS, load balancer, Gateway or Ingress controller, Service, endpoints, pod. Bonus for kube-proxy or eBPF, and NetworkPolicies.

"How would you do a zero-downtime deployment?" Rolling updates with readiness probes, PodDisruptionBudgets, graceful shutdown handling, backward-compatible database changes, canary or blue-green for risky changes.

I don't hire for knowing every flag. I hire for knowing how to find out, and knowing when to be careful.

CI/CD and Terraform

"Describe a good CI/CD pipeline." Fast feedback first, build once and deploy the same artifact everywhere, automated tests and security scans, progressive rollout, easy rollback. Listen for "why", not just the stages.

"What is Terraform state and why does it matter?" The mapping between code and real resources. Remote, locked, encrypted, versioned. Contains secrets. Good candidates mention moved and import blocks, or what happens if state is lost.

"Someone changed a resource manually in the console. What happens next time Terraform runs?" Drift: Terraform tries to revert it. How to detect it, how to decide whether code or reality wins, how to prevent it.

"How do you handle secrets in a pipeline?" Not in Git, not in plain CI variables if avoidable. OIDC for cloud access, a secret manager, short-lived credentials, masking in logs.

Troubleshooting scenarios

I love open-ended scenarios, because they show how someone thinks:

"After a deployment, error rates jump to 10%. What do you do?" First: mitigate. Roll back if the deployment is the likely cause. Then investigate: what changed, which endpoints fail, logs, traces. Communicate to stakeholders. Afterwards, a blameless postmortem. The best candidates mention rollback early.

"Users in one region report the site is slow; others are fine." DNS and routing, CDN, regional infrastructure, a dependency in that region, network path. How would you confirm each hypothesis?

"Your cloud bill doubled this month. How do you find out why?" Cost explorer by service, account and tag, looking for new resources, data transfer, logs or a runaway autoscaler. Then prevention: budgets, alerts, tagging.

System design for DevOps

"Design the infrastructure for a web application that must survive the loss of an availability zone." I'm looking for: multiple AZs, load balancing, stateless app tier with autoscaling, managed database with multi-AZ failover, backups in another region, infrastructure as code, monitoring and alerts, a deployment strategy. And the candidate asking questions: how much traffic, what's the budget, what's the acceptable downtime?

Asking clarifying questions is one of the strongest signals in a design interview.

Behavioural questions

"Tell me about an outage you were involved in. What did you learn?" Honesty, ownership without blame, and real learning.
"Tell me about a time you automated something painful." Impact, and how you got others to adopt it.
"How do you handle disagreement with a developer about a deployment?" Collaboration over gatekeeping.

Tips for take-home tasks

Read the brief twice and do what's asked, not more.
Write a README: how to run it, what you'd do with more time, trade-offs you made.
Keep it clean: small commits, sensible structure, no secrets in the repo.
Make it work end to end before making it fancy.
Be ready to explain every line, especially if AI helped you write it.

So, how should you prepare?

Build things, break things, and be able to explain what happened. Practise talking through your debugging process out loud. And prepare two or three real stories from your experience: an outage, an automation, a disagreement. They're often what interviewers remember most.

My take: the best DevOps interviews feel like solving a problem together. Show how you think, admit what you don't know, and stay curious.

— Desly

Which DevOps certifications are worth it?

Tue, 20 Oct 2026 23:10:30 +0200

Certifications are a touchy subject in tech. Some people collect them like badges. Others say they're worthless and only experience counts. The truth is somewhere in the middle.

A certification won't replace real experience. But the right one can help you learn in a structured way, get past CV filters, and show commitment, especially early in your career or when changing direction. Here's my honest view of the ones that matter for DevOps.

When certifications help

Early career or career change: when you don't have years of experience to show, a respected cert proves you've put in the work.
Getting past filters: some companies, recruiters and public sector roles explicitly ask for them.
Consulting and partners: cloud partners often need certified staff, so certs directly matter to employers.
Structured learning: a clear syllabus and a deadline are great motivation.

When they matter less

When you already have strong, demonstrable experience.
When the cert is multiple-choice and easy to cram without understanding.
For senior roles, where interviews focus on depth and judgement.

Kubernetes certifications

These are run by the Linux Foundation / CNCF, and are highly respected because they're hands-on: you solve real tasks in a live terminal under time pressure, not multiple-choice questions.

CKA (Certified Kubernetes Administrator): cluster setup, troubleshooting, networking, storage, upgrades. The most valuable for DevOps and platform roles. The curriculum was updated in 2025 to include more modern topics like Gateway API and Helm.
CKAD (Certified Kubernetes Application Developer): deploying and configuring applications on Kubernetes. Good for developers and a nice first step.
CKS (Certified Kubernetes Security Specialist): securing clusters and workloads. Requires an active CKA. Excellent if you want to specialise in security.
KCNA and KCSA: entry-level, multiple-choice associate exams covering cloud-native and security basics.

Get all five, and you're a Kubestronaut, a CNCF programme with some perks and a lot of bragging rights.

Hands-on exams are the ones I respect most. You can't fake your way through a broken cluster with a timer running.

Cloud certifications

Pick the cloud that's most common in the jobs you want.

AWS: - Cloud Practitioner: basic, aimed more at non-technical roles. Skip it if you're hands-on. - Solutions Architect – Associate: the go-to cloud cert, broad and well-recognised. A good first step. - SysOps Administrator – Associate and Developer – Associate: more focused on operations or development. - DevOps Engineer – Professional: tough, but highly valued for senior roles.

Azure: - AZ-104 (Azure Administrator): the core operations cert. - AZ-400 (DevOps Engineer Expert): CI/CD, infrastructure as code, monitoring on Azure. - Very common in European enterprises and Microsoft-heavy companies.

Google Cloud: - Associate Cloud Engineer: a solid first step. - Professional Cloud DevOps Engineer: SRE-flavoured, focused on reliability and delivery.

Other useful certifications

HashiCorp Terraform Associate: covers Terraform fundamentals. Fairly easy, widely recognised, and Terraform knowledge applies to OpenTofu too.
Linux: LFCS (Linux Foundation Certified System Administrator) or RHCSA (Red Hat). Both hands-on. RHCSA is especially valued in Red Hat environments.
GitHub Actions and GitHub Advanced Security certifications: newer, useful if you work heavily with GitHub.
Security: CompTIA Security+ as a foundation, CKS for Kubernetes security.
Prometheus Certified Associate (PCA) and OpenTelemetry Certified Associate (OTCA): smaller, but growing as observability becomes more important.

Worth the money?

Rough return on investment, from my perspective:

Certification	Value for DevOps roles	Difficulty
CKA	Very high	Medium–high (hands-on)
AWS Solutions Architect – Associate	Very high	Medium
AZ-104 / AZ-400	High (esp. in enterprises)	Medium / high
AWS DevOps Engineer – Professional	High for senior roles	High
CKS	High for security focus	High
Terraform Associate	Medium	Low–medium
RHCSA / LFCS	Medium–high	Medium (hands-on)
Cloud Practitioner / KCNA	Low for technical roles	Low

Exam prices are typically a few hundred euros or dollars each, and many employers pay for them. Linux Foundation exams often go on sale (Black Friday, Cyber Monday), and usually include a free retake.

How I'd combine them

A strong path for someone starting out:

One cloud associate cert (AWS Solutions Architect – Associate or AZ-104).
CKA.
Terraform Associate, if you want a quick win.
Later: a professional cloud cert, or CKS if security interests you.

And for every certification, build a project that uses what you learned. A cert plus a GitHub repo showing real work is far more convincing than either one alone.

So, are they worth it?

The hands-on ones and the major cloud associate certs, yes, especially early in your career. Beyond that, depth of experience matters more than the number of badges.

My take: certifications open doors. Experience keeps you in the room. Get a couple of the right ones, then let your work do the talking.

— Desly

Portfolio projects that get you hired

Tue, 20 Oct 2026 23:10:30 +0200

When you're trying to get your first DevOps job, you're stuck in a classic loop: companies want experience, but you need a job to get experience. Portfolio projects break that loop. They show what you can actually do, in a way a CV line like "familiar with Kubernetes" never can.

Here are fifteen projects that I think demonstrate real skills, grouped by level. You don't need to build all of them. Three or four good ones, done properly and well documented, are worth more than fifteen half-finished repos.

Beginner projects

1. A static website with CI/CD. A personal site or blog built with a static site generator, deployed automatically on every push with GitHub Actions to GitHub Pages, Netlify, or an S3 bucket behind a CDN. Add a custom domain and HTTPS. Shows: Git, CI/CD basics, DNS, TLS.

2. A hardened Linux server. A cloud VM with SSH keys only, a firewall, automatic security updates, fail2ban, a non-root user, and NGINX serving your site. Documented step by step, then automated with a script or Ansible. Shows: Linux, security basics, automation.

3. Containerised app with Docker Compose. A small web app with a database and a cache, running with one docker compose up. Multi-stage Dockerfile, small image, health checks. Shows: containers, networking between services.

4. Uptime and certificate monitor. A Python script (or small Go tool) that checks a list of websites for availability and certificate expiry, runs on a schedule, and sends alerts to Slack, Telegram or email. Shows: scripting, APIs, scheduling, thinking about reliability.

5. Infrastructure for a simple app in Terraform. A VPC, subnets, a VM or container service, a database and a load balancer, all in Terraform, with remote state. Destroy and recreate it in one command. Shows: cloud fundamentals, infrastructure as code.

Intermediate projects

6. Full CI/CD pipeline for a containerised app. Tests, linting, image build, security scan (Trivy), push to a registry, deploy to staging automatically, promote to production with approval. Use OIDC instead of stored cloud keys. Shows: real-world pipeline design and security awareness.

7. Kubernetes deployment with Helm. Your app running on a local cluster (kind or k3s) and on a managed cluster, packaged as a Helm chart with sensible defaults, probes, resource requests and a Gateway API route. Shows: Kubernetes fundamentals.

8. GitOps with Argo CD or Flux. A GitOps repository managing several apps across two environments, with automatic sync, and promotion between environments through pull requests. Shows: modern deployment practices.

9. Observability stack. Prometheus, Grafana and Loki (or a ClickHouse-based tool) monitoring your app. A RED dashboard, two meaningful alerts with runbooks, and OpenTelemetry tracing across two services. Shows: you think beyond "it's deployed".

10. Automated backups and restore test. Scheduled database backups to object storage in another region, and an automated job that restores the latest backup to a test database and verifies the data, with alerts if anything fails. Shows: reliability thinking, which most junior candidates skip.

A project that shows you thought about what happens when things break is worth more than one that only works on a sunny day.

Advanced projects

11. A homelab Kubernetes cluster. Three nodes (mini PCs, Raspberry Pis or VMs), Talos or k3s, Cilium, GitOps, cert-manager, storage, monitoring and backups. Write about what broke and how you fixed it. Shows: deep understanding of the layers managed services hide.

12. Internal developer platform in miniature. A template that creates a new service with repo, pipeline, Helm chart, monitoring and a catalog entry (Backstage or a simple CLI). One command from idea to running service. Shows: platform engineering mindset.

13. Policy and supply chain security. Signed images with Cosign, SBOMs, Kyverno policies that block unsigned images, privileged containers and latest tags, and a pipeline that enforces it all. Shows: security beyond the basics, highly relevant with new regulations.

14. Multi-environment infrastructure with Terraform modules. Reusable modules, separate state per environment, plan on pull request and apply on merge, policy checks, cost estimates with Infracost. Shows: production-grade infrastructure as code.

15. Chaos and resilience testing. Run chaos experiments (Chaos Mesh or LitmusChaos) against your app: kill pods, add latency, fail a dependency. Document hypotheses, results and the fixes you made. Shows: SRE thinking and maturity.

What to include in the README

Your README matters as much as the code. Employers often only read the README. Include:

What it is and why you built it, in two or three sentences.
An architecture diagram. Even a simple one.
How to run it, step by step.
Design decisions and trade-offs: why this tool and not another.
What you'd do next with more time.
What broke and what you learned. This is the most impressive section for many interviewers.

Hosting it cheaply

You don't need a big budget:

Free tiers on AWS, Azure, Google Cloud and Oracle Cloud.
Local clusters (kind, k3d, minikube) for most Kubernetes work.
Cheap VPS providers like Hetzner for always-on projects at a few euros a month.
Always set budget alerts, and destroy expensive resources with Terraform when you're done. Screenshots and a recorded demo can replace a permanently running environment.

Presenting projects in interviews

Pick one or two projects to talk about in depth rather than listing everything.
Tell the story: what problem, what you built, what went wrong, what you learned.
Be ready to go deep: why this design? What would you change at ten times the scale?
Link them on your CV and LinkedIn, and consider writing a blog post about each one.

So, where do I start?

Pick a project one level above what you're comfortable with. Finish it, document it well, and write about it. Then build the next one on top of it. A single app that grows through several projects (containerised, deployed, monitored, secured) tells a great story.

My take: show, don't tell. A well-documented project that survived your own chaos test says more than any line on a CV.

— Desly

From sysadmin to DevOps

Tue, 20 Oct 2026 23:10:30 +0200

Many of the best DevOps engineers I know started as system administrators. They spent years keeping servers alive, fixing networks, restoring backups at 2 a.m., and being the person everyone called when "the internet is broken".

If that's you, and you're wondering whether you can move into DevOps: yes. You already have a big part of what it takes. You just need to change how you work, and add a few skills.

Skills you already have

Sysadmins often underestimate how valuable their experience is. You probably already know:

Linux (or Windows) in depth: processes, services, file systems, permissions, performance.
Networking: DNS, firewalls, routing, load balancers, VPNs. Many developers moving into DevOps struggle with this. You don't.
Troubleshooting under pressure: calm, methodical debugging when production is down.
Operations thinking: backups, monitoring, patching, capacity, what happens when things fail.
Security basics: access control, hardening, the consequences of getting it wrong.
Dealing with people: users, managers, vendors, incidents.

These are exactly the skills that are hardest to teach and that interviewers look for in troubleshooting questions.

The gaps

The shift from sysadmin to DevOps is mostly a shift in mindset: from doing things by hand to writing code that does things, and from pets to cattle.

The typical gaps:

1. Coding. Not just scripts, but code that's version-controlled, reviewed, tested and maintained. Python is the easiest start. Bash is useful but not enough.

2. Git and pull requests. Everything lives in Git: infrastructure, configuration, pipelines. Working through pull requests and code review becomes daily life.

3. Infrastructure as code. Terraform or OpenTofu instead of clicking or SSH-ing. Ansible for configuration.

4. Containers and Kubernetes. Packaging applications as containers, and running them on an orchestrator instead of on hand-managed servers.

5. CI/CD. Automated pipelines that build, test and deploy.

6. Cloud. If your background is on-premises, one major cloud provider. The good news: your networking and systems knowledge transfers very well, because the cloud is "just" someone else's data centre with an API.

7. Working closely with developers. Understanding how software is built, and helping teams ship, rather than receiving finished software to run.

The biggest change isn't the tools. It's moving from "I'll fix it" to "I'll make sure it fixes itself, or can't break that way again".

Getting experience in your current job

You don't have to wait for a DevOps job title to start doing DevOps work. Some ideas:

Put your scripts and configs in Git. Even if you're the only one using them.
Automate a repetitive task with Ansible: user creation, patching, server setup.
Write Terraform for something you'd normally click together, even a test environment.
Containerise an internal tool and run it with Docker or Podman.
Set up a CI pipeline for your automation code, with linting and tests.
Improve monitoring: add Prometheus and Grafana, write meaningful alerts.
Volunteer for projects involving cloud migration, automation or developer tooling.
Work with your developers: offer to help with their pipeline or deployment problems.

Every one of these becomes a story for your CV and interviews: "I automated our server provisioning with Ansible and Terraform, cutting setup time from two days to an hour."

Learning outside work

A homelab is especially powerful for sysadmins, because you already understand the hardware and networking side. Build a small Kubernetes cluster, run your own services on it with GitOps, and break it on purpose.

Certifications can help signal the transition: CKA and a cloud associate certification are the most valuable. Linux certs like RHCSA are good, but you may already have the knowledge.

Your CV

When updating your CV for DevOps roles:

Lead with automation and impact, not daily tasks. "Automated patching for 300 servers with Ansible" beats "Responsible for server maintenance".
Show numbers: time saved, incidents reduced, servers managed.
List your tools honestly, separated into "experienced" and "familiar".
Link to a GitHub profile with real projects.
Highlight incident and troubleshooting experience. It's a strength.

Job titles to look for besides "DevOps Engineer": Site Reliability Engineer, Platform Engineer, Cloud Engineer, Infrastructure Engineer. Cloud engineer roles are often the easiest bridge from sysadmin work.

So, can you make the move?

Absolutely. You already have the foundations many people coming from development lack. Add coding, Git, infrastructure as code and containers, start using them in your current job, and the title will follow.

My take: sysadmins don't need to start over to become DevOps engineers. They need to start writing down, in code, everything they already know how to do.

— Desly

On call without burning out

Tue, 20 Oct 2026 23:10:30 +0200

If you work in DevOps or SRE, you probably know the feeling: the phone on the bedside table, volume up. Checking it before falling asleep. Not going too far from the laptop on a Sunday. Jumping at every buzz, even when it's just a message from a friend.

On call is part of running production systems. Someone has to respond when things break. But it doesn't have to wear people down. Done well, on call is manageable, even educational. Done badly, it's one of the fastest ways to burn out a team.

What makes on call hard

It's rarely the big incident that breaks people. It's the accumulation:

Too many pages, most of them not needing action.
Night pages, again and again, ruining sleep for days after.
Too few people in the rotation, so it comes around too often.
Not knowing what to do: unfamiliar systems, missing runbooks, no one to escalate to.
Constant low-level anxiety, even when nothing happens.
No recognition or compensation for the time and stress.

A fair rotation

Some principles for a healthy rotation:

Enough people. As a rough guide, at least six to eight people per rotation, so each person is on call around one week in six or eight. With fewer than four or five, it gets very hard to sustain.
Primary and secondary. A second person as backup means nobody feels completely alone, and there's a fallback if the primary can't respond.
Reasonable shift lengths. One week is common. Some teams split weekdays and weekends.
Follow the sun if you have teams in different time zones: each region covers its own daytime, so nobody gets paged at night.
Easy swaps. Life happens. Make trading shifts simple and normal.
Proper handovers: what happened during the last shift, what's still open, what to watch.
Onboarding: new people shadow an experienced engineer before going on call alone.

A healthy on-call rotation is measured by how well people sleep, not just by how fast they respond.

Fewer pages

The most effective way to improve on call is to reduce how often it's needed.

Every page must need urgent human action. If it doesn't, downgrade it to a ticket or remove it.
Alert on symptoms users feel, ideally SLO burn rates, not on every CPU spike.
Track pages per shift and review them weekly or monthly as a team.
Fix recurring causes. If the same alert fires every week, the fix belongs in the backlog with real priority.
Automate the known fixes. If the response to an alert is always "restart the service", automate it, and then fix why it needs restarting.
Protect deployments: avoid risky changes on Friday evenings and before holidays, and use progressive delivery so problems are caught early.

Google's SRE guidance suggests aiming for a small number of incidents per shift, so engineers have time to handle each properly and follow up. If your team regularly gets many pages per night, that's a reliability problem, not a people problem.

Being paid for it

On call is work. It limits your freedom, even when nothing happens. Fair compensation matters:

A standby allowance for being on call.
Extra pay or time off for actual incidents, especially at night and on weekends.
Time off after a bad night. If you were up at 3 a.m. fixing production, you shouldn't be expected at the 9 a.m. stand-up.

In Germany and much of Europe, working time and rest period rules also apply to on call. Rest periods after night work aren't just nice, they can be a legal requirement. Check with HR how your company handles it.

Support during incidents

Clear escalation paths. Who to call when you're stuck, at any hour.
Runbooks for every alert.
No blame. People need to feel safe asking for help or admitting they don't know.
Incident commander role for bigger incidents, so the person on call doesn't have to coordinate and fix at the same time.

Looking after yourself

Some personal habits that help me and colleagues:

Prepare at the start of your shift: laptop charged, VPN and access working, recent changes reviewed.
Set boundaries: on call means available, not glued to the screen. Live your life, just within reach.
Use a separate notification profile so only real pages break through at night.
Hand over properly at the end of your shift, and then actually switch off.
Talk about it. If on call is affecting your sleep, health or relationships, tell your manager. It's a signal the system needs fixing.

For managers

Look at the numbers: pages per shift, night pages, time to recover, and how people feel.
Treat on-call load as a reliability metric, and make reducing it a priority.
Make sure the people who build the systems share the on-call duty. It's the strongest incentive to build reliable software.
Join the rotation yourself, or at least the escalation path.

So, what's a good first step?

Look at last month's pages together as a team. Count how many needed action, and how many happened at night. Pick the three noisiest alerts and fix or remove them. That single meeting often makes the next month noticeably calmer.

My take: production systems need to be reliable, and so do the people who look after them. Protect both.

— Desly

Why tools alone don't make DevOps

Tue, 20 Oct 2026 23:10:30 +0200

I've seen companies "do DevOps" by buying tools. Kubernetes, a CI/CD platform, an observability suite, maybe a new team called "DevOps". A year later, releases are still slow and painful, developers still throw code over the wall, and the new DevOps team is just the old ops team with a new name and a longer ticket queue.

The tools aren't the problem. They're just not the point.

What DevOps was supposed to fix

The word "DevOps" was coined around 2009, when Patrick Debois organised the first DevOpsDays in Belgium. The problem it addressed was a human one: developers wanted to ship changes quickly, operations wanted stability. They had different goals, different managers and different incentives. So they fought, and software delivery was slow and fragile.

DevOps proposed bringing them together: shared goals, shared responsibility, shared tools, and a lot of automation so that speed and stability stop being opposites.

Notice the order. People and goals first, tools to support them.

The CALMS framework

A useful way to think about DevOps is CALMS, a framework popularised by Jez Humble and others:

Culture: shared responsibility, collaboration, learning from failure.
Automation: removing manual, error-prone work from building, testing, deploying and operating.
Lean: small batches, limiting work in progress, removing waste and waiting.
Measurement: data about delivery and reliability (like the DORA metrics), used to improve, not to punish.
Sharing: knowledge, tools, responsibility and success across teams.

Tools mostly cover the A and part of the M. The C, L, and S depend on how people work together.

Tools make good collaboration faster. They also make bad collaboration faster.

Signs of "DevOps in name only"

A DevOps team that receives tickets from developers and does all the deployment and infrastructure work for them. That's a new silo, not DevOps.
Developers never see production: no access to logs, metrics or alerts for their own services.
Blame after incidents: someone gets told off, nobody looks at the system.
Big, infrequent releases despite having a CI/CD tool.
Approval boards for every change, meeting once a week.
Tools chosen by one team and forced on others without asking what they need.

Breaking silos

What actually helps:

Shared goals. Developers and operations measured on the same outcomes: delivery speed and reliability, not one each.
"You build it, you run it", with support. Teams own their services in production, including on call, with platform teams making that manageable.
Platform teams that serve, building self-service tools that let developers move independently, instead of doing work for them.
Embedding: an SRE or platform engineer working within a product team for a while, sharing knowledge both ways.
Shared rituals: joint postmortems, shared dashboards, demos across teams.

Feeling safe to speak up

Google's research on team effectiveness, known as Project Aristotle, found that the most important factor in high-performing teams was psychological safety: the belief that you won't be punished for speaking up, asking questions, or admitting mistakes.

The DORA research says something similar: a generative culture, where information flows freely and failure leads to inquiry rather than blame, predicts better software delivery and better well-being.

In practice, psychological safety in DevOps looks like:

Blameless postmortems where the question is "how did the system allow this?", not "who did this?"
People saying "I don't know" or "I broke it" without fear.
Juniors comfortable asking questions in public channels.
Leaders admitting their own mistakes first.

Without it, problems get hidden, and hidden problems become outages.

Leading the change

If you want to move your organisation towards real DevOps:

Start with a pain point everyone feels: slow releases, painful deployments, frequent incidents.
Pick one team willing to try a different way. Show results.
Measure before and after (DORA metrics are great for this).
Invest in automation that removes the most painful manual work.
Change incentives: what gets rewarded and measured shapes behaviour more than any tool.
Get leadership support. Culture changes from the top as much as from the bottom.
Be patient. Culture change takes years, not sprints.

So, are tools useless?

Not at all. Good tools make good practices possible and scalable. But they come after the decision to work together differently, not instead of it.

My take: DevOps is something you practise, not something you buy. The tools are the easy part. The people are the point.

— Desly

Green DevOps: the carbon cost of our servers

Tue, 20 Oct 2026 23:10:30 +0200

It's easy to think of software as weightless. Code is just text, the cloud is just "somewhere". But every request, every pipeline run, every idle VM runs on physical hardware in a data centre that uses electricity and water, and was manufactured with real materials.

Data centres already use a noticeable chunk of the world's electricity, and the AI boom is making that number rise quickly. As the people who decide how much infrastructure runs and how efficiently, DevOps engineers have more influence over this than we often realise.

Why it matters now

Regulation. In the EU, the Corporate Sustainability Reporting Directive (CSRD) requires many large companies to report environmental impact, which includes IT. The Energy Efficiency Directive requires larger data centres to report energy and water use. Even where requirements have been scaled back or delayed, the direction is clear.
Customers and investors increasingly ask about emissions, including from digital services.
AI workloads are energy-hungry, and growing quickly.
Cost. Energy is a big part of what you pay for in the cloud. Wasted compute is wasted money and wasted carbon at the same time.

Where software emissions come from

Roughly three sources:

Operational energy: electricity used by servers, storage and networking while running your workloads.
Carbon intensity of that energy: the same kilowatt-hour can have very different emissions depending on where and when it's used. A grid powered by wind and hydro is much cleaner than one powered by coal or gas.
Embodied carbon: emissions from manufacturing the hardware. Using hardware more efficiently, and longer, spreads that out.

The Green Software Foundation defines a Software Carbon Intensity (SCI) specification, now an ISO standard, to calculate emissions per unit of work (for example per request or per user), combining energy, carbon intensity and embodied emissions.

Measuring it

You can't reduce what you can't see. Tools that help:

Cloud provider dashboards: AWS Customer Carbon Footprint Tool, Google Cloud Carbon Footprint, Microsoft's Emissions Impact Dashboard. Good for an overview, usually with a delay and limited detail.
Cloud Carbon Footprint: an open-source tool that estimates emissions from cloud billing data across providers.
Kepler (Kubernetes-based Efficient Power Level Exporter, a CNCF project): uses eBPF and hardware counters to estimate the energy use of individual pods and containers, exposed as Prometheus metrics.
Electricity Maps and WattTime: real-time and forecast carbon intensity data for electricity grids.
Carbon Aware SDK from the Green Software Foundation: helps applications use that data to make decisions.

The greenest compute is the compute you don't run. The second greenest is the compute you run efficiently, in a clean place, at a clean time.

What DevOps teams can do

Most of these are also cost optimisations, which makes them easier to justify.

Use less: - Delete idle and forgotten resources. - Right-size VMs, containers and databases. - Turn off non-production environments outside working hours. - Scale to zero where possible. - Keep observability data lean: fewer logs, sampled traces, shorter retention. - Avoid unnecessary CI runs (only build what changed, cancel outdated runs).

Use it more efficiently: - Increase utilisation by packing Kubernetes nodes better (Karpenter consolidation, honest resource requests). - Use energy-efficient hardware like ARM-based instances, which often use less energy for the same work. - Optimise hot code paths (continuous profiling helps find them). - Cache and compress to reduce network traffic and repeated work.

Use cleaner energy: - Choose regions with cleaner grids when latency and data rules allow. Regions in countries with lots of hydro, wind or nuclear typically have much lower carbon intensity. Cloud providers publish data about their regions. - Carbon-aware scheduling: run flexible workloads (batch jobs, training, reports, non-urgent CI) when or where the grid is cleaner. For example, shift a nightly job to the hours with the most wind power, or to a cleaner region.

Use hardware longer: - For on-premises, extending hardware lifetime reduces embodied emissions.

Carbon-aware scheduling, in practice

A simple version: a batch job that can run any time within the next 12 hours checks a carbon intensity forecast and starts in the cleanest window. Tools and Kubernetes projects are emerging to do this automatically, using KEDA scalers based on carbon intensity or schedulers that consider grid data.

It doesn't work for everything. User-facing requests need to run now, close to users. But a surprising amount of compute is flexible: data pipelines, model training, backups, test suites.

Saving money and CO₂ together

The nice thing about green DevOps: it rarely conflicts with good engineering. Efficient systems are cheaper, faster and greener. FinOps and sustainability teams often find they're working on the same list.

A useful habit: next to the cost of a service, show its estimated energy or carbon footprint. It gives engineers one more reason to clean up, and makes the impact visible.

So, where do I start?

Look at your cloud provider's carbon dashboard to get a baseline. Then do the efficiency work you'd do for cost anyway: remove waste, right-size, turn off what's idle. If you run Kubernetes, try Kepler to see energy per workload. And for your next batch workload, ask whether it could run at a cleaner time or in a cleaner region.

My take: every idle server is burning money and carbon for nothing. Efficient infrastructure is good engineering, good business and good for the planet, all at once.

— Desly

DevOps in 2026: what changed this year

Tue, 20 Oct 2026 23:10:30 +0200

Every year in DevOps feels busy. But looking back at 2026, a few shifts stand out as more than the usual churn of new tools. Some of them change how the job feels day to day. Here's my look at what changed, what's fading, and what I expect next.

The big shifts

1. AI agents moved into the workflow

The biggest change of the year. AI went from autocomplete and chat windows to agents that read a repository, run commands, fix failing builds and open pull requests. Tools like Claude Code, GitHub's coding agent and others became a normal part of many teams' workflows.

With that came new work for DevOps: deciding what agents may touch, sandboxing them, giving them narrow credentials, and making sure every change still goes through review and CI. The Model Context Protocol (MCP) became the standard way to connect AI to tools like Kubernetes, GitHub and observability platforms, along with a new class of security concerns, especially prompt injection.

2. Platform engineering became the default model

"Platform engineering" stopped being a buzzword and became how many organisations structure their teams: platform teams building golden paths and self-service tools, product teams owning their services. The conversation matured from "should we have a portal?" to "is our platform actually reducing cognitive load?"

3. Goodbye ingress-nginx, hello Gateway API

The retirement of ingress-nginx in March 2026 forced one of the biggest Kubernetes migrations in years. For many teams, it was the push to finally adopt Gateway API, which is now the default way to route traffic into clusters.

4. Supply chain security got serious, and regulated

After a run of high-profile supply chain attacks (compromised GitHub Actions, self-spreading npm worms, hijacked maintainer accounts), pinning, signing, SBOMs and provenance moved from "best practice" to "expected". In the EU, the Cyber Resilience Act's reporting obligations started applying in September 2026, with the full requirements coming in December 2027.

2026 was the year we stopped trusting our dependencies by default, including the AI ones.

5. Infrastructure as code split into two paths

Terraform and OpenTofu continued to diverge, each with features the other lacks. Teams now make a real choice rather than defaulting to one tool.

Related: Terraform or OpenTofu?

6. Cost and sovereignty became infrastructure topics

FinOps became a normal part of engineering work, helped by the FOCUS billing standard. In Europe, digital sovereignty moved from niche to boardroom, with hyperscalers launching sovereign offerings and European providers gaining attention. Some companies also continued moving steady workloads off the public cloud.

7. AI workloads changed infrastructure

GPUs, model serving and LLM observability became regular infrastructure concerns. Kubernetes features like Dynamic Resource Allocation matured, and projects for serving LLMs on Kubernetes grew quickly.

8. OpenTelemetry won

OpenTelemetry is now the default way to instrument systems, with Prometheus 3 speaking OTLP natively and profiling arriving as a fourth signal. The new focus is cost: collecting less, but better.

What's fading

Hand-written YAML from scratch. Generated, templated or AI-drafted, then reviewed.
Long-lived cloud keys in CI. OIDC has become the norm.
Sidecar-heavy service meshes. Sidecarless modes are taking over.
Manual certificate renewal. Shrinking certificate lifetimes make automation unavoidable.
"DevOps team" as a ticket queue. Replaced by platform teams and real ownership.
Jenkins for new projects. Still running a lot of pipelines, rarely chosen fresh.

What's rising

Agent guardrails as a discipline: permissions, sandboxes, audit logs for AI.
Policy as code everywhere, from Kubernetes admission to Terraform plans to AI tool calls.
eBPF-based tools for networking, security and zero-instrumentation observability.
Post-quantum readiness: crypto inventories and hybrid key exchange.
Green and efficient infrastructure, driven by both cost and reporting.
Reviewing as a core skill: reading diffs and plans critically, because so much is now generated.

My predictions for next year

Most routine pull requests in infrastructure repos will be opened by bots or agents, with humans reviewing.
An AI-agent-related security incident will become a widely discussed case study, and push the industry towards stricter agent sandboxing standards.
The CRA's full application in December 2027 will make SBOMs and vulnerability handling a standard part of every release process in Europe.
Gateway API will be the only routing API most new tutorials teach.
Platform teams will start measuring developer experience as seriously as uptime.

8/10

My verdict

The film balances moral complexity with sharp dialogue, though its slow pacing occasionally softens the tension of its choices.

— Desly

Blood Simple — Frances McDormand's intensity anchors the chaos

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

John Getz portrays a man trapped by his own indecision, making his eventual downfall both inevitable and tragic. McDormand’s performance is quietly explosive, suggesting layers of resentment beneath her calm exterior. The script gives the characters few clear motives, which makes their actions feel more like impulses than calculated decisions.

The Coens use a stylized visual style that can take attention away from the emotions at the heart of the story. The dialogue is sharp and full of dry humor, but it doesn’t always make the characters’ true intentions clear. The film moves slowly, letting quiet tension build before sudden bursts of violence interrupt the calm.

M. Emmet Walsh and Dan Hedaya bring a weary cynicism that contrasts with Getz’s confusion. Samm-Art Williams adds a menacing presence without overplaying his role as a hired killer. The film’s structure keeps the audience guessing, but not always in a satisfying way.

The film struggles to balance the characters’ inner conflicts with the violent actions they take. As the Coens’ debut, it shows promise but sometimes favors style over substance. Even with its flaws, Blood Simple is still a compelling look at guilt, betrayal, and failing morally.

8/10

My verdict

The film’s tension comes from its characters’ flawed choices rather than plot twists. The Coens balance moral ambiguity with sharp dialogue, though some scenes feel overly stylized.

— Desly

Barton Fink — A playwright's unease in a strange town

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

Barton Fink arrives in Hollywood with ambition, only to find himself isolated by his own expectations and the eerie quiet of the Hotel Earle. The dialogue is sharp, often laced with double meanings that reflect the characters' hidden anxieties and unresolved pasts. John Turturro conveys a nervous energy that makes Barton Fink's descent into paranoia feel personal rather than theatrical.

The hotel setting feels oppressive, like the walls are closing in on Barton's shaky grip on reality. John Goodman's Charlie Meadows provides comic relief but also adds real moments of connection and vulnerability. The Coen brothers use silence well, letting tension build without needing jump scares or big reveals.

Judy Davis brings a subtle menace to her role, adding depth to the film’s exploration of identity and performance. Michael Lerner's portrayal of the hotel manager adds to the surreal atmosphere with his cryptic behavior and unsettling presence. Steve Buscemi contributes a darkly humorous edge that contrasts with the more serious themes of the story.

The jump from comedy to thriller feels rough in spots, breaking the film’s steady mood. Some subplots, like Barton's chats with other guests, are underdeveloped and feel a bit forced. But despite these issues, the film is still a strong look at artistic pressure and mental unease.

1991 · English. Film details

8/10

My verdict

The film's claustrophobic tone and layered dialogue reveal the slow unraveling of Barton Fink's confidence. The Coen brothers balance humor with creeping dread, but some tonal shifts feel abrupt.

— Desly

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

Reese Witherspoon’s portrayal of a high school student caught in an adult power struggle is both sharp and vulnerable. Matthew Broderick plays a manipulative teacher with a veneer of charm that hides his moral decay. Chris Klein's character is defined by his quiet desperation, which contrasts effectively with the more flamboyant roles around him.

The dialogue is fast-paced and leans into exaggerated tones that highlight the film's satirical side. It moves between absurdity and real tension without losing its comedic rhythm. The story keeps going even when some character motives aren't fully clear.

Witherspoon’s performance gives the film a grounded emotional core amid its satire. Broderick’s timing is impeccable, but his role risks becoming a caricature rather than a fully realized person. Klein’s quieter moments provide a necessary counterbalance to the film's louder humor.

The script relies a lot on wit, which can make the characters feel more like types than real people. Still, the film stays engaging thanks to its sharp writing and good performances. It works well as a comedy, but sometimes gives up depth for jokes.

8/10

My verdict

The film balances satire and sincerity, but its humor occasionally overshadows the emotional stakes beneath the surface.

— Desly

About Schmidt — A quiet reckoning with regret

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The film follows a retired judge dealing with his life’s failures after his wife’s death. It sets up a melancholic tone that doesn’t quite match the comedy-drama label. His journey to meet his estranged daughter drives the narrative, but the emotional stakes feel underdeveloped in key moments. Alexander Payne tries to balance humor and sorrow, but the tonal shifts between scenes often feel jarring rather than intentional.

The direction leans on long silences and awkward pauses, which sometimes enhance the mood but also stretch the film’s runtime unnecessarily. The script gives Nicholson room for reflection, but the supporting characters lack the same depth or motivation. Hope Davis portrays the daughter with sincerity, but her role is limited to a few key scenes that don’t fully justify her screen time.

Jack Nicholson delivers a nuanced performance, capturing the loneliness of a man confronting his own failures with quiet dignity. His timing and delivery suggest years of experience, making even small moments feel weighted with meaning. Kathy Bates plays the late wife with warmth, but her limited presence prevents a deeper exploration of the central relationship.

The film’s humor feels forced in places, especially when it tries to undercut the heavier themes with lightweight dialogue. There is a clear attempt at emotional resonance, but it often falls short due to pacing choices that emphasize detachment over engagement. Despite its flaws, About Schmidt remains a thoughtful, if uneven, portrayal of aging and regret, anchored by Nicholson’s performance.

7/10

My verdict

Jack Nicholson's performance anchors the film, but its emotional weight is undercut by uneven pacing and tonal shifts that dilute the central themes.

— Desly

Sideways — A man's frustration with life and love

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

Two men embark on a wine-tasting road trip that becomes an unintentional therapy session for one of them. Miles Raymond's cynicism is both a shield and a barrier, making his eventual vulnerability hard-earned but satisfying. Jack Cole's charm and self-deprecation create a dynamic contrast to Miles' bitterness.

The film moves at a calm pace, like the characters' winding trip. Each wine-tasting scene hides a quiet tension between what they expect and what actually happens. The dialogue skips over clichés, using jokes to hide bigger worries.

Paul Giamatti conveys Miles' exhaustion without ever making him unlikable or pitiable. Thomas Haden Church brings a warmth that keeps Jack from becoming a caricature of his own flaws. Sandra Oh and Virginia Madsen add emotional stakes without overshadowing the central dynamic.

The romantic parts feel like side effects rather than main points, which is both good and bad. Some scenes push the premise for laughs rather than real growth. But the film's honesty about middle-age struggles makes it stick with you.

8/10

My verdict

The film balances humor and heartache, but its romantic elements feel secondary to the character-driven comedy. The performances elevate the material beyond its premise.

— Desly

The Descendants — A father's grief reframed through family tension

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The central conflict revolves around a man confronting his daughter’s accident while navigating strained relationships with his ex-wife and stepchildren. George Clooney's performance anchors the emotional core despite the script's occasional missteps. Shailene Woodley adds depth as the estranged daughter, though her role is constrained by the narrative’s focus on the father.

The dialogue leans more on cleverness than real emotion, which throws off the film's tone. Alexander Payne keeps things sharp overall, but sometimes the irony gets in the way of the real feelings. The pacing jumps around between quiet moments and satire, which can mess with how emotions build up.

Beau Bridges and Judy Greer deliver grounded performances that contrast with the script’s more stylized moments. The father-daughter dynamic is compelling but underexplored in favor of broader family conflicts. Matthew Lillard's role as a lawyer adds levity but lacks narrative purpose beyond comic relief.

The film tries to handle grief and making up with people, but it ends up oversimplifying those heavy topics. Some scenes feel too planned out, turning deep emotions into jokes or dramatic moments. Still, it does a decent job showing how messy and awkward the healing process can be, even if it's not perfect.

7/10

My verdict

The film balances humor and heartbreak but leans too heavily on its premise, reducing emotional stakes to a structural gimmick.

— Desly

Win Win — A man's lies begin to unravel

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The story hinges on a coach’s ethical compromise and the ripple effects of his choices. His lies are small at first, but they accumulate into something more troubling for everyone involved. The film does not excuse the behavior, but it also avoids outright condemnation.

Tom McCarthy’s direction keeps the tone light but doesn’t fully address the moral weight. Scenes move quickly, balancing dialogue with quiet tension. The pacing is efficient, but some emotional beats feel rushed in favor of comedic timing.

Paul Giamatti conveys the character's internal conflict without overacting. His voice and body language suggest a man trying to convince himself as much as others. Amy Ryan and Melanie Lynskey provide sharp contrast with their more grounded, honest performances.

The film’s humor is smart but sometimes clashes with its moral questions. Some jokes land well, but they sometimes undercut the emotional stakes. Overall, it succeeds as a character study rather than a fully satisfying drama.

7/10

My verdict

The film balances dark humor with emotional stakes, but its moral ambiguity leaves some questions unanswered. Paul Giamatti anchors the central tension with a layered performance.

— Desly

The Visitor — A lonely man's quiet transformation

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The central conflict is the slow unraveling of a man’s assumptions about himself and others, set against New York’s post-9/11 backdrop. His initial detachment gives way to unease as he becomes entangled with an immigrant couple living in his apartment. The film relies on small moments to suggest deeper themes, but these often feel underdeveloped.

The film moves slowly, giving time for quiet observation but also making some scenes feel stretched, especially when the dialogue isn’t urgent or emotionally clear. It goes from isolation to a tentative connection, but never really finds a satisfying emotional ending.

Richard Jenkins gives a controlled performance, avoiding big gestures but showing inner conflict. Haaz Sleiman and Danai Gurira bring quiet dignity to their roles, but their reasons for acting the way they do aren’t fully explained. The dialogue leans on explanation rather than natural conversation, making the emotional stakes feel a bit distant.

The film’s strength is its willingness to sit with uncomfortable feelings rather than offer a neat resolution. But this approach might leave some viewers feeling disconnected from the themes. Despite its flaws, The Visitor is a thoughtful, if uneven, look at identity and belonging.

7/10

My verdict

Richard Jenkins conveys a subtle shift in perspective without melodrama. The film’s emotional stakes are undercut by its own restraint.

— Desly

Junebug — A quiet tension beneath polite exchanges

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

Junebug is about a family meeting where old and new problems are hidden under normal talk. The characters speak carefully, like they're avoiding something big. This slow pace creates a mood, but it can make it hard for the audience to follow what's really going on.

The film is quiet, focusing on pauses instead of big moments. It lingers on small actions, but these feel slow and without clear reasons. The story depends on what's not said, which can make the conflicts feel weak.

Amy Adams gives a warm and honest performance without overdoing it. Ben McKenzie and Embeth Davidtz hold the film together with controlled acting that hints at bigger stories. The dialogue is simple, leaving a lot to the audience to figure out, but sometimes that makes the story unclear.

The film's quiet style feels more like a choice than something that comes naturally. There are times when the emotions feel forced by the tone. Even with its flaws, Junebug does show a kind of fragile connection through its careful, slow storytelling.

7/10

My verdict

The film mixes humor and sadness but holds back too much, so the emotional parts don't fully come through even with good acting.

— Desly

You Can Count on Me — A fractured bond tested by time

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

Sammy's isolation is shown through small, everyday interactions that reveal her loneliness without needing to spell it out. Her relationship with her brother is built on shared history rather than dramatic confrontation. The film avoids melodrama by focusing on the subtle shifts in their connection over time.

The direction keeps things calm, letting silence and glances do most of the work. Scenes move at a steady pace that matches the characters' inner struggles. It's not fast-paced, which might bore people looking for more drama.

Laura Linney portrays Sammy with quiet strength, conveying vulnerability without overt emotion. Mark Ruffalo brings a grounded presence to his role, balancing warmth with underlying resentment. Dialogue feels natural, avoiding cliché while still revealing the characters' histories.

The film moves slowly, which can feel tedious but also lets the emotions sink in. Some scenes depend on what's not said rather than what's spoken, so you have to pay attention. Even with its slow approach, it stays interesting because of how it explores personal relationships and regret.

8/10

My verdict

The film balances emotional depth with a measured pace, though its quiet moments occasionally test the patience of those seeking more overt drama.

— Desly

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The robbery is not just about money but about personal desperation and familial pressure, shaping the characters' choices. John Wojtowicz's actions are driven by a need to provide for his ill mother, adding complexity to his role as a criminal. The script avoids making him a villain, instead focusing on the emotional and moral ambiguity of his situation.

Sidney Lumet’s direction keeps the tension high without rushing toward resolution or moralizing too quickly. The pacing is deliberate, letting the audience sit with the characters instead of pushing them away. Longer scenes feel natural, capturing the anxiety of a hostage situation without fake urgency.

Al Pacino conveys vulnerability beneath his bravado, making Wojtowicz relatable despite his crimes. John Cazale's performance as the conflicted police officer adds another layer to the moral complexity. Dialogue is sharp and realistic, often revealing hidden fears or desires without heavy-handed exposition.

There are moments where the film leans too heavily on its real-life origins, which can make the story feel less original. But the emotional core stays strong, keeping the focus on human struggle rather than just crime. The film’s strength is in not simplifying its characters or their choices, giving a nuanced look at morality.

9/10

My verdict

The film balances a criminal act with the emotional stakes of those involved. Al Pacino's performance elevates the tension beyond mere spectacle.

— Desly

Dogville — A stage set as a moral landscape

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The film unfolds in a single, bare space that becomes a metaphor for human morality and exploitation. Grace's arrival disrupts the town's fragile peace, revealing hidden cruelties beneath polite surfaces. The townspeople's decisions are tested through escalating demands on Grace, pushing them toward moral collapse.

The direction has a strong theatrical feel, which can make the emotions feel a bit removed at times. The pacing is slow but builds tension gradually, with pressure increasing as the story moves forward. The simple set design doesn't offer much visual relief, which makes the emotional weight of each scene feel heavier.

Nicole Kidman's performance is restrained yet emotionally charged, anchoring the film's moral gravity. Paul Bettany and Stellan Skarsgård bring layered complexity to their roles as town leaders with hidden ambitions. The dialogue often feels heightened, echoing stage conventions that may not fully serve the story's emotional core.

There is a risk of intellectualizing the drama at the expense of raw human emotion. The film's ambition overshadows its quieter moments, which can feel underdeveloped in comparison. Despite this, the moral inquiry remains compelling, asking difficult questions about complicity and survival.

8/10

My verdict

Dogville's sparse design forces attention on the characters' choices. The moral dilemmas feel urgent, even if the structure risks abstraction.

— Desly

Duel — A silent threat behind the wheel

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The central conflict is a man being stalked by an unknown driver, making the danger feel personal and inescapable. Dennis Weaver portrays a commuter whose vulnerability is heightened by the isolation of his situation. The script avoids explaining the trucker’s motives, which keeps the threat ambiguous but persistent.

Spielberg uses long stretches of quiet driving to show the passenger's helplessness. Not seeing the trucker adds to the pressure on the protagonist. The film keeps a steady rhythm that doesn't let up or get repetitive, even though it's short.

Dennis Weaver conveys fear without melodrama, grounding his performance in believable reactions. Jacqueline Scott and Carey Loftin provide brief but effective supporting roles that contrast with the main tension. Dialogue is minimal but purposeful, often reinforcing the protagonist’s isolation and confusion.

The film sometimes relies too much on its own idea, which can make the tension feel predictable. Its best part is how it uses space and sound to turn a simple car ride into a life-or-death situation. Duel still works because it lets the audience feel the fear without explaining everything.

8/10

My verdict

The unseen menace creates tension through absence rather than presence. The film's focus on the driver’s fear elevates it beyond simple chase tropes.

— Desly

The Hitcher — A predator in the backseat

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The film follows a stranded driver and a hitchhiker whose motives are unclear from the beginning. There's a clear sense of danger, but it's hard to tell if that danger is real or imagined. The characters don't have much depth, which makes their conflict feel more like a setup than a real story.

The direction keeps the tension high with tight framing and limited settings, but it doesn't let up for long. The dialogue is tense, but it lacks the emotional depth needed to make the threat feel personal. The film moves quickly, but it never slows down enough to let the audience catch their breath or think about what's happening.

Rutger Hauer brings a calm menace that is convincing in moments, though his character lacks a clear motivation beyond violence. C. Thomas Howell plays his role with nervous energy, but his fear never fully justifies the escalating danger around him. Jennifer Jason Leigh’s presence adds some emotional weight, but her scenes are limited to brief exchanges without much development.

The film's atmosphere is its strongest point, but it overshadows the characters. The threat feels more like a gimmick than a real danger. It does a good job of building suspense, but the lack of character depth weakens the impact of the ending. Despite its flaws, The Hitcher is still an effective example of how to create tension, even if it feels a bit formulaic at times.

7/10

My verdict

The Hitcher leans into its own tension, but never fully justifies its violence. Rutger Hauer’s menace is effective but not entirely convincing as a sustained threat.

— Desly

The Driver — Ryan O'Neal’s silence speaks volumes

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

Ryan O’Neal plays a criminal who avoids confrontation, making his eventual conflict feel inevitable yet emotionally thin. Bruce Dern’s detective is methodical, but lacks the personal stakes that would make his pursuit more urgent. Isabelle Adjani’s role adds some emotional weight, though her screen time remains limited and underdeveloped.

The film has a steady pace, avoiding big action scenes but finding it hard to build suspense from regular heists. The dialogue is short and to the point, not really showing why the characters are doing what they're doing. Walter Hill focuses more on the mood than on moving the story forward, which creates a feeling but not much forward motion.

O’Neal’s performance is controlled but lacks vulnerability, making his choices feel more like a puzzle than a personal tragedy. Adjani’s presence hints at deeper themes, but they are left unexplored due to the film’s restrained approach. Dern’s character remains professional yet emotionally flat, which limits the stakes of his conflict with O’Neal.

The film is well-structured, but its emotional heart doesn't match its style. It works as a stylish example of restraint but struggles when it needs to connect with people. Its quiet confidence is effective until the end, where its moral uncertainty becomes more confusing than interesting.

7/10

My verdict

The Driver balances tension with a detached tone, but its emotional distance softens the impact of its moral choices.

— Desly

Thief — A heist film with quiet tension

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The film centers on a safecracker trying to escape his criminal past, but the real focus is his strained connection with his wife. There's tension in how much he trusts her, and whether she truly wants to leave the life behind. Michael Mann avoids flashy action sequences, favoring close-ups that emphasize the weight of each decision.

The direction keeps the audience in the room with the characters rather than following them on a chase. Long pauses and sparse dialogue make the emotional stakes feel immediate and unflinching. The film's rhythm is deliberate, letting quiet moments carry as much tension as any break-in sequence.

James Caan portrays the lead with controlled intensity, never letting his character become a caricature of crime. Tuesday Weld brings a grounded presence that contrasts with the high-stakes world around her. Their conversations feel real, with pauses and hesitations that suggest a history beyond what's shown.

The film occasionally leans too heavily on its own atmosphere, risking emotional detachment. At times, the pacing feels slow without enough narrative urgency to justify it. Still, the focus on personal stakes over spectacle makes this heist story feel more intimate and human.

8/10

My verdict

The slow-burn pacing and emotional stakes elevate the crime above standard genre fare. The central relationship feels lived-in rather than manufactured.

— Desly

Manhunter — A profiler's past haunts his present work

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

Will Graham’s return to the field is driven by a need to understand his own limits rather than just solving a case. Michael Mann builds atmosphere through silence and careful pacing, letting the isolation of the characters speak for itself. The script often leans on exposition rather than showing Graham's internal conflict in real time.

William Petersen shows Graham’s exhaustion without overdoing it, making his struggle feel real rather than dramatic. Tom Noonan brings menace to Dollarhyde through small gestures and calm dialogue. Brian Cox plays the FBI agent with quiet confidence, but his character doesn’t get much depth.

The film’s focus on the killer’s perspective risks overshadowing the profiler’s emotional journey. The score and cinematography enhance the mood without overpowering the narrative’s quieter moments. Joan Allen’s presence adds emotional depth to Graham’s personal life, though her role is limited.

Some scenes drag, especially the ones with the killer in prison. The film has strong performances and a good tone, but it never really decides if it’s horror or a police story. Still, Manhunter is a solid early example of how the serial killer genre can explore real psychological tension.

1986 · English. Film details

7/10

My verdict

The film balances psychological tension with procedural detail, but its emotional core feels underdeveloped despite strong performances.

— Desly

To Live and Die in L.A. — A chase with no clear exit

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

Two Secret Service agents pursue a counterfeiter whose crimes blur the line between artistry and criminality. Their mission becomes as much about personal obsession as professional duty, complicating their sense of justice. The script rarely pauses to question whether their pursuit is worth the cost in human terms.

William Friedkin directs with tight framing, keeping the audience at a distance. The editing moves quickly between scenes, emphasizing urgency but sometimes making things hard to follow. The score supports the film’s mood without overpowering quieter moments.

William Petersen conveys determination without much interior conflict, making his character feel functional rather than fully realized. Willem Dafoe brings a dangerous charm to his role, hinting at deeper layers beneath the surface performance. John Pankow grounds the film in bureaucratic realism, offering a contrast to the more flamboyant characters.

The pacing is fast but can feel repetitive, making key confrontations less emotionally powerful. The tension between duty and desire isn’t explored much, with action scenes taking priority. Still, the film stays engaging because of its clear, if limited, vision.

7/10

My verdict

The film balances tension and moral ambiguity, but its procedural focus leans too heavily on spectacle rather than character depth.

— Desly

Sorcerer — Four men carry a deadly burden

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

Each man's history haunts their steps as they transport unstable explosives across treacherous terrain. Their motivations are buried beneath layers of regret and survival instinct, rarely spoken but always present. The stakes are not just external—each carries a personal reckoning that threatens to unravel them.

Friedkin keeps the tension tight without flashy tricks or fake suspense. The journey moves slowly, with long stretches of silence broken by sudden, violent moments. There's no clear ending—just the slow fading of hope as the burden gets heavier.

Roy Scheider conveys desperation without melodrama, his performance grounded in physical exhaustion. Francisco Rabal and Bruno Cremer embody the quiet despair of men who have nothing left to lose. Their dialogue is sparse but charged with unspoken histories and simmering distrust.

The film's pace sometimes drags under its own symbolism. Some scenes feel too long, testing patience with their bleakness. But the emotional heart stays strong: it's about redemption through endurance.

8/10

My verdict

The film balances physical peril with psychological strain. Its tension lies not in escaping danger, but in the weight of past choices.

— Desly

Point Blank — Lee Marvin's brooding presence anchors the film

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

Marvin plays a man seeking revenge for his wife’s murder, but his motives remain emotionally distant, complicating the audience's investment. The script gives him few lines that reveal inner conflict, leaving much to his physicality and measured delivery. His co-stars deliver solid performances, but their roles often feel secondary to Marvin's presence.

The film moves quickly through its plot beats, but some scene transitions lose the urgency of earlier parts. There’s a deliberate slowness in certain moments that breaks the tension built by the action. Still, the direction keeps the story focused on Marvin’s character without over-explaining his choices.

Angie Dickinson portrays his wife with emotional restraint, but her role is limited to memory and backstory. Her scenes are brief but impactful, suggesting a deeper tragedy beneath the surface. The dialogue often feels clipped, as if designed to reflect the urgency of the protagonist’s mission rather than character development.

There is an occasional stiffness in the performances that makes emotional stakes feel less immediate. This is especially true during moments meant to convey grief or regret, which are underdeveloped compared to the action sequences. Still, Marvin’s grounded performance and the film’s sharp pacing ensure it remains a compelling, if uneven, entry in the crime genre.

7/10

My verdict

The film balances moral ambiguity with a taut narrative, though its pacing falters in quieter moments. Marvin’s performance remains its most consistent strength.

— Desly

Get Carter — A mood of weary resolve

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The tone is grim, shaped by the protagonist’s relentless pursuit of justice in a world that offers no easy answers. His moral certainty clashes with the chaos around him, but this tension isn’t explored much. The dialogue is terse, giving the film a grounded feel but also limiting how much emotion it can show.

The pacing moves steadily forward without much variation, relying on the protagonist’s single-minded focus to keep things moving. There are moments where the tension between what’s expected and what happens feels sharp, but they’re not consistently developed. The lack of clear stakes beyond revenge weakens the emotional impact, even though the atmosphere is heavy.

The performances suggest a character driven by purpose rather than complexity, which fits the film’s tone but limits how much it connects with the viewer. The protagonist’s actions match his goals, but his internal motivations are vague. Supporting characters don’t give much insight into the main figure beyond what’s needed for the plot.

The film’s strength is its atmosphere rather than its character development or themes. This makes it a solid but ultimately unremarkable entry in the crime genre, with few lasting impressions beyond its mood. Its restrained approach works within its own limits, but it doesn’t elevate it beyond being a competent, if forgettable, experience.

7/10

My verdict

The film balances bleak realism with moments of dry wit, but its emotional core feels underdeveloped despite the protagonist's clear determination.

— Desly

The Hit — A tense exchange without a clear exit

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The film unfolds through tight conversations that feel urgent yet incomplete, leaving room for suspicion rather than resolution. The protagonist's actions are driven by necessity, but their internal conflict remains underexplored, making their choices feel pragmatic rather than emotionally resonant. Dialogue is clipped and purposeful, emphasizing the high stakes without offering much in the way of personal insight.

The direction keeps the tension high, but the setting feels static and repetitive because of the lack of visual variety. The pacing is deliberate, but some scenes drag without adding to the story or character development. The film relies on the uncertainty of its situation instead of showing the emotional cost of its choices.

Performances are grounded but restrained, which fits the mood but makes it harder to connect with the audience emotionally. The supporting characters feel more like obstacles than fully developed people, which weakens their role in the main conflict. There's a clear sense of danger, but it's not tied to personal stakes that would make the outcome feel important.

The structure keeps the viewer engaged, but the lack of emotional payoff makes the overall impact weaker. Some moments hint at deeper themes, but they're left unexplored to keep the tension going. Despite these issues, The Hit is a taut and watchable example of suspenseful storytelling.

7/10

My verdict

The Hit balances suspense with character moments, but its emotional reach is limited by the pacing and lack of depth in its central relationship.

— Desly

The Offence — A detective's guilt wears thin over time

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The detective’s crime is not just an act, but a burden he must carry through repeated confrontations with his own conscience. Each flashback reveals more about Johnson than the victim, making the audience question whether justice or vengeance is truly at stake. The structure creates tension by forcing the viewer to live alongside Johnson's unraveling thoughts.

Lumet’s direction keeps the scenes tight, but the tone sometimes feels repetitive, which softens the urgency of the crisis. The flashbacks are well-timed, yet they repeat emotional moments without adding much new. The pacing is slow, and it can feel like the film lingers too long on Johnson’s internal struggle instead of moving the story forward.

Sean Connery delivers a restrained performance that avoids melodrama but struggles to fully convey the depth of his character’s turmoil. Trevor Howard and Vivien Merchant provide strong support, grounding the film in moments of emotional clarity. The dialogue is sparse but effective, often revealing more through silence than explicit confession.

The repetition of Johnson's crime feels necessary for its thematic weight, yet it risks making his guilt feel less like a burden and more like a routine. There’s a certain elegance to the film’s moral ambiguity, even if its emotional core is occasionally diluted by its own structure. Despite its flaws, The Offence remains a powerful, if uneven, exploration of how far a man will go to justify his actions.

7/10

My verdict

The film’s tight focus on moral disintegration is compelling, but its emotional depth is undercut by a repetitive rhythm that softens the impact of its central tragedy.

— Desly

The Hill — A prison of the mind and body

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The film centers on a group of prisoners forced to build a hill under brutal conditions, their fates tied to the success of the project. Their desperation and conflicting loyalties are revealed through terse exchanges and glances that carry unspoken weight. The Hill's emotional core lies in how men respond to powerlessness, with no clear escape from their shared fate.

The film focuses on the monotony of physical labor, which reflects the characters' mental exhaustion. The pace doesn't change much, so the suffering might feel more like a routine than a real experience. Without big dramatic moments or a clear ending, some viewers might feel lost by the time it's over.

Performances are understated but effective, with actors conveying inner turmoil through subtle shifts in posture and tone. Dialogue is sparse but charged, often revealing tensions that remain unresolved for much of the film. The actors’ restraint allows the audience to focus on the oppressive atmosphere rather than overt emotion.

The film shows how cruel systems can be without using drama or overacting. Its slow build might frustrate people looking for emotional release, but it gives a thoughtful look at power and obedience. Even with its pacing problems, The Hill is still a strong look at how people endure extreme pressure.

8/10

My verdict

The Hill's rigid structure and slow pacing create a claustrophobic tension that is both oppressive and methodical, though its deliberate rhythm may test patience.

— Desly

The Pawnbroker — Rod Steiger's silence speaks volumes

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

Steiger’s portrayal of a traumatized pawnbroker anchors the film in quiet despair and moral ambiguity. His character's internal conflict is shown through pauses and glances rather than direct confession or exposition. The screenplay avoids easy resolutions, focusing instead on the emotional aftermath of violence.

Lumet’s direction uses stillness to show the protagonist’s isolation. The film feels heavy and somber, with few bright moments. Some scenes drag, and the dialogue can feel too long without a clear reason.

Geraldine Fitzgerald and Brock Peters provide emotional counterpoints but are secondary to Steiger’s performance. Their interactions reveal the protagonist's fractured psyche through subtle tension and unspoken history. Dialogue is sparse but weighted with subtext, demanding attention from the viewer.

The film’s focus on trauma can feel too narrow, limiting its bigger themes. But its emotional heart is strong and deeply human. Steiger’s performance lifts the material, making it a gripping, if slow, look at guilt and survival.

8/10

My verdict

The film captures the emotional weight of trauma without melodrama. Its pacing is deliberate but occasionally slow, testing patience.

— Desly

Seconds — A disquieting look at identity and transformation

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The central dramatic situation revolves around a man seeking escape through radical change, only to find himself trapped in a new existence he cannot control. Rock Hudson portrays a man unraveling beneath the surface of his new identity, hinting at inner turmoil without overt expression. His performance is restrained, allowing the audience to infer his emotional state from subtle shifts in behavior.

The dialogue feels stiff and rehearsed, showing how disconnected the characters are from who they used to be. John Randolph is cold and efficient as part of The Company, making the transformation process feel clinical. The film takes its time, with long stretches that highlight the main character's isolation and confusion.

Salome Jens brings an eerie quality to her role, with her lines hinting at deeper layers beneath the surface. The film moves through stages of transformation, each more unsettling than the last, but it never gives clear answers. The mix of psychological horror and sci-fi elements sometimes feels unresolved or underdeveloped.

The atmosphere is consistently heavy, focusing on the main character's inner struggle rather than action. Even with its flaws, the film's look at identity is still compelling and makes you think. The heart of it is the question of whether change can ever be truly freeing or if it just swaps one prison for another.

8/10

My verdict

The film's unsettling tone and deliberate pacing elevate its psychological tension, though the ending feels slightly detached from its earlier unease.

— Desly

The Swimmer — A man's delusion becomes a burden

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The central conflict revolves around a man who believes he is swimming through his own neighborhood, losing grip on reality. His journey reflects a descent into personal failure and the erosion of social connections. The film's surreal tone is grounded in the protagonist’s deteriorating mental state.

The film takes its time, focusing on quiet, lonely moments instead of rushing to a big emotional payoff. The visuals match the main character's confusion, but some parts drag and repeat themselves. The slow pace makes you sit with the discomfort rather than giving quick emotional fixes.

Burt Lancaster conveys a fragile pride beneath the surface of his character’s denial. His performance balances bravado with vulnerability, making the collapse feel earned. Janice Rule and Marge Champion provide emotional anchors in otherwise abstract scenes.

The script uses symbols a lot, but not always clearly. Sometimes the film's vague style feels more like a choice than something the story really needs. Still, it's a strong look at self-deception and downfall.

7/10

My verdict

The film balances poetic decay with emotional collapse, but its slow rhythm risks alienating viewers who crave resolution.

— Desly

Birdy — A friendship tested by war and identity

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The film tells the story of two friends whose friendship is tested by their time in the Vietnam War. It uses flashbacks and a frame narrative to show their bond, which is the heart of the film. But the ending feels messy and unclear. The back-and-forth between past and present builds tension, but it also makes things confusing at times.

The film's pacing is all over the place. Some parts feel too fast, while others drag on without much point. The flashbacks do show us more about their relationship, but they don't always carry the emotional weight needed to hold the story together. The film tries to explore themes like identity and trauma, but it doesn't really commit to any one angle.

Matthew Modine and Nicolas Cage deliver nuanced performances, capturing the fragility of their characters. Their chemistry is believable, especially in quieter moments where their connection feels genuine. However, the dialogue sometimes leans into melodrama, undermining the subtlety of their emotions.

The film's best parts come from its visuals rather than its script. It often uses tired ideas about war and masculinity without giving us anything new. Even with its flaws, Birdy is still a gripping, if flawed, look at friendship and the damage war can do.

1984 · English. Film details

7/10

My verdict

The film captures the psychological toll of war but falters in balancing its characters’ inner lives with external events. The performances are strong, yet the narrative occasionally feels fragmented.

— Desly

The Last Picture Show — Small-town dreams and fading hope

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

Two high-school friends navigate growing up in a town that offers few options beyond repetition or departure. Their friendship is tested by ambition, desire and the weight of expectation from their community. The film's focus on male adolescence feels both intimate and universal, shaped by the setting and time period.

Bogdanovich's direction focuses on quiet moments, letting silence show the characters' regrets. The scenes move slowly at first, then build to sudden emotional moments, creating a natural rhythm. Some parts feel too slow, making tense moments less urgent than they could be.

Jeff Bridges and Timothy Bottoms embody the tension between loyalty and personal aspiration without overacting. Their chemistry is subtle but convincing, grounding the film's more dramatic themes in real, flawed relationships. Ellen Burstyn and Cloris Leachman add weight to the town's decaying atmosphere with their grounded performances.

The film's nostalgic tone can make its critique of stagnation feel soft. But the characters' real emotions make up for any pacing or tone issues. It's still a touching look at youth, memory, and time, with enough depth to stay relevant.

8/10

My verdict

The film balances nostalgia with the ache of missed chances. Its emotional core is its greatest strength, even if its pacing occasionally softens the impact.

— Desly

Five Easy Pieces — Jack Nicholson's brooding stillness

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

Jack Nicholson carries the film with a presence that feels both detached and deeply wounded, anchoring the story in quiet frustration. Bobby Dupea is a man caught between his working-class reality and an unfulfilled artistic potential, a conflict that drives much of the drama without needing exposition. The script avoids melodrama by focusing on small, awkward interactions that reveal the character’s inner turmoil.

The direction keeps scenes grounded in real-time tension, avoiding theatrical flourishes that might soften the character's edges. The pacing is deliberately slow, mirroring Bobby’s reluctance to confront his past or his identity. This approach might feel slow for some, but it lets the emotional stakes build gradually rather than being forced by plot mechanics.

Karen Black and Susan Anspach provide sharp contrast to Nicholson's stoicism, their dialogue often laced with biting honesty. Their performances highlight Bobby’s isolation without ever reducing him to a passive figure in their stories. The film’s weakness is that it doesn’t fully explore the emotional fallout of Bobby’s decisions, leaving some threads dangling without resolution.

This ambiguity may frustrate viewers expecting catharsis but aligns with the character's own indecision and emotional paralysis. The restraint in direction and dialogue gives the film a raw authenticity that feels more real than polished. Despite its flaws, the film remains a compelling study of identity and disconnection, anchored by Nicholson’s powerful, understated performance.

8/10

My verdict

The film's emotional core lies in its reluctance to offer easy resolutions. The tension between Bobby’s past and present remains unresolved but deeply felt.

— Desly

The King of Comedy — A darkly funny obsession with fame

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The central conflict revolves around a man's desperate pursuit of stardom through a dangerous connection with a comedian. De Niro’s character is both pitiable and repulsive, embodying the film’s critique of fame’s corrupting allure. Jerry Lewis plays a figure of influence who remains morally ambiguous throughout.

The dialogue leans into exaggerated humor that doesn’t always match the film’s darker themes of violence and manipulation. Sandra Bernhard’s lines are sharp and highlight the absurdity of media obsession. The pacing is uneven—some parts drag, while others move too fast to let the emotions sink in.

De Niro’s performance is intense but occasionally overwrought, especially in moments of self-pity. Lewis’s character is underdeveloped, making his moral choices feel inconsistent. Bernhard’s wit provides a necessary counterbalance to the film’s darker impulses.

The film has a strong satirical edge, but its tone and focus sometimes waver. Its critique of media culture still feels relevant, even if the story feels a bit forced in places. Despite these issues, it does capture the uneasy tension between ambition and morality.

8/10

My verdict

The film explores how far someone will go for a moment in the spotlight, but its tone occasionally undermines its own bleakness.

— Desly

After Hours — A night out that spirals into absurdity

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

Paul Hackett stumbles through a series of bizarre encounters as he tries to return home after a night out in New York. His journey becomes increasingly surreal, with each new situation compounding his frustration and bewilderment. The film’s humor arises from the contrast between Paul's desperation and the absurdity of his surroundings.

Scorsese keeps the tension high by moving quickly between scenes, without needing jump scares or big thrills. The city feels like another character, changing around Paul as he walks its streets. Each situation is short but packed with meaning, avoiding long speeches or clear answers.

Griffin Dunne conveys Paul's vulnerability and confusion without overacting or melodrama. His performance keeps the character grounded even when the plot becomes increasingly farcical. Supporting actors deliver sharp, concise lines that reflect their own peculiarities without overshadowing Paul’s plight.

The film relies too much on its own idea in the later parts, turning some characters into stereotypes. Still, the mix of humor and tension works for most of the movie. After Hours is successful because it makes you feel Paul's confusion as he moves through a night that never really makes sense.

8/10

My verdict

The film's rhythm balances dark humor with escalating tension. The central character’s confusion mirrors the audience's disorientation.

— Desly

Alice Doesn't Live Here Anymore — A woman and her son on a journey with no clear destination

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

Alice's struggle to rebuild her life is presented without melodrama, focusing instead on small choices and quiet frustrations. The journey westward becomes a metaphor for emotional uncertainty rather than a plot-driven mission. Ellen Burstyn conveys weariness without bitterness, grounding the film in realism.

Scorsese’s direction feels more natural than showy, but it can leave some viewers feeling underwhelmed. The dialogue relies on repetition and subtext, which might make the emotional moments harder to grasp. Supporting actors like Harvey Keitel add some texture, but they don’t really lift the central conflict above its limits.

Diane Ladd’s performance as a friend adds warmth but lacks depth in her limited screen time. Kris Kristofferson’s presence feels more like a stylistic choice than a narrative necessity. The film’s humor arises from situational irony rather than character-driven wit, limiting its emotional resonance.

The characters don’t really connect with each other, which feels honest but might frustrate people looking for catharsis or closure. Even with its flaws, the film still manages to be a compelling look at a woman trying to find her place in a world that doesn’t seem to care.

7/10

My verdict

The film balances humor and hardship but never fully resolves the tension between its characters' needs and the road they're on.

— Desly

The Age of Innocence — A love that cannot be spoken aloud

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

Newland Archer is trapped between his marriage and a forbidden attraction, but the film never lets us know which path he truly wants. The film explores how social expectations can silence the most urgent emotions, leaving only gestures to convey what cannot be said. Daniel Day-Lewis embodies the internal conflict without needing explicit confession, making his restraint the story's quietest force.

Scorsese focuses on quiet moments — pauses, looks — that hold a lot of feeling. The film moves slowly, like Archer trying to decide between love and duty. Every scene with Countess Olenska feels like a test, showing how close he is to breaking the rules of his life.

Michelle Pfeiffer conveys vulnerability without melodrama, letting her character's defiance emerge through small, controlled choices. Winona Ryder plays May as both loyal and stifled, showing how love can be suffocating when bound by duty. The dialogue is precise, often indirect, leaving room for what is not said to carry the emotional weight.

The film might accidentally make the era's limits seem more appealing than they are. Sometimes, the quiet approach feels like it's holding back emotion instead of letting it flow. But the acting and how the story is told still make the hidden feelings feel real and important.

8/10

My verdict

The film's emotional core lies in what remains unsaid. The performances anchor the tension between duty and desire, even when words fail.

— Desly

The Assassination of Jesse James by the Coward Robert Ford — Brad Pitt as Jesse James is a performance of quiet, burning obsession

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

Brad Pitt embodies Jesse James with a magnetic stillness that feels both haunted and dangerous. Casey Affleck’s Robert Ford is a portrait of obsession, his eyes betraying the weight of his admiration and fear. The relationship between the two men is the film's heartbeat—tense, layered, and psychologically rich.

Andrew Dominik uses long shots and silence to let the mood carry the story. The wide angles make even busy scenes feel lonely. The slower pacing during quiet moments can feel slow, but it also helps you feel the emotional weight.

Mary-Louise Parker's performance adds a haunting undercurrent to the film’s moral complexity. Paul Schneider and Jeremy Renner provide grounding as supporting figures caught between myth and reality. The dialogue is sparse but deliberate, often carrying subtext that lingers beyond its delivery.

The film sometimes treats Jesse James’ legend with too much respect. This makes the moral questions feel less sharp than they could be. Still, the way Jesse and Robert’s relationship plays out keeps the story emotionally powerful.

8/10

My verdict

The film captures the intoxicating pull of myth and the slow unraveling of a man's legend. The pacing sometimes lags but never distracts from the emotional core.

— Desly

The Proposition — A tense moral bargain in the Australian outback

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The main conflict is a man forced to kill his brother or let someone else die. It raises ethical questions but doesn't offer clear answers. The setting highlights how isolated the characters are in their moral choices, though the story sometimes leans into melodrama. The dialogue is short and direct, matching the harsh world but sometimes missing emotional depth.

The film uses wide shots to show the vastness of the outback, which mirrors the characters' emotional distance. The editing keeps tension high but can feel rushed, leaving little time to develop the side characters. The main conflict is strong, but the supporting roles often feel underdeveloped and focused on the main story.

The protagonist's internal struggle is portrayed with a mix of grit and ambiguity, avoiding easy moral judgments. Performances are grounded but limited by the script’s occasional lack of subtlety in emotional beats. The film’s violence is starkly presented without excessive stylization, which adds to its unsettling atmosphere.

The central idea is heavy, but the way it's put together sometimes feels limited by its own themes and structure. The moral complexity is there but not always fully explored because the story moves quickly, focusing more on plot than on deeper thinking. Despite these issues, the film is still a gripping look at guilt, duty, and survival in a tough environment.

7/10

My verdict

The film balances brutal violence with uneasy morality, but its pacing and tone occasionally undermine its own tension.

— Desly

Badlands — A restless heart in a broken world

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

Holly's youthful perspective frames the killings as something distant, yet her actions escalate toward inevitability. Kit's charm masks a deepening instability that the film never fully explains but constantly implies. The relationship between Holly and Kit is built on shared purpose rather than emotional connection.

The direction focuses on small moments—like a car ride or a glance—to show the weight of their choices without being obvious. The dialogue feels natural, avoiding the exaggerated speech common in crime films from that time. There's no heavy moralizing; the violence is shown with little shock but a steady sense of discomfort.

Martin Sheen and Sissy Spacek share a chemistry that suggests mutual dependence rather than love or obsession. Their performances avoid histrionics, letting their actions speak for the emotional stakes. Warren Oates plays the lawman with quiet authority, never overreaching into caricature.

The film moves at a slow pace, matching Holly's perspective and the gradual breakdown of their lives. Sometimes, the film's restraint might feel like it's holding back from the tension, but it avoids being overly emotional. Its best part is how it makes the audience feel involved in a way that feels natural rather than forced.

8/10

My verdict

The film balances innocence and violence with quiet unease. The performances hold the tension without melodrama or overstatement.

— Desly

A Face in the Crowd — A charismatic threat without a weapon

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The central drama is built on a man's rise to fame through manipulation and self-promotion, masking deep personal flaws. His growing influence is shown through how others react to him, not just what he says or does. The film avoids outright condemnation by showing his appeal as genuine, if misguided.

The film moves at a steady pace, building from admiration to unease. Scenes don't feel rushed or dragged out. The dialogue is sharp but not overdone, letting the characters' moral struggles come through naturally. The tension grows through small changes in tone rather than big dramatic moments.

Andy Griffith carries the role with a mix of likability and menace that keeps the audience unsettled. His performance balances charm with unsettling unpredictability, making his downfall feel inevitable yet tragic. Patricia Neal and Walter Matthau provide emotional depth as those who recognize his flaws but are powerless to stop him.

The film's strength is that it doesn't paint its characters as simple villains or saints. Sometimes, the moral complexity feels a bit forced, slowing the story down a little. But the film still works as a strong warning about the risks of letting public adoration go unchecked.

1957 · English. Film details

8/10

My verdict

The film explores the danger of public adoration for a man who hides his cruelty behind charm. The performances anchor the satire in real emotional stakes.

— Desly

Sweet Smell of Success — A toxic dance of ambition and manipulation

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

Two men dominate the screen: one a ruthless press agent, the other a desperate playwright. Their relationship is built on control and resentment. Burt Lancaster's character exudes cold authority, while Tony Curtis plays his subordinate with simmering frustration. The script forces both men to constantly outmaneuver each other, making every exchange feel like a battle for survival.

The film moves quickly, with long pauses that make the tension between the two men feel heavier. Small actions—like a glance or a pause—hint at bigger conflicts. The dialogue is short but pointed, often hiding real intentions behind friendly words.

Lancaster's performance is chillingly calculated, never allowing his character to show vulnerability. Curtis conveys desperation through subtle shifts in tone and body language. Supporting actors add texture without overshadowing the central dynamic between the leads.

The film keeps its dark mood from getting too heavy by adding dry humor. It makes the audience feel like they're part of the characters' games, even though it's not clear who's right. The characters are so well done and the story is so tight that it still hits emotionally.

9/10

My verdict

The film's tension lies in the power struggle between two men with opposing goals. The dialogue crackles with subtext, revealing hidden motives beneath polite conversation.

— Desly

Ace in the Hole — Kirk Douglas as a manipulative reporter

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

Kirk Douglas plays a man who exploits others while claiming to fight for truth, creating a tense moral conflict. His character's charm and ruthlessness make him both compelling and deeply unsettling in his actions. The story hinges on his ability to manipulate people and events toward his own gain, often with tragic results.

Wilder keeps the tension high but sometimes leans into melodrama. The script moves quickly, but some character motivations feel underdeveloped by the time the climax arrives. Scenes are tightly written, yet the pacing sometimes outpaces the emotional weight of the situation.

Kirk Douglas delivers a performance that is both charismatic and morally ambiguous, anchoring the film’s tension. Jan Sterling’s role as his wife adds depth to the moral conflict but lacks the screen time needed for full development. Their dialogue crackles with tension, revealing layers of betrayal and desperation without over-explaining.

The central theme of exploitation is clear, but the resolution feels abrupt in its judgment of the characters involved. Despite this, the film remains a sharp critique of media sensationalism and personal greed. Its flaws are minor compared to its bold storytelling and strong performances, making it a memorable drama.

1951 · English. Film details

8/10

My verdict

The film’s moral decay is balanced by sharp dialogue, but the ending feels rushed compared to its buildup.

— Desly

The Ox-Bow Incident — A town's fury turns to guilt

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The town’s anger at a murdered rancher leads to swift, brutal action that later feels irreversible. A group of men, including two outsiders, form a posse convinced of their right to punish the accused. Their certainty is built on incomplete information and collective fear, not proof.

The direction keeps tension tight without flashy visuals or sudden reveals. It moves steadily toward a moral reckoning rather than a plot twist. There are few moments of relief from the pressure of what they've done.

Henry Fonda’s performance is quietly intense, showing the weight of his choices without histrionics. Dana Andrews conveys the unease of someone caught between duty and doubt. Mary Beth Hughes brings a quiet strength to her role, contrasting with the men's aggression.

The film’s moral clarity is its strongest feature, but it occasionally leans too heavily on its own message. At times, the direction feels too calculated in delivering its lesson rather than letting it unfold naturally. Still, the emotional stakes remain high enough to make the message feel earned rather than imposed.

8/10

My verdict

The film exposes the dangers of mob justice with a restrained tone. The performances anchor its moral weight without melodrama.

— Desly

The Treasure of the Sierra Madre — A search for gold becomes a test of trust

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

Two men join an old prospector in a desperate hunt for gold, but their relationships shift as the stakes rise. The dialogue often hides what is truly at risk, making conversations tense without being melodramatic. John Huston's direction keeps the focus on how people act under pressure rather than on the landscape or action.

The film moves at a steady pace, showing how the characters' decisions reveal who they really are. Walter Huston plays his part with experience without becoming a wise old man stereotype. His scenes with Humphrey Bogart show how desperate people can get and how that desperation can make it hard to know who to trust.

Tim Holt's performance adds youthful recklessness that contrasts with the older men's caution. The tension grows from what is left unsaid rather than from loud confrontations or plot twists. There is a quiet power in how the characters' goals shift as they uncover more about themselves.

The slow pace might feel too calm for some, but it gives time for the emotions to sink in without rushing to a finish. The film doesn't offer simple solutions, leaving the audience thinking about whether gold is worth losing what makes you human.

9/10

My verdict

The film balances greed and friendship with careful pacing. The performances make the moral dilemmas feel urgent rather than didactic.

— Desly

The Grapes of Wrath — Hardship without the loss of dignity

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The Grapes of Wrath is especially good at showing how much effort it takes to retain a little dignity when the practical conditions of life keep worsening. John Ford keeps the family at the centre of that pressure. Their needs are immediate and understandable, which gives the wider social questions a human scale.

Henry Fonda plays Tom Joad with a directness that feels more real than simple heroism. He makes anger understandable without making every response comfortable. Jane Darwell brings a different kind of strength as Ma Joad. Her focus on keeping the family together gives the film an emotional thread that a series of hardships alone wouldn't provide.

The dialogue works because the people speaking usually need something more immediate than an argument. They want work, shelter, an explanation or a little consideration. Larger ideas emerge from those needs. I liked how the film allows a plain exchange to carry political weight without making the characters seem aware that they are delivering a lesson.

The time period and style are clearly shown, but the central issues still feel relevant. The film understands the difference between admiring endurance and accepting the conditions that make it necessary. That difference gives its compassion real weight. The performances make the family worth caring about before the film asks what their treatment says about the world around them.

8/10

My verdict

The Grapes of Wrath makes economic hardship felt through a family rather than an abstract argument. Henry Fonda and Jane Darwell give John Ford’s film a human strength that still carries enormous weight.

— Desly

The Last Detail — A duty that becomes a test of patience

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

Two sailors are forced to take a recruit on a long journey, testing their own limits and his vulnerability. The dynamic between the older sailor and the younger recruit reveals tension beneath the surface humor. The film leans into the absurdity of the situation without fully committing to its emotional gravity.

The film moves quickly, but it doesn't spend much time on what matters most. There's a rhythm to the journey, but it often feels more like going through a list than telling a story. The mood shifts suddenly between funny and serious, which makes it feel a bit off-balance.

Jack Nicholson brings a weary charm that grounds the film's more chaotic moments. His character's cynicism masks a deeper frustration with authority and responsibility. Randy Quaid and Carol Kane add tension but struggle to match Nicholson's presence in quieter scenes.

The humor sometimes feels fake, which takes away from the real emotions in the story. The film isn't sure if it wants to be a comedy or a character study. But the way the characters interact is still interesting enough to keep people watching.

7/10

My verdict

The film balances dark humor with moral unease, but its tone falters in the final act. Nicholson's performance remains its most consistent anchor.

— Desly

The Commitments — Colm Meaney's frustration is convincing

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

Colm Meaney carries the film with a believable mix of ambition and self-doubt, anchoring the story in real frustration. The script gives Jimmy Rabbitte a clear goal, but the supporting roles feel more like stage props than fully realized people. The musical numbers are lively, yet they occasionally distract from the characters' personal stakes.

Alan Parker keeps the film moving with a steady energy, but it doesn’t pause long enough for the quieter emotional moments. The dialogue is sharp and often funny, but it leans too much on Dublin slang, which might not land well with everyone. The story moves quickly, leaving little time to dig into why the characters act the way they do.

Robert Arkins adds some humor as a band member, but his role lacks the weight of the central story. The Commitments is at its best when focusing on Jimmy's personal drive rather than the group dynamic. There’s an uneven balance between comedy and drama that keeps the film from fully resonating.

The music is a big part of what makes the film enjoyable, but it can’t make up for the underdeveloped side characters. The film has a clear charm, but it doesn’t quite back up its emotional goals. It’s a fun, lively movie with some heartfelt moments, but it doesn’t always keep its energy up for long.

7/10

My verdict

The Commitments leans on charm and music but lacks the emotional depth to fully commit to its characters' struggles.

— Desly

The Loneliness of the Long Distance Runner — A solitary figure against institutional pressure

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The main character's loneliness comes through in how he runs, not in what he says or argues. There's a quiet struggle between what he wants and what's being forced on him. The film doesn't show us his thoughts much, which makes it harder to connect with him emotionally.

The film moves forward at a steady pace but doesn't let us look deep inside his mind. The lack of a clear ending feels on purpose, but it might leave the audience feeling a bit disconnected. The direction keeps things visually simple, sometimes at the cost of emotional clarity.

The acting is low-key but doesn't give enough depth to understand his decisions. He carries himself with a certain calm, but it doesn't always grab you. The dialogue is minimal but often feels like it's getting in the way instead of helping.

The film's message about personal freedom is clear, but it feels a bit distant. The way it's put together might be on purpose, but it sometimes hides how emotionally involved we're meant to be. It's still a thoughtful film, even if it doesn't fully reach its emotional goals.

1962 · English. Film details

7/10

My verdict

The film mixes youthful rebellion with a feeling that things can't be changed. It has a strong emotional centre, but the story relies too much on its own setup.

— Desly

The Killing Fields — A war-torn city as a character in its own right

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The central conflict revolves around survival amid chaos, where moral choices are rarely clear or kind. Characters move through a city that feels like an antagonist, shaping their fates with indifference. The film’s pacing allows moments of quiet despair without rushing toward resolution.

The film shows destruction and loss through visuals rather than explicit violence. The dialogue is minimal but heavy with meaning, carrying the weight of what's left unsaid. The tragedy unfolds slowly, matching the characters' confusion and exhaustion.

Performances are understated yet powerful, conveying trauma through silence as much as speech. The lack of named actors does not hinder the emotional impact of their roles. Each interaction feels urgent but incomplete, reinforcing the sense of entrapment.

One issue is that the film's focus on suffering can feel repetitive in how it shows despair. There are moments where the story leans too much on its grim subject without giving much relief. Still, it's a strong look at how people endure in the face of overwhelming destruction.

8/10

My verdict

The Killing Fields captures the brutality of war without needing to explain every detail. The film’s emotional core is its refusal to look away from suffering.

— Desly

The Year of Living Dangerously — A crisis of identity amid political unrest

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The main conflict is a journalist getting caught up in a foreign revolution, but his personal struggles don't get enough attention compared to the outside chaos. The film moves quickly, which makes the quieter, emotional moments feel rushed and disconnected. It tries to connect the personal and political sides of the story, but they often feel like separate things.

The visuals show the setting's instability well, but the protagonist's emotional journey isn't fully grounded. Conversations between characters feel forced, like they're trying to carry both the personal and political tension on their own. It's unclear how the journalist's choices are shaped by his environment or his inner struggles.

The acting shows promise but doesn't have the depth needed to make the character's choices feel urgent or real. The supporting cast seems more focused on the setting than the emotional journey of the main character. Important scenes rely on dialogue that feels more like explanation than emotional connection.

The film has big ambitions, but some emotional parts don't get resolved. The historical context is interesting, but it doesn't fully match up with the personal journey of the main character. This mismatch makes some of the most powerful scenes feel a bit disconnected, leaving the overall experience slightly off-balance.

7/10

My verdict

The film balances personal turmoil with historical upheaval, but its emotional core is often overshadowed by its ambition.

— Desly

The Quiet American — A love affair with dangerous consequences

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The central conflict is a romantic entanglement that becomes a moral trap for the characters involved. Michael Caine's character navigates guilt and responsibility with a measured tone, but his motivations remain underexplored. Brendan Fraser plays an idealist whose conviction clashes with the real-world violence around him.

The film moves between fast-paced political scenes and slower emotional moments, but the rhythm doesn't always feel right. Conversations often feel like they're delivering information rather than showing how characters think or feel. The setting is well done, but it doesn't really affect what's going on inside the characters.

Michael Caine's performance anchors the film, even when the script offers little depth for his character. Brendan Fraser conveys youthful fervor but lacks the emotional range to carry the film's moral weight. Supporting actors contribute to the atmosphere without overshadowing the central relationship.

The film has a clear message about politics, but it doesn't really tie that message to what's happening with the characters. Some scenes use dialogue that feels more like lessons than real emotions. Even with its problems, it does a decent job showing how idealism can run into real-world problems.

7/10

My verdict

The film balances personal tragedy and political tension, but its emotional core feels underdeveloped compared to the sharp dialogue and setting.

— Desly

The American — A quiet performance in a loud setting

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

George Clooney portrays an assassin seeking anonymity, but his performance remains emotionally distant despite the role's potential for depth. The script offers few clear motivations, leaving the character's actions underdeveloped and his internal conflict vague. The film leans heavily on visual tension rather than dialogue or character development to maintain suspense.

The scenes drag because there's no clear story or emotional hook. The side characters don't add much beyond a tense vibe, and they don't help the main character or the story's moral questions feel more real. The film focuses more on mood than on substance, which makes it feel like a style experiment rather than a complete thriller.

Clooney's presence is steady but underutilized, with few moments allowing his subtlety to shine through the film's colder tone. Dialogue often feels artificial, lacking the natural rhythm needed to support the film's dramatic and psychological ambitions. The pacing is uneven, with some sequences moving too slowly while others feel rushed or disconnected from the central mystery.

There are some ideas about identity and morality, but they don't get much attention or development. The film uses visuals instead of clear storytelling, which makes it feel like it's aiming higher than it actually hits. Still, Clooney's performance is steady, and there are moments where it feels like there's more depth than the script lets him show.

6/10

My verdict

George Clooney's restrained acting contrasts with the film's tense atmosphere, but the narrative lacks urgency and emotional stakes to match its ambitions.

— Desly

The Duellists — A duel of patience and pride

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The film is about two men locked in a rivalry driven by pride and honor. Their repeated clashes feel more like rituals than real conflicts. The focus on form over urgency makes their struggle feel repetitive and less emotionally engaging.

The film uses silence and stillness to show the weight of history between the two men. Their dialogue is sparse but full of unspoken tension and grudges. However, the lack of background detail makes their motivations feel distant and more symbolic than personal.

The actors give controlled performances with moments of warmth, especially when showing hesitation or doubt. They use posture and eye contact to show tension rather than big gestures. This can work well, but it also leaves some ambiguity that feels unresolved rather than intentional.

The film’s structure is elegant but sometimes weakens its emotional impact. Its themes of honor and repetition are interesting, but the formal style can make the characters feel more like symbols than real people. It’s a good meditation on pride, but the characters don’t always feel fully human.

7/10

My verdict

The film balances restraint with tension, but its pacing occasionally saps the emotional stakes. The central conflict feels more ritual than urgent.

— Desly

The Cook, the Thief, His Wife & Her Lover — A quiet tension between desire and violence

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The story reveals its stakes through small, intimate moments between characters. It takes its time building relationships, which can feel like a deliberate pause rather than a natural rhythm. The tension between passion and violence remains unresolved, leaving some emotional threads unfinished.

The pacing gives space for quiet intimacy but also drags in scenes that could have been tighter. The dialogue is restrained, as if the characters are holding back from full emotional expression. This distance might make it harder for the audience to connect with them.

The lead performers convey desire and conflict without overacting, which adds to the film's subtlety. Their performances suggest inner turmoil but rarely expose it fully to the viewer. Supporting roles add texture but do not always serve the central emotional arc clearly.

The film’s look is rich and atmospheric, adding to its mood of decadence and decay. But this visual focus sometimes drowns out the urgency of the main conflict. The film feels like it has potential that never fully comes together into a satisfying emotional experience.

7/10

My verdict

The film balances sensuality with brutality, but its emotional core feels underdeveloped. The central conflict is compelling but rarely fully realized.

— Desly

The Draughtsman's Contract — A drawing becomes a threat

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The draughtsman’s commission creates a situation where art and violence collide in a way that feels intentional and uncomfortable. The quiet scenes hint at a deeper anxiety hidden beneath polite talk and precise lines. The film moves slowly, but it relies on repetition more than it builds toward a strong emotional peak.

The dialogue has a tense edge without ever turning confrontational. Characters speak clearly, but their reasons stay just out of reach, like the draughtsman’s incomplete drawings. The film looks clean and controlled, but its emotional punch doesn’t match its visual precision.

Performances are restrained, which fits the tone but limits the depth of character engagement. There is a sense of restraint that keeps the drama from fully breaking through the surface formality. The draughtsman’s obsession with accuracy becomes a metaphor for the film’s own careful construction.

Even with its elegance, the emotional heart feels a bit far from the viewer. The tension is there, but it doesn’t fully settle in a way that gives the audience what they want. Its formal beauty is clear, but it leaves some emotional ground untouched.

7/10

My verdict

The Draughtsman's Contract balances tension with elegance, but its emotional stakes feel slightly restrained by its formalism.

— Desly

The Devils — A clash of wills and faith

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

A man's unwavering belief in his visions puts him at odds with a rigid system that demands obedience over truth. The pressure of conformity creates a personal struggle that feels urgent yet underdeveloped in its resolution. The film leans into silence and suggestion rather than overt drama, which risks distancing the audience from the central conflict.

The pacing is deliberate, allowing tension to build without rushing toward resolution or explanation. This measured approach emphasizes the psychological stakes but may leave some viewers wanting more direct engagement with the characters' turmoil. The dialogue carries weight, especially in moments where conviction is challenged by authority.

The performances suggest internal conflict without overexplaining motivations, which can feel both restrained and effective. There are moments when the emotional core of the story feels slightly obscured by the film's formal restraint. The tension between personal truth and institutional power remains the central force driving the narrative forward.

The film’s refusal to offer easy answers aligns with its themes but may leave some questions unresolved. This ambiguity is a strength in some respects, yet it also prevents deeper exploration of the characters' inner lives. Despite these limitations, The Devils maintains a compelling focus on the moral and spiritual stakes at its heart.

8/10

My verdict

The Devils explores the tension between spiritual conviction and institutional control. Its restrained approach leaves some emotional weight unexplored, but the core conflict remains sharp.

— Desly

Don't Look Now — A performance that lingers in the silence

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The central dramatic situation is a couple grappling with grief and an unclear threat, their emotions layered beneath polite restraint. The actors convey inner turmoil without overt gestures, relying on pauses and glances to suggest deeper conflicts. This restraint allows the audience to project their own fears onto the characters’ ambiguous actions.

The film moves slowly, spending time in quiet, uneasy moments instead of pushing toward a quick ending. There are long parts with little dialogue but lots of unspoken tension, letting the audience fill in the gaps. The director avoids typical horror tricks, building fear through small details in the environment and the emotional distance between characters.

The lead performance is understated yet deeply affecting, capturing a man’s struggle to hold onto reality. The supporting cast adds complexity without overshadowing the central couple’s dynamic, their interactions hinting at hidden tensions. Dialogue is sparse but precise, with each line carrying multiple meanings depending on context.

One thing that feels off is how much the film relies on suggestion, sometimes leaving emotions underdeveloped. Still, the acting and mood stick with you after the movie ends. The mix of mystery and real feelings makes it a quiet, powerful but slightly unfinished experience.

8/10

My verdict

The film’s tension lies not in its plot but in how characters navigate their own confusion. The direction leans on suggestion rather than explanation, with one notable exception.

— Desly

Angel Heart — A city of shadows and secrets

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

Harry Angel's search for Johnny Favorite is driven by a mix of curiosity and desperation that feels personal rather than professional. The film's setting in New Orleans adds an eerie texture to the unfolding mystery but does not fully justify its supernatural elements. Mickey Rourke brings a brooding intensity to Harry, grounding the surreal aspects of the plot with a sense of tangible struggle.

Alan Parker's direction focuses more on mood than on making things clear. Some scenes feel more like they're trying to set a tone than move the story forward. The pacing is slow, and a few parts drag without really adding tension or revealing much about the characters. Lisa Bonet and Charlotte Rampling add to the film's mysterious feel with performances that are vague but not without emotion.

Robert De Niro's role adds a layer of moral ambiguity, though his screen time feels limited in its impact. Dialogue often leans into poetic ambiguity rather than clear exposition, which can frustrate as much as it intrigues. The film's refusal to fully explain its supernatural elements leaves some questions unanswered but also risks alienating the audience.

The film has a certain charm in not giving everything a neat ending, even if it sometimes sacrifices clarity for mood. The emotional parts are clear, but they don't always match up with the more out-there supernatural ideas. Despite its flaws, Angel Heart is still an interesting mix of noir and supernatural mystery.

7/10

My verdict

The film leans into its noir tone but falters in balancing mystery with emotional depth. The cast delivers strong performances, yet the narrative becomes overly cryptic.

— Desly

The Serpent and the Rainbow — A slow unraveling of folklore and fear

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The story revolves around a journalist investigating claims of real zombies in Haiti, following the non-fiction accounts of Wade Davis. This premise offers a unique angle but lacks the sharp focus needed to make it compelling or immersive. The film's approach to the subject feels more like an academic exercise than a gripping narrative.

Wes Craven's direction is respectful but cautious, avoiding deeper exploration of cultural or psychological themes. Bill Pullman plays his character well, but he stays emotionally distant from the material he's investigating. Cathy Tyson and Paul Winfield add depth to their roles, though the script doesn't give them much to work with.

The dialogue often feels academic or detached, making it hard to connect with the audience on a personal level. The central mystery unfolds too slowly, and the stakes don't feel urgent. The film's tone wavers between eerie and inert, never fully committing to either.

Its reliance on folklore without deeper exploration weakens its impact as a horror story. The slow pacing and infrequent scares make it more curious than frightening. Despite its intentions, The Serpent and the Rainbow feels like an intriguing idea that never quite reaches its full potential.

6/10

My verdict

The film leans heavily on its source material but struggles to translate ethnobotanical intrigue into emotional or narrative urgency. The pacing feels drawn out, diluting the tension.

— Desly

The Entity — A house that refuses to be safe

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The film's central conflict is a woman trapped in a home she cannot escape, besieged by an invisible force. Her isolation is clear, but the narrative often prioritizes shock over psychological depth. Barbara Hershey portrays fear with conviction, though her character’s choices sometimes lack clarity.

The film moves at an inconsistent pace, with long quiet stretches followed by sudden horror scenes. The sound design helps build tension, but the unease doesn’t last long. The invisible entity is never clearly shown, so its presence feels more suggested than real.

Barbara Hershey’s performance anchors the film, even when the script falters. Ron Silver’s role as her husband adds some emotional complexity but remains underdeveloped. Dialogue often feels rushed, with little time to explore the characters’ fears or motivations.

The film uses a lot of supernatural clichés, which makes it feel unoriginal. There’s one moment where the protagonist faces the unknown that actually feels unsettling, but it gets lost in the usual horror tropes. Even with its flaws, the film has a certain old-fashioned fear that still feels real in some quiet scenes.

6/10

My verdict

The Entity leans heavily on jump scares and supernatural clichés, with limited success in building tension or emotional stakes.

— Desly

Images — A mind unraveling in isolation

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

A woman's battle with her sanity is at the heart of the film, set in a remote place that makes her isolation feel worse. Her fear and confusion are shown without being over the top, using small changes in tone and actions. The film has a creepy mood, but its strange logic sometimes makes it hard to follow.

The film uses silence and stillness to create a heavy, lingering mood in every scene. There's not much dialogue, which adds tension but also leaves some emotional moments feeling incomplete. The pacing is slow, letting quiet fear build, but it can drag when it needs to be clearer.

Susannah York shows vulnerability without overdoing it, making her breakdown feel real and personal. Her performance gives the film's more abstract parts a solid base of fear and confusion. René Auberjonois adds to the unease as a character whose reality is unclear, making the main character's confusion worse.

The film's ambiguity is its best feature but also its biggest problem—some questions stay unanswered. There are times when the horror feels more like a mood than something that hits you emotionally. Even with its flaws, Images does a good job of showing how hard it is to tell real life from illusion when your mind is unstable.

7/10

My verdict

The film builds tension well, but its ambiguity gets in the way. The main character's mental decline feels real, but the story never really comes together.

— Desly

Dead Ringers — Jeremy Irons as twins with a shared obsession

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

Jeremy Irons embodies both twins with such precision that their differences feel like variations on the same emotional axis. Their shared obsession with female anatomy becomes a metaphor for their inability to distinguish self from other. The script leans heavily on dialogue to reveal inner conflict, which risks feeling more intellectual than visceral.

Cronenberg's direction keeps a cold, clinical feel, which makes the psychological horror more intense but also makes some moments of raw emotion feel distant. Geneviève Bujold plays their patient with restraint, adding a layer of uncertainty to the power struggles in the film. The quieter scenes drag a bit, with long internal monologues that don't always feel necessary or satisfying.

Irons avoids making the twins feel like caricatures, giving their downfall a more tragic than grotesque edge. The film's best part is how it keeps the audience guessing, never letting them feel fully in control of the story. But some side plots don't get enough attention, leaving some emotional moments feeling incomplete or underdeveloped.

The use of mirrors and reflections is a visual motif that reinforces the theme of identity but rarely surprises. Despite this, the central performances remain compelling enough to sustain the film's unsettling tone. Its most effective moments are those where the brothers' detachment from reality feels almost poetic in its inevitability.

8/10

My verdict

The film's tension comes from the brothers' unraveling, not just their secrets. The direction leans into unease but occasionally softens the stakes.

— Desly

Crash — A collision of perspectives

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The film tries to explore race, class and identity through a series of separate scenes. But these moments often feel like rough drafts rather than complete ideas. The film has a clear goal, but it doesn't hold together well emotionally or thematically.

The film's rhythm is all over the place. Some parts move too slowly, while others rush past key ideas. The dialogue leans on tired phrases instead of offering new perspectives or character growth. There are a few tense moments, but they don't last long enough to make an impression.

Acting quality varies. Some actors bring real depth to their roles, while others come off as stiff and unconvincing. Without a strong central thread, the individual stories and their overall message feel disconnected. The film's attempts at humor or irony can sometimes get in the way of its more serious themes.

The way the stories are put together feels clumsy, like they were patched together instead of growing naturally from one another. The themes have promise, but they're not given enough time or care to fully develop. The film's emotional impact is weakened by its lack of focus and its own high aims.

1996 · English. Film details

6/10

My verdict

The film's attempt to weave multiple stories falls short of its own emotional ambition. The tone shifts awkwardly between tragedy and triviality.

— Desly

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The main problem is a fear the protagonist can't talk about. The film moves slowly, which builds atmosphere but makes the story feel stuck. It works when the tension is felt, but it stumbles when it needs to explain things clearly.

The film's pacing is all over the place. Some scenes are too long, others too short, and not much happens emotionally. The dialogue is quiet and confusing, which makes the characters feel distant. This can be interesting, but it sometimes makes it hard to connect with the main character.

The acting is low-key, which fits the mood but makes it harder to get emotionally involved. Some character choices feel random because their reasons aren't clear. The film tries to explore loneliness and regret, but it doesn't follow through on those ideas in a satisfying way.

Even with its problems, there are moments that feel real and moving. The film focuses on mood rather than action, which can be good but also makes the story feel shallow. It's worth watching, but it doesn't reach much higher than its basic ideas.

7/10

My verdict

The film leans on its atmospheric tension but falters when trying to balance mystery with emotional stakes, resulting in a mostly effective but uneven experience.

— Desly

The Autopsy of Jane Doe — A father-son tension under a corpse's gaze

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The pressure between father and son is palpable, even when their dialogue is sparse or indirect. The corpse in the morgue becomes a silent observer of their strained dynamic rather than a catalyst for change. The film's tension relies on the audience knowing more about the characters' history than they do.

The film moves slowly as the mystery unfolds, with some parts feeling too drawn out. The quiet, uneasy moments are spoiled by reveals that feel too expected. The dialogue is often awkward, especially when characters have to explain things without much emotion.

The father's hesitation and the son's frustration are suggested but not really shown in detail. The characters' reasons for acting the way they do aren't clear, which makes their emotional journey feel flat. The setting helps create a mood, but the film doesn't use it well to dig deeper into the characters' minds.

The film tries to build suspense, but it often feels like it's following a list instead of building naturally. The mystery is interesting but doesn't really make you care about what happens. Still, there are quiet moments that leave you feeling uneasy long after the film is over.

2016 · English. Film details

7/10

My verdict

The film leans on its eerie setting but struggles to sustain the emotional stakes of its central relationship. The mystery feels more like a backdrop than a driver.

— Desly

The Babadook — A mother's grief becomes a monster

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The film focuses on the mother's mental state but doesn't explore her past or motivations enough. The Babadook is more of an abstract idea than a fully formed character, which weakens its effect. The child's role is passive, making their emotional journey less impactful.

The direction creates a tight, uncomfortable atmosphere that heightens the tension between mother and son. Shadows and sounds build unease without relying too much on sudden scares. The pacing slows down during quieter moments, where more character depth could have been added.

The lead actor shows deep sorrow but doesn't have enough range to fully show her mental breakdown. Supporting actors do well but don't lift the film beyond its basic idea. The dialogue often feels stiff, especially in scenes meant to show emotional cracks.

The film's metaphor for grief is interesting but not fully worked out, leaving some ideas hanging. Its ambition is greater than its execution, especially in the final act where the ending feels too quick. Despite these issues, The Babadook is still a memorable look at trauma and its lasting effects.

2014 · English. Film details

7/10

My verdict

The Babadook balances psychological tension with supernatural dread, but its emotional core feels underdeveloped despite strong performances.

— Desly

Relic — A slow-burn unease lingers in the air

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The central conflict revolves around a family unraveling as they confront an unseen force in their home. Emily Mortimer's performance carries the weight of uncertainty without overreaching into melodrama. Robyn Nevin and Bella Heathcote provide layered tension that grounds the supernatural elements.

The film focuses on mood more than story, which can make it feel more like a mood than a plot. The dialogue is quiet, letting the emotions hang in the air instead of being spelled out. It does a good job of making you feel uneasy through small details and awkward moments between characters.

The film tries to mix psychological horror with family drama, but the two don't always fit well. The acting is solid, but it doesn't always fix the parts of the script that feel unclear. The direction is more about feeling than action, which might not satisfy people looking for a fast-paced horror movie.

Even with its problems, the film makes you feel alone and trapped. The heart of the story is strong enough to keep you watching, even when the pacing stumbles. The mood stays creepy all the way through, even when the story gets a bit confusing.

7/10

My verdict

The film balances familial tension with supernatural dread, but its pacing occasionally softens the urgency of its own mystery.

— Desly

The Dark and the Wicked — A farm steeped in grief and silence

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

Two siblings return to their family's farm after their mother's suicide, drawn by a sense of unresolved duty and fear. The script offers little in the way of clear motivations, leaving the characters' actions feeling hesitant rather than purposeful. Bryan Bertino builds tension through silence and isolation but never fully commits to a singular vision.

The pacing is slow, but the story doesn't build enough urgency to make the horror feel real or immediate. The farm is a strong setting, but it's not explored much beyond its spooky atmosphere. Marin Ireland does a good job showing quiet fear without overdoing it, but her character doesn't have much emotional depth to hold onto.

Michael Abbott Jr. plays his role with some vulnerability but doesn't fully convince as a strong character. Xander Berkeley brings a serious tone, but his character doesn't have much to do or connect with the audience. The dialogue often feels forced, like it's waiting for a jump scare instead of building real tension.

There are some good creepy moments that show what the film could have been. But the story doesn't follow through on its emotional promises, and the lack of direction makes the horror feel more like a missed opportunity than a real scare. The setting is interesting, but the film doesn't do enough with it to make the horror stick.

6/10

My verdict

The film leans on its eerie setting but lacks the emotional depth to make the supernatural threat feel urgent or personal.

— Desly

It Comes at Night — A slow-burn tension with no clear resolution

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The family’s isolation is both their refuge and their prison, creating an immediate sense of claustrophobia and distrust. Decisions are made in silence, with few words exchanged, emphasizing the fragility of human connection under pressure. The script avoids easy answers, leaving characters to navigate moral uncertainty without clear guidance.

Shults uses long pauses and sparse dialogue to build tension, but this can also slow the narrative’s momentum. Visual restraint is used effectively, though the lack of clear visual cues sometimes muddles the stakes. The pacing feels uneven, with some scenes dragging while others resolve too quickly for full impact.

Joel Edgerton carries much of the weight, his performance grounded and tense without overreaching. Kelvin Harrison Jr. adds a quiet vulnerability that contrasts with the film’s colder tone. Riley Keough’s character is underutilized, her role feeling more like a subplot than a central concern.

The ambiguity works as a stylistic choice but risks alienating viewers seeking resolution. Some emotional beats feel underdeveloped, leaving characters’ motivations slightly unclear. Despite its flaws, the film succeeds in making the audience question what they would do in such an extreme situation.

7/10

My verdict

The film leans into unease but lacks a satisfying emotional core. Performances are strong, yet the ambiguity feels more frustrating than profound.

— Desly

The Blackcoat's Daughter — Isolation as a psychological test

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

Two girls are left alone in a nearly abandoned school during a blizzard, with no clear reason why they are there or how to leave. Their fear is personal but rarely felt as urgent or immediate as the situation demands. The film leans on atmosphere rather than action, which risks distancing the audience from their plight.

The dialogue sometimes feels forced, making their conversations seem more planned than natural. Without a clear enemy or outside danger, their fear lacks a solid reason to focus on. This uncertainty might work for some but can make the emotional stakes feel unclear.

The performances are restrained, which fits the tone but limits the depth of connection with the characters. There is a quiet unease in certain moments that suggests stronger potential than what is fully realized. The film's structure moves slowly, which may frustrate viewers expecting more immediate tension.

It has some good moments that stick with you even after the film ends. The problem is that the emotional and mental tension isn't fully explained or wrapped up. It's an intriguing idea but has trouble keeping the right balance between its mood and the need to keep the audience hooked.

2015 · English. Film details

7/10

My verdict

The film's emotional core is its focus on two girls trapped in an empty school, but the pacing and tone undercut its potential for real tension.

— Desly

The Witch — Anya Taylor-Joy's silence speaks volumes

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The family’s isolation is felt immediately, not explained through exposition or dialogue. A child’s disappearance becomes the catalyst for escalating tension without melodrama. The script avoids easy horror tropes, focusing instead on the slow erosion of trust.

The camera focuses on everyday tasks, making the supernatural feel like it's part of the normal world. Long periods without much happening let the audience sit with the family's growing worry. This slow pace is intentional but can feel slow in the quieter parts.

Anya Taylor-Joy conveys fear without screaming, her eyes holding the weight of suspicion. Ralph Ineson’s performance as the patriarch is quietly menacing, his voice carrying authority and doubt. Kate Dickie brings a simmering tension to her role, her presence always felt rather than shown.

The film's uncertainty is its best part but also its weakest. Some questions stay unanswered, which can feel unsatisfying. A few scenes drag on and lose their emotional punch. However, the film's stick-to-its-own-rules approach makes its creepy ending both surprising and unsettling.

8/10

My verdict

The Witch builds unease through naturalistic performances and deliberate pacing. Its final act risks overreaching its own restrained tone.

— Desly

The House of the Devil — A slow, uneasy build-up

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The film's central conflict revolves around a young woman's decision to take a babysitting job she barely understands. The slow reveal of what lies ahead creates a mood of isolation and dread, but never fully resolves into terror. Ti West builds tension through silence and suggestion rather than jump scares or explicit violence.

The editing holds on moments that feel creepy but doesn't push them far enough to be truly scary. Long parts of the film don't have clear dangers, so the later horror feels sudden instead of built up. The pacing is slow and careful, but this can make the film feel like it's dragging as it moves toward the end.

Jocelin Donahue conveys vulnerability and confusion with quiet precision, grounding the supernatural elements in real fear. Tom Noonan's performance is unsettlingly calm, adding to the sense of something wrong without overacting. Dee Wallace and Mary Woronov provide a sinister presence that lingers in the background of the story.

The film's structure is thoughtful but sometimes wanders, making the horror feel less urgent. Some scenes depend too much on hints instead of clear direction, leaving the audience unsure of what to be scared of. Even with these issues, the mood and acting make for a memorable, if imperfect, slow-burn horror film.

7/10

My verdict

The House of the Devil balances tension with deliberate pacing but falters in its final act. The performances are strong, yet the horror lacks a sharp edge.

— Desly

The Innkeepers — A slow reveal of unease

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The employees get obsessed with the hotel's past, but this obsession takes focus away from their loneliness. Their interest in the haunted history feels forced, like it's there just to move the plot forward. The film doesn't really explain why the strange things happening matter to them personally or how they escalate.

The film drags out tense moments, turning them into long pauses that don't add much. It's unclear what's real and what's imagined, which makes it hard for the audience to feel the unease the film is trying to create. It never really decides if it's a ghost story or a look at loneliness.

The main characters keep going even though they're confused, but their reasons for doing so aren't clear. Their conversations during tense scenes feel stiff and not natural. The film hints at bigger ideas but doesn't explore them enough to make them meaningful.

The film's best part is how still and quiet it feels, but this is ruined by a lack of direction. The ghostly elements feel more like background decoration than something that affects the characters' emotions. Even with its problems, it tries to explore memory and loneliness, but it never really gets there.

6/10

My verdict

The film leans on atmosphere but lacks the emotional core to make its supernatural claims feel urgent or personal.

— Desly

The Sacrament — A cult's secrets are hard to untangle

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The main conflict revolves around a group's isolation and the protagonist's growing discomfort, but the tension doesn't feel fully earned. The situation is clear: someone investigating a cult, but the stakes are unclear and underdeveloped. The film avoids giving much detail about the cult's activities or the characters' pasts, which weakens its impact.

The pacing slows down in key moments, making the events feel more like a list than a compelling story. The dialogue often feels forced, as if the script is trying too hard to sound like real conversations but failing to capture their natural flow. The protagonist's reasons for acting the way they do aren't clear, making it hard to care about their journey.

The acting is okay but not impressive, with little change in tone or intensity. There's a feeling of distance from the characters' inner thoughts, making their choices seem random rather than natural. The film tries to create unease but rarely keeps it going beyond a basic level of discomfort.

Its use of real events might give it some credibility, but it also limits how deeply it can explore themes or emotions. The structure feels more like a documentary experiment than a complete story with real emotional weight. Despite its goals, the film never really justifies why it exists beyond being a curiosity.

6/10

My verdict

The film leans on its real-world inspiration but lacks the emotional urgency to make its revelations feel urgent or unsettling.

— Desly

The House That Jack Built — A murderer's obsession with his own story

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The main conflict is between the killer's need to explain his actions and the audience's discomfort with his point of view. Each new murder adds another chapter to his self-justifying story, but the emotional gap grows with each act. There's no clear moral guide for the killer's choices, which makes his reasons feel disconnected from real consequences.

The pacing lets long monologues sit without adding to the characters or conflict. The film focuses on its own style without giving a good reason to follow its logic. The lack of emotional connection to the victims weakens the impact of the violence.

The voiceover narration is more about the filmmaker's style than revealing anything new. The tone and rhythm don't change much, making the experience feel repetitive and distant. The film's ambition is bigger than its ability to connect emotionally with the audience.

The idea of a murderer telling his own story is interesting but not fully explored. The lack of a clear ending or redemption leaves the story feeling unfinished and unsatisfying. The structure is bold, but it doesn't balance form with real meaning well.

2018 · English. Film details

6/10

My verdict

The film's focus on its own violence can overshadow the emotional parts. The way it's structured feels more like a display than a real story device.

— Desly

The Neon Demon — A performance with no emotional anchor

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

Elle Fanning's performance as the model feels flat, like a style choice rather than a real emotion. Her character's loneliness isn't explained, so the horror comes off as more of a surface reaction to beauty and jealousy. The other actors say their lines with a detached feel, but their characters don't have much to work with.

The film focuses more on strange, dreamlike images than on telling a clear story. Music and lighting take over scenes, sometimes messing up the rhythm or emotional flow. There's a lot of interest in symmetry and mirrors, but it doesn't help us understand the characters' minds.

The dialogue sounds too planned, like it was written rather than spoken naturally. The film's mood keeps changing between being exploitative and thoughtful, but it never really decides which one it wants to be. Jena Malone and Keanu Reeves are there, but their characters don't get much depth.

The real fear in the film never feels personal or deep—it's more about visual shocks than real psychological tension. Even though it tries to be ambitious, it doesn't connect its style with real character growth. It's more about looking cool than making you care about what happens to the main character.

6/10

My verdict

The film leans on style over substance, leaving the protagonist's motivations and fears underdeveloped despite a strong visual palette.

— Desly

Only God Forgives — A tense, overheated moral vacuum

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The central conflict revolves around a father's violent quest for justice in Bangkok, but the emotional stakes remain muddled. Ryan Gosling plays a man consumed by vengeance yet emotionally detached, creating a disconnect between his actions and motivations. Kristin Scott Thomas delivers a performance that feels underutilized, her character existing more as an idea than a fully realized presence.

The film uses stylized violence and neon visuals, but the pacing feels forced. Long pauses and quiet moments try to set the mood, but they often skip over the story and characters. The oppressive tone is consistent, but it doesn’t always help the plot or people in it.

Ryan Gosling's performance is technically precise but lacks emotional depth, making his character more of a symbol than a person. Kristin Scott Thomas and Vithaya Pansringarm share scenes that suggest tension but rarely build into meaningful conflict. The dialogue often feels sparse and underdeveloped, failing to give the characters enough room to breathe or evolve.

The film’s look is its best part, but it doesn’t make up for the weak storytelling. There’s a certain visual appeal, but it doesn’t fix the lack of emotional connection. It tries to explore moral gray areas, but it doesn’t follow through on its own ideas.

6/10

My verdict

The film's style overshadows its substance. It leans on mood rather than narrative or character clarity, leaving little to anchor the viewer.

— Desly

The Guest — A visitor who never quite leaves

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The film begins with a man arriving unannounced, claiming to be a friend of the family's dead son. His presence unsettles the household but also offers a strange kind of comfort in its early stages. The script leans on mystery without ever fully justifying the stakes of its central character.

The film uses close-ups and quiet moments between dialogue to build a tense atmosphere. It keeps the threat feeling constant, even when not much is happening. But sometimes the structure repeats itself, which can slow down the tension.

Dan Stevens carries the role with a smoothness that borders on disarming, making his violence feel more like a performance than a threat. Maika Monroe gives a grounded performance but struggles to match the intensity of her character’s suspicion. Supporting actors add weight to the sense of unease, even when their roles are minimal.

The film's middle section drags a bit, relying too much on suspense without giving new clues. This makes some parts feel slow and repetitive instead of exciting. Still, The Guest does a good job of leaving you with a lingering mood after it's over.

7/10

My verdict

The Guest balances tension with its own contradictions. Dan Stevens plays a man whose charm and violence are both oddly convincing.

— Desly

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The father and son navigate a desolate landscape where survival is the only goal, and trust is a luxury they cannot afford. Their journey is defined by scarcity, fear, and quiet desperation rather than grand gestures or dramatic confrontations. The screenplay leans heavily on sparse dialogue, which reflects the characters' isolation but can also feel emotionally distant.

The film uses wide shots of empty spaces to show how big their struggle is, without explaining everything. The pacing is slow, with long silences that build tension but might bore some viewers during quiet moments. There's a rhythm to their movement that feels like a routine, but the film never really explains why they keep going.

Viggo Mortensen carries much of the emotional weight with a stoic performance that avoids melodrama but risks underplaying vulnerability. Kodi Smit-McPhee conveys fear and confusion without overacting, though his limited lines leave little room for depth. Charlize Theron and Robert Duvall appear briefly but are effective in their roles as fleeting threats or fleeting kindnesses.

The film’s restraint is its strength but also its limitation—some moments feel too detached to really connect with the heart. It does a good job showing how bleak the world is, but the characters' inner struggles don't always feel relatable. Even with its flaws, The Road is still a strong film about love and survival in a broken world.

7/10

My verdict

The film balances bleak realism with emotional restraint, but its minimalist approach risks distancing the audience from its characters' humanity.

— Desly

The Rover — A man and a girl on the run

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

A man and a girl travel through a lawless wasteland, their relationship defined more by survival than shared purpose. Their journey is driven by a vague threat, which limits the depth of their motivations or conflicts. The sparse dialogue emphasizes isolation but leaves little room for emotional investment.

The direction uses wide shots to show their vulnerability in the empty landscape. The pacing is slow, but without clear stakes, the urgency feels off. The setting creates a mood more than it drives the story, and there's not much to ground the moral or emotional weight of what's happening.

The male lead carries a quiet desperation, but his actions often lack clear reasoning or resolution. His companion is equally ambiguous, her role shifting without enough narrative foundation. Their interactions are tense but rarely reveal deeper layers of character.

The film relies on visuals to tell its story, which works sometimes but falls short when dialogue is needed to explain what's going on. There's a feeling of violence coming, but the threat never really comes to a satisfying head. The characters don't have clear directions in their journey, so their story feels more like a half-finished idea than something that leaves a strong impression.

7/10

My verdict

The film’s tension is built from sparse details and uncertain alliances, but its emotional core feels underdeveloped despite strong performances.

— Desly

These Final Hours — A quiet, unresolved tension

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The story takes place in a small space with little outside conflict. It focuses on the characters' uncertainty and hesitation. They don't act quickly, which makes the mood feel passive rather than urgent. This hesitation seems more like a style choice than something that moves the story forward.

The film moves slowly, often drifting without a clear goal. There are quiet moments that hint at deeper character development, but they never fully come together. The dialogue is minimal, which fits the mood but also makes it hard to follow.

The acting is understated, but the actors don't show enough emotion to make the story stand out. The film has a sad tone, but it doesn't really explain why it's sad or what it's trying to say. There's a feeling of longing that never gets resolved.

The setting helps create the mood, but it doesn't play an active role in the story. Without clear conflicts, it's hard to care about the characters' choices. Even though the film has a strong atmosphere, it doesn't fully justify its emotional or narrative weight.

2013 · English. Film details

6/10

My verdict

The film uses its setting well, but it doesn't have a strong emotional centre. Without clear reasons for the characters' actions, the tension feels weak, even though the mood is atmospheric.

— Desly

Faults — A fragile moral line

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The central tension is between a couple's attempt to help someone and their own ethical boundaries being tested. The characters are placed in situations where their values clash with their actions, creating immediate friction. The script leans into absurdity but never fully commits to either comedy or thriller as its primary mode.

The film moves quickly between jokes and unsettling moments, which can feel disjointed. There's not enough tension to make the moral dilemmas feel serious. The dialogue leans into irony, but the characters don't really change much throughout the film.

Mary Elizabeth Winstead carries much of the emotional weight with a grounded performance amidst the chaos. Leland Orser adds a layer of menace that keeps the film from becoming purely farcical. Supporting actors contribute to the chaotic energy, but few moments allow them to fully develop their characters.

The humor can take attention away from the serious themes about trust and morality. The film struggles to find a consistent tone between satire and real tension. Still, Faults has an interesting idea worth checking out, even if it never fully sorts out its tone.

7/10

My verdict

The film balances dark humor with real emotional stakes, but its tone occasionally undermines the gravity of its characters' choices.

— Desly

Compliance — A chilling performance anchors a moral dilemma

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

Ann Dowd's portrayal of the restaurant manager is unsettlingly convincing, capturing a slow unraveling of judgment. Her character’s compliance with an authority figure feels disturbingly plausible, rooted in real-world dynamics. The film leans into the horror of ordinary people following orders without questioning their morality.

The film moves at a steady pace that builds tension but doesn't reach strong emotional highs or lows. Scenes are carefully put together, focusing on dialogue and little action to show the pressure of the situation. There's not much room for characters to grow beyond what's needed for the main story.

Dreama Walker’s performance as the employee adds vulnerability, though her role remains constrained by the plot’s design. Bill Camp’s voice as the fake officer is chillingly authoritative but never fully explored as a character. The dialogue feels naturalistic, yet it often serves the film's purpose rather than revealing complex inner lives.

The film relies a lot on its real-life story, which makes the horror feel real but limits how much it can invent. Sometimes, the focus on how things work gets in the way of connecting with the people involved, making it hard to feel emotionally involved. Still, the uncomfortable truth of the situation stays with you, acting as a warning about how people follow authority without thinking.

7/10

My verdict

The film exposes the dangers of blind obedience but falters in its emotional impact. The real-life inspiration adds weight, yet the tone remains clinical.

— Desly

Cheap Thrills — A darkly comedic descent into moral decay

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

Two friends are lured into a game that promises money but demands ethical compromise, exposing their vulnerabilities. The premise leans on the absurdity of the challenges without fully justifying their appeal or consequences. The script often prioritizes shock value over character depth, leaving motivations unclear and relationships shallow.

The film jumps between tones in a way that feels more like a stylistic choice than something that grows naturally from the story. Some scenes are slow and drag, while others rush past moments that could have built real tension or resolution. The humor doesn't always land, especially when the characters are making choices that hurt themselves more than help them.

Pat Healy and Sara Paxton carry the film but lack clear emotional anchors to make their choices feel authentic. Their performances are competent but do not elevate the material beyond its surface-level provocations. David Koechner's role adds some levity, yet his character remains underdeveloped and disconnected from the main conflict.

The film has clear ambition, but it doesn't manage to balance its darker themes with a solid story. The moral questions it raises are interesting, but the script doesn't follow through on them properly. It's a provocative look at greed and peer pressure, but it never really finds a reason to exist beyond that.

6/10

My verdict

The film's unsettling tone is undercut by a lack of emotional stakes. The characters' choices feel arbitrary rather than tragic or revelatory.

— Desly

Tue, 20 Oct 2026 21:14:31 +0200

Spoiler-free review.

The experiment feels more like a stage setup than a real psychological study, making it hard to connect emotionally. The actors do their jobs well, but their performances don't bring enough raw feeling to make the characters' choices feel urgent or personal. The script relies on exposition instead of natural dialogue, which makes the moral dilemmas feel more like school lessons than real emotions.

The direction focuses on the cold, sterile environments rather than the characters' inner struggles, which limits the psychological depth of the situation. The pacing is slow and often feels like going through a list rather than exploring how people sink into madness. The film holds back from showing the full consequences of the characters' actions, which keeps the audience from really feeling their suffering.

Without strong personal stakes, the ethical questions feel more like a puzzle than a real human drama. There's an attempt to make the audience think, but it doesn't really get into the emotional aftermath of what happens. Weak character development makes the moral questions feel less powerful.

Even with its flaws, the film does bring up important ideas about power and corruption. It's an interesting but emotionally shallow look at a disturbing real event. The mix of critique and entertainment doesn't quite work, leaving the viewer with more questions than real emotional impact.

7/10

My verdict

The film leans on its real-life subject for tension but struggles to balance ethical critique with human complexity. The central conflict remains emotionally distant.

— Desly

Mon, 19 Oct 2026 14:32:01 +0200

Spoiler-free review.

Soft & Quiet is a hard film to sit through. What makes it disturbing is how ordinary the surroundings are. There is no reassuring distance between the horror and the sort of places people move through every day.

Beth de Araújo keeps the camera close and the action moving, like one long stretch of time. That approach leaves no room for the discomfort to settle. There's no cut to another person's day, and not much chance to step back and collect yourself.

The dialogue is the part that gets under my skin. Grievances are offered casually, people encourage each other, and ugly beliefs find reassurance in the group. The performances make those exchanges feel socially familiar even when what is being said is repellent. Stefanie Estes is especially effective at the contrast between a composed manner and the hostility underneath it.

I appreciated how the direction makes you notice permission being given in small ways: a response, a laugh, a decision to go along. The film understands that a group can make people feel justified rather than responsible. It does not need a speech to make that frightening.

My reservation is how relentless it becomes. At times the escalation feels designed to leave you as distressed as possible, and I wanted a little more depth beyond that pressure. Still, the control of the performances and the camera makes the experience difficult to dismiss.

8/10. Disturbing, tightly directed, and very effective at finding horror in familiar behaviour. I would go in without reading the plot; the performances and the growing unease are enough to know about beforehand.

8/10

My verdict

Beth de Araújo turns ordinary conversation into something deeply unsettling. Relentless direction and convincing performances make this a difficult, effective watch.

— Desly

The Hunt — when people stop listening

Mon, 19 Oct 2026 14:32:01 +0200

Spoiler-free review.

Mads Mikkelsen is the reason The Hunt works so well for me. He plays Lucas, a kindergarten teacher falsely accused of abuse, with a restraint that makes the situation more painful. You can see him trying to remain recognisable to people who have already decided who he is.

Thomas Vinterberg sets up the small town as familiar and safe before turning it hostile. The people know each other, share routines, and feel at home in their usual places. Once that comfort is gone, even simple interactions become tense. The direction doesn't need fancy tricks to show the growing hostility.

The conversations are especially frustrating in a convincing way. People ask questions while already seeming to know the answer they want. Concern becomes certainty, and listening becomes something they think they have already done. The film makes that process feel frighteningly easy.

Mikkelsen keeps the character human through it. There is hurt, confusion, and anger, without every scene becoming a display of suffering. Some of the escalation feels heavily arranged to put him under maximum pressure, but his performance keeps bringing it back to an individual person.

8/10. A tough film with a standout lead performance. What stuck with me was how fast people you know can become people you can't reach.

8/10

My verdict

Mads Mikkelsen is brilliant as a teacher facing a false accusation. A painful drama about how quickly a community can become certain.

— Desly

Children of Men — nowhere to stand still

Mon, 19 Oct 2026 14:32:01 +0200

Spoiler-free review.

The world of Children of Men looks exhausted. No babies have been born for eighteen years, and the loss of a future is visible in the way people move through the present. The film gives you that feeling through streets, broadcasts, and background detail rather than a long explanation.

Clive Owen plays Theo well — a man who seems worn out before the story even starts. Protecting a pregnant woman gives him a purpose, but he doesn’t suddenly turn into a smooth action hero. His hesitation and awkwardness help keep the danger real.

The long takes are the standout. Alfonso Cuarón lets movement and action build within a shot, so you have time to register the surroundings and then realise how exposed everyone is. They look astonishing, but their strongest effect is making it feel as though there is no convenient break from what is happening.

I didn’t connect with some of the supporting characters as much. The film’s energy is so strong that a few relationships feel rushed, and the symbolism can feel a bit heavy-handed. I liked the filmmaking more than I engaged with the full story.

7/10. Worth seeing for the atmosphere, Owen’s worn-out performance, and those amazing long takes that feel like they’re unfolding in real time.

7/10

My verdict

A worn-out man, a pregnancy in an infertile world, and some remarkable long takes. The direction makes the danger feel immediate.

— Desly

Gattaca — more than a test result

Mon, 19 Oct 2026 14:32:01 +0200

Spoiler-free review.

The idea behind Gattaca is what drew me in: a society can measure your genes and mistake that information for the whole of your potential. Vincent, born without genetic selection, takes another man’s identity to pursue his ambition of going to space. Even a routine check can threaten everything.

Andrew Niccol creates a clean, controlled look for the world. The buildings, clothes, and daily routines suggest people are expected to fit into a system that’s already decided their place. The restraint fits a story where being noticed can be dangerous.

Ethan Hawke gives Vincent determination without making him constantly announce it. Jude Law adds a more bitter kind of frustration, and their scenes together give the premise some personal weight. The practical effort of maintaining the deception can be more interesting than the larger speeches about ambition.

The dialogue is clear, sometimes too much so. Some lines feel like they’re meant to explain the film’s message, and the investigation isn’t as gripping as the world itself. I wanted more depth in how that society handles contradictions, not just the one example it shows.

7/10. A strong premise, elegant design, and enough emotion to make the questions worth thinking about. I found the quieter moments more effective than the direct statements.

7/10

My verdict

A thoughtful science-fiction premise about genetic privilege and ambition. Its quiet style suits a man trying to pass every inspection.

— Desly

Nightcrawler — ambition without a conscience

Mon, 19 Oct 2026 14:32:01 +0200

Spoiler-free review.

Jake Gyllenhaal makes Lou Bloom unsettling before he has done much at all. The attentive stare, the careful politeness, the way he sounds as if he has memorised advice about succeeding: something is wrong even when the words are perfectly reasonable.

In Nightcrawler, Lou starts filming crime scenes around Los Angeles and selling the footage to television news. Dan Gilroy makes the work feel both grubby and competitive. The city at night looks inviting from a distance, while the business taking place in it is anything but.

The dialogue is the best part for me. Lou talks about opportunity, improvement, and professional relationships with an enthusiasm that makes those phrases feel sinister. Gyllenhaal rarely softens the delivery to make him easier to like. Rene Russo is an excellent match for him, especially when a conversation becomes a negotiation over what someone is willing to accept.

It is dark and gripping, though the point about ambition and the market for suffering becomes clear fairly early. After a while, I wanted the film to complicate that argument more rather than keep demonstrating it. The central performance held my attention even when the idea started to repeat.

7/10. A very strong performance in a sharply observed thriller. Lou’s calm way of speaking is often creepier than the footage he is trying to sell.

7/10

My verdict

Jake Gyllenhaal makes ambition deeply creepy. A dark, gripping look at a man who turns other people’s worst nights into a business.

— Desly

Incendies — the weight of what goes unsaid

Mon, 19 Oct 2026 14:32:01 +0200

Spoiler-free review.

Incendies gives silence a lot of room. People hesitate before answering, or look as if answering would cost more than they can manage. That restraint drew me in more than any explanation of the family history could have.

Denis Villeneuve moves between a mother’s past and her children’s search with a clear sense of purpose. The changes in time ask for attention, but the film never feels interested in confusing you for the sake of it. There is always a person trying to understand another person underneath the structure.

Lubna Azabal is the strongest reason it works for me. She gives Nawal a stubborn physical presence, even when there is very little dialogue. The performance makes suffering feel specific to a person rather than something included simply to make a scene more serious.

The violence is difficult, and the film can be relentless. Occasionally the story feels too tightly arranged, with its construction more visible than I would like. The quieter scenes are often the ones I trust most: a face, a pause, someone trying to find the next words.

8/10. Controlled direction and an excellent central performance make this worth the emotional effort. I would keep any reading beforehand to a minimum.

8/10

My verdict

Patient direction and powerful performances give this family drama its force. A difficult watch that earns most of its emotional weight.

— Desly

Memories of Murder — confidence is not evidence

Mon, 19 Oct 2026 14:32:01 +0200

Spoiler-free review.

There is a strange rhythm to Memories of Murder. A scene can be almost ridiculous, then become deeply unpleasant before you have quite stopped laughing. Bong Joon-ho makes those changes feel like part of the same world.

The detectives keep me watching. They argue, jump to conclusions, and treat authority like a badge of correctness. Song Kang-ho makes confidence look both silly and scary. Kim Sang-kyung’s calmer approach adds real tension to their clashes.

I like how much happens around the investigation. People wander through spaces they should not be in, crowds gather, and the weather makes already difficult work worse. The direction lets you notice the disorder instead of always pointing straight at the next clue.

The dialogue is often blunt, which suits people more comfortable asserting themselves than admitting uncertainty. As the pressure builds, those habits stop being amusing. The film is good at making you question a method you may initially have accepted as part of the genre.

A few parts feel a bit repetitive, but that’s fair — the investigation itself is slow and frustrating. 8/10. It’s funny in awkward moments, well-observed, and much more about flawed people than perfect detectives.

8/10

My verdict

Bong Joon-ho finds grim humour in a messy investigation without losing sight of its cruelty. The detectives’ behaviour is as absorbing as the case.

— Desly

Predestination — a story worth listening to

Mon, 19 Oct 2026 14:32:01 +0200

Spoiler-free review.

The best stretch of Predestination is built around someone telling a story and someone else listening. For a film with a complicated science-fiction premise, it is surprisingly willing to sit with a conversation. I liked that confidence.

Sarah Snook makes the story feel real rather than just told. There's hurt and defensiveness in her performance, but also dry humour that stops the character from being all hardship. Ethan Hawke is a good listener in the scene; his restraint helps keep it together.

Michael and Peter Spierig give the different settings a clear visual identity without burying them in futuristic decoration. The scale is fairly contained, which leaves the actors room to carry the film.

My reservation is how much attention the structure eventually demands. Following the connections can become more absorbing than caring about the people making them. Some of the explanation also feels heavier than it needs to be. I admired the design, but did not always feel as involved as I had during the quieter conversation.

7/10. An inventive, well-acted film with a particularly strong performance from Snook. Worth watching with a clear head, and without a plot summary open beside it.

7/10

My verdict

Sarah Snook gives this intricate science-fiction story a human centre. The performances held me more consistently than the mechanics.

— Desly

Coherence — an ordinary room turns uneasy

Mon, 19 Oct 2026 14:32:01 +0200

Spoiler-free review.

Coherence gets a lot out of a familiar discomfort: being at a dinner where people have more history with each other than they are saying aloud. Before anything unusual happens, the interruptions and small tensions give the evening a believable awkwardness.

James Ward Byrkit keeps the camera close to that social mess. People talk over each other, miss information, and disagree about what deserves attention. It can feel untidy, but that untidiness helps the uncertainty spread. You are trying to follow the conversation at the same time as the characters.

Emily Baldoni gives the film a useful point of focus. Her watchfulness lets you settle into one person’s experience without making everyone else feel like background. The ordinary rooms and darkness outside do much of the visual work; the film rarely needs anything elaborate to make a space feel wrong.

The roughness is not always a strength. Some of the overlapping dialogue becomes tiring, and there are moments when the group seems to be explaining a problem for the audience rather than speaking naturally. The characters are also unevenly developed, so I cared more about some reactions than others.

7/10. A clever, resourceful thriller whose strongest tool is an uncomfortable conversation. Best given your full attention before anyone explains the premise too thoroughly.

7/10

My verdict

A dinner-party conversation becomes an effective source of unease. Resourceful and absorbing, though the rough edges sometimes show.

— Desly

Se7en — a city with no breathing room

Mon, 19 Oct 2026 14:32:01 +0200

Spoiler-free review.

The rain in Se7en feels less like weather than something the characters have to carry around. The streets are cramped, the rooms are poorly lit, and even an ordinary day at work looks exhausting. David Fincher builds a place you want to leave almost as soon as you arrive.

The contrast between the two detectives is what keeps me engaged. Morgan Freeman’s Somerset carries the weight of someone who’s seen too much. Brad Pitt’s Mills is all quick reactions and barely contained frustration. Their dialogue works because they don’t seem to want to be friends — not yet.

The direction is meticulous without making the investigation feel clean. You spend time watching people read, wait, and try to make sense of ugly things. The violence is disturbing, but the suggestion of it can be just as effective as what is shown.

At times, the bleakness feels too neatly planned. The film has a message about the world, and you can feel it nudging everyone toward that message. But the performances add enough real-life tension to keep it from feeling forced.

8/10. A tense, tightly controlled thriller where the mood is just as important as the mystery. Best watched without looking up the ending.

8/10

My verdict

A grim atmosphere and two very different detectives make this more than a hunt for clues. Fincher keeps the pressure on.

— Desly

The Prestige — the cost of being better

Mon, 19 Oct 2026 14:32:01 +0200

Spoiler-free review.

The part of The Prestige I find most convincing is how quickly professional admiration can turn sour. These men care about their work, but being good soon seems less important than making sure the other man is worse off.

Hugh Jackman and Christian Bale play the rivalry with different tones. Jackman has the relaxed confidence of someone who knows how to win a room; Bale is more guarded and rougher. Neither makes obsession look noble. Michael Caine adds a grounded presence to their world, especially when everyone else is getting harder to read.

Christopher Nolan moves between periods and perspectives with confidence. The structure demands your attention, but there's usually an emotional reason to stay curious — something like a slight, a disappointment, or an injured ego can drive a whole scene.

Some of the dialogue about sacrifice feels a bit heavy-handed. I also wanted the women to have more space beyond being shaped by the rivalry. Those limits stand out in a film so focused on the men's ambitions.

8/10. Cleverly constructed and compelling, with enough bitterness underneath the showmanship to give it weight. I would avoid reading any plot breakdown beforehand.

8/10

My verdict

A rivalry that gets more absorbing as it gets less reasonable. The craft is impressive, but the wounded pride makes it work.

— Desly

Gladiator — spectacle with someone to follow

Mon, 19 Oct 2026 14:32:01 +0200

Spoiler-free review.

Gladiator does not need a complicated story to get you involved. It gives you someone to follow, something for him to lose, and a world where power is rarely fair. The scale is enormous, but the emotional pull is fairly direct.

Russell Crowe makes the simple story work. He doesn't turn every scene into a chance for a big speech. The quiet moments show restraint, which makes the louder, public scenes feel more powerful. Joaquin Phoenix brings a different kind of energy — he feels out of place even when he's in charge, and there's a sense of bitterness and need in his performance.

Ridley Scott is good at making spectacle feel physical. The crowds, dust, and noise give the arena scenes a weight that goes beyond the choreography. Hans Zimmer and Lisa Gerrard’s music also supplies a tenderness the fighting alone would never provide.

The film is a bit broad in places. Some characters are clearly drawn, and the emotions are not always subtle. A few action scenes are so fast that I wanted to see what was happening more clearly. But the film's confidence in its basic story keeps it from falling apart.

8/10. A gripping epic with a strong lead performance and a big scale that still makes room for personal loss.

8/10

My verdict

Big battles and a direct emotional story, anchored by Russell Crowe. The spectacle works because the central performance stays grounded.

— Desly

The Departed — nobody gets to relax

Mon, 19 Oct 2026 14:32:01 +0200

Spoiler-free review.

The Departed makes a phone call feel like a dangerous activity. People are constantly measuring what they can say, whom they can trust, and whether they have already said too much. That pressure is there even when a scene is funny.

The dialogue is a big part of the appeal. William Monahan gives people sharp, defensive voices; an insult can be a joke, a test, or a way of taking control of a room. Mark Wahlberg gets some of the most aggressive material, but the quieter exchanges can be just as hostile.

Leonardo DiCaprio makes anxiety visible without needing to explain it. Matt Damon is good at the opposite sort of tension: trying to appear comfortable while keeping track of everything. Watching those performances against each other gives the film much of its momentum.

Martin Scorsese keeps the cutting and music lively enough that the length rarely feels heavy. Jack Nicholson’s performance is entertaining, though there are moments when its size pulls me out of the otherwise convincing unease. Some of the supporting relationships could also use more space.

8/10. Messy people, excellent tension, and dialogue with real bite. It is at its best when everyone in a room has a reason to lie.

8/10

My verdict

Fast, abrasive, and full of people watching what they say. The dialogue gives the tension a nasty sense of humour.

— Desly

Shutter Island — unease in every room

Mon, 19 Oct 2026 14:32:01 +0200

Spoiler-free review.

The setting is the first thing that works in Shutter Island. The ferry, the gates, the corridors: each new space makes the outside world feel further away. Martin Scorsese gets a lot of tension from the simple act of entering a room.

Leonardo DiCaprio plays Teddy Daniels with a focus that makes even simple questions feel personal. Mark Ruffalo’s quieter approach balances him well. Their back-and-forth gives you something steady to hold on to as the environment grows more tense.

I like the way the direction mixes the practical business of an investigation with images that feel much less stable. The sound and music are forceful, sometimes almost overwhelming, but they fit the sense of someone unable to settle. The film is rarely interested in allowing a neutral moment.

That focus is also where I have a problem. A few scenes push the mood so strongly that the film’s structure becomes obvious, and some dialogue feels like it’s trying too hard to explain things. I found it more engaging when it left a look or an awkward silence hanging without resolution.

8/10. A moody, well-acted mystery that’s easy to get drawn into. Give it your attention and skip the plot summaries.

8/10

My verdict

A mystery driven by atmosphere and an increasingly strained central performance. The setting does a lot of the unsettling work.

— Desly

Prisoners — fear hardening into certainty

Mon, 19 Oct 2026 14:32:01 +0200

Spoiler-free review.

Prisoners is uncomfortable because it gives fear time to turn into something else. A search for missing children becomes a test of what people are willing to believe, and how quickly believing something can become permission to act.

Hugh Jackman is frighteningly forceful here. His anger feels connected to the panic underneath, making the performance harder to dismiss. Jake Gyllenhaal takes a different approach: restrained, watchful, and showing how hard it is to keep that restraint.

Denis Villeneuve does not rush to relieve the pressure. Roger Deakins’s photography makes the grey streets and dim interiors feel lived in rather than merely gloomy. The spaces between conversations are often where the discomfort really builds.

The dialogue works best when people talk past each other. Everyone wants answers, but they are not always asking the same questions. I appreciated that the film makes understanding someone’s desperation very different from accepting their decisions.

It’s a long, punishing watch, and some parts feel more planned than the performances around them. Still, the central conflict is heavy enough to keep those parts from dragging too much.

8/10. Strong performances and patient direction make this difficult to shake off. A thriller that gives its moral discomfort as much attention as its investigation.

8/10

My verdict

A heavy, patient thriller about desperation and the damage certainty can do. Jackman and Gyllenhaal give it very different kinds of intensity.

— Desly

Django Unchained — conversation under pressure

Mon, 19 Oct 2026 14:32:01 +0200

Spoiler-free review.

The conversations are what I enjoy most in Django Unchained. Quentin Tarantino lets someone speak politely for long enough that the politeness starts to feel threatening. A pause over a table can carry as much tension as a weapon.

Christoph Waltz is especially good at that rhythm. He makes elaborate speech sound effortless, with humour that can change the balance of a scene. Jamie Foxx gives Django a more economical presence, which is a useful counterweight to all the people who enjoy hearing themselves talk.

Leonardo DiCaprio and Samuel L. Jackson make their scenes deeply unpleasant in different ways. The film’s broad style does not soften the cruelty of the world it depicts. The shifts between humour, horror, and exaggerated violence can be jarring; some are very effective, and others left me wanting a little more restraint.

The music and the wide landscapes give it plenty of Western energy. My main issue is the length. A few stretches repeat a point or keep a scene running after its strongest moment, and the momentum becomes uneven.

8/10. The dialogue and performances are the strongest reasons to watch. A tighter version of the film might work better, but the best scenes have enough confidence and tension to earn the time.

8/10

My verdict

Big performances, sharp dialogue, and a Western that takes its time before it erupts. Entertaining, brutal, and occasionally overextended.

— Desly

Perfect Days — finding enough in a day

Mon, 19 Oct 2026 14:32:01 +0200

Spoiler-free review.

Not much needs to happen in Perfect Days for a scene to work. A cassette goes into the player, sunlight falls through some leaves, someone stops for lunch. Written down, that sounds almost too slight. Watching it, the small differences start to matter.

Wim Wenders follows Hirayama, a man who cleans public toilets in Tokyo, with real patience. The routine gives the film its shape, but it never makes him feel like a collection of charming habits. There is a private life behind that calm face, and Koji Yakusho lets us sense it without spelling everything out.

The direction is what I like most here. Wenders knows when to leave a shot alone. He gives an ordinary task enough time to become interesting, and lets a change in expression do work that a speech would only flatten. The music fits that approach too: these are songs someone lives with, rather than songs chosen to tell us what to feel.

It does ask you to settle into its pace. If you keep waiting for a larger plot to take over, a few stretches may feel repetitive. For me, the repetition is mostly what makes the interruptions count.

9/10. A film that made the ordinary feel valuable without pretending life is simple. Yakusho gives it a warmth that never turns sugary.

9/10

My verdict

Wim Wenders makes a daily routine feel worth paying attention to. Quiet, warm, and carried by a lovely performance from Koji Yakusho.

— Desly

The Usual Suspects — everyone has a story

Mon, 19 Oct 2026 14:32:01 +0200

Spoiler-free review.

The Usual Suspects throws a lot of names and information at you, but it also gives you people who are fun to listen to. That matters. A complicated crime story gets tiring quickly if its characters only exist to deliver the next clue.

Christopher McQuarrie’s dialogue gives the group plenty of swagger. They interrupt, needle each other, and make confidence sound like a professional skill. Even when a conversation is doing heavy work for the plot, there is usually enough personality in it to keep it moving.

Bryan Singer keeps the storytelling restless, moving between an interrogation and the events being described. The question of how a story gets told becomes as interesting as what supposedly happened. I liked having to decide which details deserved my attention, rather than having every important moment underlined.

There are places where the film seems a little pleased with its own cleverness. Keeping track of the names can also take more effort than getting invested in the people behind them. Still, the performances and the dry humour keep it from becoming just an exercise in plotting.

8/10. Tightly put together, entertaining, and especially good when it lets a conversation become a contest. Go in knowing as little as possible.

8/10

My verdict

Sharp dialogue and a slippery crime story. The pleasure is in listening carefully, even when you’re not sure whom to trust.

— Desly

The Boy in the Striped Pyjamas — difficult to sit with

Mon, 19 Oct 2026 14:32:01 +0200

Spoiler-free review.

The strongest parts of The Boy in the Striped Pyjamas are often the simplest conversations. A child asks something directly, and an adult avoids answering it. You can feel the distance between what is being said and what is being understood.

Asa Butterfield plays Bruno with a curiosity that makes their conversations uncomfortable. Jack Scanlon gives Shmuel a quieter presence, and their scenes rely more on awkward attempts to connect than on fancy dialogue. The acting gives the film a human heart.

Mark Herman keeps the telling straightforward. The contrast between the children’s limited understanding and the adults’ behaviour does much of the work. Vera Farmiga is particularly effective in scenes where a reaction tells you more than the words around it.

Some of the writing pushes hard for an emotional response, and the simplified setup has serious limits. UCL’s Centre for Holocaust Education has documented the historical misconceptions associated with the story. I would treat it as a fictional drama, rather than a reliable picture of camp life.

9/10 for its emotional impact and the performances. A painful watch, keeping in mind the difference between moving fiction and accurate history.

9/10

My verdict

The young performances give this drama its emotional force. Powerful as fiction, though its view of history needs care.

— Desly

Oldboy — every frame feels deliberate

Mon, 19 Oct 2026 14:32:01 +0200

Spoiler-free review.

Oldboy has an intensity that is there before anyone throws a punch. Rooms feel oppressive, faces are held in the frame just long enough to become uncomfortable, and even a quiet conversation can feel threatening.

Park Chan-wook’s direction is why it works for me. The compositions are precise but not stiff. He can make a space look almost beautiful while still making you want to get out of it. The visual style is striking, but it stays tied to the character’s confusion and anger.

Choi Min-sik gives the film a physical weight. He can be frightening, pathetic, and oddly funny without making those shifts feel like separate performances. The action has that same weight: people get tired, movement gets ugly, and violence feels punishing rather than effortless.

The dialogue has a heightened quality that suits this world, although the film’s push for extremes can be exhausting. There were moments when I admired the control more than I enjoyed being in the scene. That is part of the experience, but also why this is an 8 for me.

8/10. Bold direction and a remarkable central performance. This is the original Korean film from 2003, and it is best approached without reading much about the story.

8/10

My verdict

Park Chan-wook brings striking control to a brutal story. Visually bold, uncomfortable, and carried by Choi Min-sik.

— Desly

Mr. Nobody — too many possible lives

Mon, 19 Oct 2026 14:32:01 +0200

Spoiler-free review.

Mr. Nobody starts with the sort of question that can eat up an afternoon: what would your life look like if you had made a different choice? Then it refuses to settle for just one alternative.

Jaco Van Dormael moves between possible lives with real visual imagination. A cut, a repeated image, or a change in setting can make two very different paths feel connected. I enjoyed that freedom, especially when the film trusted an image to carry the idea.

The structure is also where it gets in its own way. There are so many possibilities competing for attention that some relationships feel more like examples in an argument than people I have had time to know. Jared Leto gives the film a consistent presence, but the emotional connection comes and goes.

The dialogue is mixed for me. Some exchanges catch the uncertainty of trying to choose a life. Others explain the bigger ideas a little too neatly, when the images have already made the point. I wanted more time inside a few moments and a little less time being told what they might mean.

7/10. Ambitious, sometimes beautiful, and worth watching for its imagination. I liked the questions more consistently than the way it arranged all the answers.

7/10

My verdict

An imaginative film about choices and the lives we might have led. Beautiful in places, though its ideas sometimes crowd out its people.

— Desly

2001: A Space Odyssey — space to think

Mon, 19 Oct 2026 08:30:57 +0200

Spoiler-light review.

There is a particular kind of silence in 2001: A Space Odyssey. It gives you enough time to admire the image, then enough time to become uncomfortable inside it. Stanley Kubrick is in no hurry to explain what you are looking at. Sometimes that feels generous. Sometimes it feels like a test.

The film moves from the beginnings of human development towards a future of space travel, machines, and questions that technology cannot neatly answer. That is a large canvas, but its power often comes from something very small: a red light, a breath, a voice responding a little too calmly.

Images that deserve your attention

The space sequences have a precision that makes them absorbing even when very little seems to be happening. Movement, geometry, colour, and music do much of the storytelling. The technology has weight and routine around it. Space travel involves waiting, working, and moving carefully through an environment that does not care whether you survive.

That patience is part of the appeal. The film allows an image to become an experience before moving on. Watching while checking a phone would cut away much of what makes it interesting.

HAL brings the unease closer

HAL is a brilliant change of scale. The film can contemplate humanity and the universe, then find tension in a conversation between people and a computer. The voice is polite. The environment is controlled. Reassurance starts to sound suspicious.

There is something lasting about that discomfort. Trusting a machine is easy when its decisions agree with yours. The difficult part begins when you cannot understand the reasoning and cannot simply walk away.

The patience comes with a price

This is not an easy film to recommend to someone looking for a brisk story. The deliberate pacing can feel heavy, and the emotional distance may make the human characters harder to connect with than the design around them.

The more abstract passages also resist a single tidy explanation. That openness can keep the film alive in your mind, but it can equally leave you feeling that it has asked for a lot without giving enough back. Admiring its craft and struggling with its pace are perfectly compatible reactions.

Worth watching?

Yes, especially for its visual imagination and the unease surrounding HAL. Give it a quiet evening and a screen that lets the images breathe. There is no need to solve every moment to appreciate the scale of the attempt.

An 8/10 fits a film with remarkable ambition and a rhythm that asks something of the viewer. It rewards attention more readily than impatience.

Directed by Stanley Kubrick. Science fiction · English. Film details and official artwork: Warner Bros. Artwork © Warner Bros. Entertainment.

8/10

My verdict

Strange, patient, and visually extraordinary. Kubrick makes space feel enormous, while one calm computer voice makes it feel very small.

— Desly

Three Billboards Outside Ebbing, Missouri — anger with nowhere to go

Mon, 19 Oct 2026 08:30:57 +0200

Spoiler-light review. Discusses grief and violence without revealing the ending.

Three signs beside a road become a way of forcing an entire town to look at something it would rather leave alone. Mildred Hayes wants movement in her daughter's unsolved murder case. The billboards are direct, confrontational, and impossible to mistake for a polite request.

That is the starting point of Three Billboards Outside Ebbing, Missouri. What follows is less interested in laying out clues than in what grief does when it has nowhere useful to go.

Frances McDormand holds the centre

McDormand gives Mildred an anger that feels like effort. It takes work to keep fighting everyone, and the performance allows the exhaustion to show without making her suddenly gentle. She can be funny, cruel, and painfully vulnerable without seeming like a different person between scenes.

The character does not need to be pleasant to command attention. Her refusal to let the town settle into its routines gives the film its force. At the same time, her certainty does not make every decision wise or every target fair.

The humour catches you off guard

Martin McDonagh's dialogue is often funny, even when it's not the right time to laugh. The jokes come from stubbornness, irritation, and people saying things that make bad situations worse.

It does not remove the grief. If anything, the contrast makes the hurt more visible. A scene can turn sharply because the film lets hostility, affection, and absurdity occupy the same space.

People are more difficult than positions

Woody Harrelson and Sam Rockwell give the confrontation different kinds of resistance. The town never becomes a simple arrangement of one person who is right and everyone else who is wrong. That complication keeps the drama moving beyond the original provocation.

The film raises questions about how it handles cruelty, racism, and the chance for change. Feeling someone's pain doesn't undo the harm they do. Some shifts in who you sympathise with might feel earned, others might feel too kind. The film is strongest when it leaves that discomfort in place.

Why it lands

The performances give the sharp writing emotional weight. There are moments that could become speeches or symbols, yet the faces and silences keep pulling them back towards people trying to live with something unbearable.

The tonal changes will not work for everyone, and it is worth knowing that the subject matter is distressing. This is not a light comedy with a dramatic premise attached.

A 9/10 rating shows how strong the acting is and how the film makes space for difficult emotions. There's a lot to argue about, which is part of why the drama stays with you after you've seen it.

Written and directed by Martin McDonagh. Dark comedy / drama · English. Film details and official poster: Searchlight Pictures. Artwork © Searchlight Pictures.

9/10

My verdict

Grief turns into a public confrontation. Frances McDormand anchors a sharp, uncomfortable drama that makes room for humour without easing the hurt.

— Desly

No Country for Old Men — listen to the silence

Mon, 19 Oct 2026 08:30:57 +0200

Spoiler-light review. Contains discussion of violence, but no major plot revelations.

A man finds money at a crime scene and decides to take it. Plenty of thrillers could begin there. What makes No Country for Old Men so unsettling is how quickly the prospect of an escape gives way to the practical business of staying alive.

The danger feels real because it's grounded in physical details. Doors, distances, and the consequences of actions are clear. Small choices carry weight because someone is always watching closely.

Tension without much fuss

The Coens understand how long a viewer will stare at a doorway when given a reason to worry about what is behind it. Footsteps, pauses, and the arrangement of a room become enough to hold a scene. The filmmaking trusts you to notice.

Josh Brolin gives Llewelyn Moss a convincing resourcefulness. Watching him think through a problem makes the pursuit more engaging than a series of narrow escapes would be. Competence offers a little hope, without promising safety.

A frightening kind of calm

Javier Bardem makes Anton Chigurh unsettling through his calm and patience. His lack of emotion doesn't make him fair. It makes the people facing him work harder to figure out a situation that may not give them much of a chance.

The familiar image of the character can almost obscure how effective the performance is in motion. A pause or an ordinary question can become threatening because he seems so detached from the social habits everyone else relies on.

The sheriff changes the weight of it

Tommy Lee Jones gives Sheriff Bell a weariness that adds something beyond the pursuit. His presence asks what it means to keep trying to make sense of violence, especially when the explanations you have lived with start to feel inadequate.

That is where the film's title begins to feel heavier. There is a thriller moving forward and a man trying to understand the world around it. The two do not always want the same kind of answer.

A fair warning about expectations

The film breaks some of the usual rules of a chase story. If you're expecting every loose thread to be tied up, you might feel left hanging.

That refusal has a purpose, but it does not mean every viewer has to enjoy it. The film's control is easier to appreciate if you let the uncertainty be part of the experience.

The verdict

9/10. Precise performances, extraordinary command of tension, and a sense of unease that reaches beyond the immediate danger. A film that makes listening feel as important as watching.

9/10

My verdict

A bag of money, a relentless pursuit, and tension built from tiny sounds. The Coens make danger feel close without giving it an easy explanation.

— Desly

Psycho — the unease is in the ordinary

Mon, 19 Oct 2026 08:30:57 +0200

Spoiler-light review of Alfred Hitchcock's original film. The major twists are left untouched.

It is difficult to approach Psycho without bringing something you already know. The title, the music, and the motel have travelled far beyond the film itself. Yet knowing the reputation does not explain away the tension of watching it unfold.

Marion Crane is on the road after taking money that is not hers. An isolated motel offers a place to stop. That simple decision creates a setting where politeness and discomfort begin to overlap.

An ordinary conversation can do a lot

Anthony Perkins makes Norman Bates interesting before the film asks you to decide what to make of him. The awkwardness is not played at one obvious volume. There is courtesy, hesitation, and something harder to place.

Janet Leigh gives Marion enough interior life to make the early uncertainty involving. Watching her read a situation matters. Hitchcock allows the viewer to do the same, then makes that act of interpretation increasingly uncomfortable.

The frame does some of the worrying

Rooms, windows, and lines of sight feel carefully chosen. The black-and-white photography gives ordinary spaces a severity that suits the story. A house above a motel can become an entire relationship before anyone has explained much.

The editing and music are forceful when they need to be, but quieter moments carry plenty of weight. Suspense comes from where attention is placed and how long it stays there. An image can feel threatening without anything visibly changing inside it.

More than the famous parts

The film's cultural familiarity can make it seem like a collection of celebrated moments waiting to happen. It works better when treated as a complete experience. The apparently smaller scenes give those moments their context.

There is an uncomfortable intimacy to the viewing position, too. The film repeatedly invites curiosity about people and spaces, then makes that curiosity feel less innocent than it first appeared.

What shows its age

Some of the explanation-heavy dialogue feels more tied to its era than the visual storytelling does. The psychological language is best approached as part of the film's dramatic construction, rather than treated as a modern account of mental health.

Viewers expecting the pace of a contemporary horror film may also find the setup deliberate. Its strength lies in anticipation and manipulation of attention, rather than a constant supply of shocks.

The verdict

8/10. Still an effective piece of suspense, with performances and visual control that deserve attention beyond the familiar references. Avoid plot summaries if you can. Even for a widely discussed film, there is value in letting it choose when to reveal things.

Directed by Alfred Hitchcock. Psychological suspense / horror · English. Film details and official poster: Universal Pictures At Home. Artwork © Universal Studios.

8/10

My verdict

A roadside motel, an awkward conversation, and ordinary details that stop feeling ordinary. Hitchcock’s suspense still works beyond its famous reputation.

— Desly

Burning — the doubt stays with you

Mon, 19 Oct 2026 08:30:57 +0200

Spoiler-light review. No explanation of the ending or claims about what the mystery definitively means.

Burning is very good at making an ordinary detail feel slightly wrong. A conversation, a room, or the absence of something expected can become difficult to forget. The film gives you time to notice, then leaves you uncertain about how much significance to attach to it.

Jongsu reconnects with Haemi, someone he knew earlier in life. When she returns from a trip with the wealthy, self-assured Ben, the relationship between the three becomes increasingly uncomfortable. That is enough of the setup to know before watching.

The distance between people

Class is present in the ease with which people occupy their lives. Ben seems comfortable wherever he goes. Jongsu often appears to be working out how to stand, speak, or respond. Their differences do not need a speech to become visible.

The discomfort is also personal. Desire and insecurity make it harder to separate what is observed from what is feared. The film asks you to pay attention to that difference without offering a reliable place outside it.

Three performances, no easy access

Yoo Ah-in gives Jongsu a withdrawn quality that makes watching him watch other people part of the experience. Jun Jong-seo brings an openness to Haemi that does not make her fully available to the people trying to understand her.

Steven Yeun makes Ben's confidence quietly disconcerting. The performance leaves room for several readings of the same smile or remark. That uncertainty is more effective than making the character announce what you should think of him.

A slow burn that needs the time

Lee Chang-dong allows scenes to unfold long enough for their mood to change. The attention to spaces, light, and pauses helps the film build a world where a mystery can take root without turning everything into a clue.

It is a demanding pace. At nearly two and a half hours, the film can feel slow if you are waiting for each scene to advance the plot in an obvious way. Its interest lies partly in the accumulation of feeling, which is not always the same as the accumulation of information.

Uncertainty is the point of tension

The temptation is to turn every detail into evidence for one complete explanation. The film is more unsettling when the limits of that evidence remain visible. Suspicion can tell you something about a situation, but it can also tell you something about the person who is suspicious.

That openness will be a strength for some viewers and a frustration for others. Anyone wanting the reassurance of a neatly explained mystery should know that the film has different priorities.

The verdict

8/10. Patient, beautifully controlled, and uncomfortable in ways that linger. Best watched when you can give the small details your full attention, with enough room afterwards to disagree about what they mean.

8/10

My verdict

A quiet Korean mystery shaped by class, desire, and the limits of what can be known. Lee Chang-dong lets suspicion grow in the spaces between events.

— Desly

Burn After Reading: everyone has a plan

Mon, 19 Oct 2026 08:30:57 +0200

Spoiler-light review.

What worked for me was how unpredictable it felt. I liked not knowing where it would go next. And beneath all the absurdity, the people felt realistic: their selfishness, their assumptions, and the way they make a situation worse while believing they have it under control.

Give a room full of people half the facts and complete faith in their own intelligence. Then let them make decisions. That is the engine of Burn After Reading, and it runs on the kind of confidence that should probably require a licence.

There is a disc. There are two gym employees who think they have found something valuable. And there is an ex-CIA analyst whose life is already coming apart. What follows has the ingredients of an espionage thriller, but very little of the competence.

A spy film with the wrong people in it

The joke is not simply that these people are foolish. It is that each one thinks they understand what sort of story they are in. Someone sees an opportunity. Someone else sees a threat. Nobody pauses long enough to check whether the information connecting those ideas means anything.

The film gets a lot of mileage out of that gap. Ordinary wants become elaborate schemes. Small misunderstandings collect consequences. Even when the machinery starts moving in a dangerous direction, the people inside it remain busy with their own concerns.

The cast is the main attraction

Brad Pitt plays Chad with an enthusiasm that makes him both ridiculous and oddly endearing. The physical comedy matters as much as the dialogue: the posture, the expressions, the certainty that he is helping. Frances McDormand gives Linda a harder edge. Her determination keeps the story moving, even when a sensible person would have walked away.

George Clooney brings nervous energy to Harry, while John Malkovich makes Osborne's irritation feel permanently close to boiling over. Tilda Swinton adds a much colder presence. Put them together and the pleasure comes from watching very different kinds of self-importance collide.

Funny, until it suddenly isn't

The Coens do not soften the consequences just because the setup is absurd. The humour can turn uncomfortable quickly. That gives the film its bite, but it also means the experience is less cosy than the cast and the comedy label might suggest.

There is no reassuring genius waiting to explain the whole mess. The film's distance from its characters is part of the joke. It watches their behaviour closely without offering much comfort when their plans fail.

What might not work for everyone

Spending time with this many selfish, misguided people can be tiring. If you need a character to root for, the film makes that difficult. And if you arrive wanting an intricate spy mystery whose pieces fit together satisfyingly, the deliberate waste and confusion may feel frustrating.

Its abrupt turns are another dividing line. For some viewers, they are what make the comedy land. For others, they interrupt the fun. Both reactions make sense: the film is intentionally unsentimental about the people it has persuaded you to watch.

Worth an evening?

Yes, for viewers who enjoy dry humour, uncomfortable situations, and a thriller structure being quietly dismantled from within. The cast gives the foolishness enough personality to keep it entertaining, and the film stays focused rather than stretching the premise.

Best approached as a dark comedy about people making a mess, rather than a mystery waiting to be solved. Go in without knowing the big turns. The less you bring with you, the better the surprises work.

8/10

Unpredictable, with believable human flaws.

The unpredictable story kept it interesting for me. The situation is absurd, but the way people behave feels realistic. That combination is what makes it work.

Directed by Joel and Ethan Coen. English · Dark comedy · 96 minutes. Film details: Focus Features. Poster: Universal Pictures At Home, © Focus Features.

— Desly

Goodbye passwords

Sun, 18 Oct 2026 19:27:24 +0200

How many passwords do you have? Be honest. Now, how many of them are actually different?

Most of us rely on a few favourite passwords, tweaking them slightly — a capital letter here, an exclamation mark there, a year at the end. We know it's bad. We do it anyway, because nobody can remember two hundred random strings of characters.

Working in DevOps, I see the other side of this too. A huge share of security problems still start with a stolen or guessed password. Not clever hacking, just someone typing the right word into the wrong website.

Passkeys are the first real fix I've seen for this. And the good news: you can start using them today.

What a passkey actually is

A passkey replaces your password with something you don't have to remember, and that can't be stolen from the website.

When you create a passkey for a website, your phone or computer makes a matching pair of digital keys. One is private and never leaves your device. The other is public, and that's all the website stores.

When you sign in, the website sends a little challenge. Your device answers it with the private key, after you unlock it with your face, fingerprint or PIN. The website checks the answer with the public key. If it matches, you're in.

No password is typed. No password is sent. No password is stored on the server.

The website keeps a lock. Only your phone has the key.

Why it's so much safer

Nothing to steal from the website. When a company gets hacked and its password database leaks, millions of accounts are suddenly at risk. With passkeys, all the hackers get is public keys. They're useless on their own.

Phishing stops working. This is the big one. A fake login page can trick a human into typing a password. It can't trick a passkey, because a passkey is tied to the real website's address. If the site isn't really your bank, your phone simply won't offer the passkey.

Nothing to reuse. Every passkey is unique to one website. One leak can't unlock the rest of your life.

Nothing to forget. You unlock your phone dozens of times a day anyway. Signing in feels exactly like that.

Who supports them

Passkeys are built on a standard from the FIDO Alliance, and Apple, Google and Microsoft all committed to supporting them together. That's rare, and it's why this is actually happening.

On an iPhone or Mac, passkeys are saved in your Apple account's keychain and sync between your devices. On Android and Chrome, they're saved in Google Password Manager. Windows has them too. Password managers like 1Password and Bitwarden can store them as well, which helps if you use a mix of devices.

A growing list of big services already let you sign in with one: Google, Apple, Microsoft, Amazon, PayPal, GitHub, WhatsApp and many more. Microsoft has even started making new accounts passwordless by default.

How to start (it takes five minutes)

Pick the account that matters most. Usually that's your main email, because email is the key that resets everything else.

Go to the security settings of that account and look for "passkeys" or "sign in with a passkey". Click create, confirm with your face or fingerprint, and you're done. Next time you sign in, your device will offer the passkey instead of asking for a password.

On a computer that isn't yours, many sites can show a QR code. Scan it with your phone, approve it there, and you're signed in, without typing anything on that computer.

The honest downsides

It's not perfect yet.

Switching ecosystems can be awkward. If all your passkeys live in Apple's keychain and you move to Android, moving them over has historically been a pain. The industry is working on a standard way to transfer them, but it's still early.

Not every site supports them. Plenty of websites still only take passwords. You'll live in a mixed world for a while.

Losing your devices needs a plan. Because passkeys sync through your account, losing one phone is fine. Losing access to your whole Apple or Google account is not. Set up account recovery properly, with a recovery contact or recovery key.

It can be confusing. Different sites word it differently, and sometimes they still ask for a password "just in case". It will get smoother.

Are passwords really going away?

Not overnight. Passwords have been around since the earliest days of computing and they'll stick around for a long time on older sites. But for the accounts that matter most, I think within a few years typing a password will feel as old-fashioned as writing a cheque.

I've started switching my important accounts over. The first time I signed in with just my face, on a site that used to need a long password and a code from my phone, it honestly felt like cheating.

My take: set up a passkey for your email today. It's the five minutes of security you'll never regret.

— Desly

Will AI take my DevOps job?

Sun, 18 Oct 2026 19:27:24 +0200

Every few weeks someone sends me a video with a title like "AI agent replaces entire DevOps team." I watch it, I laugh a little, and then, if I'm honest, I think about it a bit longer than I'd like to admit.

I'm a DevOps engineer. My job is to make sure software gets built, tested, shipped and kept running. Pipelines, cloud infrastructure, containers, monitoring, and the occasional alert that ruins a quiet evening. So when people say AI will automate everything, my job is supposed to be near the top of the list. Here's what I actually think.

What AI is already good at in my world

Let's be fair first. AI has become genuinely useful in DevOps, and pretending otherwise would be silly.

Writing the boring configuration. A pipeline file, a Dockerfile, a Kubernetes manifest, a chunk of Terraform. Things that follow patterns and that I used to copy from old projects or documentation. An AI assistant gets me a solid first draft in seconds.

Reading logs faster than any human. When something breaks, the answer is usually buried in thousands of lines of logs. AI tools are very good at summarising them, spotting the one error that matters and pointing at the change that probably caused it.

Explaining unfamiliar things. An old script nobody remembers writing, a tool I haven't used before, a strange error message. Asking an AI to explain it saves a lot of searching.

Doing small fixes on its own. The newest tools act more like agents. They can see a failing test, read the logs, guess the cause, write a fix and open a pull request. The picture above isn't science fiction anymore.

What it can't do, yet

And yet, the hard parts of my job are mostly not typing.

Knowing the context. Why is this service configured in this strange way? Because three years ago it caused an outage, and the fix was this exact strange setting. That knowledge lives in people's heads, old tickets and half-remembered conversations. AI sees the code. It doesn't see the history.

Taking responsibility. When production is down and customers are affected, someone has to decide: roll back, or push a fix forward? Wake up the database team, or wait ten minutes? Those calls involve risk, trade-offs and accountability. An AI can suggest. A human has to own it.

Being confidently wrong, safely. AI writes configuration that looks perfect and is subtly broken. A permission that's far too open. A setting that works in testing and falls over under real traffic. In infrastructure, small mistakes can be very expensive, or very public. Every AI suggestion still needs someone who can tell the difference.

Talking to people. A surprising amount of DevOps is conversation: understanding what developers need, agreeing on standards, explaining to a manager why we can't just "turn on the cloud and save money". No model does that for me.

AI is a very fast junior engineer who never gets tired, and never quite knows when it's wrong.

How the job is actually changing

I don't think the job is disappearing. I think it's moving up a level.

Less time writing configuration by hand, more time reviewing it. Less time digging through logs, more time deciding what to do about what the logs say. Less time on repetitive fixes, more time designing systems that don't break in the first place. And a new kind of work: setting up the guardrails that let AI agents help safely. What they're allowed to touch, what needs a human approval, how we test their changes, how we undo them.

That last part is very DevOps. We've always been the people who build the safety rails for automation. AI is just a new, very powerful kind of automation.

And then there's MLOps

There's also a funny twist. Someone has to build, deploy and keep the AI systems themselves running. Models need pipelines, monitoring, versioning, rollbacks and on-call too. That's a big part of why I started learning MLOps. If AI is coming into my world, I'd rather understand how it works from the inside than watch it from the outside.

What I'd tell someone starting in DevOps today

Learn the fundamentals properly, because they're what let you judge AI's output: networking, Linux, how the cloud actually works, security basics. Use AI tools every day and get good at them, the same way earlier generations learned scripting. And practise the human side: writing clearly, explaining trade-offs, staying calm when things break.

The engineers who struggle won't be the ones replaced by AI. They'll be the ones replaced by engineers who use AI well.

So, will AI take my job?

Parts of it, yes. The repetitive parts, the copy-and-paste parts, the "read ten thousand log lines" parts. Honestly, I won't miss them.

The job itself? I think it will look quite different in five years. But someone will still need to understand the whole system, make the hard calls, and be the one who says "no, don't deploy that." For now, that's still me.

My take: AI proposes, humans decide. My job is making sure it stays that way where it matters.

— Desly

Proving a photo is real

Sun, 18 Oct 2026 19:27:24 +0200

Remember the picture of the Pope in a huge white puffer jacket? It went everywhere. People shared it, laughed at it, and a lot of them believed it. It was made with an AI image generator. Nobody took that photo, because there was no photo.

Tools have improved since then. Now you can type a sentence and get an image that looks like it came out of a real camera. Hands are fine now. Text is fine. Light and shadows are convincing.

As someone who takes photos, this worries me in a specific way. Not that people will make fake images, that was always possible. It's that people will stop believing real ones.

Spotting fakes is a losing game

For a while, the advice was: look for six fingers, weird earrings, melted text in the background. That advice is already out of date. Every time someone finds a tell, the next model fixes it.

AI detection tools have the same problem. They guess, they get it wrong, and they will always be one step behind. So the smarter people in this space flipped the question. Instead of asking "is this fake?", ask "can this prove it's real?"

You can't catch every fake. But you can give real photos a way to prove themselves.

Content Credentials, explained simply

The idea is called content provenance, and the most important standard for it comes from a group called the C2PA, the Coalition for Content Provenance and Authenticity. It was started in 2021 by companies including Adobe, Microsoft, Intel, Arm, the BBC and Truepic. The friendly name for what they built is Content Credentials.

Think of it as a nutrition label for a photo, with a tamper-proof seal.

When a supported camera takes a picture, it attaches a small record: this image was captured by a camera, at this time, and here is a cryptographic signature to prove it. When you edit the photo in a supported app, the app adds its own entry: exposure changed, cropped, this part was generated with AI. Each step is signed. If anyone changes the image without updating the record, the signature breaks, and anyone checking can see it.

It doesn't say whether a photo is "true". A real photo can still be misleading. But it tells you where the image came from and what happened to it along the way. That's a lot more than we have now.

Who's actually using it

This isn't just a white paper anymore. Leica released the first camera with Content Credentials built in, back in 2023. Sony, Nikon and Canon have all started adding support to some of their professional models, mostly aimed at news photographers. Recent phones from Google and Samsung have started adding credentials too, at least to some photos and to images edited with their AI tools.

On the software side, Adobe's apps can attach credentials when you export, and Adobe's own image generator marks its output as AI-made. OpenAI adds credentials to images made by its generators. Google also uses its own invisible watermark, SynthID, for AI images.

And you can check an image yourself. There's a free tool at contentcredentials.org/verify. Drop an image in, and if it has credentials, it shows you the history.

The catch: credentials are easy to lose

Here's the honest problem. Content Credentials live in the file's metadata. Take a screenshot, and they're gone. Upload to many social media sites, and they get stripped when the image is compressed. Send it through a chat app, often the same.

So right now, a photo without credentials proves nothing. It might be fake, or it might be a perfectly real photo that lost its label on the way. The system only becomes really powerful when the big platforms keep the credentials and show them to you. Some have started: LinkedIn shows a small label on images that carry them, and others show "AI info" tags. It's progress, but slow.

Invisible watermarks, hidden in the pixels themselves, help with this, because they can survive a screenshot. Combining the two, a signed record plus a watermark that points back to it, is where things seem to be heading.

The privacy question

There's a tension here that I feel personally. When I put photos on this website, I deliberately remove the location data hidden in the files. Nobody needs to know exactly where I was standing, or where I live.

A credential that proves a photo is real could, if you're not careful, also reveal who took it and where. The standard lets you choose what to include. You can sign a photo as yours without publishing your GPS location. For a journalist in a dangerous place, that choice matters a lot. For the rest of us, it's worth checking the settings before switching it on.

What this means for photographers like me

Honestly, my cameras don't support this yet, and neither do the photos on this site. But I think in a few years it will be normal, the way the little padlock in your browser became normal for websites. You won't think about it. You'll just notice when it's missing.

For news photos, evidence and anything important, I think we'll slowly learn to ask: where did this come from? Does it have credentials? And for everything else, maybe a healthy habit: before you share the shocking picture, take five seconds and wonder whether anyone actually took it.

My take: we can't stop fake photos. But we can make real ones easier to trust.

— Desly

Your next car is a computer on wheels

Sun, 18 Oct 2026 19:27:24 +0200

For as long as I can remember, I've been a car person. The sound, the design, the feeling of a good road. I grew up thinking a car was a machine: engine, gearbox, suspension, and a bit of electronics to keep it all running.

That idea is quietly going out of date. The car you buy next is very likely to be, at its heart, a computer. One that happens to have wheels, seats and a very large battery or fuel tank attached.

What "software-defined" actually means

The industry calls it the software-defined vehicle. Behind the buzzword is a real change in how cars are built.

For decades, every function in a car had its own little computer. One for the windows, one for the airbags, one for the engine, one for the radio. A modern car can have more than a hundred of them, from different suppliers, all talking to each other. It works, but it's messy, and it's very hard to update.

The new approach is more like how your phone works: a few powerful central computers, with the car split into zones that handle the hardware nearby. The behaviour of the car, from how the screen looks to how the brakes feel, is controlled more and more by software. And that software can change after you buy the car.

A car used to be at its best on the day you bought it. Now it can get better on your driveway.

The good part: cars that improve

Tesla made over-the-air updates normal. Your car downloads an update overnight, like a phone, and in the morning it has a new feature or a fix. The famous example is from 2018, when a well-known consumer magazine criticised the Model 3's braking distance. Tesla pushed an update within days, and the braking distance improved. No workshop visit, no recall letter.

Today almost every manufacturer does some version of this. Maps, the infotainment system, driver assistance, battery management, even the way the car charges can all be improved remotely. Some recalls that once meant a trip to the dealer can now be fixed overnight. As someone who works in DevOps, I love this. It's exactly how good software should be delivered: small, frequent, safe updates.

The part that annoys me: paying again for what you own

Here's where the car person in me gets angry.

A few years ago, BMW offered heated seats as a monthly subscription in some countries. The heating elements were already built into the seat. You had paid for the hardware. You just had to keep paying to switch it on. The backlash was so strong that BMW dropped the idea for heated seats in 2023.

Mercedes offered extra acceleration on some of its electric cars in the US as a yearly subscription. Same motor, same battery. The car simply goes faster once you pay.

I get why manufacturers do it. Building one version of a car and unlocking features with software is cheaper. But if the hardware is in my car and I paid for my car, it feels wrong to rent it back. Optional services like live traffic or streaming are one thing. Locking the seat heater in a German winter is another.

When software goes wrong

Software makes cars better, but it also brings software problems.

Volkswagen's early ID.3 electric cars had missing features that were promised later through updates. Reviews focused more on bugs and slow screens than on driving. VW fixed much of it over time, but it showed that building good software is a very different skill from building good cars.

Then there's security. In 2015, two security researchers showed they could take control of a Jeep Cherokee remotely, over the internet, while a journalist was driving it on a highway. Chrysler recalled 1.4 million vehicles to fix it. A car that's always connected is a car that has to be defended like any other computer on the internet.

Your car knows a lot about you

This is the part people think about least. A connected car knows where you go, when, how fast, how hard you brake, and often which phone is connected and who you call. Some cars have cameras inside watching the driver.

When the Mozilla Foundation reviewed car brands for privacy in 2023, it called cars the worst product category it had ever looked at. Phones and smart speakers did better. Most of us read the privacy settings on our phones. Almost nobody reads them in their car.

What I'd look for in my next car

After reading way too much about this, here's my personal checklist:

Proper over-the-air updates for the whole car, not just the maps. And a track record of the manufacturer actually delivering them.
No subscriptions for hardware I already paid for. Services, fine. Seat heating, no.
Physical buttons for the things you use while driving. Climate, volume, hazard lights. I like screens, but not for everything.
Clear privacy settings I can understand and actually switch off.
Phone integration that works, because for many of us, our phone's software is still better than the car's.

Where this is going

I don't think we're going back. Cars will keep becoming more like computers, and in many ways that's great: safer, smarter, and better for longer. The manufacturers that get the software right will win. The ones that treat software as a way to charge us again for the same metal will, I hope, lose.

The engine sound may be fading. But the car person in me is still excited. It's just that now, I also care about the release notes.

My take: buy the car for how it drives, but check how it updates.

— Desly

What if the internet is already dead?

Sun, 18 Oct 2026 19:27:24 +0200

Scroll through the comments under any viral post. "So true!" "This is amazing 🔥" "Who else is watching this at 3 a.m.?" A profile picture that's a little too perfect, a username with eight random numbers at the end, and a bio that says nothing at all.

At some point you start wondering: is anyone actually here?

That feeling has a name. The Dead Internet Theory.

Where it came from

The theory took shape in 2021, in a long post on a small online forum. The author argued that the internet "died" somewhere around 2016 or 2017. Since then, they claimed, most of the content and activity online has been generated by bots and algorithms, with real humans a shrinking minority. The darker version says it's deliberate: governments and corporations filling the internet with fake activity to shape what we think and buy.

The Atlantic wrote about it later that year, under a headline that asked whether the internet had died five years earlier and we'd simply missed it. It was presented as a strange, slightly ridiculous idea. Fun to read about. Obviously not true.

The theory started as paranoia. Then the bots got better at writing.

Why it suddenly feels less crazy

Then generative AI arrived. And a lot of things the theory predicted started showing up in plain sight.

The bot traffic is real. Imperva, a security company, releases an annual report on website visitors. For years, bots have accounted for nearly half of all web traffic. In their latest reports, automated traffic now outnumbers human traffic.

AI content is everywhere. In 2024, Facebook feeds were full of strange AI-generated images, like "Shrimp Jesus"—a picture of Jesus made of shrimp. Thousands of comments said "Amen". Many of those comments looked automated too. Bots posting for bots, with algorithms encouraging them, because engagement is engagement.

Even the people building it noticed. Sam Altman, CEO of OpenAI, joked online that he never took the dead internet theory seriously. But he added that there seem to be a lot of AI-run accounts around now. When the person behind ChatGPT says that, you pay attention.

Search results feel emptier. Look up a product review and you'll often find pages that read like they were written by nobody, for nobody, mostly to sell you something. That's because many of them were.

Where the theory goes too far

Here's where I get off the train.

The internet clearly isn't dead. Real people are still here: arguing in group chats, posting holiday photos, writing long angry reviews, building websites like this one. I still get comments from people I can actually talk back to. Bots are many, but they're mostly noise. They don't replace us.

The "secret plan" idea doesn't hold up. There's no proof of a single coordinated conspiracy. What there is, is something more boring and in some ways worse: lots of separate actors—spammers, scammers, marketers, propaganda farms, and platforms hungry for engagement—all with a motive to create fake activity. No one needs to plan it. The money does the planning.

How I deal with it

I've started treating the internet a bit like a busy city. Most of the noise isn't meant for me. I look for signs of a real person: someone who has a history, a face, a point of view, who replies like a human, makes typos, disagrees sometimes.

I follow people, not feeds. I pay more attention to small communities where everyone knows everyone. And I've accepted that the "comment section" is, more and more, a performance by machines for an algorithm.

The funny thing is, that makes real human corners of the internet feel more valuable. Like this one, I hope.

Verdict: not dead, but crowded with bots. The internet's still alive, just harder to hear over the machines.

— Desly

What if my phone is slowing down on purpose?

Sun, 18 Oct 2026 19:27:24 +0200

You know the feeling. Your phone was fast. Then, around the time the shiny new model launches, apps start taking a second longer to open. The keyboard lags. The battery gives up before dinner. And a small voice says: they're doing this on purpose.

The theory is called planned obsolescence, the idea that companies design products to fail or slow down so you'll buy new ones. This one has some real history behind it, unlike most theories in this section.

It has happened before

In the 1920s, the world's biggest light bulb makers formed a group known as the Phoebus cartel. They agreed to limit bulb life to about 1,000 hours, and fined members whose bulbs lasted too long. It's one of the clearest documented cases of a whole industry making products worse on purpose.

So the idea isn't crazy. The question is whether it's happening in your pocket.

Then came "batterygate"

In 2017, users noticed that some older iPhones got dramatically faster after a battery replacement. A developer at Geekbench, a popular performance-testing app, looked at the data and found a clear pattern: iPhones with worn batteries were running slower.

Apple confirmed it. An iOS update had added a feature that slowed down iPhones with ageing batteries. Apple's explanation was that old batteries can't always deliver enough power at peak demand, which was causing some phones to shut down unexpectedly. Slowing the processor prevented the shutdowns.

The slowdown was real. Not telling anyone was the real mistake.

That explanation is technically reasonable. The problem was that Apple didn't tell anyone. People thought their phones were simply getting old and bought new ones, when a cheaper battery would have fixed it.

The fallout was huge. Apple apologised and cut the price of battery replacements. It added a Battery Health screen to iOS so you can see your battery's condition and whether the phone is being slowed down. It paid hundreds of millions of dollars to settle lawsuits in the US, and France fined it 25 million euros. In Italy, regulators fined both Apple and Samsung over software updates that hurt older phones' performance.

So is my phone slowing down on purpose?

Probably not in the way the theory says. There's no good evidence that phones secretly get a "slow down now" signal when a new model launches. But several real things make phones feel slower over time, and they tend to happen together:

The battery ages. Lithium batteries lose capacity with every charge cycle. A worn battery means shorter life, and on some phones, managed performance.
Apps get heavier. Apps are built for the newest phones. Each update adds features, animations and, yes, more tracking. Your old processor has to work harder to do the same thing.
New software is built for new hardware. A big yearly update is designed for this year's phone first. Older models run it, but not always gracefully.
Storage fills up. A nearly full phone has less room to breathe, and things slow down.
Our expectations change. Try a friend's brand-new phone for five minutes, and your own suddenly feels sluggish. Nothing changed except what you compared it to.

The good news: the rules are changing

The batterygate scandal helped push governments to act. In the EU, new rules now require phones to have batteries that keep most of their capacity for hundreds of charge cycles, make spare parts available for years, and keep getting software updates for years after a model stops being sold. Right-to-repair is slowly becoming the law, not just a slogan.

What I do

When a phone starts feeling slow, before I think about upgrading, I check the battery health first. If it's worn, a new battery is far cheaper than a new phone and often feels like getting a new phone. Then I clear out storage and delete apps I don't use. Most of the time, that's enough to buy another year or two.

And when I do upgrade, I try to make it because the new phone does something I actually want, not because the old one has been made to feel tired.

Verdict: partly true. It has happened, it got caught, and it got fined. But most slowdowns are batteries, bloat and time, not a secret plan.

— Desly

What if Area 51 is hiding aliens?

Sun, 18 Oct 2026 19:27:24 +0200

There's a sign at the edge of a desert in Nevada that, as a photographer, I find almost personally offensive. It says, more or less: restricted area, use of deadly force authorised, and photography prohibited.

Behind that sign is Area 51, probably the most famous secret base in the world. For over seventy years, people have believed that what's hidden there isn't just secret planes. They think it's alien spacecraft, maybe even the aliens themselves.

The base that didn't exist

Part of what makes Area 51 so fascinating is that, for decades, the US government wouldn't even admit it was there. It didn't appear on official maps. Pilots were told to avoid the airspace. Workers flew in from Las Vegas on unmarked planes and weren't allowed to talk about their jobs.

The CIA only officially acknowledged the base in 2013, when declassified documents about the U-2 spy plane were released. If you want to grow a conspiracy theory, there's no better soil than a government pretending something doesn't exist.

Roswell: where the alien story starts

In 1947, a rancher near Roswell, New Mexico found strange debris on his land: rubber, foil, sticks and tape. The local army airfield put out a press release saying it had recovered a "flying disc". The next day, it corrected the story: it was a weather balloon.

That correction, of course, was exactly what a cover-up would look like. Decades later, the Roswell story grew into crashed saucers, alien bodies and autopsies, and the bodies were said to have been taken to, you guessed it, Area 51.

In the 1990s, the US Air Force released reports explaining that the debris came from Project Mogul, a top-secret programme using high-altitude balloons to listen for Soviet nuclear tests. The "alien bodies", they said, were most likely memories of crash-test dummies dropped from balloons in later years, mixed up over time. It fits the rubber, foil and sticks pretty well.

The truth is out there. It just might be a balloon.

The real secret: spy planes

Here's the part I find most convincing. Area 51 was built in 1955 to test the U-2, a spy plane designed to fly far higher than any airliner of the time. Later came the A-12, the even faster ancestor of the SR-71 Blackbird, and the stealth prototypes that became the F-117, which looked like nothing anyone had seen before.

A CIA history published in the 1990s admitted something remarkable: many UFO sightings in the 1950s and 60s were actually these secret planes. A silver aircraft glinting in the sun at 60,000 feet, where people thought nothing could fly, looks a lot like a UFO. And the government was happy to let people believe in aliens rather than reveal its spy programmes.

So, in a way, the theory is right. Area 51 really was hiding strange flying objects. They were just ours.

But then the Pentagon started talking about UFOs

This is where it gets interesting again. In 2017, the New York Times revealed a secret Pentagon programme that had been studying UFOs. In 2020, the US Navy officially released videos taken by fighter pilots, showing objects that seemed to move in impossible ways. UFOs got a new official name: UAPs, unidentified anomalous phenomena.

In 2023, a former intelligence officer told the US Congress under oath that the government had recovered crafts and "non-human biologics". It was headline news around the world.

But in 2024, the Pentagon's own UFO office published a review of decades of records and said it found no evidence of alien technology, or of any secret recovery programme. Most cases, when there's enough data, turn out to be balloons, drones, birds, satellites, or sensor glitches. Some remain unexplained, mainly because the data is poor, not because it's alien.

Why we want it to be true

I think the Area 51 legend survives because it combines two things people believe deeply: that we're not alone in the universe, and that governments don't tell us everything. The second one is definitely true. The first one might be.

And honestly, I'd love it to be real. Who wouldn't want proof that we're not alone? But wanting something to be true is exactly when you need to be most careful.

In 2019, a joke Facebook event called "Storm Area 51, They Can't Stop All of Us" got millions of people clicking "going". On the day, only a small crowd showed up in the desert, mostly for the festivals and the photos. Which, honestly, is the most human response to a conspiracy theory I can imagine.

Verdict: a real secret base, real secret aircraft, and very real cover-ups. Aliens? No evidence yet. But I'll keep watching the sky.

— Desly

What if aliens built the pyramids?

Sun, 18 Oct 2026 19:27:24 +0200

When I visited the little church of St. Bartholomä at Königssee, under the Alps, I remember standing there wondering how people got all that stone to a lake shore you can really only reach by boat. Hundreds of years ago. No trucks, no cranes, no power tools.

Now imagine that feeling multiplied by a few thousand, and you get the Great Pyramid of Giza.

It was built around 4,500 years ago for the pharaoh Khufu. It's made of roughly 2.3 million stone blocks, some weighing many tonnes. It was originally about 146 metres tall, and for nearly four thousand years it was the tallest building humans had ever made. It's aligned to the compass points with astonishing accuracy.

So it's not surprising that some people look at it and think: humans couldn't have done that.

Where the alien idea comes from

The "ancient astronauts" theory became famous in 1968 with a book by Erich von Däniken called Chariots of the Gods?. He argued that many ancient wonders, from the pyramids to Stonehenge to the Nazca lines in Peru, were built with help from visitors from space, who early humans then remembered as gods.

The book sold millions of copies. Decades later, a TV series called Ancient Aliens turned the idea into a long-running show, complete with dramatic music, and gave the internet a famous meme: "I'm not saying it was aliens... but it was aliens."

The question isn't whether humans could build the pyramids. It's why we find it so hard to believe they did.

What the evidence actually shows

Here's what I find fascinating. We don't just have the pyramids. We have a surprising amount of evidence about the people who built them.

The workers' town. Near the pyramids, archaeologists found the remains of a town where the builders lived: bakeries, breweries, sleeping quarters, and enough animal bones to show the workers were well fed with meat. Not slaves in chains, as old movies showed, but organised crews of labourers, many of them likely farmers working in rotation.

The workers' tombs. Right next to the pyramids are the graves of the builders themselves, buried with honour near their king. Some skeletons show healed injuries and signs of medical care.

Their graffiti. Inside the pyramids, in places nobody was supposed to see, work gangs painted their team names. Names like "Friends of Khufu". It's ancient office banter.

A logbook. In 2013, archaeologists found the oldest known inscribed papyri, at a harbour on the Red Sea coast. Among them was the diary of an official called Merer, who describes his team transporting limestone blocks by boat along the Nile to Giza, for the Great Pyramid. It's literally a work diary from the construction project.

How they moved the stones

The Egyptians moved huge blocks on wooden sledges. An ancient tomb painting shows a giant statue being dragged on a sledge while a man pours water onto the sand in front of it. In 2014, physicists tested this and found that wetting the sand to the right amount roughly halves the friction. It's a simple, clever trick, and it works.

And they had the Nile. A study in 2024 found evidence of an ancient, now-dried branch of the river that once flowed close to the pyramid sites. Boats could bring stone almost to the building site.

Ramps, levers, sledges, boats, an enormous, well-organised workforce, and about twenty years. No spaceships needed.

The best evidence: they got it wrong first

This is my favourite part. The Egyptians didn't get pyramids right the first time.

The earliest one, the Step Pyramid of Djoser, is basically a stack of flat platforms. A later attempt at Meidum seems to have partially collapsed. Then came the Bent Pyramid, which changes angle halfway up, almost certainly because the builders realised the original slope was too steep and unstable. Only after that did they build the Red Pyramid, and then the Great Pyramid.

That's not what you'd expect from aliens with advanced technology. That's what you'd expect from humans learning by trial and error, over generations. It's engineering. It's beautiful.

Why the theory bothers me a little

It's worth noticing which ancient wonders get credited to aliens. It's usually the pyramids of Egypt, the cities of the Americas, the monuments of Africa and Asia. Rarely anything built in Europe.

Many Egyptians find the alien theory insulting, and I understand why. It quietly takes away one of humanity's greatest achievements from the people who actually did the work.

Coming from Kerala, a place with its own ancient temples, palaces and traditions of craftsmanship, I'd rather celebrate what people built with their own hands and brains. That, to me, is far more impressive than little green men with a crane.

Verdict: built by humans. Thousands of skilled, well-fed, organised humans, who left their names on the walls. No aliens needed.

— Desly

Who really killed JFK?

Sun, 18 Oct 2026 19:27:24 +0200

Some conspiracy theories are fun. This one isn't really. A president was shot in front of his wife and a cheering crowd, and the man accused of doing it was himself shot dead two days later, live on television. If you had designed an event to make people suspicious forever, you couldn't have done it better.

I wanted to look at it properly. It's the granddaddy of all modern conspiracy theories.

What happened

On 22 November 1963, President John F. Kennedy was riding in an open car through Dealey Plaza in Dallas, Texas. At 12:30, shots were fired. Kennedy was hit in the neck and the head. Texas Governor John Connally, sitting in front of him, was badly wounded.

Within hours, police arrested Lee Harvey Oswald, a former US Marine who had once defected to the Soviet Union and come back. He worked at the Texas School Book Depository, overlooking the route, and a rifle was found on the sixth floor. Oswald said he was "just a patsy". Two days later, while being moved through a police basement, he was shot by a nightclub owner called Jack Ruby. There would be no trial.

The official answer

In 1964, the Warren Commission said Oswald fired three shots from the sixth-floor window and acted alone.

The most attacked part of the report is the so-called "single bullet theory". It says one bullet passed through Kennedy's neck and then went on to cause all of Connally's wounds, in his back, chest, wrist and thigh. Critics nicknamed it the "magic bullet", especially because the bullet was found in surprisingly good condition.

When the official story needs a "magic bullet", people will start looking for a magician.

Why so many people don't buy it

The Zapruder film. A local man, Abraham Zapruder, filmed the whole thing on his home movie camera. In the film, Kennedy's head moves sharply backwards at the fatal shot, which to many viewers suggests a shot from the front, from the grassy knoll, not from behind.

The grassy knoll. Several witnesses said they heard shots from behind a wooden fence on a small hill in front of the car.

A second investigation disagreed. In 1979, a US House committee concluded that Kennedy was "probably assassinated as a result of a conspiracy". That conclusion leaned heavily on a police radio recording that seemed to contain a fourth shot. A few years later, a panel of scientists re-examined that recording and found that the sounds came from about a minute after the shooting.

The CIA did hide things. This is the part that matters most to me. Later investigations showed the CIA hadn't told the Warren Commission about its secret plots to assassinate Fidel Castro, and that it had been watching Oswald closely weeks before, during a visit to Mexico City. Governments hiding things isn't a theory here. It's documented.

What the evidence says now

Modern 3D reconstructions of the car show that Connally was sitting lower and further inside than Kennedy, and turned in his seat. From the sixth-floor window, a straight line through Kennedy's neck does lead to Connally's wounds. The "magic" bullet path looks much less magical when you model the real positions. Medical experts also explain the backward head movement as a reaction of the body, not proof of a shot from the front. That's still argued about.

And then there are the files. After Oliver Stone's film JFK in 1991 caused public outrage, the US passed a law to release all the assassination records. That took decades. Tens of thousands of pages were finally released in 2025. Historians found plenty of embarrassing detail about the CIA's Cold War operations. What they didn't find was a smoking gun showing that someone other than Oswald pulled the trigger.

Where I land

I think the evidence points to Oswald firing the shots. I also understand completely why people don't trust that answer. The CIA withheld information, the investigation was rushed, and the man who could have told us the most was killed before he could speak.

I think the real cover-up was probably not murder. It was embarrassment: intelligence agencies hiding how much they knew about Oswald, and the things they were doing that they didn't want anyone to see. Secrecy around the truth can look exactly like a lie.

That might be the most important lesson of all the conspiracy theories in this section. When institutions hide things, even small, unrelated things, people fill the gap with the worst possible story. And sometimes, honestly, who can blame them?

Verdict: most likely Oswald, most likely alone. But the secrecy was real, and that's why the doubt will never die.

— Desly

What if Tesla invented free energy?

Sun, 18 Oct 2026 19:27:24 +0200

Nikola Tesla has become a kind of internet saint. A misunderstood genius, robbed by Edison, ignored by history, whose greatest invention was hidden from us. The car company named itself after him. There are memes, T-shirts and videos with millions of views claiming that Tesla invented free energy, and that powerful people made sure we'd never have it.

As someone who loves technology, I really wanted to know: how much of that is true?

The genius part is real

Let's start with what's not in doubt. Tesla was brilliant. His work on alternating current, AC, and the induction motor helped create the electrical system the whole world still uses. In the famous "war of the currents" in the late 1880s, Tesla's AC, backed by George Westinghouse, beat Thomas Edison's direct current. In 1895, AC power from a new plant at Niagara Falls began lighting up the region. Every time you plug something into a wall socket, you're using an idea Tesla helped make possible.

He also did pioneering work on radio. In 1943, the US Supreme Court ruled on a long patent battle and invalidated a key radio patent held by Guglielmo Marconi, partly because Tesla and others had got there first.

The tower

The free energy story centres on one place: Wardenclyffe, on Long Island, New York. In 1901, with funding from the banker J.P. Morgan, Tesla began building a huge tower, about 57 metres tall, with a giant mushroom-shaped dome on top.

The plan started as wireless communication across the Atlantic. But Tesla's real dream was bigger: to transmit electrical power without wires, using the Earth itself as part of the circuit. Power for everyone, everywhere.

Then the money ran out. Morgan stopped funding the project. A popular story says Morgan pulled out because he asked, "Where do we put the meter?" There's no evidence he ever said that. More likely, he simply saw that Marconi was already sending radio signals across the Atlantic with much cheaper equipment, and Tesla kept asking for more money for a vision that kept growing. The tower was never finished. It was torn down in 1917 and sold for scrap to pay debts.

Tesla's tower wasn't buried by conspiracy. It was buried by a budget.

The missing papers

When Tesla died in a New York hotel room in 1943, broke and living alone, the US government seized his papers. That sounds sinister, and it fuels a lot of the theory. It was the middle of World War II, and Tesla had talked publicly about a "death ray".

The government asked an MIT engineer, John G. Trump, to examine the papers. His conclusion was that they were mostly speculative and philosophical, and contained nothing that could be built into a dangerous weapon. Trivia I couldn't resist: John Trump was the uncle of a future US president. The FBI has since released its files on Tesla.

The physics problem

This is where the "free energy" idea really falls apart, and where I think the myth does Tesla a disservice.

Tesla never claimed to create energy from nothing. His idea was to transmit energy, generated somewhere like a power station at Niagara, through the air and the ground. It still needed a power plant. Someone still had to pay for that.

And broadcasting power over long distances runs into a basic problem: it spreads out and gets lost. Send it in every direction, and almost all of it never reaches the device that needs it. That's why wires, boring as they are, are still the most efficient way to move electricity across a country.

A true "free energy" machine, one that produces more energy than it uses, would break the law of conservation of energy, one of the most tested rules in all of physics. Nobody has ever built one that works, and many have tried.

Tesla's dream, today

Here's the nice ending. Part of Tesla's dream did come true. The phone on your desk probably charges wirelessly. Electric toothbrushes, smartwatches and some electric cars use wireless charging. It works using electromagnetic induction, the same physics Tesla played with. It just works over centimetres, not continents.

Researchers are also experimenting with beaming power using lasers and microwaves, even from solar panels in space. It's early, it's expensive, and it's far from free. But Tesla would have loved it.

Where I land

I don't think Tesla's genius was suppressed. I think it was misunderstood, underfunded and sometimes over-promised by the man himself. He was a visionary who was often right about the future, and sometimes very wrong about the details.

And honestly, the real Tesla, a brilliant immigrant engineer who changed the world, died poor and was nearly forgotten, is a much more powerful story than any secret machine.

Verdict: a real genius with a real dream. No free energy, no secret cover-up. Just physics, and a very expensive tower.

— Desly

What if the Titanic never sank?

Sun, 18 Oct 2026 19:27:24 +0200

Everyone knows the story of the Titanic. The "unsinkable" ship, the iceberg, the band playing on, not enough lifeboats, more than 1,500 people lost on a freezing April night in 1912.

There's a theory that the ship that sank wasn't the Titanic at all. It was her nearly identical older sister, the Olympic, swapped in secret and sunk on purpose so the owners could collect insurance money.

It's one of those theories that sounds ridiculous at first and then, for about ten minutes, surprisingly convincing. So let's give it those ten minutes.

Two sisters

The White Star Line built three giant sister ships in Belfast: Olympic, Titanic and later Britannic. Olympic was finished first, in 1911. Titanic followed a year later. From the outside, they looked almost exactly the same: the same black hull, the same four tall funnels, the same lines.

In September 1911, Olympic collided with a British warship, HMS Hawke. Olympic was badly damaged, and an inquiry decided Olympic was to blame. That meant, the theory says, the insurance wouldn't pay for the repairs. Repairs were expensive, and they delayed work on Titanic.

The theory

The idea was popularised in a 1998 book by Robin Gardiner. It goes like this: White Star secretly swapped the two ships. The damaged Olympic was dressed up as Titanic, sent out on the maiden voyage, and deliberately sunk to collect the insurance on a "brand-new" ship. Rescue ships were supposedly waiting nearby, but something went wrong. The real Titanic, meanwhile, sailed on for years under the name Olympic.

There's an even darker version. J.P. Morgan, the banker whose company owned White Star, cancelled his trip at the last minute. Some of the richest men in the world died on board. So, the theory goes, maybe the sinking was planned to get rid of them. That version has even less behind it.

For the switch to work, thousands of shipyard workers would have had to keep a perfect secret, forever.

Why it falls apart

The money doesn't work. Titanic was insured for about £1 million, but she cost about £1.5 million to build. Sinking her on purpose would have meant losing a huge amount of money, not making it. And White Star lost its reputation, faced lawsuits and paid out claims for years.

The sisters weren't identical. When Titanic was built, the designers made changes based on Olympic's first months at sea. The most visible one: the forward half of Titanic's A-deck promenade was enclosed with windows, to protect passengers from spray. On Olympic, it was open. The number and spacing of some portholes near the bow were also different. Photos of the wreck show Titanic's layout, not Olympic's.

The number on the propeller. In the shipyard, Olympic was hull number 400 and Titanic was 401. Explorers of the wreck have reported the number 401 stamped on one of the propeller blades.

The wreck has been scanned in detail. In 2023, a team made a full digital 3D scan of the wreck, from hundreds of thousands of images. It's the most detailed record we have of the ship, and it's Titanic.

Thousands of people would have known. Swapping two of the biggest moving objects on Earth would have needed thousands of shipyard workers, crew and officials to keep quiet for the rest of their lives. Not one credible person ever confessed.

What happened to Olympic

Olympic went on to have a long and successful career. She carried troops in World War I, was nicknamed "Old Reliable", and stayed in service until 1935, when she was retired and scrapped. Some of her fittings ended up in a hotel in England, where you can still see them today.

Why we love this story

I think the Titanic switch theory survives because the real story is so hard to accept. A ship called unsinkable sank on her first voyage, because of speed, overconfidence, an iceberg and not enough lifeboats. That's not a plot. It's just a terrible series of human decisions.

A secret swap gives the tragedy a villain and a reason. And people prefer stories with reasons. But sometimes the real lesson is simpler and harder: no ship is unsinkable, and no amount of confidence replaces a lifeboat.

Verdict: no switch. The ship at the bottom of the Atlantic is Titanic, hull number 401. The tragedy was real, and that's sad enough.

— Desly

iPhone Air, one year later

Sun, 18 Oct 2026 15:57:29 +0200

For a full year now, the iPhone Air has been my only phone. Every day, every trip, every walk, and a fair number of photos on this website. So this isn't a first-impressions review. This is what's left after the "wow, it's so thin" phase wears off.

Short version: I'm happy with it. Not blindly happy. There are things I'd change. But I'd buy it again.

The design is the whole point

Let's start with the obvious. This phone is sleek. At 5.6 mm thick and 165 grams, it doesn't feel like a brick in your pocket the way most phones do now. You forget it's there, and then you pick it up and still get that small "huh, nice" feeling, even after a year.

5.64 mm, side on · Image: Apple

It's genuinely good to carry. Jeans pocket, jacket pocket, one hand on a crowded tram. Big screen, small presence. That combination is the reason to buy this phone, and it delivers.

Tougher than it looks

This was my biggest worry. A phone this thin feels like it should snap if you look at it wrong. I'll be honest: I don't use a case. And it has fallen. More than once. Onto real floors.

It's still fine. No bend, no cracked glass, nothing that would make me nervous. The titanium frame and the Ceramic Shield glass on the front and back are doing their job. I'm not recommending you drop-test your phone, but if durability is the thing stopping you, after a year of real life I can tell you it's sturdier than it looks.

It looks fragile. It isn't. That's the best surprise of the year.

Battery: one full day, and that's it

The battery gets me through one full day. Morning to night, with photos, maps, messages, some video, I go to bed with something left. But it's one day, not two. If you're used to phones that last into the next afternoon, this isn't that.

On long travel days, heavy navigation or a lot of 4K video, I keep an eye on the percentage. Apple sells a MagSafe battery made for this phone, which takes video playback from 27 to 40 hours. That says a lot about where the trade-off is. You're carrying less phone, so you're carrying less battery.

Camera

There's one camera on the back: a 48MP main sensor with a 2x "optical-quality" crop for portraits. For everyday photos it's excellent. Sharp, natural colours, great in daylight, solid at night. Some of the photos in my gallery were shot on it.

What you don't get is an ultra-wide or a real zoom lens. As someone who takes photography seriously, I notice that. No wide landscapes from close up, no macro, no 5x shots of something far away. For most people it won't matter. For me, it's the one thing that occasionally makes me reach for another camera.

Performance and storage

The A19 Pro chip is the same family as the Pro models, and after a year it still feels fast. Editing photos, switching between apps, nothing stutters. I went with the 512 GB version and I'm glad I did. With photos and 4K video, I've never had to think about storage. If you shoot a lot, don't go for the smallest option.

The good and the not-so-good

Here's the honest list, including the things that bug me and that you should know before buying:

What I like

Sleek, light and genuinely easy to carry
Surprisingly sturdy, even after several falls without a case
Gorgeous 6.5-inch 120Hz display, bright outdoors
Fast A19 Pro chip that still feels new after a year
Excellent main camera for everyday photos
512 GB means I never think about storage

What I don't

Battery lasts one day, with little margin on heavy days
Only one rear camera: no ultra-wide, no macro, no real zoom
Single speaker, so sound is fine but not rich
eSIM only. Great once set up, annoying when you travel and want a local SIM card
USB-C at USB 2 speed makes big video transfers slow
You pay Pro-level money for a phone with fewer features than the Pro

Technical specifications

Storage	256 GB, 512 GB (mine), 1 TB
Display	6.5" Super Retina XDR OLED, 2736 × 1260 at 460 ppi, ProMotion up to 120Hz, Always-On, up to 3000 nits outdoors
Chip	A19 Pro: 6-core CPU, 5-core GPU with Neural Accelerators, 16-core Neural Engine
Rear camera	48MP Fusion Main (26 mm, ƒ/1.6, sensor-shift OIS), 12MP 2x Telephoto (optical quality), digital zoom up to 10x
Video	4K Dolby Vision up to 60 fps, Action mode, slo-mo up to 240 fps
Front camera	18MP Center Stage, ƒ/1.9, 4K Dolby Vision video
Battery	Up to 27 hours video playback (40 hours with iPhone Air MagSafe Battery)
Charging	USB-C (USB 2), 50% in about 30 min with 20W+, MagSafe and Qi2 up to 20W
Build	Titanium frame, Ceramic Shield 2 front, Ceramic Shield back, IP68 (6 m for 30 min)
Size & weight	156.2 × 74.7 × 5.64 mm, 165 g
Connectivity	5G (Apple C1X modem), Wi-Fi 7, Bluetooth 6, Thread, NFC, second-gen Ultra Wideband
SIM	Dual eSIM only, no physical SIM
Controls	Action button, Camera Control, Face ID
Colours	Space Black, Cloud White, Light Gold, Sky Blue

Specifications from Apple's official tech specs page. Battery figures are Apple's own test results; real-world use varies.

Who should buy it

If you want a big screen in a phone that's a pleasure to carry, and you mostly take everyday photos, the iPhone Air is a great choice. If you need two-day battery life, an ultra-wide or zoom lens, or you swap SIM cards a lot while travelling, look at the Pro or the regular iPhone instead.

8/10

Would I buy it again? Yes.

A year in, the design still makes me smile, it's survived my clumsiness, and it gets through my day. Just know what you're giving up for that thinness.

— Desly

Samsung HW-Q995GF, six months later

Sun, 18 Oct 2026 15:57:29 +0200

Six months ago I set up the Samsung HW-Q995GF, and since then it's been running almost every day. Movies, gaming, music, and even while I'm editing. If you only read one line of this review, make it this one: the sound is awesome. Immersive in a way I honestly didn't expect from a soundbar.

It's not perfect, but I'll get to the annoyances. This is the best sound setup I've owned.

My setup

For context, this isn't a huge living room. My room is roughly 12 by 12 feet, about 3.7 by 3.7 metres, and the soundbar sits with my Samsung Odyssey 37-inch 4K screen. The box comes with four pieces: the main bar, a wireless subwoofer, and two wireless rear speakers. Together that's 11.1.4 channels and 23 speakers in the main bar alone. In a room this size, that's a lot of sound, in the best way.

The sound: immersive is the right word

The thing that makes this system special is the Dolby Atmos height effects. Rain sounds like it's falling from above you. A helicopter actually moves over your head. Both the main bar and the rear speakers have up-firing drivers that bounce sound off the ceiling, and in my room it works properly. It doesn't sound like a speaker in front of you. It sounds like the room itself.

The bass is deep and controlled. The subwoofer has two 8-inch drivers, and it hits hard in action scenes without turning everything into boom. Dialogue stays clear even in loud scenes, which matters more than people think. No more turning the volume up for quiet talking and then down again for explosions.

It doesn't sound like a speaker in front of you. It sounds like the room itself.

Gaming, music and editing

For gaming, the rear speakers change everything. Footsteps behind you actually come from behind you. Samsung's Game Pro mode tunes the sound automatically when it detects a console.

For music I mostly use AirPlay straight from my iPhone. It just works, no pairing dance. Spotify Connect and Tidal Connect are built in too.

And since I edit on the same setup, I appreciate that it plays back high-resolution audio cleanly. It's not a studio monitor and I wouldn't do a final mix on it, but for reviewing edits it's a huge step up from monitor speakers.

The wireless rears

I love that the rear speakers are wireless. No cables running across the floor to the back of the room. One small catch: "wireless" means no audio cable. They still need a power socket each, so plan where they'll go.

In six months, a satellite speaker disconnected once. It reconnected and hasn't happened again since, but it's worth mentioning in an honest review.

The downsides

This thing is heavy. The full set weighs about 24 kg, and the main bar alone is 7.3 kg and over 1.2 metres wide. I've owned other soundbars that I could pick up and move to another room in a minute. This is not that. Once it's set up, it stays where it is.

What I like

Awesome, genuinely immersive sound
Dolby Atmos height effects that actually work
Deep, controlled bass from the dual 8-inch subwoofer
Clear dialogue, even in loud scenes
Wireless rear speakers make real surround easy
AirPlay 2, Spotify Connect and Tidal Connect built in
Great for movies, gaming, music and editing alike

What I don't

Heavy and not portable, about 24 kg for the full set
A satellite speaker disconnected once in six months
The rears still need their own power sockets
HDMI pass-through tops out at 4K 60Hz, so connect 120Hz consoles to the screen directly
Bluetooth only supports the basic SBC codec. Use AirPlay or Wi-Fi for music instead
Premium price. You're paying for the whole system

Technical specifications

System	11.1.4 channels: main bar, wireless subwoofer, wireless 4.0.2 rear speakers
Speakers	23 in the main bar (front, side, up-firing and centre)
Subwoofer	Wireless, dual 8-inch drivers
Rear speakers	Wireless, with up-firing drivers
Audio formats	Dolby Atmos (incl. wireless), Dolby TrueHD, Dolby Digital, DTS:X, DTS 5.1, multichannel LPCM, Hi-Res 24-bit
Sound features	SpaceFit Sound Pro, Adaptive Sound, Active Voice Amplifier Pro, Game Pro mode, Night mode, Q-Symphony
HDMI	2 in, 1 out, ARC and eARC, 4K 60Hz pass-through with HDR10+
Other inputs	Optical
Wireless	Wi-Fi (2.4 / 5 GHz), Bluetooth 5.2
Streaming	AirPlay 2, Spotify Connect, Tidal Connect, Google Cast
Voice	Alexa built in; works with Google Assistant devices
Main bar	1232 × 70.8 × 138 mm, 7.3 kg
Subwoofer size	249 × 251.8 × 249 mm, 8.3 kg
Rear speakers size	129.5 × 201.3 × 140.4 mm, 3.4 kg each
Full set	About 23.8 kg

Specifications from Samsung's official product page. Features can vary by region and firmware.

Who should buy it

If you want real cinema sound at home without running cables for a full speaker system, and you have the space for it, this is it. It's fantastic for movies, gaming and music. If you need something light that you'll move around, or you're on a tighter budget, a smaller soundbar will make more sense.

9/10

Highly recommended.

Six months in, it's still the best sound I've had at home. Heavy, yes. One hiccup, yes. But every movie night reminds me why I bought it.

View the HW-Q995GF on Samsung.com ↗

— Desly

Samsung Odyssey G7 37", six months later

Sun, 18 Oct 2026 15:57:29 +0200

For the past six months, the Samsung Odyssey G7 37-inch has been the centre of my desk. It's where I play on my PS5 Pro, edit my photos, watch movies, and do my actual work. One screen doing four jobs, and doing them all well. That's the short version.

The longer version has a couple of "I wish Samsung had…" moments, mostly about ports. But first, the good stuff, because there's a lot of it.

The screen is the star

37 inches is a sweet spot I didn't know I wanted. It's big enough to feel immersive, but not so big that I'm turning my head to read a menu. The 1000R curve wraps the edges slightly towards you, so at this size everything stays comfortably in view.

And it's 4K. At 37 inches, text is crisp, photos are sharp right down to the fine detail, and you can fit a lot on screen when working. After using it for a while, going back to a lower-resolution screen feels blurry.

One screen, four jobs: gaming, editing, movies and work. It handles all of them.

Gaming with the PS5 Pro

Gaming is where it really shines. Motion looks smooth, and with HDR turned on, games look properly vivid. The panel goes up to 165Hz, which you'll see on a PC. The PS5 Pro itself tops out at 120Hz, so that's what you get from the console, and it still looks great. Both HDMI ports are HDMI 2.1, which is what you need for 4K at high refresh rates from a modern console.

Photo editing and colour

As someone who edits a lot of photos, colour matters to me, and I'm happy with it. Colours look rich and accurate, and HDR content has real punch. Samsung quotes 90% DCI-P3 and 99% sRGB coverage, and in practice my edits look the way I expect when I check them on other screens.

One small thing for photographers: on a curved screen, perfectly straight lines can look slightly bent at the edges. It's not a problem for normal editing, but for very precise architectural work, I double-check on a flat screen.

Movies and work

Movies look fantastic on it, especially in a dark room where the VA panel's deep contrast helps. For work, the sheer amount of space at 4K means two windows side by side without squinting. I switch between my PC and my Mac, and having two HDMI ports plus DisplayPort makes that easy enough.

What annoys me: ports and eARC

This is my main complaint. The ports are limited. You get two HDMI 2.1, one DisplayPort 1.4, a small USB hub and a headphone jack. That's it. With a PC, a Mac and a PS5 Pro all wanting a connection, I run out of inputs quickly.

There's also no eARC, and the monitor has no built-in speakers at all. On a TV, eARC lets you send audio from everything plugged into the screen straight to a soundbar with one cable. Here, getting sound from all my devices to my Samsung soundbar takes more planning than it should. If you're building a setup like mine, think about your audio routing before you buy.

What I like

Razor-sharp 4K at a perfect 37-inch size
Comfortable 1000R curve that keeps everything in view
Smooth 165Hz on PC, 120Hz on PS5 Pro
Vivid HDR for games and movies
Rich, accurate colours for photo editing
HDMI 2.1 for modern consoles
Height, tilt and swivel adjustable stand

What I don't

Limited ports for a multi-device setup
No eARC, and no built-in speakers
No USB-C, so a Mac or laptop needs an HDMI or DisplayPort cable or adapter
350 nits typical brightness, so HDR doesn't hit as hard as OLED or mini-LED
VA panels can show slight smearing in very dark, fast scenes
Wide footprint, over 80 cm across, so measure your desk

Technical specifications

Model	Odyssey G7 G75F, 37" (LS37FG750EW)
Panel	37" curved VA, 1000R
Resolution	4K UHD, 3840 × 2160, 16:9
Refresh & response	Up to 165Hz, 1ms (GtG)
Brightness & contrast	350 nits typical, 3000:1 static contrast
HDR	VESA DisplayHDR 600, HDR10+ Gaming
Colour	1.07 billion colours, 90% DCI-P3, 99% sRGB
Adaptive sync	AMD FreeSync Premium Pro
Ports	2× HDMI 2.1, 1× DisplayPort 1.4, USB hub (1 upstream, 2× USB-A 3.2), headphone out
USB-C	No
Speakers	None
Stand	Height 120 mm, tilt −5° to 20°, swivel ±20°, VESA 100 × 100
Size & weight	81.6 × 67.4 × 30.4 cm with stand, 11.2 kg
Extras	Picture-in-Picture, Auto Source Switch+, Black Equalizer, Eye Saver Mode, Flicker Free, CoreSync lighting

Specifications from Samsung's official product page. Response time is measured in Extreme mode.

Who should buy it

If you want one big, sharp screen for gaming, editing, movies and work, and you're mostly connecting one or two devices, the Odyssey G7 37" is an easy recommendation. If you have a lot of devices, need USB-C for a laptop, or want simple one-cable audio to a soundbar, check the ports carefully first.

7/10

Would I buy it again? Yes, with a few reservations.

Six months in, the picture still impresses me every day. More ports and eARC would have made it an 8 or higher.

View the Odyssey G7 37" on Samsung.com ↗

— Desly

Insta360 Link 2, six months later

Sun, 18 Oct 2026 15:57:29 +0200

For about six months now, the Insta360 Link 2 has been sitting on top of my screen, plugged into my Mac. I use it every working day for meetings, and for recording videos. I bought it expecting a better picture than a normal webcam. What I didn't expect was how much the little gimbal and the smart features would change how I work on camera.

Short version: it's the best webcam I've used, and I don't say that lightly.

Picture quality

This is the first thing people notice. Colleagues have literally asked me what camera I'm using. The image is sharp, it records in 4K, and with HDR switched on, a bright window behind me doesn't blow everything out. Skin tones look natural, not orange or washed out the way cheaper webcams make you look.

Low light is where it really separates itself. Evening calls, a dim room, a single lamp on, and it still looks clean. That's thanks to a bigger 1/2-inch sensor and a bright f/1.8 lens, which is far more than most webcams have.

Colleagues have literally asked me what camera I'm using.

AI tracking and gestures

The camera sits on a small 2-axis gimbal, so it can physically turn and tilt to follow you. When I stand up, lean back or walk to grab something during a recording, it keeps me in frame. For recording videos this is brilliant, because I don't have to stay glued to one spot.

The gestures took me a day to get used to, and now I use them without thinking. Raise your hand and it starts or stops tracking, and you can zoom with a gesture too. It feels a bit like magic the first few times, and then it just becomes normal.

Desk view and whiteboard mode

These two modes are underrated. Desk view tilts the camera down so you can show something on your desk: a sketch, a gadget, notes on paper. Whiteboard mode finds a whiteboard and straightens and enhances it so people can actually read it. For explaining things in meetings, both are genuinely useful, not gimmicks.

The microphones

I honestly expected to keep using a separate microphone. I don't. The built-in mics sound clear, and the AI noise cancelling does a good job of removing background noise. There are three modes: Voice Focus, Voice Suppression and Music Balance. For meetings, Voice Focus is my default. People hear me, not the street outside.

On the Mac

It's plug and play over USB-C with my Mac. FaceTime, Zoom, Teams, everything recognised it immediately. The Insta360 Link Controller app is where you fine-tune things like tracking, modes and noise cancelling, and once it's set up, you rarely need to open it again.

The two things I'd change

What I like

Sharp 4K picture with HDR and natural colours
Excellent in low light, thanks to a large 1/2" sensor and an f/1.8 lens
AI tracking on a real gimbal that keeps you in frame
Gesture control that quickly becomes second nature
Desk view and whiteboard mode are genuinely useful
Clear built-in microphones with AI noise cancelling
Plug and play on Mac

What I don't

It's expensive for a webcam, several times the price of a basic one
4K tops out at 30 fps. For smooth 60 fps you have to drop to 1080p

Neither is a deal-breaker. The price is easier to accept once you realise you might not need a separate microphone. And for meetings and most recordings, 4K at 30 fps looks great. It's only for fast motion that I'd want 60.

Technical specifications

Sensor	1/2" sensor
Lens	f/1.8, 26 mm equivalent, 79.5° diagonal field of view (67° horizontal)
Video	4K at 30 fps, 1080p at 60 fps, HDR, landscape or portrait
Zoom & focus	Up to 4x digital zoom, autofocus from 10 cm
Gimbal	2-axis (pan and tilt) with AI tracking
Smart modes	Gesture control, desk view, whiteboard mode, portrait mode, privacy mode
Audio	Built-in microphones with AI noise cancelling (Voice Focus, Voice Suppression, Music Balance)
Video formats	H.264 and MJPEG, 8-bit
Connection	USB-C
Weight	About 101.5 g (camera), 166.5 g with magnetic mount
Works with	Mac and Windows; Zoom, Teams, Google Meet, OBS and more
Software	Insta360 Link Controller

Specifications from Insta360's support documentation and published reviews. Not to be confused with the Link 2 Pro, which has a larger 1/1.3" sensor.

Who should buy it

If you spend a lot of your day on video calls, or you record yourself for videos and tutorials, the Link 2 is worth every cent. You look better, you sound better, and you're free to move. If you only join the odd call each week, a basic webcam will do the job for much less.

9/10

Highly recommended.

Six months in, it's the one piece of my desk setup that everyone on the other end notices. Pricey, but it earns it.

View the Insta360 Link 2 on Amazon ↗

— Desly

AI & MLOps, from the ground up

Sun, 18 Oct 2026 15:57:29 +0200

Everyone is talking about AI. Every app has an AI button now, every company has an AI strategy, and every second post I see is someone explaining how AI will change everything. At some point I realised I'd been reading about it far more than I understood it.

So I decided to stop just reading and actually learn it. Properly, from the ground up. The illustration above shows the loop I'm trying to understand: data, training, tracking, serving, monitoring, and then retraining again.

Why MLOps and not just "AI"

Training a model in a notebook is the fun, exciting part. You load some data, run a few lines of code, and suddenly the computer is predicting things. It feels like magic.

But a model sitting in a notebook on my laptop doesn't help anyone. The hard part, and the part I find genuinely interesting, is everything after that. How do you turn it into something people can actually use? How do you know it still works next month, when the data has changed? How do you update it without breaking things? That's MLOps: the engineering that takes machine learning from an experiment to something reliable.

Building a model is the beginning. Keeping it working is the real job.

My plan

I wrote myself a roadmap. Twenty-four weeks, about 8 to 10 hours a week, starting with Python and data foundations and ending with a model that is deployed, monitored, and can be retrained safely.

The idea I like most is to build one project the whole way through instead of lots of small disconnected exercises. It starts as a simple notebook and grows step by step: into a tested Python package, then a tracked and reproducible training pipeline, then an API, then a container, then something running in the cloud with dashboards watching it. Every new skill gets added to the same system, so I can see why it matters.

My weeks have a rhythm, too: a couple of hours learning concepts, most of the time building, an hour or two on testing and automation, and one hour at the end to look back and write down what I learned. That last hour is the one I'm most tempted to skip, and probably the most important.

Where I actually am

Honestly? Right at the start. Phase 0. I've set up the project, the tools and the structure. My first real test checks that a function calculating an average still gives the right answer with negative numbers. Not exactly artificial intelligence.

But that's kind of the point. My first checkpoint is that a single command can check my code style and run all my tests, and pass. It's small and unglamorous, and it's the foundation everything else will stand on. I'd rather build that properly now than have a clever model on top of a mess later.

The tools I'll be learning

For anyone curious, the plan is one tool per problem to start with: Python with pandas and scikit-learn for the machine learning, pytest for testing, MLflow to track experiments, DVC to version data, FastAPI to serve predictions, Docker to package everything, GitHub Actions to automate it, and Prometheus, Grafana and Evidently to monitor it. My roadmap has a line I keep coming back to: the exact tools matter less than understanding reproducibility, automation, observability and safe change.

What I'd tell someone starting today

Start smaller than you think. Pick a boring, simple problem with public data. Get the basics working end to end before chasing the fancy stuff. And write down what you learn every week, because future you will forget.

I'll keep writing here as I go. The wins, the bugs, and the moments where I have no idea what I'm doing. Which, I suspect, will be most of them.

Status: Phase 0 complete-ish. 23 weeks to go.

— Desly

The camera is software now

Sun, 18 Oct 2026 15:57:29 +0200

Look at the sky in the photo above. Deep orange clouds, detail in the bright parts, and the water still visible underneath. I took it on a phone. A few years ago, a shot like that would have needed a proper camera, a tripod and some patience. Or it would have come out as a bright white sky over a black silhouette.

I own a DSLR. I learned photography on one. And I'll be honest: these days, my phone wins more often than I'd like to admit. Not because its lens or sensor is better. It isn't. It wins because of software.

What's actually happening when you press the button

When you take a photo on a modern phone, it usually isn't taking one photo. It's often capturing several frames, some of them before you even press the shutter, at different exposures. Then the processor lines them up and merges them, taking the shadow detail from one frame, the highlight detail from another, and reducing noise by combining them all.

This is called computational photography. Google made it famous on its Pixel phones with HDR+ and later Night Sight, which could produce surprisingly bright, clean photos in near darkness. Apple has Smart HDR, Deep Fusion and Night mode. Samsung has its own versions. The names differ, but the idea is the same: use computing power to make up for a tiny lens and a small sensor.

The lens collects the light. The software decides what the photo looks like.

The things software can do that glass can't

Portrait mode is a good example. A big camera gets that soft, blurry background from physics: a large sensor and a wide aperture. A phone fakes it. It works out how far away everything is and blurs the background artificially. Early versions looked obviously fake, with blurry hair edges and ears. Now it's often good enough that most people can't tell.

Night mode is even more impressive. Holding a phone still for a few seconds while it captures and stacks frames gives you a photo of a street at night that genuinely looks better than what your eyes saw.

Where it gets uncomfortable

Here's the part that makes me think. In 2023, a Reddit user tested Samsung's famous "Space Zoom" moon photos. He photographed a deliberately blurred image of the Moon on a screen, and the phone added crisp detail that simply wasn't there. Samsung explained that it used AI to enhance the Moon. Many people asked a fair question: is that still a photo, or is it a picture of what the phone thinks the Moon should look like?

Now phones can remove people from the background, swap faces between frames so everyone is smiling, or generate parts of an image that were never captured. All useful. All a little strange.

So what is a "good camera" now?

I think it's becoming two different things. If you want a quick, great-looking photo of a moment, a phone is now the best camera for most people, most of the time. If you want control, a real optical zoom, shallow depth of field from physics, or a photo that is exactly what was in front of you, a dedicated camera still matters.

I use both. The phone for life, the camera when I want to slow down. And I've learned to see the software as another tool, like a lens or a filter. Just one that makes a lot of decisions for you, quickly and quietly.

My take: the best camera is still the one you have with you. It just happens to be a computer now.

— Desly

AI in everyday apps

Sun, 18 Oct 2026 15:57:29 +0200

Somewhere in the last couple of years, every app on my phone got an AI button. My keyboard can rewrite my messages. My photos app can erase people. My notifications can summarise themselves. My search can explain things instead of just finding them.

Some is genuinely useful. Some is a flashy icon on a feature nobody wanted. After using them all for a while, here's how I'd sort them.

The ones I actually use

Removing things from photos. Google's Magic Eraser, Apple's Clean Up, Samsung's object eraser. Tap a stranger in the background or a bin next to a building, and it's gone. As a photographer I was sceptical, but for casual photos it saves a lot of shots. I'd never use it to pretend a scene was different from reality, but a random tourist's elbow? Gone.

Transcription and live captions. Voice memos and meeting recordings turned into searchable text, on the device. This is one of those quietly life-changing features. I record a thought while walking and find it later by searching a word.

Translation. Pointing a camera at a menu or a sign and reading it in my own language still feels like science fiction. Having lived and travelled abroad, this one has saved me more than once.

Search that understands what I'm looking at. Google's Circle to Search, and similar visual search features, let you circle something on screen and ask about it. Useful when you see a gadget in a video and want to know what it is.

The best AI features don't feel like AI. They just feel like the app got smarter.

The ones I've switched off

Notification summaries, for important things. The idea is great: a stack of messages squeezed into one line. In practice, summaries sometimes miss the point or get it wrong, and that's not okay when it's news or something that matters. Apple even paused summaries for news apps in early 2025 after they produced misleading headlines. I keep them for group chats and turn them off for anything serious.

Rewriting my messages. It's impressive that my keyboard can make a text sound more "professional" or "friendly". But when it does, it stops sounding like me. For a work email, maybe. For a message to a friend? No thanks.

Chatbots squeezed into apps that didn't need them. I don't need to "chat" with my shopping app. I need it to find the thing and show me the price.

How I decide

I've ended up with a simple test. A good AI feature does one of three things: it saves me real time, it does something I genuinely couldn't do before, or it removes a small annoyance without me thinking about it. A bad one makes me check its work, changes my voice, or adds a step to something that was already easy.

And one more rule: if it's going to read my messages, photos or voice, I want to know where that happens. A lot of new features run on the device itself, which I much prefer. When something gets sent to a server, I'd like to be asked.

Where this is going

I think the hype will settle down, the sparkle icons will slowly disappear, and the useful features will just become normal parts of every app. Nobody calls autocorrect "AI" anymore. In a few years, that's probably how we'll talk about erasing objects from photos or translating a menu.

My rule: use the AI that gives you time back. Switch off the AI that asks for your attention.

— Desly

What if we're living in a simulation?

Sun, 18 Oct 2026 15:57:29 +0200

I think everyone has had this moment. You're lying in bed, staring at the ceiling, and a strange thought sneaks in: what if none of this is real? Not in a dramatic movie way. Just quietly. What if it's all running on something?

It sounds like the plot of The Matrix, and partly it is. But the modern version of this idea didn't come from Hollywood. It came from a philosopher.

Where it comes from

In 2003, the Oxford philosopher Nick Bostrom published a paper with a very calm title: "Are You Living in a Computer Simulation?" His argument goes roughly like this. If a civilisation ever gets advanced enough to run realistic simulations of its ancestors, and if it actually wants to, it could run millions of them. In that case, simulated minds would massively outnumber real ones. So statistically, you'd probably be one of the simulated ones.

He didn't say we definitely are. He said one of three things must be true: civilisations almost never get that advanced, or they get there and don't bother, or we're very likely in a simulation. Pick one. None of them is especially comforting.

The scary part isn't the idea. It's that it's surprisingly hard to argue against.

Why people take it seriously

It got a big boost in 2016, when Elon Musk said on stage that the chance we're living in "base reality" is one in billions. Suddenly everyone was talking about it.

And when you look at the world through that lens, some things do feel a bit suspicious. The universe runs on maths. Physics seems to have a smallest meaningful scale, below which space and time stop making sense. Light has a hard speed limit, almost like a processing limit. Physicists have even proposed experiments to look for tiny "grid" patterns in high-energy cosmic rays, the kind of fingerprint a simulation might leave.

What the evidence actually says

Here's the honest bit: there's no evidence that we're in a simulation. None of those proposed tests has found anything. And the bigger problem is that the theory is almost impossible to test. Any strange result could be explained as "that's just how the simulation works", and any normal result as "the simulation is very good". When an idea can't be proven wrong, scientists file it under philosophy, not physics.

Also, simulating an entire universe down to every atom would need a computer bigger than the universe itself. Believers say the simulation could cut corners and only render what someone is looking at, like a video game. Which is a clever answer, and also exactly the kind of answer that can't be checked.

Where I land

I don't believe it. But I can't fully dismiss it either, and I think that's okay. For me the idea is less about computers and more about humility. We're tiny, we're new here, and there's a lot we don't understand.

And if it is a simulation? The coffee still tastes good, the sunsets are still beautiful, and the people I love are still worth loving. Real enough for me.

Verdict: fascinating, unprovable, probably not. But fun to think about at 2 a.m.

— Desly

What if the Moon landing was staged?

Sun, 18 Oct 2026 15:57:29 +0200

Look at the photo at the top. Buzz Aldrin, the American flag, the lunar module on the left, and a pitch-black sky. It's one of the most famous photographs ever taken. And for some people, it's also the evidence that the whole thing was faked. The flag looks like it's waving. There are no stars. So which is it?

The Moon landing conspiracy is probably the most famous one of all. The claim is that in 1969, NASA didn't actually land on the Moon, and the whole thing was filmed in a studio to beat the Soviet Union in the space race. It really took off in 1976, when Bill Kaysing published a book called "We Never Went to the Moon". Since then it's never quite gone away.

The famous "proof"

If you've ever gone down this rabbit hole, you'll know the classics:

The flag is waving, but there's no wind on the Moon. It does look like it's waving. But the flag had a horizontal rod along the top to hold it out, and it moved because the astronauts were twisting the pole into the ground. With no air to slow it down, it kept swinging longer than it would on Earth. In still frames it stays perfectly still.

There are no stars in the sky. True, and every photographer knows why. The lunar surface in sunlight is extremely bright. If you expose for a bright subject, faint stars disappear. Try photographing a lit-up building at night and see how many stars you get.

The shadows aren't parallel, so there must be studio lights. On uneven ground, shadows from a single light source fall at different angles. Add perspective from a wide lens and they look even stranger. I see this in my own photos all the time.

The radiation in the Van Allen belts would have killed them. The belts are real and dangerous if you stay in them. Apollo crews passed through fairly quickly, on a path that avoided the worst parts. The total radiation dose they received was low, roughly in the range of a few medical scans.

Faking the Moon landing in 1969 would arguably have been harder than actually going.

Why I'm convinced they went

This is the part that settled it for me. Apollo astronauts left retroreflectors on the Moon, basically special mirrors. Observatories on Earth still fire lasers at them today and time how long the light takes to bounce back. That's how we know the Moon is slowly drifting away from us, about 3.8 cm a year.

On top of that, the Apollo missions brought back around 382 kg of Moon rock, which has been studied by scientists all over the world. NASA's Lunar Reconnaissance Orbiter has photographed the landing sites from orbit, showing the hardware and even the astronauts' tracks. And the Soviet Union, who had every reason to expose a fake, tracked the missions and never claimed it was staged.

Thousands of people worked on Apollo. Keeping that many people quiet for more than fifty years would be its own miracle.

Why the theory survives anyway

I get why people doubt it. It's genuinely hard to believe. The computers were weaker than the phone in my pocket, and then we just stopped going for decades. That gap makes it feel unreal. Mistrust of governments doesn't help either.

But "it sounds unbelievable" isn't the same as "it didn't happen". Sometimes humans really do pull off something incredible.

Verdict: they went. The mirrors are still up there to prove it.

— Desly

What if Atlantis was real?

Sun, 18 Oct 2026 15:57:29 +0200

Every time I look down at clear, shallow water, like in the photo above, part of my brain goes looking for ruins. Square shapes. Old walls. A road under the sand. I think that's the Atlantis effect. Once you've heard the story, the sea never looks quite the same.

Where the story comes from

Here's something many people don't know: almost everything we know about Atlantis comes from one person. The Greek philosopher Plato described it around 360 BC in two of his dialogues, Timaeus and Critias.

In his telling, Atlantis was a powerful island empire beyond the "Pillars of Hercules", which is usually taken to mean the Strait of Gibraltar. It was rich, advanced and proud, and it went to war against Athens. Then, as punishment from the gods, it sank into the sea "in a single day and night of misfortune". Plato said all of this happened about 9,000 years before his time.

Almost everything we know about Atlantis comes from one man, writing a story with a moral.

The theories

People have been trying to find it ever since. A few of the favourites:

Santorini. Around 1600 BC, a massive volcanic eruption destroyed the island of Thera, now Santorini, and severely damaged the Minoan civilisation. It's an advanced island culture, a sudden disaster, and the sea is involved. It's the most popular real-world candidate, even though the dates and location don't match Plato's account exactly.

The Bimini Road. Off the Bahamas there's an underwater line of flat stones that looks a lot like a paved road. Geologists say it's natural beachrock that cracked into blocks. It still looks amazing.

The Eye of the Sahara. The Richat Structure in Mauritania is a giant set of rings visible from space. Some people say its circles match Plato's description of Atlantis. Geologists say it's an eroded dome of rock. And it's in the middle of a desert, which is a strange place for a city that sank into the sea.

What the evidence actually says

No archaeological evidence for Atlantis has ever been found. No ruins, no artefacts, no writing from the time mentioning it. Most historians think Plato made it up as a lesson: a story about a proud, powerful nation that gets too big for itself and is destroyed. He used stories like this often to make philosophical points.

The modern Atlantis craze mostly started in 1882, when an American writer called Ignatius Donnelly published a bestselling book claiming it was real and the source of all ancient civilisations. That book did more for Atlantis than Plato ever did.

Why I still love it

I don't think Atlantis was a real place. But I understand why the story has survived for more than 2,000 years. It's about something we're all a little afraid of: that everything we build could disappear, and the sea would just carry on.

And who knows. The ocean is mostly unexplored. I'll keep looking down at clear water anyway.

Verdict: a brilliant story, probably not a real place. Santorini is the best "maybe".

— Desly

What if the Mandela Effect is real?

Sun, 18 Oct 2026 15:57:29 +0200

Quick test. How do you spell the name of the cartoon bear family? Berenstein Bears? It's Berenstain. With an "a".

In Star Wars, Darth Vader says "Luke, I am your father", right? He doesn't. The actual line is "No, I am your father." And the Monopoly man has a monocle. Except he doesn't, and he never did.

If you got any of those wrong, you're in very good company. This is the Mandela Effect, and the first time I fell into it, I genuinely felt a bit dizzy.

Where the name comes from

The term was coined around 2009 by Fiona Broome, a paranormal researcher. She discovered that she, and lots of other people, clearly remembered Nelson Mandela dying in prison in the 1980s. Some even remembered news coverage of his funeral. In reality, Mandela was released in 1990, became President of South Africa, and died in 2013.

So many people shared the same false memory that it got a name.

The strangest part isn't being wrong. It's being wrong in exactly the same way as millions of strangers.

The wild explanation

Here's where the rabbit hole gets deep. Some people believe the Mandela Effect is evidence of parallel universes. The theory goes that we've slipped between slightly different realities, and in our original one, it really was "Berenstein" and the Monopoly man really did have a monocle. Some people blame the particle collider at CERN for "shifting" timelines.

I'll be honest, it's a fun idea. It would explain everything. It's also the kind of explanation that explains everything without needing any evidence.

What science says

The less dramatic, but honestly more interesting, answer is that human memory doesn't work like a video recording. Every time you remember something, your brain rebuilds it, filling in gaps with what seems likely. And "likely" is shaped by patterns. "-stein" is a far more common name ending than "-stain". Rich old cartoon tycoons often wear monocles. "Luke, I am your father" is how everyone quotes the line, so that's what gets reinforced.

In 2022, psychologists Deepasri Prasad and Wilma Bainbridge published a study showing that people consistently got the same details wrong in famous logos and characters, like Pikachu's tail (no black tip) and the Fruit of the Loom logo (no cornucopia). The errors weren't random. Many people made the same mistakes, even about images they'd seen thousands of times.

Where I land

I don't think we're sliding between universes. I think our brains are prediction machines that are usually right and occasionally, collectively, very wrong.

And honestly, that's a bit humbling. If I can be completely sure about a cartoon bear's name and still be wrong, what else am I sure about? Maybe that's the real lesson. Hold your memories a little more loosely.

Verdict: real effect, no parallel universes required. Your brain is just guessing, confidently.

— Desly

What if the Bermuda Triangle is cursed?

Sun, 18 Oct 2026 15:57:29 +0200

I took the photo above on a beach at dusk. A whole ship, run aground and left on the sand, black against a pink sky. Standing next to something that big, built to survive the ocean, and seeing the ocean win anyway, you understand why sailors have always told scary stories about the sea. It's beautiful, it's huge, and it doesn't care about you at all.

The Bermuda Triangle is the most famous of those stories. A rough triangle of the Atlantic between Miami, Bermuda and Puerto Rico, where ships and planes supposedly vanish without a trace.

The legend

The name was coined in 1964 by a writer called Vincent Gaddis, in a magazine article. Ten years later, Charles Berlitz published "The Bermuda Triangle", which became a huge bestseller. Explanations ranged from strange magnetic fields to alien abductions to leftover technology from, yes, Atlantis.

And there were real disappearances to point to. In 1918, the US Navy ship USS Cyclops vanished with about 300 people on board, and no wreck has ever been found. In 1945, five US Navy bombers known as Flight 19 disappeared during a training flight, and a rescue plane sent to find them was lost too. Stories like that are genuinely chilling.

The ocean doesn't need a curse to be dangerous. That's the scary part.

What the numbers say

Here's what surprised me when I looked into it. The Bermuda Triangle isn't statistically more dangerous than other busy stretches of ocean. The US Coast Guard doesn't recognise it as an especially dangerous area. Lloyd's of London, the insurance market, which knows a thing or two about ships sinking, doesn't charge higher rates to sail through it.

It's one of the busiest shipping and flight areas in the world. More traffic means more accidents, simply by numbers. Add the Gulf Stream, a fast, powerful current that can scatter wreckage quickly, sudden tropical storms, and some very deep water, and you have plenty of reasons for things to go wrong without anything supernatural.

In 1975, a librarian called Larry Kusche went back to the original records of the famous cases. He found that many of the "mysteries" had been exaggerated, some ships had sunk in storms that the legends didn't mention, and a few hadn't even been in the Triangle at all.

Why the legend won't die

Because it's a great story. A mysterious triangle on the map, a few real tragedies, and the human brain's love of patterns. Once something has a scary name, every accident nearby becomes "another one".

And there's something comforting about a curse, in a strange way. A curse means there's a reason. The truth, that the ocean is simply powerful and sometimes things go wrong, is harder to sit with.

Verdict: not cursed. Just a busy, stormy, beautiful, dangerous piece of sea. Like a lot of the sea.

— Desly

Munich, again and again

Sun, 18 Oct 2026 15:57:29 +0200

Munich is a city that's very close to my heart. I didn't plan for that. I went there for work, and then I kept going back for work, and somewhere between all those trips it stopped feeling like a business destination and started feeling like a place that knew me.

The photo at the top is from one of those visits. That's St. Paul's Church on the left, and on the right, tents and rides spread out below the rooftops. The whole city glowing in the evening light. I remember standing there thinking it looked like a toy model of itself.

A new piece of history every time

The funny thing about visiting a city many times is that you'd expect it to get boring. Munich never did. Every trip I found a new place, a new corner with a story behind it. A church I'd somehow walked past ten times without going in. A square with a history I'd never heard of. A building that had survived things I could barely imagine.

It's a city that rewards you for paying attention. You think you've seen it, and then it shows you something else.

The beer

I have to say it. The beer is on another level. I'm not an expert and I won't pretend to be. But sitting in a beer garden on a long summer evening, with a proper Maß in front of you and people you like around the table, is one of those simple things that's very hard to beat. I wrote about one of those evenings in Crackling in Munich.

Some cities you visit for work. Some cities end up working on you.

The first winter

My first winter there was really an experience. Coming from Kerala, cold is not something you understand until it actually hits you. Short days, grey skies, breath you can see, and the strange joy of walking into a warm café after being outside for too long. I learned a lot that winter, mostly about layers.

Family, even at work

What made Munich special, though, wasn't the buildings or the beer. It was the people. Even at work, everyone was considered family. Colleagues became friends, and friends became the reason I looked forward to every trip back.

When I think about Munich now, three things come to mind: friends, travel and work. All mixed together, and all good. Those are the things I carry in my heart from that city.

— Desly

Kozhikode, close to my heart

Sun, 18 Oct 2026 15:57:29 +0200

Some cities you visit. Some cities stay with you. Kozhikode is the second kind for me.

My wife and I travelled there together, and I still think about that time more than I probably should. It wasn't a big, fancy trip. We didn't tick off a list of sights. We mostly walked, ate, talked to people, and ate some more. And somehow that turned into one of my favourite memories of us.

The food

Let's be honest, half the reason anyone goes to Kozhikode is the food. The delicacies there are just alluring. You walk past a restaurant and the smell alone changes your plans for the evening.

We went to Paragon, because you have to go to Paragon. We went to Rahmath, because everyone told us to, and everyone was right. And then there was Kuttichira biryani, which is a whole different thing. The rice is small-grained and fragrant, the meat falls apart, and every plate tastes like someone's family has been perfecting it for generations. Which, honestly, they probably have.

I've eaten biryani in a lot of places since. It's good. It's just not Kozhikode.

Missing those. A lot. Some nights I seriously consider whether a flight is a reasonable price to pay for one plate.

The evenings

In the evenings we walked around Mananchira square. Nothing special happens there, and that's exactly the point. People sitting on benches, kids running around, families out for a slow walk after dinner. You just become part of the city for an hour.

And then the beach. The photo at the top was taken there, at sunset. The whole sky went orange, and the old broken pier stood out in the water like a row of dark teeth, gulls sitting on top of the posts. Someone walked slowly along the wet sand and their reflection walked with them. Everyone in the city seems to come out at that hour. Nobody is in a hurry.

The people

What I remember most, though, is the people. They are nice in a way that doesn't feel like politeness. Someone gives you directions and then walks you halfway there. A shopkeeper asks where you're from and suddenly you've been chatting for ten minutes. You leave feeling like you made friends, even if you never learned their names.

Kozhikode is so close to my heart. Part of it is the city. Part of it is the biryani. But mostly, I think, it's that it was ours.

— Desly

Crackling in Munich

Sun, 18 Oct 2026 15:57:29 +0200

The day after Königssee we ended up in Munich, sitting in a beer garden, very hungry. When in Bavaria, you order the thing Bavaria is famous for. So I ordered Schweinshaxe.

If you haven't had it: it's pork knuckle, roasted slowly for hours until the skin turns into crackling. It comes with a big potato dumpling and a dark gravy that you will want to drink with a spoon. Nobody tells you how big it is. Nobody tells you how loud it is either. The first time your knife goes through that crackling, it actually makes a sound, like breaking a very thin, very delicious window.

Some food you eat. Some food you remember. This was the second kind.

The table

The beer came in a proper Maß, one full litre in a glass so heavy you need two hands for the first few sips. Across the table someone had ordered roast duck, with red cabbage and a slice of orange on the side, and it looked so good I took a photo of that plate too.

The photo at the top of this page says more about that evening than anything I can write. The Schweinshaxe in front. The Maß on the left, already half gone. And behind it, a friend in a blue hoodie, phone in hand, also taking a picture of his food. We were all doing the same thing. It wasn't really about the food anymore. It was about wanting to keep the moment.

What I learned

Bavarian food is not light food. It is food that assumes you walked up a mountain that morning. Which, in a way, we kind of had.

I've had pork knuckle a few times since. It's never quite the same. Maybe the recipe was special. Or maybe it was the beer garden, the long evening, and the tired, happy feeling after two days of road trip and lakes and churches. I suspect it was mostly that.

— Desly

A church under the Alps

Sun, 18 Oct 2026 15:57:29 +0200

Some trips you remember for one big moment. This one I remember in pieces, and all of them are good.

It started as a road trip. The kind where the drive is half the point. Green fields, small Bavarian villages, and the mountains slowly getting bigger in the windscreen until they stopped looking like a postcard and started looking like a wall.

On the way we passed a Fossil watch production unit. I don't know why that stuck with me so much. Maybe because I'd only ever seen those watches in shop windows, behind glass, and here was the place they actually came from, just sitting by the road like any other building. It's a strange feeling when something you know as a brand suddenly becomes a real place.

The boat

At Königssee you can't just drive to the church. You take a boat across the lake. The water is this unreal green, so clear you keep looking over the side, and the mountains come straight down into it on both sides.

The boat trip was fantastic. There was music on board, and a guide who explained the history of the place as we went: why the church was built where it is, what the lake has meant to people here for centuries. I understood maybe most of it. It didn't matter. The voice, the music and the quiet of the lake all kind of blended together.

Some places don't need you to understand them. They just need you to be quiet for a minute.

The church

And then St. Bartholomä comes into view. A small white church with red onion domes, sitting right at the edge of the water, with the Alps rising up behind it. Honestly, the architecture was a blessing for the eyes. It looks almost too perfect, like someone placed it there to make the mountains look even bigger.

I took this photo on my iPhone 7 Plus. Nothing special in terms of gear. But I remember standing there thinking I didn't need a better camera. I just needed to not mess it up.

I've taken a lot of photos since then, with much better cameras. This one is still on the wall in my head.

— Desly

Twenty minutes of blue

Sun, 18 Oct 2026 15:57:29 +0200

Everyone talks about golden hour. It's nice, sure. Warm light, long shadows, everyone looks good. But I've slowly become a blue hour person.

Blue hour is the time right after sunset, before it's fully dark. The sky becomes a deep, clean blue, and the city lights come on. For a short while, the sky and lights balance each other. The sky isn't too bright, the lights aren't too harsh. Everything just glows.

The problem is it doesn't last. Twenty minutes, maybe thirty if the weather is kind. Then the sky goes black and it's just a night photo.

A small walk in Offenburg

This one happened on an autumn evening in Offenburg. Nothing planned. We just went out for a small walk through town, the kind you take to stretch your legs after a long day, and ended up in the town square.

And then the sky did that thing. It turned that exact shade of blue. The big canopy over the square was lit from underneath in pink and purple, the tree beside it still had its yellow autumn leaves catching the street light, and people were standing around a small stall like it was any other evening. For them, it was.

I stopped and took the photo. It's the one at the top of this page, and still one of my favourites.

Good light doesn't wait for you to be ready. You either carry the camera or you don't.

I think about this outside photography too. A lot of the good stuff comes in short windows. A conversation that only happens because you stayed out ten minutes longer. A walk you almost skipped because you were tired.

That probably sounds like a fridge magnet. I'm still learning how to say these things without sounding like one. But I do believe it.

So now I check sunset times. If I'm out and the sky starts turning blue, I stop and look around. Most evenings nothing happens. Some evenings you get the square.

— Desly

The cat who taught me to wait

Sun, 18 Oct 2026 15:57:29 +0200

The Canon 4000D is not a fancy camera. It's the one shops recommend when you say "I want to get into photography" and then mention a budget. When I bought it, for the first few weeks I shot everything on the green auto mode, because the dial had too many letters on it and I didn't want to admit I didn't know what half of them meant.

The photos were fine. They looked like phone photos, just heavier.

Then there was this cat. Orange and white, it seemed to live nowhere and everywhere. It had a favourite spot on a black metal rail outside. Every afternoon around four, it would stretch out there like it owned the place. I started trying to photograph it mostly because it was the only subject that would sit still long enough for me to fiddle with settings.

Learning by getting it wrong

I switched to aperture priority because a YouTube video told me to. Opened the lens up as wide as the kit lens would go. Zoomed all the way in. Suddenly the background melted into this soft green blur and the cat looked like it was in a magazine. I genuinely said "oh" out loud.

Most of the photos were still bad. The focus would land on the rail instead of the eyes. Or the cat would blink. Or yawn, which is either the worst or the best photo depending on your mood. I took maybe two hundred pictures of that one animal over a couple of weeks.

The cat never moved for me. I had to learn to move for the cat.

What it actually taught me wasn't about aperture. It was about waiting. You don't take a good photo of a cat. You sit near a cat for twenty minutes until it decides to look at you for half a second, and you'd better be ready when it does.

That's become how I shoot pretty much everything now. People, light, streets. I get set up, I get quiet, and I wait for the half second.

I don't know where the cat is now. I hope it found a warmer rail.

— Desly

Where the road runs out

Sun, 18 Oct 2026 15:57:29 +0200

We left before five because someone had read online that the wind gets bad after noon. Nobody checked if that was true. It didn't matter. Leaving in the dark always makes a trip feel more serious than it is.

There were two of us and two KTMs. Mine had a bag strapped to the back that kept sliding left no matter how many times I fixed it. By the time the sun was properly up we'd stopped three times, twice for the bag and once for tea that was mostly sugar.

The Pamban bridge is the first moment you realise you're going somewhere strange. The land just stops and the road keeps going. The water underneath isn't one colour, it's about six, and they change as clouds pass. I pulled over, which you probably shouldn't do on a bridge, and held the GoPro out over the railing as far as my arm would go. That's the photo on this site. I didn't frame it. I just pointed and hoped.

Some of my favourite photos are ones I didn't really take. I just happened to be holding the camera.

After Rameswaram the road to Dhanushkodi gets thinner and thinner until it feels like a ruler laid on top of the sea. Water on the left, water on the right. The wind was exactly as bad as the internet promised. At the end there's a roundabout, and then nothing. Just sand, and the idea that Sri Lanka is somewhere out there, closer than most cities I've been to.

We sat there longer than planned. Nobody said much. The GoPro died around then, which is why the shot of the bike at dusk is from my phone. I almost didn't take it because I thought phone photos "didn't count". Funny, it's one of the ones people ask me about most.

What I kept

I don't remember most of the ride back. I remember the colour of the water from the bridge, the sound the wind made in my helmet, and my friend laughing at my bag sliding off for the fourth time. The photos help, but honestly they mostly remind me of things the camera didn't catch.

I want to go back with a proper camera one day. I also kind of don't. Some places are better as one imperfect memory.

— Desly

The photos I don't post

Sun, 18 Oct 2026 15:57:29 +0200

If you scroll through the photographs on this site you'll see cats, bikes, bridges, the sea. What you won't see is what I actually shoot the most, which is people. Mostly family. Kids at family gatherings, couples on their big days, grandparents who don't want their photo taken and then ask for a copy.

Honestly, that's where my best work is. Portraits taught me more than anything else. Getting the eyes sharp when a one-year-old won't stop moving. Finding the one spot in a backyard where the light falls softly. Making someone who hates cameras laugh just long enough.

So why not show them?

Because they're not really mine to show. Those moments belong to the people in them. A toddler can't agree to being on a stranger's screen. A family celebration isn't content. When I took those photos, nobody was thinking about a website. They trusted me with a camera at a private moment, and I'd like to keep that trust.

A photo can be your best work and still not be yours to share.

The photo at the top of this page is the closest I'll get. It's a silhouette of a kid watching the sun go down. You can't tell who it is. I like it partly for that reason. It could be anyone's kid on anyone's balcony. It feels more universal because it's anonymous.

What it changed

Thinking about this actually made me a better photographer, I think. When you're not shooting for likes, you shoot for the people in front of you. You care if they love the photo, not if it does well online. Some of my favourite pictures have only been seen by about five people, and those five people have them printed on a wall.

That's a pretty good audience, if you ask me.

— Desly