DEV Community: Sergey Zhekpisov

diffyml: a faster, leaner YAML diff tool

Sergey Zhekpisov — Tue, 17 Mar 2026 10:21:17 +0000

I love "dyff". I really do. For a long time, it was the best CLI tool for comparing YAML files for me.

But I was tired of typing "dyff between " every time. Every time thinking: why "between"? A diff tool should just... diff.

That small friction was the start. Then I submitted a PR and waited five months with no response. The project seemed to have stalled.

dyff is a well-built tool that popularised structural YAML diffing, and I have a lot of respect for it. Maintaining open source is hard, and I don't blame anyone for stepping back. But I needed a tool I could rely on and evolve — so I built one.

Meet diffyml.

→ "diffyml file1.yaml file2.yaml". No subcommands, no ceremony.
→ Faster than dyff at every file size tested.
→ 1 runtime dependency vs dyff's 14 — just yaml.v3 and the Go stdlib. Fewer deps = smaller attack surface.
→ Lowest memory footprint at every file size tested (18.4 MB at 5K lines vs 21–326 MB for alternatives).
→ Kubernetes-aware — auto-detects resources by apiVersion/kind/metadata and tracks renames as moves, not remove + add.
→ Git-native — works as GIT_EXTERNAL_DIFF and KUBECTL_EXTERNAL_DIFF drop-in replacement.
→ CI/CD annotations — GitHub Actions, GitLab CI, and Gitea output formats built in.
→ Directory comparison — compares entire directories, matching files by name.

But what about code quality?

→ 1,400+ tests — unit, end-to-end, property-based, and fuzz.
→ 99.9% code coverage on core logic, with mutation testing on every PR.
→ CI runs govulncheck, golangci-lint, CodeQL, and OpenSSF Scorecard.

It's out now, MIT-licensed. Install via Homebrew tap or go install.

Try it, and if you like it, leave it a star, so other fellow YAML developers can discover it too!

szhekpisov / diffyml

A fast, structural YAML diff tool — in a single-dependency binary

diffyml

A fast, structural YAML diff tool with built-in Kubernetes intelligence. One dependency, minimal attack surface, native CI annotations for GitHub, GitLab, and Gitea.

diffyml compares YAML files and shows meaningful, structured differences — not line-by-line text diffs.

Why diffyml?

Fastest at scale. 7x faster than dyff on 78 KB files, 9.5x faster on 780 KB files, with the lowest memory footprint among YAML-aware tools at scale. Near-linear scaling. See PERFORMANCE.md for methodology and results.

One dependency, zero surprises. A single runtime dependency (yaml.v3) and pure Go stdlib. Minimal attack surface, auditable in minutes.

Gets YAML right. Dotted keys, type preservation, mixed-type lists, nil values — concrete edge cases other tools get wrong. diffyml treats YAML semantics as first-class, not an afterthought.

How It Compares

Feature	diffyml	dyff	plain `diff`
YAML-aware (structural diff)	Yes	Yes	No (line-based)
Kubernetes resource matching	By apiVersion + kind + name (or generateName)

…

View on GitHub

Honest impression about Amazon Q

Sergey Zhekpisov — Sat, 09 Aug 2025 13:27:27 +0000

I know, you're tired of AI noise, I get it. No worries, me too! But listen, here is the story I want to tell you - no propaganda, just pure experience.

For the record, I was not paying for any AI subscription - no ChatGPT, no Claude, no Cursor, and for sure no Perplexity. I didn't see the value! However, I must admit that I used it occasionally - to research the best robot vacuum on the market, to check my English grammar, and to create a travel plan for the weekend. Life was simple, and the free tier of every model was more than enough.

However, more than one month ago, I came across an article stating that AWS had released MCP (Model Context Protocol) for EKS (Elastic Kubernetes Service, managed Kubernetes service in AWS), which you can connect to Amazon Q - Generative AI Assistant from Amazon.

I never heard of Amazon Q. There was always a button in the console that never did anything useful, so I was successfully ignoring it.

But as a long-time practitioner of EKS, I was curious. "Why don't I give it a shot?"

Oh boy, I wasn't ready for the outcome. Amazon Q is mighty. Here is the list of scenarios it helped me with:

Create NACL (Network Access Control List) using VPC flow logs from the last 24 hours. You don't need to combine complex rules anymore - ask in the chat.
Identify issues with the ELK (Elastic, Logstash, Kibana) stack deployed in EKS.
Troubleshoot faulty pods and suggest solutions for the problems that require attention.
Troubleshoot network connectivity and provide suggestions on the cause of the issue.
Identify access issues and recommend a policy to resolve them.
Find a security group where I deleted a rule during the last 30 minutes
...and many, many more!

Let's examine one of the scenarios: the pod is restarting. What would you do? Usually, it means that the pod is out of memory, or the liveness probe has not passed. Therefore, you should check the logs, the monitoring tool, and verify resource usage, limits, and requests of the pod. Based on the data, you can then make a decision.

And this is where Agentic AI is doing its best - working with data! It collects information from multiple sources and creates a summary of what is going on. And now, instead of spending time on all that analysis, you can ask AI and verify its conclusion, which is, in most cases (but not always), right.

And here the cherry on the top: I was struggling with my Terraform code. The AWS Config configuration that worked in one region didn't work in another. It drove me crazy - the region was the only difference, and I couldn't figure out why it was not working. I checked everything and double-checked my access - nothing.

As a last resort, I went to ask Amazon Q what was wrong. It went through access and suggested using the service config principal instead of the service role, which will have access to the bucket for the delivery channel.

"It does not make sense", were my thoughts, "service role should be fine, it's Security Hub recommendation, it works already". But I had nothing to lose, so I agreed to try that.

And it worked.

It turns out that AWS has undocumented regional discrepancies in its configuration (and their support confirmed it). And Amazon Q helped me to discover it.

I find it quite entertaining that one product from the company helped to find flaws in another product of the same company.

However, it's not a silver bullet. Of course, if the context is limited, its conclusions will be faulty. Additionally, Amazon Q offers Claude-Sonnet-3.7 and Claude-Sonnet-4; however, in reality, only the latest version is capable of producing meaningful results. And sometimes it uses incorrect parameters for the AWS CLI and fails to consider the entire context until it is pointed out, making it less than ideal.

But it's capable, I can assure you. With MCP for EKS and Terraform, it has become a daily tool for me now. Luckily, there is a free version available, allowing you to try it out for yourself.

At Katanox, we, as a "tech-first" company, are always looking for opportunities to improve our processes, and Amazon Q has already helped me to:

Reduce troubleshooting time by 50%
Reduce time-to-enable by 65%
Generate tests to cover the code and critical cases

Did I tell you that I don't pay for any AI subscription? Now it's changed.

If you tried Amazon Q already, what is your impression? Which MCPs are you using in addition? Please let me know in the comments below; I am curious.

Bottlerocket OS and ECS

Sergey Zhekpisov — Fri, 30 May 2025 09:47:55 +0000

When you run your ECS on Bottlerocket OS images, make sure that your user data is configured correctly.

❌ Wrong way:

module "autoscaling" {
  source  = "terraform-aws-modules/autoscaling/aws"
  version = "8.3.0"

  for_each = {
    # On-demand instances
    ex_1 = {
      instance_type              = t3.micro
      user_data                  = <<-EOT
        #!/bin/bash
        cat <<'EOF' >> user-data.toml
        [settings.ecs]
        cluster = "ecs-cluster"
        EOF
      EOT
    }
  }

✅ Right way:

module "autoscaling" {
  source  = "terraform-aws-modules/autoscaling/aws"
  version = "8.3.0"

  for_each = {
    # On-demand instances
    ex_1 = {
      instance_type              = t3.micro
      user_data                  = <<-EOT
      [settings.ecs]
      cluster = "ecs-cluster"
      EOT
    }
  }

AWS Config and S3 Delivery Channel issue

Sergey Zhekpisov — Fri, 16 May 2025 12:21:49 +0000

Today, I was fighting the enablement of a delivery channel for AWS Config, and every time I received an error:

InsufficientDeliveryPolicyException: Insufficient delivery policy to s3 bucket

It took half a day to figure out a small but essential nuance — it turns out that AWS Config does not support the delivery channel to an Amazon S3 bucket where object lock is enabled with default retention enabled.

So, if you face the same issue, check if your bucket's object lock is disabled.

Brightness control for Samsung Odyssey G7

Sergey Zhekpisov — Wed, 31 Jul 2024 14:56:24 +0000

I have a Samsung Odyssey G7 connected to my MacBook Pro (M1 Pro) as a second display. I dislike adjusting the brightness using the hardware button and on-screen display (OSD), so I looked for software tools to control it.

Fortunately, I found one: MonitorControl. It works like a charm!

You can install via Homebrew:

brew install MonitorControl

Memorious Prometheus

Sergey Zhekpisov — Tue, 27 Feb 2024 18:21:43 +0000

Recently, we received alerts in Alertmanager, deployed with a kube-stack-prometheus Helm chart. The alert stated that 50% of the EKS endpoints for "apiserver/kubernetes" were down.

50% of the apiserver/kubernetes targets in the default namespace are down.

A brief look at Prometheus revealed that there were four(!) targets for the serviceMonitor/monitoring/prometheus-operator-monito-apiserver/0 endpoint - two were down, and two were up. Upon examining other clusters, it became clear that there are normally only two targets for each cluster.

So, it turns out that the EKS Control Plane was updated during the night, and the apiserver endpoints received new IP addresses. However, the Prometheus scraper retained old IP addresses in its database.

Solution was simple:

kubectl rollout restart statefulset prometheus-prometheus-operator-monito-prometheus -n monitoring

...and the old targets that were "down" disappeared, and the alert was resolved.