Forem: Tommaso Bertocchi

I built an AI agent that does OSINT investigations from your terminal

Tommaso Bertocchi — Fri, 08 May 2026 13:07:52 +0000

Most OSINT tools are great at one thing. You run holehe for emails, sherlock for usernames, sublist3r for domains. But you're the one deciding the workflow, switching between tools, copy-pasting results.

I wanted to remove that middle layer. So I built OpenOSINT — you describe a target in plain English, the AI figures out what to investigate and how, runs the tools, and hands you a report.

How it works

The core idea is simple: instead of hardcoding a fixed pipeline, I use Claude's native tool use API to let the model decide at each step what to do next based on what it found so far.

you ❯ investigate john.doe@gmail.com

→ search_email(john.doe@gmail.com)
  Found: spotify, wordpress, office365, gravatar

→ search_breach(john.doe@gmail.com)
  Found: 2 breaches (LinkedIn 2016, Adobe 2013)

→ search_paste(john.doe@gmail.com)
  No results.

✓ Report saved to reports/2025-05-08_john-doe.md

No hardcoded sequence. The model sees the holehe results and decides whether to check breaches next, look up the domain, or go straight to the report. It's a genuine reasoning loop, not a fixed script.

Why native tool use matters

The first version I built used a manual ReAct loop — I was parsing JSON from the model, extracting tool calls, running them, feeding results back. It worked but it was fragile. Models hallucinate tool results when they're bored.

With the Anthropic tool use API, the model returns stop_reason: "tool_use" when it wants to call something. You execute it, return the result, and the model continues. The loop is clean:

def run(self, prompt: str) -> str:
    messages = [{"role": "user", "content": prompt}]

    while True:
        response = self.provider.chat(
            messages=messages,
            system=SYSTEM_PROMPT,
            tools=self.tool_registry.get_definitions()
        )

        if response.stop_reason == "end_turn":
            return response.content

        if response.stop_reason == "tool_use":
            messages.append({"role": "assistant", "content": response.raw_content})

            results = []
            for call in response.tool_calls:
                result = self.tool_registry.execute(call.name, call.input)
                results.append({
                    "type": "tool_result",
                    "tool_use_id": call.id,
                    "content": result
                })

            messages.append({"role": "user", "content": results})

The model never gets a chance to invent results because it always receives the actual tool output before continuing.

Tools included

Tool	What it wraps	What it finds
`search_email`	holehe	social accounts linked to an email
`search_username`	sherlock	accounts across 300+ platforms
`search_domain`	sublist3r	subdomains
`search_breach`	HaveIBeenPwned API	data breach exposure
`search_whois`	python-whois	domain registrant info
`search_ip`	ipinfo.io	geolocation, ASN, hostname
`generate_dorks`	built-in	Google dork URLs for any target
`search_paste`	psbdmp API	Pastebin dump mentions
`search_phone`	phoneinfoga	carrier, country, line type

Each tool handles missing dependencies gracefully — if sherlock isn't installed it tells you the install command instead of crashing.

Multi-provider

The AI layer is completely swappable. On first run you pick your provider:

Select provider:
  [1] Anthropic (Claude) — Recommended
  [2] OpenAI (GPT-4o)
  [3] Ollama (Local) — Experimental

The same agentic loop runs regardless. Anthropic is noticeably better at following structured tool-use instructions, but all three work. Local models via Ollama are marked experimental because they're inconsistent with JSON-structured responses.

The terminal UI

Built with Rich. Tool calls log inline as they happen so you can see the investigation unfold in real time rather than waiting for a final dump.

openosint ❯ investigate john.doe@example.com

  ⠸ Investigating...

  → search_email          john.doe@example.com
  ✓ Found: spotify, wordpress, gravatar, office365

  → search_breach         john.doe@example.com
  ✓ Found in 2 breaches

  ╭──────────────────── Report ─────────────────────╮
  │ ## Ambiguity Check                              │
  │ Single target identified — high confidence.     │
  │                                                 │
  │ ## Online Presence                              │
  │ Confirmed: Spotify, WordPress, Gravatar,        │
  │ Office365                                       │
  │                                                 │
  │ ## Data Breaches                                │
  │ LinkedIn (2016), Adobe (2013)                   │
  ╰─────────────────────────────────────────────────╯

  Report saved → reports/2025-05-08_john-doe.md

Install

pip install openosint
openosint config    # runs the setup wizard
openosint investigate "john.doe@example.com"

Or from source:

git clone https://github.com/OpenOSINT/OpenOSINT
cd OpenOSINT
pip install -e .
openosint config

What's next

Web UI (optional, for non-terminal users)
Export to PDF
Graph visualization of connections between identifiers
More tools: LinkedIn scraping, GitHub profile analysis, image metadata

Reminder: OpenOSINT is for authorized use only. Read DISCLAIMER.md before using.

Source: github.com/OpenOSINT/OpenOSINT

8 Tools Powering the Fastest-Growing Startups in 2026

Tommaso Bertocchi — Wed, 06 May 2026 12:05:58 +0000

Most "startup stack" articles are written by people who haven't shipped anything in two years.

They'll tell you: Next.js, Prisma, Vercel, Supabase, done. That's the 2022 answer.

The startups gaining traction right now are making different choices — edge-native, serverless-first, zero-lock-in choices that weren't available or production-ready three years ago.

This isn't a list of "cool tools." It's the actual infrastructure decisions that let a 3-person team scale to 100k users without hiring a DevOps engineer.

How I selected these

I'm not ranking by GitHub stars or Twitter buzz. My criteria:

Ships fast — can a solo dev go from zero to deployed in under a day?
Edge or serverless-native — no single-region Node servers pretending to be modern
Doesn't own your data — open-source core or real self-host options
TypeScript-first DX — type errors at build time, not at 2am in production
Solves something boring that used to require a dedicated hire — security, background jobs, auth

TL;DR: The fastest startups in 2026 aren't using the default stack — they're building on edge-native, serverless-first tools that make a 3-person team feel like 10.

giphy.com

Hono — The API framework that actually runs at the edge
Neon — Serverless Postgres that branches like Git
Drizzle ORM — The TypeScript ORM that doesn't fight your database
Trigger.dev — Background jobs that don't require a PhD in distributed systems
shadcn/ui — UI components you copy, own, and never regret
pompelmi — The one security layer most early-stage startups skip
OpenNext — Escape Next.js infrastructure lock-in
Supabase — The open-source BaaS that didn't make you regret it later

1) Hono — The API framework that actually runs at the edge

What it is: A tiny (~14kB), ultra-fast web framework that runs identically on Cloudflare Workers, Bun, Deno, AWS Lambda, and Node.js.

Why it matters in 2026: Most API frameworks were designed for a single-region server. Hono was designed for a world where your function runs in 300 locations simultaneously. When cold starts are zero and latency is single-digit milliseconds globally, the old pattern of running Express in us-east-1 starts looking embarrassing. The ergonomics are close enough to Express that migration isn't a rewrite — it's an afternoon.

Best for: API-first products, edge-deployed backends, developers escaping Express or Fastify who don't want to give up familiar routing.

Links: GitHub | Website

2) Neon — Serverless Postgres that branches like Git

What it is: Fully managed, serverless Postgres with instant database branching — one command and you have an isolated copy of your database for any PR or experiment.

Why it matters in 2026: The "prod data leaking into staging" problem doesn't need to exist anymore. Neon's branching model means every preview deployment gets its own database copy, spun up in seconds, torn down automatically — no more shared staging databases everyone's afraid to touch. Scale-to-zero billing means pre-revenue startups aren't paying for idle Postgres at 3am.

Best for: Early-stage startups, teams using Vercel/Railway preview environments, developers who want managed Postgres without the AWS RDS tax.

Links: GitHub | Website

3) Drizzle ORM — The TypeScript ORM that doesn't fight your database

What it is: A TypeScript ORM with a SQL-like query API, zero dependencies, and first-class support for Postgres, MySQL, SQLite, and edge runtimes.

Why it matters in 2026: Prisma is excellent until it isn't — complex joins, raw migrations, or edge deployments all eventually expose its limits. Drizzle's philosophy is "SQL is the interface, TypeScript is the wrapper" — you write queries that look like SQL and the types fall out automatically. In an era where AI-generated code constantly hits ORM edge cases, having a predictable mental model matters more than magic.

Best for: TypeScript-first teams, developers deploying to Cloudflare Workers or Bun, anyone who's hit Prisma's migration drift at least once.

Links: GitHub | Website

Happy New Year Celebration GIF by Faith Holland - Find & Share on GIPHY

Discover & share this Happy New Year Celebration GIF by Faith Holland with everyone you know. GIPHY is how you search, share, discover, and create GIFs.

giphy.com

4) Trigger.dev — Background jobs that don't require a PhD in distributed systems

What it is: An open-source platform for creating long-running background jobs in TypeScript — with built-in retries, scheduling, fan-out, and a real-time observability dashboard.

Why it matters in 2026: Every startup eventually needs background jobs: send emails, process uploads, sync external APIs, generate AI content. The default move is still "throw it in a queue and hope." Trigger.dev gives you durable, observable, type-safe background execution with the same DX as writing a regular function — no SQS configuration, no dead-letter queue archaeology. With LLM workloads now routinely taking 30–120 seconds, having a real background job platform isn't optional anymore.

Best for: Startups running AI pipelines, teams replacing Inngest or raw SQS queues, developers who want background jobs that don't silently fail at 4am.

Links: GitHub | Website

5) shadcn/ui — UI components you copy, own, and never regret

What it is: A collection of accessible, composable UI components built on Radix UI and Tailwind — installed by copying source code directly into your project, not by adding a package dependency.

Why it matters in 2026: Most component libraries eventually become a cage. shadcn/ui's model is radical: the code lives in your repo, you own it completely, and upgrading is opt-in and surgical. With AI-assisted UI development accelerating, having full source access means LLMs can actually modify your components correctly — not guess at a black-box library's undocumented internals.

Best for: Startups building internal tools or customer-facing dashboards, developers on Next.js or Remix who want full design control without writing Radix from scratch.

Links: GitHub | Website

giphy.com

6) pompelmi — The one security layer most early-stage startups skip

What it is: A minimal Node.js wrapper around ClamAV that scans any file and returns a typed Verdict (Clean, Malicious, ScanError). No daemons, no cloud, no native bindings, zero runtime dependencies.

Why it matters in 2026: User-generated content is everywhere, and every startup with a file upload is one malicious PDF away from a security incident. In a world where AI-generated malware is getting harder to detect, dropping a local ClamAV scan into your upload pipeline costs 10 lines of code and potentially saves your entire reputation. Most early-stage security checklists skip file scanning because it sounds hard — pompelmi makes it a 5-minute integration.

Best for: Startups accepting file uploads from users, SaaS products handling sensitive documents, developers who want server-side file validation without adding a cloud scanning service to their vendor list.

Links: GitHub

7) OpenNext — Escape Next.js infrastructure lock-in

What it is: An open-source adapter that deploys Next.js anywhere — Cloudflare Workers, AWS Lambda, Deno Deploy — not just Vercel.

Why it matters in 2026: Vercel is excellent, but "excellent" shouldn't mean "only option." Next.js became so tightly coupled to Vercel's infrastructure that deploying elsewhere felt like reverse engineering — OpenNext changes that by properly implementing the missing adapter layer. For startups with data residency requirements or cost concerns at scale, having a real self-hostable path for Next.js changes the architecture conversation entirely.

Best for: Startups evaluating multi-cloud or hybrid deployments, teams hitting Vercel's pricing at scale, developers who need Next.js but can't accept single-cloud lock-in.

Links: GitHub | Website

8) Supabase — The open-source BaaS that didn't make you regret it later

What it is: An open-source Firebase alternative — Postgres, real-time subscriptions, auth, storage, and edge functions, all in one platform with a self-hostable option.

Why it matters in 2026: Firebase's lock-in cost finally caught up with enough startups that "Firebase alternative" became a real product category. Supabase won that category by building on Postgres instead of a proprietary database — meaning your data model is portable from day one and the entire SQL ecosystem just works. With vector extensions, branching support, and a maturing edge functions story, Supabase in 2026 is not the scrappy Firebase clone it was in 2020.

Best for: Full-stack teams that want to move fast without infrastructure babysitting, startups that need auth + database + storage without stitching three separate services together.

Links: GitHub | Website

giphy.com

Final thoughts

The best startup stacks in 2026 were built for a world where compute is cheap, cold starts are unacceptable, and a 2-person team needs to move like a 20-person team.

That's why the tools actually winning right now are built around:

Edge-native execution as the default, not an afterthought
Type safety all the way from schema to frontend component
Open-source cores with managed hosting options — not one or the other
Security baked in early, before an incident forces the conversation
Boring infrastructure decisions made once, not revisited every quarter

The "default stack" gets you started. These tools get you to scale without burning out your team or your runway.

If I missed something obvious, drop it in the comments.

What's the one tool in your stack you'd refuse to build a startup without?

9 Open-Source Tools to Own Your Stack (and Kill Your Cloud Bills) in 2026

Tommaso Bertocchi — Tue, 05 May 2026 09:59:50 +0000

Most "self-hosting" articles are basically a list of Docker Compose files.

They tell you what to run. They don't tell you why the smart money is moving away from managed cloud services — or what a real production stack looks like when you do it right.

The shift isn't about being cheap. It's about control.

Your data. Your pipeline. Your infra. No vendor lock-in, no surprise pricing changes, no terms-of-service update that kills your product overnight.

Here's the stack I'd build today if I were starting from scratch — tools that are production-grade, actively maintained, and built by teams who eat their own cooking.

How I picked these

I'm not ranking by GitHub stars or Hacker News upvotes. I'm ranking by:

Production-readiness — does it hold up under real load, or is it a weekend project with a pretty README?
Migration story — can you replace an existing paid service without a 3-month rewrite?
Maintenance burden — how much ops work does it create vs. eliminate?
Privacy posture — does it send anything home? Telemetry, usage data, silent pings?
Community momentum — growing or stagnating?

TL;DR: In 2026 you can run a full production stack on cheap VPS hardware and own everything from auth to analytics to AI inference — the cloud is a choice, not a requirement.

giphy.com

Ollama — Run any LLM locally, one command
Coolify — Deploy apps without touching AWS or Vercel
Plausible — Analytics that don't spy on your users
Authentik — Auth without the $300/month Auth0 invoice
Forgejo — Git hosting that's actually yours
pompelmi — File scanning without sending files to the cloud
Meilisearch — Search that doesn't bill per query
Windmill — Automate workflows without Zapier's pricing ceiling
Netdata — Real-time monitoring without Datadog sticker shock

giphy.com

1) Ollama — Run any LLM locally, one command

What it is: A runtime that lets you download and run open-weight LLMs (Llama 3, Mistral, Gemma, Phi-4, DeepSeek) on your own hardware with a single CLI command.

Why it matters in 2026: Every app is getting an AI feature bolted on, and most teams are routing everything through OpenAI — which means user prompts, internal documents, and sensitive data are leaving your infrastructure constantly. Ollama changes the threat model entirely. Your inference stays local. No API key, no usage ceiling, no per-token bill that scales into a surprise. With Apple Silicon and consumer NVIDIA cards getting faster every cycle, "local LLM" has crossed the threshold from demo to production-viable for most workloads.

Best for: privacy-sensitive apps, teams building on open-weight models, developers who want zero inference cost during iteration.

Links: GitHub | Website

2) Coolify — Deploy apps without touching AWS or Vercel

What it is: A self-hostable PaaS that handles deployments, SSL, reverse proxying, database provisioning, and environment management — a full Heroku/Vercel replacement you run on your own VPS.

Why it matters in 2026: Vercel's pricing restructure and Render's new limits made a lot of teams do the math. A $6/month Hetzner VPS running Coolify handles most indie projects better than $50/month on a managed platform. The interface is clean, deployment from Git is one-click, and it handles Docker Compose natively. The difference from older self-hosted PaaS tools (Dokku, CapRover) is that Coolify actually feels finished.

Best for: indie hackers, small agencies, teams that want Heroku UX on their own hardware.

Links: GitHub | Website

giphy.com

3) Plausible — Analytics that don't spy on your users

What it is: A lightweight, privacy-first web analytics tool that gives you pageviews, referrers, and traffic sources — without cookies, without GDPR banners, without sending data to Google.

Why it matters in 2026: GA4 is still a compliance headache and a UX nightmare. More critically, a growing segment of users actively block Google Analytics. Plausible's tracker is under 1KB and so privacy-respecting that it loads on pages where GA4 gets blocked. Self-hosted, your data never leaves your server. You get cleaner numbers, not inflated by bot traffic that GA4 struggles to filter.

Best for: GDPR-conscious teams, devs building privacy-first products, anyone who tried GA4 onboarding and immediately wanted to quit.

Links: GitHub | Website

4) Authentik — Auth without the $300/month Auth0 invoice

What it is: A self-hosted identity provider and SSO platform that supports OAuth2, SAML, LDAP, and SCIM — a full Auth0/Okta alternative you run in a Docker container.

Why it matters in 2026: Auth0's free tier got gutted, and Okta's breach history hasn't helped confidence. The irony is that Authentik is genuinely more configurable than the SaaS alternatives — custom flows, policy engines, MFA, and social logins — all with no per-MAU pricing. If your app handles sensitive data, running your own auth means you control the session store, token lifetimes, and audit logs.

Best for: B2B SaaS teams, compliance-sensitive apps, developers who've hit Auth0's pricing wall.

Links: GitHub | Website

5) Forgejo — Git hosting that's actually yours

What it is: A community-maintained fork of Gitea that gives you a full GitHub-like experience — repos, issues, PRs, CI/CD hooks, and package registries — on your own infrastructure.

Why it matters in 2026: GitHub is owned by Microsoft. GitLab's self-hosted path got increasingly hobbled toward enterprise licensing. Forgejo is the community fork that said no thanks to both trajectories. It runs on a $5 VPS, mirrors to GitHub if you want redundancy, and doesn't phone home. For teams handling proprietary code or working in regulated industries, your Git host shouldn't be someone else's SaaS.

Best for: teams with IP concerns, regulated industries, developers who want GitHub UX without GitHub dependency.

Links: GitHub | Website

giphy.com

6) pompelmi — File scanning without sending files to the cloud

Why it matters in 2026: If you're self-hosting everything else, why are you sending uploaded files to a cloud AV API? That's a data exfiltration vector you're literally paying for. pompelmi gives you local file scanning in one function call — it wraps ClamAV without the usual C-binding pain or process management overhead. With LLM-generated code being used to create novel malware at scale, user upload scanning isn't optional anymore — and it shouldn't require trusting a third party with your files.

Best for: self-hosted file storage, Node.js backends with upload endpoints, teams running ClamAV who don't want to manage it directly.

Links: GitHub

7) Meilisearch — Search that doesn't bill per query

What it is: A fast, typo-tolerant, open-source search engine you self-host — think Algolia's UX without Algolia's pricing.

Why it matters in 2026: Algolia is still excellent. It's also $1/1000 operations, which adds up fast once you have any real traffic. Meilisearch delivers sub-50ms search out of the box, handles typos and faceted filtering natively, and ships as a single binary. The API is close enough to Algolia's that migration is low-friction. For any product where search is a core feature and you're already hosting your own data, this is a no-brainer.

Best for: product teams replacing Algolia, developers building search-heavy apps, e-commerce on self-hosted infrastructure.

Links: GitHub | Website

giphy.com

8) Windmill — Automate workflows without Zapier's pricing ceiling

What it is: A self-hosted workflow automation and internal tool builder — write scripts in Python, TypeScript, or Go, connect them into flows, trigger via webhook, cron, or API.

Why it matters in 2026: Zapier's task-based pricing model breaks at scale. n8n is solid but has a steep learning curve. Windmill is what you'd get if you rebuilt Zapier for engineers — scripts are first-class, version-controlled, and testable. Audit logs, RBAC, and secrets management are built in. Teams running internal ops, data pipelines, or API integrations are migrating here because the code is actually theirs.

Best for: engineering teams running internal tooling, data teams replacing Make/Zapier for complex flows, developers who want code-first automation.

Links: GitHub | Website

9) Netdata — Real-time monitoring without Datadog sticker shock

What it is: A high-resolution, real-time infrastructure monitoring agent that collects thousands of metrics with zero configuration and visualizes them in a live dashboard — fully self-hosted.

Why it matters in 2026: Datadog's pricing has become a running joke — teams routinely get hit with invoices they didn't budget for. Netdata installs in 60 seconds, collects at 1-second resolution by default, and the dashboard is genuinely better-looking than most paid alternatives. The Netdata Cloud tier is optional — you can run it entirely air-gapped. For teams that moved to self-hosted infra, this closes the observability gap without re-introducing a SaaS dependency.

Best for: self-hosted infrastructure, on-call teams who need high-resolution metrics, developers who tried Prometheus + Grafana and decided life was too short.

Links: GitHub | Website

giphy.com

Final thoughts

The cloud is still useful — but "we have to use the cloud" is almost never true anymore.

The tools above cover the full surface area of a production stack: inference, deployment, analytics, auth, version control, file security, search, automation, and observability. All open source. All self-hostable. All production-grade.

That's why the best infrastructure decisions being made right now are about:

Ownership over convenience
Privacy by architecture, not by policy
Cost predictability as a first-class engineering requirement
Vendor lock-in treated as a risk to be mitigated, not a feature
Local-first as the default, cloud as the deliberate exception

The irony is that the self-hosted stack is often faster, cheaper, and more reliable than the managed equivalent — once you get past the initial setup.

If I missed something obvious, drop it in the comments.

Which managed service are you most tempted to replace right now?

7 Mistakes Every Developer Makes in 2026 — And the Open-Source Fix for Each

Tommaso Bertocchi — Mon, 04 May 2026 10:59:30 +0000

Most "best practices" articles are useless.

They tell you to "write tests" and "use environment variables" without ever showing you the specific moment those warnings actually matter. You nod along and forget them by tomorrow.

This is the version with names, repos, and real consequences.

Every mistake below has a free, self-hostable open-source fix — no SaaS required.

These aren't theoretical. They're the kind of thing that causes a 3am incident, a silent data breach, or a "how did this even work" Slack thread that ends careers.

How I picked these

Not by StackOverflow survey popularity or Twitter discourse. I ranked by:

Cost of getting it wrong — does this mistake cause a data breach, an outage, or just mild annoyance?
How often developers skip it — not because they don't know better, but because the fix felt annoying to set up
Whether a drop-in open-source fix exists — something you can actually add today, not a six-month architecture project
Relevance to 2026 specifically — AI-generated code, LLM integrations, and supply chain attacks changed what "default safe" even means

TL;DR: The most dangerous developer mistakes in 2026 aren't about writing bad code — they're about skipping the invisible layers that make code trustworthy.

giphy.com

Infisical — Stop hardcoding secrets, you know who you are
pompelmi — Your file upload endpoint is a malware delivery service
SigNoz — You're flying blind the moment you ship
Atlas — Your database migrations are ticking time bombs
Scalar — Your API docs are a lie and your team knows it
Testcontainers — "Works on my machine" never fixed a production outage
Unkey — Your API is open for abuse right now

1) Infisical — Stop hardcoding secrets, you know who you are

What it is: A self-hosted secrets manager that replaces .env files, GitHub secrets, and the shame of finding your API key in a public repo two years later.

Why it matters in 2026: AI code assistants train on public repositories. If your key leaks into a commit, it's not just crawled by bots — it's potentially ingested into model training data. Secrets management is no longer a DevOps concern; it's an AI-era data hygiene issue. Infisical gives you a centralized vault with access control, audit logs, and SDK support for Node, Python, Go, and more — replacing the .env file that currently lives on 7 different machines with no rotation policy.

Best for: Solo devs tired of rotating leaked keys, teams onboarding new engineers, any project using more than 2 third-party APIs.

Links: GitHub | Website

giphy.com

2) pompelmi — Your file upload endpoint is a malware delivery service

Why it matters in 2026: Every app that accepts file uploads is one crafted .pdf away from distributing malware to other users. With AI-generated documents now trivially easy to weaponize, most upload handlers still do zero scanning — and they're one shared file away from becoming the distribution vector. pompelmi wraps ClamAV in a single function call, runs fully local (no files ever leave your server), and drops into any Node.js middleware stack in under 10 lines. It's the security layer most tutorials forget to mention.

Best for: Node.js APIs that accept file uploads, SaaS platforms with user-generated content, developers who need antivirus scanning without touching a cloud vendor's data pipeline.

Links: GitHub

3) SigNoz — You're flying blind the moment you ship

What it is: A full-stack observability platform (metrics, traces, logs) built on OpenTelemetry — a self-hosted alternative to Datadog and New Relic that doesn't send your data to a third party.

Why it matters in 2026: The average developer adds a console.log and calls it monitoring. Then their LLM-powered feature starts misbehaving at scale and they have no idea which requests are failing, why, or for whom. Observability is the difference between a 5-minute fix and a 3-hour war room. SigNoz uses OpenTelemetry natively — no vendor lock-in, no 6-figure Datadog bill, and your traces stay on your own infra.

Best for: Teams running microservices, developers building on top of LLM APIs who need to trace latency per model call, anyone who opened a surprise Datadog invoice.

Links: GitHub | Website

giphy.com

4) Atlas — Your database migrations are ticking time bombs

What it is: A schema management tool that treats your database schema like code — versioned, reviewed, and applied safely. Think terraform plan but for your Postgres or MySQL schema.

Why it matters in 2026: Half the startups I've seen have migrations that were run manually once and never committed. Someone adds a column in production, forgets to update the migration file, and three months later a new engineer runs migrate up and breaks staging. With AI assistants generating schema changes faster than ever, migration debt is compounding at a rate humans can't manually track. Atlas gives you a schema diff, a migration linter, and CI integration so schema changes go through the same review process as your code.

Best for: Postgres/MySQL/SQLite users, teams using ORMs that generate inconsistent migrations, any project where "just run this ALTER TABLE manually" has been said out loud.

Links: GitHub | Website

5) Scalar — Your API docs are a lie and your team knows it

What it is: A beautiful, interactive API reference generator that renders OpenAPI specs as live documentation with a built-in HTTP client, dark mode, and code generation.

Why it matters in 2026: Every team I've worked with has Swagger docs that are three sprints out of date. Developers end up Slack-messaging the engineer who wrote the endpoint instead of reading docs. When AI coding assistants generate code against your API, stale docs don't just waste time — they produce broken integrations at scale. Scalar auto-renders from your OpenAPI spec, runs as a single script tag or self-hosted service, and actually looks good enough that people open it voluntarily.

Best for: API-first teams, developer tools companies, anyone building something other developers will integrate against.

Links: GitHub | Website

Happy New Year Celebration GIF by Faith Holland - Find & Share on GIPHY

Discover & share this Happy New Year Celebration GIF by Faith Holland with everyone you know. GIPHY is how you search, share, discover, and create GIFs.

giphy.com

6) Testcontainers — "Works on my machine" never fixed a production outage

What it is: A library (Node, Go, Java, Python, .NET, and more) that spins up real Docker containers for your tests — actual Postgres, Redis, Kafka, not mocks — and tears them down when the test finishes.

Why it matters in 2026: Mocking your database in tests is a lie you tell yourself. The mock passes, the query fails in production because your ORM generated slightly different SQL than you expected. AI assistants now write most test code, and they default to mocking everything — which means your test suite looks green while the actual behavior is untested. Testcontainers runs the real dependency for the duration of the test with zero local setup. No "but it worked in CI."

Best for: Backend engineers tired of flaky integration tests, teams where AI generates most test scaffolding, any project where unit tests keep missing bugs that only show up in staging.

Links: GitHub | Website

7) Unkey — Your API is open for abuse right now

What it is: An open-source API key management and rate limiting platform — create, revoke, and audit API keys with per-key rate limits and usage analytics, all via a single API call.

Why it matters in 2026: Most APIs either have no rate limiting or rely on a regex check on an Authorization header someone wrote at 2am. When AI agents start calling your API autonomously in tight loops, "no rate limit" becomes a self-inflicted DDoS from your own paying users. Unkey treats API keys as first-class objects — each key gets its own rate limit, expiry date, metadata, and audit trail. You can issue temporary keys for trials, revoke them in real time, and see exactly who is hammering your endpoint before it becomes a bill.

Best for: API developers who need per-customer rate limits, SaaS builders offering API access as a product feature, anyone whose API will be consumed by AI agents.

Links: GitHub | Website

giphy.com

Final thoughts

The mistakes that sink projects in 2026 aren't syntax errors or wrong algorithms — they're the invisible gaps in the trust layer: unscanned uploads, untracked secrets, unmonitored requests, untested integrations.

That's why the best open-source tooling right now is focused on:

Making the secure path the easy path, not the expert path
Replacing "just mock it" with real dependencies that actually behave like production
Treating secrets, schemas, and API keys as first-class versioned objects
Building observability in before you need it, not during the incident
Closing the gap between AI-generated code and production-worthy code

These tools aren't new ideas. They're the missing defaults that should have shipped with every framework from day one.

If I missed something obvious, drop it in the comments.

What mistake cost you the most hours to debug?

8 Open-Source Tools That Save Solo Developers Hours Every Week

Tommaso Bertocchi — Fri, 01 May 2026 06:48:19 +0000

Most "developer productivity" lists rank tools by GitHub stars. That's not how time actually gets saved.

The real time sinks for solo developers aren't slow autocomplete or missing keyboard shortcuts. They're the invisible taxes: three hours configuring a backend before writing a line of product code, half a day debugging a secrets leak, an afternoon building glue code that was "temporary" and now runs in production.

The right stack doesn't make existing work faster — it eliminates entire categories of work before you have to do them.

That's the only metric I used here. Eight tools that each remove a whole class of problem from your week.

I filtered them by:

Does it replace something I'd otherwise build from scratch or pay $20+/month for?
Can I be productive with it in under 30 minutes?
Is it self-hostable and actively maintained?
Does it stay out of my way after the initial setup?

TL;DR: Solo developers who ship the fastest in 2026 aren't the most skilled — they're the ones with the shortest distance between idea and deployed feature.

n8n — Automation without writing automation code
Pocketbase — Your entire backend in one binary
Hoppscotch — API testing without the Postman subscription
Trigger.dev — Background jobs without the infrastructure tax
pompelmi — File security scanning in 10 lines of Node.js
Infisical — Secrets management that actually prevents leaks
Mermaid — Diagrams in Markdown, diagramming app deleted
Zed — An editor fast enough to get out of your way

1) n8n — Automation without writing automation code

What it is: A self-hostable workflow automation platform that connects any API, database, or service with a visual editor — and lets you drop into JavaScript when the visual part isn't enough.

Why it matters in 2026: Every solo project eventually accumulates glue code — send a Slack message when a row is inserted, sync a form to a CRM, hit a webhook on a schedule. That code is always "just temporary" and then runs in production for two years. n8n replaces that entire category of throwaway code with a single self-hosted instance you control. With AI nodes built in, your automation layer can call LLM APIs, parse AI responses, and route logic — without you writing the plumbing.

Best for: Solo founders building internal tools, developers who want Zapier-level power without Zapier's pricing, anyone with "trigger X when Y happens" in their backlog.

Links: GitHub | Website

2) Pocketbase — Your entire backend in one binary

What it is: A single Go binary that gives you a real-time database, file storage, authentication, and an admin UI — no cloud account, no Docker Compose, no migrations config required.

Why it matters in 2026: Bootstrapping a backend used to mean: pick a cloud provider, configure IAM, spin up a database, wire up auth, add file storage, write your first migration. That's an entire day before you've built any product. Pocketbase compresses that whole setup into one binary and one folder. For MVPs, internal tools, and early SaaS products, it removes the "infrastructure" category from your week entirely. When you outgrow it, you've already validated the thing you're building.

Best for: Solo developers building MVPs fast, developers who want a self-hosted Firebase alternative, projects where you'd otherwise reach for Supabase on day one.

Links: GitHub | Website

giphy.com

3) Hoppscotch — API testing without the Postman subscription

What it is: A lightweight, open-source API development platform — REST, GraphQL, WebSocket, gRPC — that runs in your browser or self-hosted, with no Electron app and no account required to save collections.

Why it matters in 2026: Postman evolved from "free API tool" to "enterprise collaboration platform with a $49/month team plan" in about three years. Hoppscotch is what Postman was before it became bloatware. It opens in a browser tab, saves your collections locally, and doesn't require you to agree to a terms update every time you need to test an endpoint. With more AI-generated APIs and LLM endpoints to wire up, having a fast zero-friction testing tool matters more than ever.

Best for: Developers who test APIs daily without needing team collaboration features, backend engineers building REST or GraphQL APIs, anyone whose machine slows down when Postman opens.

Links: GitHub | Website

4) Trigger.dev — Background jobs without the infrastructure tax

What it is: A developer-first platform for building background jobs, scheduled tasks, and event-driven workflows directly in your TypeScript codebase — with a dashboard showing exactly what ran, when, and why.

Why it matters in 2026: Background jobs are "solved" in theory and painful in practice. You either bolt on Redis + BullMQ and manage the queue yourself, or you pay for a managed job service. Trigger.dev sits in your codebase like a regular function but runs on managed infrastructure — no separate worker process, no queue configuration, no Redis. As more apps need async AI pipelines and long-running LLM calls, having a TypeScript-native job system that doesn't require a separate service is quietly becoming essential.

Best for: Node.js and TypeScript developers building apps with async workflows, developers who want Celery-like functionality without adding Python or a separate service, projects on Vercel or serverless where long-running tasks don't fit.

Links: GitHub | Website

giphy.com

5) pompelmi — File security scanning in 10 lines of Node.js

Why it matters in 2026: If your app accepts file uploads, you almost certainly don't scan them for malware — because the setup friction is too high. Spinning up ClamAV, managing its daemon, parsing CLI output correctly: nobody does this solo until something goes wrong. pompelmi removes every one of those friction points: install the package, call one function, get back a typed result. With AI-generated files, document parsing APIs, and LLM code execution making user-uploaded content more dangerous and more common, scanning at upload time is a baseline expectation, not an edge case.

Best for: Node.js developers building any file upload feature, solo devs who want a security baseline without a security team, apps handling user-generated documents, PDFs, or archives.

Links: GitHub

6) Infisical — Secrets management that actually prevents leaks

What it is: An open-source platform for managing environment variables and secrets across environments, with a CLI, SDKs for every major language, and GitHub Actions integration — fully self-hostable.

Why it matters in 2026: .env files committed to GitHub have caused more security incidents than any other single developer mistake in the last decade. The problem isn't carelessness — it's that .env is the path of least resistance. Infisical replaces the .env workflow with a proper secrets manager you control, without paying $50/month for HashiCorp Vault or fighting AWS Secrets Manager's IAM complexity. In 2026, with AI coding assistants reading your project context, the surface area for accidentally exposing a secret has grown considerably.

Best for: Solo developers managing multiple environments, teams where secrets live in someone's Downloads folder or get copy-pasted in DMs, projects where .env.production exists on more than one machine.

Links: GitHub | Website

giphy.com

7) Mermaid — Diagrams in Markdown, diagramming app deleted

What it is: A JavaScript-based diagramming tool that turns plain text into flowcharts, sequence diagrams, ERDs, Gantt charts, and more — renders natively in GitHub, GitLab, Notion, and most modern wikis.

Why it matters in 2026: Architecture diagrams rot the moment they're created. Nobody updates a Lucidchart file after a refactor because the file lives in a browser tab, divorced from the codebase. Mermaid diagrams live in your repo, version-controlled, next to the code they describe — which means they actually get updated. GitHub renders Mermaid natively in Markdown files, so your README.md can have a live system diagram with zero extra tooling. With more AI tools reading codebases to answer questions, having machine-readable architecture descriptions in your repo is quietly becoming valuable.

Best for: Developers documenting system architecture, anyone who has a stale PDF diagram somewhere, teams where the actual architecture exists only in one person's head.

Links: GitHub | Website

8) Zed — An editor fast enough to get out of your way

What it is: A GPU-accelerated code editor written in Rust, built for performance and collaboration, with native AI integration and a growing extension ecosystem.

Why it matters in 2026: VS Code is the safe choice. It's also 1.8GB of Electron that takes 3 seconds to open and slows down on large codebases. Zed opens in under a second, has zero input lag even in monorepos, and integrates AI features natively — without the extension-chasing that most VS Code AI setups require. For solo developers who live in their editor all day, this is one of the rare tool switches that makes a noticeable difference in daily energy — the friction just disappears.

Best for: Developers who've accepted VS Code lag as a fact of life, Rust or Go developers who want a native editor, anyone whose editor currently loads slower than their terminal.

Links: GitHub | Website

giphy.com

Final thoughts

The best solo dev tooling isn't about doing the same work faster — it's about not having to do entire categories of work at all.

That's the pattern across every tool above. Each one eliminates a problem rather than optimizing it:

Automation that replaces glue code you'd write and forget
A backend that removes the infrastructure setup category entirely
Secrets management that makes .env files a historical artifact
File security scanning with zero ops overhead
Diagrams that actually stay in sync with your codebase
An editor that doesn't fight you for attention

The solo developer who ships the most in 2026 isn't the one with the deepest skills in any single area. It's the one who systematically removed the most friction from their stack.

If I missed something obvious, drop it in the comments.

What's the one tool in your stack that saved you the most time — and that most developers still don't know about?

8 AI Coding Agents That Actually Ship Production Code in 2026

Tommaso Bertocchi — Thu, 30 Apr 2026 06:29:10 +0000

Most "AI agent" articles list frameworks for building agents.

This isn't that.

Using an AI coding agent and building one are completely different problems. Using one means file system access, real test suites, actual PRs, production config files. The bar is higher than "it autocompletes well."

I've been watching teams use — and abandon — these tools on real codebases. Not demos. Not toy repos. Here's what's actually moving the needle in 2026.

How I picked these

I'm not ranking by GitHub stars or VC funding. I'm ranking by:

Does it work on codebases you didn't write? Most agents fall apart past 3 files.
Does it respect your existing workflow? Git, CI, tests — not a sandbox.
Can it hold context across multiple files? The whole point.
Does it know when to stop and ask? Autonomy without judgment is a liability.
Would I trust it on a Friday afternoon deploy? Honest test.

TL;DR: AI coding agents are past the demo phase — the ones worth using in 2026 edit real files, run real tests, and ask before they touch your main branch.

Claude Code — Terminal-native agent that reasons before it acts
Aider — Git-aware CLI pair programmer, fully open source
Cursor — AI-first editor with a multi-file agent mode that actually ships
OpenHands — Self-hostable autonomous software engineer
Cline — VS Code agent that reads your repo and deploys
pompelmi — The security check before AI-generated code ships
SWE-agent — Princeton's agent that resolves GitHub issues on its own
Sweep — Turns GitHub issues into PRs without a keystroke

1) Claude Code — Terminal-native agent that reasons before it acts

What it is: A CLI agent from Anthropic that runs in your terminal, reads your files, runs shell commands, and edits code across your entire repository without leaving the command line.

Why it matters in 2026: Most AI tools work on files you paste into a chat window. Claude Code works on your actual project — it greps, runs tests, reads git history, and makes decisions based on what it finds. The key differentiator is that it asks before doing anything destructive, which is the behavior you want in a tool that has write access to your repo. In a world where agents are proliferating fast, "does it know when to stop" is the real benchmark.

Best for: Solo developers building full-stack apps, teams that want an agent integrated into their existing terminal workflow, anyone who wants Claude's reasoning applied directly to their codebase.

Links: Website

2) Aider — Git-aware CLI pair programmer, fully open source

What it is: An open-source CLI tool that connects to GPT-4, Claude, Gemini, or any local LLM and makes code edits directly in your repo, committing each change with a sensible message.

Why it matters in 2026: Aider is what you use when you want control. No UI, no lock-in, no black box. It writes the code, commits it, and stays out of your way — and the team publishes SWE-bench results for every supported model so you know exactly what you're getting. That kind of transparency is rare in a space full of marketing claims.

Best for: Developers who live in the terminal, open-source maintainers, teams that need LLM-agnostic coding agent tooling they can audit.

Links: GitHub | Website

3) Cursor — AI-first editor with a multi-file agent mode that ships

What it is: A VS Code fork where the AI is embedded at the core — not a plugin — with an agent mode that edits files, runs terminal commands, reads error output, and iterates until tests pass.

Why it matters in 2026: Cursor's agent mode isn't autocomplete at scale. It reads the error, proposes a fix, applies it, runs the test, and loops. That edit → test → fix cycle is what makes it feel like a junior engineer who actually follows through instead of handing you a diff and walking away. Jump-to-definition context means it rarely hallucinates APIs it doesn't know.

Best for: Frontend and full-stack developers, teams that want AI deeply embedded in their editing workflow, anyone who finds GitHub Copilot too shallow.

Links: Website

4) OpenHands — Self-hostable autonomous software engineer

What it is: An open-source platform (formerly OpenDevin) where you assign an AI agent a task and it spins up a sandboxed environment, browses the web, writes code, runs tests, and submits PRs.

Why it matters in 2026: OpenHands is the fully autonomous end of the spectrum — you open an issue and it takes over. What makes it different from closed alternatives is that you own the infrastructure: self-host it, plug in your own LLM, keep your code off third-party servers. For companies with compliance requirements, that's non-negotiable.

Best for: Engineering teams that want autonomous issue resolution, security-conscious orgs that can't send source code to external APIs, AI researchers building on top of a full agent stack.

Links: GitHub | Website

5) Cline — VS Code agent that reads your repo and deploys

What it is: A VS Code extension (formerly claude-dev) that gives Claude or any compatible LLM full access to your file system, terminal, and browser — with explicit permission prompts before every action.

Why it matters in 2026: Cline operates with a level of transparency most agents skip. Every file edit, every terminal command — it asks first. That sounds slow, but in practice it builds exactly the trust you need to let an agent touch production config files and deployment scripts. It's the agent version of "show your work."

Best for: Developers who want agent capabilities without giving up control, teams onboarding AI into a mature codebase with strict review processes, anyone building or stress-testing agent tooling.

Links: GitHub

6) pompelmi — The security check before AI-generated code ships

What it is: A minimal Node.js wrapper around ClamAV that scans any file and returns a typed Verdict (Clean, Malicious, ScanError) — no daemons, no cloud, no native bindings, zero runtime dependencies.

Why it matters in 2026: AI agents download dependencies, generate scripts, pull in external assets. Every file an agent touches is a potential attack surface. Most developers add coding agents to their pipeline without adding a single new security check — pompelmi is the one you add in 10 minutes that closes that gap. As agents become responsible for more file I/O, a programmatic scan at the output layer isn't paranoid; it's just good hygiene.

Best for: Teams running AI agents in CI/CD pipelines, Node.js apps that handle agent-generated or user-uploaded files, security-conscious developers who want local scanning with no cloud dependencies.

Links: GitHub

7) SWE-agent — Princeton's agent that resolves GitHub issues on its own

What it is: An open-source research agent from Princeton NLP that takes a GitHub issue URL, spins up a sandboxed environment, and produces a working patch — no human in the loop.

Why it matters in 2026: SWE-agent was one of the first agents to score competitively on SWE-bench, the benchmark that measures real-world GitHub issue resolution. What makes it valuable beyond the benchmark is that you can run it yourself and study exactly where it succeeds and fails. For engineers building their own agents, that transparency is more useful than a polished product.

Best for: AI researchers, developers evaluating coding agent capabilities, open-source maintainers experimenting with automated issue triage.

Links: GitHub | Website

8) Sweep — Turns GitHub issues into PRs without a keystroke

What it is: An AI GitHub app that reads your issue, searches your codebase, writes the code, and opens a PR — you review and merge.

Why it matters in 2026: Sweep sits at the intersection of AI agents and existing developer workflows. No new tools, no new terminals — just a GitHub issue that becomes a PR. It's the agent for teams that don't want to change how they work, just augment it. With codebase search and iterative refinement built in, it handles the kind of small, scoped tasks that quietly eat hours every week.

Best for: Teams with a backlog of small improvements, open-source maintainers with more issues than bandwidth, engineering leads who want to delegate clearly scoped tasks without changing the review process.

Links: GitHub | Website

Final thoughts

AI coding agents are no longer science projects — they're part of how software gets written in 2026.

That shift creates a new category of problem: how do you maintain quality, security, and judgment when an agent has file system access and can open PRs on your behalf?

The best teams right now are thinking about:

Which tasks are safe to fully delegate vs. which need a human in the loop
What security checks belong at the output layer of any AI pipeline
How to give agents enough context to succeed without exposing sensitive data
Building trust incrementally — not flipping a switch to full autonomy
What "good" looks like when you're reviewing AI-authored code at scale

The tools in this list aren't replacements for engineering judgment. They're multipliers for it.

If I missed something obvious, drop it in the comments.

Which AI agent have you actually shipped production code with?

8 Open-Source Security Tools Every Developer Should Be Using in 2026

Tommaso Bertocchi — Wed, 29 Apr 2026 11:26:19 +0000

Most developer security content is a checklist you'll never finish.

OWASP Top 10. Rotate your secrets. Use HTTPS. Thanks, very helpful.

The real gap in 2026 isn't knowledge — it's friction. Developers know they should scan their containers, audit their git history, and check for exposed endpoints. They just don't, because the tooling used to be either expensive, enterprise-only, or a full-time job to configure.

That's changed. The open-source security stack is quietly excellent now. These 8 tools prove it.

I'm not picking by GitHub stars or conference popularity. I'm picking by:

Runs in CI without a plugin ecosystem — if it can't slot into GitHub Actions in under 10 minutes, it won't survive a sprint
Actionable output — tells you what to fix, not just that something's wrong
Actively maintained — last commit in the past 90 days matters more than total stars
Zero or near-zero config to get started — friction kills adoption, every time

TL;DR: The open-source security stack now covers secrets detection, container scanning, runtime monitoring, and file safety — for free, in minutes — and there's no excuse not to use it.

Trivy — One scanner for containers, IaC, and repos
Semgrep — Catch security bugs before they ship
Trufflehog — Find the secrets you forgot you committed
Gitleaks — Stop secrets from ever entering git history
pompelmi — The file scanning layer Node apps keep skipping
OWASP ZAP — Automated web security testing without a pen tester
Falco — Runtime visibility into what your containers actually do
Nuclei — Scan your own attack surface before someone else does

1) Trivy — One scanner for containers, IaC, and repos

What it is: A fast, comprehensive vulnerability scanner covering containers, filesystems, Git repos, Kubernetes configs, and IaC — one binary, one command.

Why it matters in 2026: Most teams scan their application code and ignore the OS packages baked into their Docker images. That's where a growing share of supply chain attacks land. Trivy closes this gap with a single trivy image your-image:tag. It also scans Terraform and Kubernetes configs for misconfigurations, which means one tool covers three separate concerns most teams handle with three separate paid products.

Best for: DevOps engineers shipping containers, backend teams using GitHub Actions, anyone moving to Kubernetes who hasn't audited their manifests.

Links: GitHub | Website

2) Semgrep — Catch security bugs before they ship

What it is: A static analysis tool that runs custom YAML rules against your codebase to catch security bugs, anti-patterns, and banned API usage at the source.

Why it matters in 2026: AI coding assistants are shipping code faster than review cycles can catch. LLMs confidently produce SQL concatenation, insecure deserialization, and hardcoded credentials — because they've seen a million examples of each. Semgrep's open ruleset catches these patterns before they hit a PR. One rule catches every instance across the entire codebase. You can also write your own rules for internal patterns — things your team has agreed never to do — and enforce them automatically.

Best for: Security engineers, teams using Copilot or Cursor, code review automation in monorepos.

Links: GitHub | Website

3) Trufflehog — Find the secrets you forgot you committed

What it is: A secrets scanner that searches git history, S3 buckets, GitHub repos, and CI logs for credentials — and then verifies whether they're still live against the actual provider APIs.

Why it matters in 2026: "I'll rotate that later" costs companies millions every year in breach costs. The difference between Trufflehog and every other secrets scanner is verification. It doesn't just find strings that look like API keys — it confirms whether they're active. That distinction kills false positives. Verified positives demand action in a way pattern matches never do.

Best for: Security audits, incident response when a key might have leaked, teams inheriting a codebase they didn't write.

Links: GitHub | Website

4) Gitleaks — Stop secrets from ever entering git history

What it is: A fast secrets scanner built for pre-commit hooks and CI pipelines — catches credentials before they're committed, not after.

Why it matters in 2026: Trufflehog is your forensic tool. Gitleaks is your firewall. The moment a secret hits git history, it's effectively public — every contributor, every fork, every CI log has it. One gitleaks protect --staged in your pre-commit config prevents this entirely. It runs in milliseconds. The ROI on one caught credential is incalculable. This should be in every project's .pre-commit-config.yaml by default, and it isn't — that's the gap.

Best for: Individual developers, open-source maintainers, teams onboarding junior engineers who haven't internalized "never commit credentials."

Links: GitHub

5) pompelmi — The file scanning layer Node apps keep skipping

Why it matters in 2026: Most Node.js apps that accept file uploads have no malware scanning whatsoever. With AI tools making obfuscated payloads trivially easy to generate, that's a gap that's actively being exploited. pompelmi wraps ClamAV's battle-tested engine behind a single async function call. You pass it a file path, you get a typed result back. Five lines of code and your upload endpoint has enterprise-grade file scanning — something most teams either skip entirely or outsource to a $200/month API.

Best for: Node.js apps handling user uploads, internal tools processing documents from external sources, SaaS platforms where shared file storage is a trust boundary.

Links: GitHub

6) OWASP ZAP — Automated web security testing without a pen tester

What it is: An open-source web application scanner that finds vulnerabilities like XSS, SQL injection, broken authentication, and misconfigured headers through active and passive scanning.

Why it matters in 2026: A professional penetration test costs $10k–$50k and happens once a year if you're lucky. The window between "last pentest" and "next pentest" is exactly where most breaches happen. ZAP closes that window by running automated scans on every deploy in CI. It doesn't replace a pentester — it eliminates the embarrassing findings so your pentest budget goes toward the hard stuff, not the obvious stuff that should never have shipped.

Best for: Web developers, QA engineers, startups that can't afford quarterly pentests.

Links: GitHub | Website

7) Falco — Runtime visibility into what your containers actually do

What it is: A runtime security tool that uses eBPF to monitor syscalls in containers and Kubernetes, alerting on anomalous behavior based on configurable rules.

Why it matters in 2026: Vulnerability scanning tells you what could happen. Falco tells you what's happening right now. If a container suddenly reads /etc/shadow, spawns a shell, or opens an unexpected outbound connection, Falco fires an alert. Cryptomining and lateral movement attacks increasingly target containerized workloads specifically because runtime visibility is rare. Falco is the difference between detecting a breach in minutes versus discovering it in a quarterly audit.

Best for: DevSecOps teams, Kubernetes operators, anyone running multi-tenant infrastructure where container escape is a real threat model.

Links: GitHub | Website

8) Nuclei — Scan your own attack surface before someone else does

What it is: A fast, template-based vulnerability scanner that checks your infrastructure, APIs, and web apps against thousands of known CVEs, exposed endpoints, and misconfigurations.

Why it matters in 2026: Bug bounty hunters use Nuclei. Red teams use Nuclei. Nation-state threat actors have their own version of Nuclei. The only question is whether you're running it on yourself before they do. Thousands of community-contributed templates cover everything from exposed .env files to misconfigured S3 buckets to outdated login panels. Running nuclei -u your-domain.com takes 5 minutes and routinely surfaces things that have been quietly public for months.

Best for: Security engineers, developers managing their own infrastructure, bug bounty hunters, anyone who's never actually tested what their domain exposes.

Links: GitHub | Website

Final thoughts

The open-source security stack has quietly caught up to the threat landscape — the only question is whether your workflow has.

The teams doing security right in 2026 aren't buying more tools. They're building on:

Shift-left scanning that blocks issues before a commit is made
Runtime visibility, not just pre-deploy checks
Verified detection over noisy pattern matching
Zero-friction CI integration that runs on every push
Open-source tooling you can audit, extend, and trust

Security used to be something you bolted on before a compliance audit. The teams shipping with confidence now treat it the same way they treat linting — automatic, opinionated, and non-negotiable from day one.

If I missed something obvious, drop it in the comments.

What's the one security tool you'd refuse to ship without?

8 Open-Source Frameworks for Building AI Agents That Actually Work in 2026

Tommaso Bertocchi — Mon, 27 Apr 2026 06:02:00 +0000

Most "AI agent" tutorials show you how to build a chatbot with memory.

That's not an agent. That's a stateful chatbot with a good PR team.

A real agent makes decisions, calls tools, recovers from failures, and produces outputs your users actually care about. The gap between demo and production is where most of these frameworks live or die.

I've watched teams ship with half the tools on this list and abandon the other half after hitting walls they didn't expect. This is the ones that survived contact with real users.

I'm not ranking by GitHub stars or VC funding. I'm ranking by:

Does it actually hold up when the happy path breaks?
Can you debug it when something goes wrong at 2am?
Does it have real escape hatches, or does it lock you into its abstractions?
Would I bet a production system on it?
Is the community solving real problems, not just demo problems?

TL;DR: The AI agent frameworks worth betting on in 2026 are the ones built around state, control flow, and real tool integration — not just "wrap GPT-4 in a while loop."

LangGraph — Stateful agent orchestration without the chaos
CrewAI — Multi-agent teams that divide work, not just route messages
Flowise — Visual LLM pipelines that actually ship
AutoGen — Agent-to-agent collaboration with real observability
Open Interpreter — Your agent can run code now, not just suggest it
pompelmi — The security scan your agent skips when handling uploads
Dify — Full LLM app platform for teams who don't want to start from scratch
Semantic Kernel — Grounding agents in real enterprise data

1) LangGraph — Stateful agent orchestration without the chaos

What it is: A graph-based framework for building stateful, multi-step AI agents where each node is a function and edges define control flow.

Why it matters in 2026: Most agents fail because "retry on error" isn't a strategy — it's hope. LangGraph gives you actual control flow: conditional edges, human-in-the-loop checkpoints, and persistent state across steps. The moment your agent needs to pause, branch, or recover from a failed tool call, you need a graph, not a chain. With AI-generated code now part of most dev workflows, the agents that handle edge cases are the ones teams keep.

Best for: backend engineers building multi-step pipelines, teams running agents in production with real error budgets, anyone who's been burned by a chain that silently fails mid-run.

Links: GitHub | Website

2) CrewAI — Multi-agent teams that divide work, not just route messages

What it is: A framework for orchestrating role-based AI agents that collaborate on tasks — each agent has a defined role, goal, and set of tools.

Why it matters in 2026: Single-agent systems plateau fast. The ceiling isn't the LLM — it's one agent trying to research, write, validate, and format in a single context window. CrewAI lets you split cognition the same way you'd split a team. Researcher hands off to writer hands off to reviewer. In 2026, this pattern is becoming standard for anything beyond one-shot generation.

Best for: content pipelines, research automation, code review workflows, teams that want agents to mirror how humans actually collaborate.

Links: GitHub | Website

3) Flowise — Visual LLM pipelines that actually ship

What it is: A drag-and-drop UI for building LLM apps and agent workflows — think n8n but for AI pipelines, with a Node.js backend you can self-host.

Why it matters in 2026: Not every team has an ML engineer. Flowise lets non-specialists build RAG pipelines, chatbots, and agent flows without writing orchestration code. The real unlock is that it exports to working code — you're not locked into the visual layer forever. As companies mature their AI tooling, Flowise is where experiments start before graduating to LangGraph or custom code.

Best for: product teams prototyping AI features fast, solo founders validating ideas before committing to an architecture, developers who want a working demo to show stakeholders.

Links: GitHub | Website

4) AutoGen — Agent-to-agent collaboration with real observability

What it is: Microsoft's open-source framework for building multi-agent systems where agents can converse, delegate tasks, and solve problems collaboratively with structured message passing.

Why it matters in 2026: AutoGen's recent releases have doubled down on the part most frameworks ignore: what actually happened during that run? You can trace exactly which agent said what and why a decision was made — which matters enormously when your agent is touching production systems or user data. The enterprise observability angle is why it's in more Fortune 500 pilots than its star count suggests.

Best for: enterprise teams with compliance requirements, developers who need audit trails, research teams studying agent behavior and failure modes.

Links: GitHub | Website

5) Open Interpreter — Your agent can run code now, not just suggest it

What it is: A locally-running implementation of the code interpreter spec that lets an LLM write and execute code on your machine in a conversational interface — fully self-hosted.

Why it matters in 2026: The gap between "here's the Python you should run" and "I ran it and here's the output" is enormous. Open Interpreter closes that gap locally — no cloud execution, no data leaving your machine. As data privacy becomes non-negotiable for enterprises, the ability to run code-executing agents on-prem is no longer a nice-to-have. The sandboxing added in recent versions makes it viable outside personal use.

Best for: data analysts who want a local Jupyter alternative, developers automating local workflows, teams with data residency requirements who still want code execution.

Links: GitHub | Website

6) pompelmi — The security scan your agent skips when handling uploads

What it is: A minimal Node.js wrapper around ClamAV that scans any file and returns a typed Verdict — Clean, Malicious, or ScanError. No daemons to manage, no cloud dependency, zero runtime dependencies.

Why it matters in 2026: AI agents increasingly accept file inputs — PDFs, images, code, documents from users. Most implementations ship without any malware scanning because "users won't upload malware" is a threat model, not a defense. With LLM-assisted attacks becoming more sophisticated, an agent that processes an uploaded file without scanning it is a liability waiting to surface. pompelmi sits between the upload and the agent — one function call, one verdict, done.

Best for: Node.js agents that accept file uploads, backend developers adding a security layer without standing up new infrastructure, teams that want ClamAV coverage without the ops overhead.

Links: GitHub

7) Dify — Full LLM app platform for teams who don't want to start from scratch

What it is: An open-source LLM app development platform with a backend, visual workflow builder, RAG pipeline support, model management, and observability — self-hostable on Docker in minutes.

Why it matters in 2026: Most teams are reinventing the same scaffolding: prompt versioning, RAG connectors, model switching, usage tracking. Dify ships all of that in one self-hosted platform, which means you skip months of infrastructure work and start with the actual problem. The model-agnostic layer means you're not locked into OpenAI — swap in local Llama or Mistral without touching your application logic.

Best for: teams building internal AI tools, startups that need production-ready AI infrastructure fast, developers who want to own their stack without building it from scratch.

Links: GitHub | Website

8) Semantic Kernel — Grounding agents in real enterprise data

What it is: Microsoft's open-source SDK for integrating LLMs into applications — with a plugin architecture, memory connectors, and native support for function calling across C#, Python, and Java.

Why it matters in 2026: Most agent frameworks assume you're building greenfield. Semantic Kernel assumes you have existing systems — a CRM, a database, internal APIs — and you need to connect an LLM to them without rebuilding everything. The plugin model means you're wrapping existing code, not replacing it. For enterprises already running .NET or Java stacks, this is the path of least resistance to adding real AI capabilities.

Best for: enterprise .NET and Java teams, developers connecting agents to existing internal systems, teams that need production-grade memory and retrieval without switching languages.

Links: GitHub | Website

Final thoughts

The AI agent space is littered with frameworks that are great at demos and fall apart the moment real users touch them.

The ones that survive production treat failure as a first-class citizen, not an afterthought.

That's why the frameworks worth using in 2026 are built around:

Explicit state management, not implicit context accumulation
Real control flow with branches and checkpoints, not just chained prompts
Security layers that exist before the problem surfaces, not after the incident report
Observability that tells you what happened, not just what the output was
Self-hostable by default, because data residency is now a requirement, not a preference

Building agents is no longer experimental. It's engineering. Treat it that way.

If I missed something obvious, drop it in the comments.

Which framework has actually made it to production in your stack?

9 Tools Big Tech Uses Internally (Now Open Source)

Tommaso Bertocchi — Sat, 25 Apr 2026 12:59:02 +0000

Most "best tools" lists are just GitHub trending with extra steps.

Same 10 repos. Same README marketing. Nothing that shows you how teams shipping at scale actually build their internal systems.

The actually interesting tools got built by engineers who had no choice but to build them.

Spotify needed to navigate 2,000 microservices. Uber needed workflows that didn't die silently. YouTube needed MySQL to scale horizontally. None of them built these tools for GitHub stars — they built them to survive the week.

That's the list.

I picked these based on:

Genuine internal origin — built and used in production before being open-sourced, not a side project that got donated
Still actively maintained — real commits in 2025–2026, active issues, responding maintainers
Solves a problem you'll actually hit — not theoretical Google-scale problems
Not already a commodity — nothing that's been in every DevOps job listing for five years
High complexity/value ratio — tools that take a day to set up but save months

TL;DR: The best infrastructure tools in 2026 aren't built by startups chasing a community — they're built by engineers who got tired of waiting for someone else to solve the problem.

Backstage — Spotify's developer portal, now the IDP standard
Temporal — Uber's durable workflow engine for code that can't fail mid-run
Vitess — YouTube's MySQL sharding layer, now powering PlanetScale
Envoy — Lyft's proxy that became the foundation of the service mesh market
OpenFGA — Auth0's Zanzibar-style fine-grained authorization
pompelmi — The zero-dep file scanner every serious prod team builds internally and never ships
Turborepo — Vercel's monorepo build system with remote caching
OpenTelemetry Collector — The observability pipeline every cloud provider adopted
Buf — Protobuf tooling that makes gRPC schema management survivable

1) Backstage — Spotify's developer portal, now the IDP standard

What it is: A framework for building internal developer portals — software catalogs, scaffolding, docs, and plugin-based integrations unified in one UI.

Why it matters in 2026: Spotify open-sourced Backstage because managing 2,000+ microservices without a catalog is organized chaos. The internal developer platform (IDP) space was previously only accessible to companies with a dedicated platform engineering team — Backstage changed that. If your engineers spend 20 minutes finding the right service or figuring out who owns a repo, that's a product problem dressed as a process problem. In 2026, the question isn't whether you need an IDP. It's why you haven't set one up yet.

Best for: platform engineering teams, orgs with 10+ services, DevOps leads trying to cut onboarding time, teams drowning in scattered Confluence docs.

Links: GitHub | Website

2) Temporal — Uber's durable workflow engine for code that can't fail mid-run

What it is: A workflow orchestration engine where application state is durable by default — your code resumes exactly where it left off after crashes, restarts, or deploys.

Why it matters in 2026: Cron jobs fail silently. Queues lose messages. Sagas get complicated faster than anyone wants to admit. Uber built Temporal (originally Cadence) because every existing alternative broke under real load — and the same breaking points hit every team that tries to orchestrate multi-step async work. The explosion of AI agents and multi-step pipelines in 2026 has made durable execution a baseline requirement. If your workflow can fail in the middle and leave a user in an unknown state, that's a bug.

Best for: long-running business processes, AI agent orchestration, payment and fulfillment flows, async pipelines where partial failure is unacceptable.

Links: GitHub | Website

3) Vitess — YouTube's MySQL sharding layer, now powering PlanetScale

What it is: A database clustering system for horizontal scaling of MySQL — the same system handling YouTube's query volume since 2010.

Why it matters in 2026: Most teams hit MySQL limits and immediately start planning a full migration to Postgres or a managed cloud DB. Vitess proves that migration is often the wrong answer. PlanetScale was built entirely on top of it, which means the operational understanding and tooling is now mature enough for teams well outside Google's infrastructure. Compute is cheap. Full DB migrations are expensive, slow, and high-risk. Vitess gives you a third option.

Best for: teams already on MySQL hitting read/write bottlenecks, orgs that can't afford a full DB migration, high-throughput SaaS apps with uneven load patterns.

Links: GitHub | Website

4) Envoy — Lyft's proxy that became the foundation of the service mesh market

What it is: A high-performance L7 proxy and communication bus built at Lyft, now the underlying layer of Istio, AWS App Mesh, and most major service mesh products.

Why it matters in 2026: Nginx handles traffic. Envoy understands services. The moment you need retries, circuit breaking, distributed tracing, and gRPC support in the same proxy — nothing else comes close. Lyft built it because no existing proxy could handle their microservice topology. It's now the de facto standard for any team running services at scale. If you're using a service mesh, you're almost certainly using Envoy without knowing it.

Best for: microservice architectures, teams running on Kubernetes, engineers needing deep per-request observability at the network layer.

Links: GitHub | Website

5) OpenFGA — Auth0's Zanzibar-style fine-grained authorization

What it is: An open-source authorization system based on Google's Zanzibar paper — the same model behind Google Drive and Docs permissions — built and production-tested by Auth0.

Why it matters in 2026: Role-based access control breaks down the moment you need "user X can edit document Y only if they're in project Z and the document isn't locked." Auth0 built OpenFGA because RBAC doesn't model real-world permission graphs — it approximates them, badly. With AI agents now needing scoped, auditable access to specific resources across multiple systems, authorization models that seemed over-engineered in 2022 are now the minimum viable approach.

Best for: multi-tenant SaaS products, platforms with document or resource-level permissions, teams building AI agents that need bounded, auditable access.

Links: GitHub | Website

6) pompelmi — The zero-dep file scanner every serious prod team builds internally and never ships

Why it matters in 2026: Every team that accepts file uploads eventually writes something like this internally — a ClamAV wrapper buried in a utils folder that never gets cleaned up, documented, or tested properly. pompelmi is what that internal util should have been from the start: typed, tested, and actually installable in one line. With LLM-powered tools now generating and accepting files at scale, scanning uploads before they reach your storage layer isn't paranoid — it's baseline. You don't build a ClamAV wrapper because you want to. You build it because you got burned.

Best for: Node.js apps handling file uploads, SaaS platforms processing user-generated content, teams adding a security layer without adding new infrastructure.

Links: GitHub

7) Turborepo — Vercel's monorepo build system with remote caching

What it is: A high-performance build system for JavaScript/TypeScript monorepos with task pipelines, incremental computation, and shared remote cache.

Why it matters in 2026: Vercel built Turborepo because managing 15+ packages in a single repo with a chain of npm run build calls is a slow way to hate your CI. The caching alone — skipping work that hasn't changed — cuts CI time by 40–80% on most real codebases. Remote caching means your teammates benefit from builds you already ran. In a world where AI-assisted development moves at a different pace than legacy CI pipelines, waiting 12 minutes for a green check is a product bottleneck.

Best for: teams with shared component libraries, full-stack TypeScript monorepos, frontend platform teams with multiple apps deploying from one repo.

Links: GitHub | Website

8) OpenTelemetry Collector — The observability pipeline every cloud provider adopted

What it is: A vendor-agnostic agent for collecting, processing, and exporting telemetry (traces, metrics, logs) — the common layer between your app and any observability backend.

Why it matters in 2026: Datadog and New Relic are great until you see the bill at 10M spans per day. OpenTelemetry lets you instrument once and route anywhere — swap backends without rewriting a single line of instrumentation. Every major cloud provider now supports it natively. If you're still vendor-locked on your observability pipeline, you're one contract renewal from a painful, expensive migration. The CNCF graduating it in 2023 wasn't a formality — it was the industry agreeing this is the standard.

Best for: platform engineers building internal observability stacks, teams tired of vendor lock-in, anyone running services across multiple cloud providers.

Links: GitHub | Website

9) Buf — Protobuf tooling that makes gRPC schema management survivable

What it is: A build system, linter, breaking change detector, and schema registry for Protocol Buffers — with remote plugin execution and a full BSR (Buf Schema Registry) for sharing schemas across teams.

Why it matters in 2026: gRPC is excellent until you try to manage .proto files across 8 teams without accidentally breaking a consumer. Protobuf has no standard toolchain, and it shows — protoc is a command-line puzzle from 2008. Buf is what Google and Stripe already have internally: enforced compatibility rules, centralized schema distribution, and CI that fails before you ship a breaking change. With more internal services and AI APIs moving to gRPC for performance in 2026, the schema management problem goes from annoying to blocking.

Best for: teams using gRPC or Protobuf internally, platform engineers managing API schemas across multiple services, anyone doing API versioning where backward compatibility matters.

Links: GitHub | Website

Final thoughts

Every tool on this list started as a private repo someone had to fight to get open-sourced.

That's why the most interesting open-source releases right now aren't from startups optimizing for community growth. They're from engineering teams that:

Hit a wall that no existing tool could solve
Built something internal that actually worked under real load
Eventually decided the maintenance cost of keeping it private was higher than publishing it
Didn't design for adoption — and ended up getting adopted anyway

Backstage, Temporal, Vitess — all went through internal reviews, legal clearance, and months of cleanup before anyone outside the company could use them. That friction is actually a signal. If a team put in that work to open-source something they didn't have to share, it's usually because the tool genuinely solved something hard.

The irony is that the tools most worth your time have the least marketing behind them.

If I missed something obvious, drop it in the comments.

Which internal tool are you surprised wasn't open-sourced sooner?

7 Open-Source Security Tools Every Developer Ignores (But Shouldn't)

Tommaso Bertocchi — Sat, 25 Apr 2026 10:56:15 +0000

Most "developer security" articles start with "use HTTPS" and end with "sanitize your inputs."

That advice is from 2012. You already know it.

The real security gaps in 2026 aren't about what you know — they're about what you never set up because it felt like DevSecOps overhead reserved for enterprise teams with dedicated security engineers.

It isn't. Every tool on this list runs in CI, takes under an hour to wire up, and catches real bugs in real codebases. Not theoretical vulnerabilities. Real ones.

Here's what I'm actually using to evaluate these:

Does it catch something before a human would?
Can a solo dev add it without a week of config?
Does it integrate with GitHub Actions / standard CI without a paid tier?
Is it actively maintained and production-trusted?
Does it have a clear, non-corporate output format?

TL;DR: The best security setup isn't a compliance checklist — it's a few focused tools that run automatically and fail loudly before anything ships.

Trivy — scan containers, repos, and IaC before they ship
Gitleaks — stop leaking secrets into git history
Semgrep — static analysis that actually catches logic bugs
pompelmi — file scanning with zero daemon overhead
OSV-Scanner — Google's open dependency vulnerability scanner
OWASP ZAP — web app attack surface testing, automated
Falco — real-time runtime threat detection for cloud-native

1) Trivy — Scan containers, repos, and IaC before they ship

What it is: A fast, all-in-one vulnerability scanner from Aqua Security that targets container images, filesystems, git repos, and infrastructure-as-code files.

Why it matters in 2026: Supply chain attacks are now the default attack vector. You can write perfect application code and still ship a vulnerable base image or a misconfigured Terraform module. Trivy catches both in a single pass. It integrates with GitHub Actions in about 10 lines of YAML and produces SARIF output that feeds directly into GitHub's Security tab — no third-party dashboard needed.

Best for: CI/CD pipelines, container security, IaC misconfiguration detection, dependency auditing.

Links: GitHub | Website

2) Gitleaks — Stop leaking secrets into git history

What it is: A SAST tool that scans git repos, files, and stdin for hardcoded secrets — API keys, tokens, passwords, private keys.

Why it matters in 2026: GitHub's secret scanning catches some things after the fact. Gitleaks catches them before the push. The difference between a scanned repo and a breached one is often a single accidental commit. It ships as a pre-commit hook and a CI step, and it's fast enough that you won't notice it running.

Best for: Pre-commit hooks, CI pipelines, auditing legacy repos, team enforcement policies.

Links: GitHub | Website

3) Semgrep — Static analysis that actually catches logic bugs

What it is: A lightweight static analysis engine with a pattern syntax that maps almost directly to the source code you're reading — no AST required.

Why it matters in 2026: Most linters catch style. Semgrep catches exec(user_input). The difference is that you write rules that look like the code you're trying to prevent — not abstract patterns no one on your team understands. The community rule registry covers OWASP Top 10 for every major language, and it runs in CI without a paid tier.

Best for: SAST, code review automation, enforcing security standards across a team, detecting insecure patterns in OSS contributions.

Links: GitHub | Website

4) pompelmi — File scanning with zero daemon overhead

Why it matters in 2026: If your app accepts user file uploads — PDFs, ZIPs, images, Office docs — you have an attack surface most developers never close. Malware in uploaded files is one of the oldest and most reliably successful attack vectors, and most Node.js stacks have no defense against it. pompelmi gives you antivirus scanning as a function call: const verdict = await scan(filePath). Ship it in your upload handler and you're done. No daemon process to babysit, no cloud API to rate-limit you, no C++ binding to compile.

Best for: File upload endpoints, user-generated content pipelines, Node.js backend security hardening, self-hosted apps that can't send files to a cloud scanner.

Links: GitHub

5) OSV-Scanner — Google's open dependency vulnerability scanner

What it is: A CLI tool from Google that queries the Open Source Vulnerabilities (OSV) database against your project's dependency lock files — covering npm, pip, Go, Cargo, and more.

Why it matters in 2026: npm audit is noisy and often wrong. OSV-Scanner queries a unified, cross-ecosystem database that Google maintains for its own production systems. It surfaces real, exploitable vulnerabilities with call-graph analysis — not just "this transitive dep has a CVE from 2019." It outputs JSON for easy CI integration and ignores noise by default.

Best for: Multi-language monorepos, CI vulnerability gates, dependency auditing, replacing npm audit / pip-audit with one tool.

Links: GitHub | Website

6) OWASP ZAP — Web app attack surface testing, automated

What it is: The Zed Attack Proxy — an open-source DAST tool from OWASP that actively probes your running web application for vulnerabilities by acting as a man-in-the-middle proxy.

Why it matters in 2026: Static analysis only sees your source code. ZAP sees your app the way an attacker does — by hitting it with actual HTTP requests. The gap between "my code looks safe" and "my app is safe" is exactly what ZAP covers. The Automation Framework lets you run a full scan in CI with a single Docker command and fail the build on high-severity findings — no GUI required.

Best for: DAST in CI/CD, API security testing, OWASP Top 10 coverage, pre-release security gates.

Links: GitHub | Website

7) Falco — Real-time runtime threat detection for cloud-native

What it is: A CNCF project that uses eBPF to monitor system calls and Kubernetes audit logs, triggering alerts when behavior deviates from a defined policy — in real time, in production.

Why it matters in 2026: Most of the tools on this list prevent vulnerabilities before deploy. Falco catches what slips through after deploy. If a container starts executing a shell, reading /etc/shadow, or making unexpected network connections, Falco fires before the attacker gets far. It's the runtime equivalent of an intrusion detection system, and it's now the standard for production Kubernetes security.

Best for: Kubernetes production clusters, runtime anomaly detection, compliance requirements (PCI, SOC 2), post-incident forensics.

Links: GitHub | Website

Final thoughts

Security isn't a phase you add at the end — it's a pipeline you build once and run forever.

That's why the best security setups in 2026 are about:

Shifting left — catch it before it ships, not after it's breached
Zero-friction tooling — if it's annoying to run, it won't get run
Defense in depth — static analysis + secret scanning + DAST + runtime coverage
Ownership — individual developers owning security, not just a dedicated team
Open source — transparent tools you can audit, extend, and trust

The seven tools above cover your code, your containers, your dependencies, your uploaded files, your running app, and your production cluster. That's end-to-end.

If I missed something obvious, drop it in the comments.

What would be your #1 pick?

7 Open-Source Tools That Make File Upload Security Actually Manageable

Tommaso Bertocchi — Fri, 24 Apr 2026 13:02:00 +0000

Every web framework tutorial shows you how to accept a file upload.
Almost none show you what to do next.
You validate the Content-Type header. You check the extension. You think you're done.

You're not.

The default file upload stack leaves you exposed on four fronts: parsing security, file type spoofing, size abuse, and malware. These 7 tools close each gap without requiring a dedicated security team.

The average web app's file upload security posture in production. Source: Giphy

TL;DR: File upload security requires a stack, not a single library. These 7 tools cover parsing, validation, and scanning end-to-end.

pompelmi — antivirus scanning before the file touches permanent storage
multer — secure multipart parsing with built-in size and field limits
busboy — low-level streaming parser for fine-grained upload control
file-type — detect the real file type from magic bytes, not the filename
mime-types — map MIME types reliably without trusting user input
sharp — re-encode images to eliminate embedded payloads
archiver — control archive creation to prevent zip bomb and path traversal risks

1) pompelmi — scan files before they land

What it is: A minimal Node.js wrapper around ClamAV that scans any uploaded file and returns a typed verdict — Clean, Malicious, or ScanError. Zero runtime dependencies, no cloud, no daemon required.

Why it matters: The file upload attack surface doesn't start with storage — it starts with what you accept. A PDF that passes as application/pdf can still carry a macro payload. An image can embed executable content. pompelmi adds a scanning layer before any file touches your database or object storage, running ClamAV locally so no user data ever leaves your server.

Best for: Express, Fastify, NestJS, Next.js, SvelteKit, any Node.js app that accepts user file uploads

Links: | Website

pompelmi / pompelmi

Minimal Node.js wrapper around ClamAV — scan any file and get Clean, Malicious, or ScanError. Handles installation and database updates automatically.

pompelmi

ClamAV for humans

A minimal Node.js wrapper around ClamAV that scans any file and returns a typed Verdict Symbol: Verdict.Clean, Verdict.Malicious, or Verdict.ScanError. No daemons. No cloud. No native bindings. Zero runtime dependencies.

Quickstart

npm install pompelmi

const { scan, Verdict } = require('pompelmi');

const result = await scan('/path/to/file.zip');

if (result === Verdict.Malicious) {
  throw new Error('File rejected: malware detected');
}

How it works

Validate — pompelmi checks that the argument is a string and that the file exists before spawning anything.
Scan — pompelmi spawns clamscan --no-summary <filePath> as a child process and reads the exit code.
Map — the exit…

View on GitHub

2) multer — multipart parsing with limits built in

What it is: Express middleware for handling multipart/form-data with configurable file size limits, field count caps, and pluggable storage engines.

Why it matters: Unbounded multipart parsing is a DoS vector. A malicious client can send a multi-gigabyte upload or thousands of fields and exhaust server memory before any route handler runs. Multer's limits configuration rejects requests that exceed your thresholds before the full payload is consumed.

Best for: Express apps, REST APIs with file upload endpoints, any multipart form processing

Links:

expressjs / multer

Node.js middleware for handling `multipart/form-data`.

Multer

Multer is a node.js middleware for handling multipart/form-data, which is primarily used for uploading files. It is written on top of busboy for maximum efficiency.

NOTE: Multer will not process any form which is not multipart (multipart/form-data).

Translations

This README is also available in other languages:

العربية	Arabic
简体中文	Chinese
Français	French
한국어	Korean
Português	Portuguese (BR)
Русский язык	Russian
Español	Spanish
O'zbek tili	Uzbek
Việt Nam	Vietnamese
Türkçe	Turkish

Installation

$ npm install multer

Usage

Multer adds a body object and a file or files object to the request object. The body object contains the values of the text fields of the form, the file or files object contains the files uploaded via the form.

Basic usage example:

Don't forget the enctype="multipart/form-data" in your form.

<form action="/profile" method="post" enctype="multipart/form-data">
  <input type="

…

View on GitHub

3) busboy — streaming multipart parsing for full control

What it is: A low-level streaming multipart parser for Node.js that processes uploads without buffering the entire payload in memory.

Why it matters: Multer is the right default. Busboy is the right tool when you need to act on files before they're fully received — streaming to S3, scanning chunks in flight, or enforcing byte-level limits mid-stream. It trades abstraction for control, which is what high-volume or security-critical pipelines need.

Best for: High-volume uploads, streaming directly to cloud storage, custom upload pipelines, apps where memory pressure matters

Links:

mscdex / busboy

A streaming parser for HTML form data for node.js

Description

A node.js module for parsing incoming HTML form data.

Changes (breaking or otherwise) in v1.0.0 can be found here.

Note: If you are using node v18.0.0 or newer, please be aware of the node.js HTTP(S) server's requestTimeout configuration setting that is now enabled by default, which could cause upload interruptions if the upload takes too long.

Requirements

node.js -- v10.16.0 or newer

Install

npm install busboy

Examples

Parsing (multipart) with default options:

const http = require('http');
const busboy = require('busboy');

http.createServer((req, res) => {
  if (req.method === 'POST') {
    console.log('POST request');
    const bb = busboy({ headers: req.headers });
    bb.on('file', (name, file, info) => {
      const { filename

…

View on GitHub

4) file-type — detect real file types from magic bytes

What it is: A library that reads the first bytes of a file (magic bytes) to identify its true MIME type — regardless of the filename or Content-Type header.

Why it matters: File extension and Content-Type are user-controlled. An attacker renames a .exe to .jpg and your extension check passes. Magic byte detection reads the actual file signature — the bytes operating systems and compilers use to identify formats. Combined with an allowlist, it's the only reliable layer for type verification.

Best for: Image upload validation, document processing, any upload workflow where file type matters for security

Links:

sindresorhus / file-type

Detect the file type of a file, stream, or data

Detect the file type of a file, stream, or data

The file type is detected by checking the magic number of the buffer.

This package is for detecting binary-based file formats, not text-based formats like .txt, .csv, .svg, etc.

We accept contributions for commonly used modern file formats, not historical or obscure ones. Open an issue first for discussion.

Install

npm install file-type

This package is an ESM package. Your project needs to be ESM too. Read more. For TypeScript + CommonJS, see load-esm. If you use it with Webpack, you need the latest Webpack version and ensure you configure it correctly for ESM.

Important

File type detection is based on binary signatures (magic numbers) and is a best-effort hint. It does not guarantee the file is actually of that type or that the file is valid/not malformed.

Robustness against malformed input is best-effort. When…

View on GitHub

Checking file extensions vs checking magic bytes. Source: Giphy

5) mime-types — reliable MIME type mapping

What it is: A comprehensive MIME type lookup library mapping file extensions to MIME types and vice versa, maintained against the IANA database.

Why it matters: Writing your own MIME allowlist is a maintenance burden with consistent gaps. mime-types provides the full IANA database in a maintained package. Use it with file-type for a two-layer check: magic bytes confirm the real format, MIME mapping drives your content handling logic.

Best for: Upload type allowlisting, Content-Type header generation, file serving middleware

Links:

jshttp / mime-types

The ultimate javascript content-type utility.

mime-types

The ultimate javascript content-type utility.

Similar to the mime@1.x module, except:

No fallbacks. Instead of naively returning the first available type mime-types simply returns false, so do var type = mime.lookup('unrecognized') || 'application/octet-stream'.
No new Mime() business, so you could do var lookup = require('mime-types').lookup.
No .define() functionality
Bug fixes for .lookup(path)

Otherwise, the API is compatible with mime 1.x.

Install

This is a Node.js module available through the npm registry. Installation is done using the npm install command:

$ npm install mime-types

Note on MIME Type Data and Semver

This package considers the programmatic api as the semver compatibility. Additionally, the package which provides the MIME data for this package (mime-db) also considers it's programmatic api as the semver contract. This means the MIME type resolution is not considered in the semver bumps.

In the past the version of mime-db…

View on GitHub

6) sharp — re-encode images to strip dangerous payloads

What it is: A high-performance Node.js image processing library that converts, resizes, and re-encodes images using libvips.

Why it matters: An image that passes file-type validation can still contain EXIF metadata with XSS payloads, embedded scripts, or polyglot content that triggers vulnerabilities in downstream image parsers. Re-encoding through sharp strips all of this — the output is a clean, verified image. For any app serving user-uploaded images to other users, this step is non-negotiable.

Best for: Profile photos, user-generated image content, any pipeline that stores and serves uploaded images

Links: | Website

lovell / sharp

High performance Node.js image processing, the fastest module to resize JPEG, PNG, WebP, AVIF and TIFF images. Uses the libvips library.

sharp

The typical use case for this high speed Node-API module is to convert large images in common formats to smaller, web-friendly JPEG, PNG, WebP, GIF and AVIF images of varying dimensions.

It can be used with all JavaScript runtimes that provide support for Node-API v9, including Node.js (^18.17.0 or >= 20.3.0), Deno and Bun.

Resizing an image is typically 4x-5x faster than using the quickest ImageMagick and GraphicsMagick settings due to its use of libvips.

Colour spaces, embedded ICC profiles and alpha transparency channels are all handled correctly Lanczos resampling ensures quality is not sacrificed for speed.

As well as image resizing, operations such as rotation, extraction, compositing and gamma correction are available.

Most modern macOS, Windows and Linux systems do not require any additional install or runtime dependencies.

Documentation

Visit sharp.pixelplumbing.com for complete installation instructions, API documentation, benchmark tests and changelog.

Examples

npm install

…

View on GitHub

7) archiver — create archives without exposing attack surfaces

What it is: A streaming archive creation library for Node.js supporting zip, tar, and other formats with programmatic entry control.

Why it matters: When you generate archives for users programmatically, archiver gives you explicit control over what's included — preventing path traversal, setting compression ratios, and limiting which files can enter the archive. When you own archive creation, you define the attack surface rather than inheriting it from user input.

Best for: Download bundles, backup generation, export features, any server-side archive creation workflow

Links:

archiverjs / node-archiver

a streaming interface for archive generation

Archiver

A streaming interface for archive generation

Visit the API documentation for a list of all methods available.

Install

npm install archiver --save

Quick Start

import fs from "fs";
import { ZipArchive } from "archiver";
// create a file to stream archive data to.
const output = fs.createWriteStream(__dirname + "/example.zip");
const archive = new ZipArchive({
  zlib: { level: 9 }, // Sets the compression level.
});

// listen for all archive data to be written
// 'close' event is fired only when a file descriptor is involved
output.on("close", function () {
  console.log(archive.pointer() + " total bytes");
  console.log(
    "archiver has been finalized and the output file descriptor has closed.",
  );
});

// This

…

View on GitHub

Final thoughts

File upload security is a pipeline, not a single check. Parse with size limits, detect real types from magic bytes, map to allowed MIME types, sanitize image content, scan for malware, and control any archive generation.

Skip any step and you have a gap. Use all seven and you have a defensible upload stack that doesn't trust user input at any layer.

What's your current file upload pipeline missing?

Pompelmi: The minimalist ClamAV wrapper for Node.js (Zero Dependencies)

Tommaso Bertocchi — Fri, 24 Apr 2026 10:40:07 +0000

Checking file uploads for malware shouldn't be a headache. Most Node.js wrappers for ClamAV rely on unstable stdout parsing or heavy native bindings.

I built Pompelmi to be different: it's a "ClamAV for humans" wrapper that focuses on stability and simplicity.

🚀 Key Features

Zero Runtime Dependencies: Built 100% on Node.js built-ins.
Exit-Code Reliability: It uses ClamAV's documented exit codes (0, 1, 2) instead of brittle regex parsing.
No Native Bindings: No node-gyp or compilation required.
Hybrid Support: Works with local clamscan or remote clamd via TCP.
Cross-Platform: macOS, Linux, and Windows.

📦 Quickstart

npm install pompelmi

const { scan, Verdict } = require('pompelmi');

const result = await scan('./untrusted-file.zip');

if (result === Verdict.Malicious) {
  console.error('Threat detected!');
}

Check it out on GitHub and let me know what you think!

GitHub: https://github.com
Website: https://pompelmi.app

Forem: Tommaso Bertocchi

I built an AI agent that does OSINT investigations from your terminal

How it works

Why native tool use matters

Tools included

Multi-provider

The terminal UI

Install

What's next

8 Tools Powering the Fastest-Growing Startups in 2026

How I selected these

Table of Contents

1) Hono — The API framework that actually runs at the edge

2) Neon — Serverless Postgres that branches like Git

3) Drizzle ORM — The TypeScript ORM that doesn't fight your database

Happy New Year Celebration GIF by Faith Holland - Find & Share on GIPHY

4) Trigger.dev — Background jobs that don't require a PhD in distributed systems

5) shadcn/ui — UI components you copy, own, and never regret

6) pompelmi — The one security layer most early-stage startups skip

7) OpenNext — Escape Next.js infrastructure lock-in

8) Supabase — The open-source BaaS that didn't make you regret it later

Final thoughts

9 Open-Source Tools to Own Your Stack (and Kill Your Cloud Bills) in 2026

How I picked these

Table of Contents

1) Ollama — Run any LLM locally, one command

2) Coolify — Deploy apps without touching AWS or Vercel

3) Plausible — Analytics that don't spy on your users

4) Authentik — Auth without the $300/month Auth0 invoice

5) Forgejo — Git hosting that's actually yours

6) pompelmi — File scanning without sending files to the cloud

7) Meilisearch — Search that doesn't bill per query

8) Windmill — Automate workflows without Zapier's pricing ceiling

9) Netdata — Real-time monitoring without Datadog sticker shock

Final thoughts

7 Mistakes Every Developer Makes in 2026 — And the Open-Source Fix for Each

How I picked these

Table of Contents

1) Infisical — Stop hardcoding secrets, you know who you are

2) pompelmi — Your file upload endpoint is a malware delivery service

3) SigNoz — You're flying blind the moment you ship

4) Atlas — Your database migrations are ticking time bombs

5) Scalar — Your API docs are a lie and your team knows it

Happy New Year Celebration GIF by Faith Holland - Find & Share on GIPHY

6) Testcontainers — "Works on my machine" never fixed a production outage

7) Unkey — Your API is open for abuse right now

Final thoughts

8 Open-Source Tools That Save Solo Developers Hours Every Week

Table of Contents

1) n8n — Automation without writing automation code

2) Pocketbase — Your entire backend in one binary

3) Hoppscotch — API testing without the Postman subscription

4) Trigger.dev — Background jobs without the infrastructure tax

5) pompelmi — File security scanning in 10 lines of Node.js

6) Infisical — Secrets management that actually prevents leaks

7) Mermaid — Diagrams in Markdown, diagramming app deleted

8) Zed — An editor fast enough to get out of your way

Final thoughts

8 AI Coding Agents That Actually Ship Production Code in 2026

How I picked these

Table of Contents

1) Claude Code — Terminal-native agent that reasons before it acts

2) Aider — Git-aware CLI pair programmer, fully open source

3) Cursor — AI-first editor with a multi-file agent mode that ships

4) OpenHands — Self-hostable autonomous software engineer

5) Cline — VS Code agent that reads your repo and deploys

6) pompelmi — The security check before AI-generated code ships

7) SWE-agent — Princeton's agent that resolves GitHub issues on its own

8) Sweep — Turns GitHub issues into PRs without a keystroke

Final thoughts

8 Open-Source Security Tools Every Developer Should Be Using in 2026

Table of Contents

1) Trivy — One scanner for containers, IaC, and repos

2) Semgrep — Catch security bugs before they ship

3) Trufflehog — Find the secrets you forgot you committed

4) Gitleaks — Stop secrets from ever entering git history

5) pompelmi — The file scanning layer Node apps keep skipping

6) OWASP ZAP — Automated web security testing without a pen tester

7) Falco — Runtime visibility into what your containers actually do

8) Nuclei — Scan your own attack surface before someone else does