I built a JSON/YAML/TOML toolkit after wasting too much time validating configs

Zerlo.net — Sun, 12 Apr 2026 14:14:15 +0000

Working with config files should be boring.

That’s exactly the problem: it usually isn’t.

I kept running into the same small annoyances over and over again:

a broken comma in JSON
YAML indentation issues
converting between formats just to test something quickly
opening three different tools for tasks that should take 20 seconds

None of this is difficult work. It’s just annoying work.
And that kind of friction adds up fast when you deal with configs regularly.

In my case, it happened often enough while working with API payloads, small web tools, AI-related settings, and general dev utilities that I got tired of constantly switching between validators, formatters, and converters.

So I built a small browser-based JSON Toolkit for my own workflow.

The goal was not to build “yet another formatter”.
The goal was to remove those tiny interruptions that break focus for no good reason.

What I wanted in one place:

format JSON quickly
validate it without extra clutter
minify it when needed
convert JSON ↔ YAML/TOML without weird surprises
keep the whole thing fast and simple

A typical example is when I have some ugly JSON like this:

{"name":"toolkit","enabled":true,"items":[1,2,3]}

and I just want this instead:

{
  "name": "toolkit",
  "enabled": true,
  "items": [1, 2, 3]
}

Or when I want to quickly turn it into YAML for a config test:

name: toolkit
enabled: true
items:
  - 1
  - 2
  - 3

That’s not a hard problem.
It’s just the kind of thing that wastes time in small, repetitive chunks.

While building it, I tried to keep the tool focused:

no overloaded interface
no unnecessary steps
no “power user” nonsense for basic tasks
just a practical utility that does the job cleanly

That was the main idea from the start:
not a big platform, not a complicated parser playground — just something useful enough that I’d actually keep using it myself.

That’s usually my best filter for small tools:
if I don’t come back to it after building it, it probably wasn’t worth building.

So far, this one stayed.

You can try the JSON Toolkit here.

I’m curious how others handle this kind of workflow:
do you prefer one small all-in-one tool, or separate tools for validation, formatting, and conversion?

What To Do When Your Website Is Under a DDoS Attack

Zerlo.net — Sat, 11 Apr 2026 15:53:03 +0000

A little while ago, Zerlo.net was hit by a DDoS attack.

At first, I assumed it was just a technical issue. But after checking our traffic and infrastructure, it became clear that this was not normal user activity. In this post, I’ll show how we identified the attack, how Cloudflare helped reduce the impact, and what actions are worth taking when your website suddenly starts collapsing under artificial load.

What is a DDoS attack?

A Distributed Denial of Service (DDoS) attack tries to make a website or service unavailable by overwhelming it with traffic from many different sources at the same time.

In practice, this often means:

huge spikes in requests
abnormal load on the origin server
suspicious user agents
repeated hits on expensive endpoints like login pages, APIs, search, or forms

There are different forms of DDoS:

network-level attacks such as UDP or ICMP floods
application-layer attacks (Layer 7) such as HTTP floods

Layer 7 attacks are especially annoying because they can look more like “normal” traffic at first glance.

How do you recognize it?

A single metric is usually not enough.

Typical warning signs are:

sharply rising server load without a corresponding rise in real users
many requests hitting expensive endpoints
strange or empty user agents
unexpected request peaks from unfamiliar ASNs or regions
high CPU or I/O load even though you didn’t deploy anything new

One of the biggest clues in our case was this:

our own counter tracks human interactions through JavaScript, and those numbers were almost identical to the previous day — while the infrastructure load was massively higher.

That mismatch is a huge red flag.

Our first practical test

The classic test was simple:

run everything locally.

If the application itself is broken, you usually see the problem locally as well.

In our case, local load was basically 0%, while the public system was struggling hard.

That was the moment it became obvious that the pressure was external.

What Cloudflare showed us

Once we checked Cloudflare, the pattern became much clearer.

Useful places to look at:

Security Events / Security Analytics
Traffic Analytics
WAF activity
Rate limiting and challenge data

In Cloudflare, you can break traffic down by:

path
country
ASN
method
user agent

That makes it much easier to distinguish real traffic from garbage.

When we enabled Under Attack Mode, the average server load dropped to around 5%. That was the clearest confirmation we needed.

What Cloudflare is actually doing here

This is the simple version:

Cloudflare sits in front of your origin and can challenge suspicious traffic before it ever reaches your infrastructure.

That means:

bots have to solve extra work
cheap flood traffic becomes more expensive
real users usually pass with minimal friction
your backend gets breathing room immediately

This does not “prevent DDoS forever”, but it buys time and drastically reduces the damage.

What should you do immediately?

You can’t stop people on the internet from sending packets to your system.

So the goal is not “prevent everything forever”.

The real goal is:

reduce the impact enough so that real users can still use the site.

Short-term actions

enable Under Attack Mode
challenge suspicious requests
put rate limiting on sensitive paths
protect forms and login-like endpoints
increase caching where possible
monitor security analytics closely

Good candidates for immediate protection

/api/
form endpoints
login pages
search
mail handlers
expensive POST requests
dynamic pages with heavy backend processing

What should you do long term?

Short-term mitigation is not enough.

After the incident, hardening should include:

proper WAF rules
Managed Challenge for suspicious traffic
Rate Limiting per IP and per path
caching public pages aggressively
bypassing cache only where needed
protecting forms with Turnstile
collecting and reviewing logs
setting alerts for unusual spikes
identifying “expensive” endpoints before the next attack

A practical rule approach

Here is a simple example of the type of logic that makes sense:


txt
(len(http.user_agent) = 0
 or lower(http.user_agent) contains "python"
 or lower(http.user_agent) contains "curl"
 or lower(http.user_agent) contains "bot"
 or lower(http.user_agent) contains "crawler")
=> Action: Managed Challenge

(http.request.method eq "POST"
 or starts_with(http.request.uri.path, "/api/")
 or http.request.uri.path contains "/sendMail.php")
=> Action: Managed Challenge

# Rate Limiting example
(http.request.method eq "POST" and starts_with(http.request.uri.path, "/api/"))
Threshold: 10 requests in 10 seconds per IP
Action: Challenge

Forem: Zerlo.net