Forem: Tommaso Bertocchi

10 Best Cybersecurity Tools Every Developer Should Know (Including One You've Never Heard Of)

Tommaso Bertocchi — Fri, 17 Apr 2026 09:50:05 +0000

Cybersecurity isn't just for ops teams anymore. As developers, we ship code that handles user data, processes file uploads, and talks to external services. The tools below will help you build safer applications — from scanning malware in uploaded files to auditing your dependencies.

1. 🍋 pompelmi — Antivirus Scanning for Node.js

Website: pompelmi.app | npm: pompelmi | License: ISC

If your Node.js application accepts file uploads, pompelmi is the tool you didn't know you needed.

It's a minimal, zero-dependency wrapper around ClamAV that lets you scan any file path and get back a clean, typed result — no daemons, no cloud calls, no native bindings.

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

async function scanUpload(filePath) {
  const result = await scan(filePath);

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

  return result; // Verdict.Clean | Verdict.Malicious | Verdict.ScanError
}

What makes it special:

One function — just call scan(path) and await a typed Verdict Symbol
Zero runtime dependencies — uses Node's built-in child_process
Cross-platform — works on macOS, Linux, and Windows
No daemon required — invokes clamscan directly, no background process to manage
Exit-code mapped — no stdout parsing, no brittle regex

Install it in seconds:

npm install pompelmi
# macOS
brew install clamav && freshclam
# Linux
sudo apt-get install -y clamav clamav-daemon && sudo freshclam

If you're building an API that accepts PDFs, images, or documents from untrusted users, pompelmi is a one-liner that can save you from a catastrophic malware incident.

🔗 Full docs, Docker guide, and API reference at pompelmi.app

2. 🔍 Snyk — Find and Fix Vulnerabilities in Your Code

Website: snyk.io | Free tier: Yes

Snyk is one of the most developer-friendly security tools available. It scans your project's dependencies (npm, pip, Maven, etc.), your container images, and even your Infrastructure-as-Code files for known vulnerabilities.

What stands out is the fix PRs feature — Snyk can automatically open a pull request to upgrade a vulnerable dependency. It integrates directly into GitHub, GitLab, and VS Code.

npm install -g snyk
snyk auth
snyk test

Best for: Continuous dependency vulnerability scanning in CI/CD pipelines.

3. 🛡️ OWASP ZAP — The Classic Web App Scanner

Website: zaproxy.org | License: Apache 2.0

The OWASP Zed Attack Proxy (ZAP) is a battle-tested, open-source web application security scanner maintained by OWASP. It can find XSS, SQL injection, CSRF, and dozens of other vulnerabilities by actively probing your running app.

It comes with both a GUI and a headless/CLI mode, making it easy to embed into your CI pipeline.

Best for: Integration and regression security testing of web apps before deployment.

4. 🔐 Vault by HashiCorp — Secrets Management

Website: vaultproject.io | License: BSL 1.1 / open-source editions available

Hardcoded secrets in your codebase are a ticking time bomb. HashiCorp Vault gives you a centralized, auditable secrets store with fine-grained access control.

It supports dynamic secrets (credentials that are generated on demand and auto-expire), encryption as a service, and integrations with AWS, Kubernetes, and more.

vault kv put secret/myapp db_password="supersecret"
vault kv get secret/myapp

Best for: Teams managing API keys, database credentials, and certificates across multiple services.

5. 🧱 Helmet.js — HTTP Security Headers for Express

Website: helmetjs.github.io | npm: helmet

A surprising number of web vulnerabilities are mitigated simply by setting the right HTTP response headers. Helmet is a tiny Express middleware that sets headers like Content-Security-Policy, X-Frame-Options, Strict-Transport-Security, and more.

const express = require('express');
const helmet = require('helmet');

const app = express();
app.use(helmet());

One line of code. Massive security improvement. No excuses.

Best for: Any Node.js/Express application serving a frontend.

6. 🕵️ Trivy — Container & IaC Vulnerability Scanner

Website: trivy.dev | License: Apache 2.0

If you ship Docker containers, Trivy by Aqua Security is the go-to scanner. It checks OS packages, language-specific packages, IaC misconfigurations, and even secrets accidentally baked into your image layers.

trivy image node:18-alpine
trivy fs ./myproject

It's fast, has zero configuration for basic use, and integrates cleanly with GitHub Actions and other CI systems.

Best for: Scanning container images and repositories before pushing to production.

7. 🔎 Semgrep — Static Analysis That Doesn't Suck

Website: semgrep.dev | Free tier: Yes

Semgrep is a fast, lightweight static analysis tool that lets you write rules in a syntax that closely mirrors the code you're analyzing. It supports 30+ languages and comes with thousands of community rules for catching common security bugs.

semgrep --config=p/security-audit ./src

Unlike traditional SAST tools, Semgrep rules are readable and easy to customize — you can write your own rule in minutes to enforce team-specific security patterns.

Best for: Catching security bugs and anti-patterns during code review and CI.

8. 🌐 Burp Suite Community Edition — Manual Pen Testing

Website: portswigger.net/burp | Free tier: Community Edition

Burp Suite is the industry standard for manual web application penetration testing. It acts as a proxy between your browser and the server, letting you intercept, inspect, and modify HTTP/S requests in real time.

The Community Edition is free and includes the intercepting proxy, repeater, decoder, and intruder tools — everything you need to manually probe your own app for logic flaws and injection points.

Best for: Deep-dive manual security testing and bug bounty research.

9. 🔑 age — Modern File Encryption

Website: age-encryption.org | License: BSD 3-Clause

age (pronounced like the word) is a modern, simple file encryption tool and Go library. It's designed as a safer replacement for GPG, with a much simpler interface and no key management footguns.

# Encrypt a file
age -r $RECIPIENT_PUBLIC_KEY secret.txt > secret.txt.age

# Decrypt it
age -d -i ~/.ssh/id_ed25519 secret.txt.age > secret.txt

Best for: Encrypting secrets files, backups, and config files before storing or transmitting them.

10. 📋 npm audit — The One You're Already Ignoring

Built into npm | Free

Okay, this one's a reminder, not a discovery. npm audit is built into every npm installation and checks your dependency tree against the GitHub Advisory Database for known CVEs.

npm audit
npm audit fix
npm audit fix --force  # upgrades breaking changes too

The dirty secret is that most developers run it once and then ignore the warnings. Make it part of your CI pipeline with npm audit --audit-level=high to fail builds on high-severity issues. No excuses — it's already installed.

Best for: Every single Node.js project, every single time.

Summary Table

Tool	Category	Language/Platform	Free?
pompelmi	Malware scanning	Node.js	✅
Snyk	Dependency scanning	Polyglot	✅ (tier)
OWASP ZAP	Web app scanning	Any	✅
HashiCorp Vault	Secrets management	Any	✅ (OSS)
Helmet.js	HTTP headers	Node.js/Express	✅
Trivy	Container scanning	Docker/IaC	✅
Semgrep	Static analysis	30+ languages	✅ (tier)
Burp Suite	Pen testing	Web	✅ (CE)
age	File encryption	Any	✅
npm audit	Dependency audit	Node.js	✅

Final Thoughts

Security doesn't have to be overwhelming. These ten tools cover the most common attack surfaces a typical application exposes: vulnerable dependencies, insecure headers, unscanned uploads, leaked secrets, and misconfigured containers.

Start with the ones closest to your stack. If you're building a Node.js API that accepts file uploads, pompelmi is the first tool you should add today — it's a npm install away and could be the difference between a safe app and a headline.

Found this useful? Drop a ❤️ and share it with your team. Security is everyone's job.

10 npm packages you will use in 2026

Tommaso Bertocchi — Thu, 16 Apr 2026 06:59:58 +0000

The npm ecosystem moves fast.

Libraries you'd never heard of six months ago are now in half the starters on GitHub.
Some are genuinely better. Some are hype.

Here are 10 that I think are actually worth your time in 2026.

TL;DR: Hono, Drizzle, Zod, Vitest, Effect, pompelmi, ofetch, unstorage, tsx, and oslo — one for almost every layer of your stack.

1. Hono — the web framework that actually stays out of your way

What it is:
A ultrafast, edge-first web framework. Runs on Cloudflare Workers, Deno, Bun, Node.js — all with the same API.

Why it matters:
Express is still fine, but it was designed before edge runtimes existed. Hono was built for the current landscape. The router is faster than Express in every benchmark I've seen, and the middleware system is dead simple.

import { Hono } from 'hono';

const app = new Hono();
app.get('/hello', (c) => c.json({ message: 'works everywhere' }));

export default app;

Links:
npm install hono — honojs.dev

2. Drizzle ORM — SQL without losing your mind

What it is:
A TypeScript ORM that writes SQL you'd actually recognize. Schema defined in TypeScript, queries look like SQL, types flow through automatically.

Why it matters:
Prisma is great but generates types at build time via a separate CLI step. Drizzle infers everything from your schema file at the TypeScript level — no codegen, no extra process, faster feedback loop.

const result = await db
  .select()
  .from(users)
  .where(eq(users.role, 'admin'))
  .limit(10);

Links:
npm install drizzle-orm — orm.drizzle.team

3. Zod — runtime validation that TypeScript actually trusts

What it is:
Schema declaration and validation library. Define a shape once, get both a TypeScript type and a runtime validator.

Why it matters:
TypeScript only protects you at compile time. The moment data comes from a form, an API, or a query string — you're on your own. Zod bridges that gap cleanly.

import { z } from 'zod';

const UserSchema = z.object({
  email: z.string().email(),
  age: z.number().min(18),
});

const user = UserSchema.parse(req.body); // throws if invalid

If you're building APIs in 2026 without Zod (or something like it), you're writing validation by hand and lying to yourself about it.

Links:
npm install zod — zod.dev

4. Vitest — tests that don't slow you down

What it is:
A Vite-native test runner. Jest-compatible API, but with native ESM support, instant watch mode, and built-in TypeScript support.

Why it matters:
Jest's startup time is noticeable. Vitest starts in under a second. If you're using Vite already (and you probably are), switching costs almost nothing.

import { describe, it, expect } from 'vitest';

describe('add', () => {
  it('returns correct sum', () => {
    expect(1 + 1).toBe(2);
  });
});

Links:
npm install -D vitest — vitest.dev

5. Effect — error handling the way it should work

What it is:
A TypeScript library for writing reliable, type-safe, composable programs. Errors, async, dependencies — all tracked in the type system.

Why it matters:
try/catch doesn't tell you what can fail or why. Effect makes errors first-class citizens. Every function signature tells you exactly what it can return and what it can fail with.

import { Effect } from 'effect';

const program = Effect.tryPromise({
  try: () => fetch('/api/data').then(r => r.json()),
  catch: (e) => new NetworkError(String(e)),
});

Steep learning curve. Worth it for anything production-critical.

Links:
npm install effect — effect.website

6. pompelmi — antivirus scanning for Node.js that actually works

What it is:
A minimal, zero-dependency wrapper around ClamAV. Scans any file and returns a typed Verdict symbol — Verdict.Clean, Verdict.Malicious, or Verdict.ScanError.

Why it matters:
Most Node.js file upload handlers have no malware scanning at all.
The ones that do usually rely on fragile stdout parsing with regex.
pompelmi maps ClamAV exit codes directly — the stable interface — so it can't silently break between ClamAV versions.

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

const result = await scan(req.file.path);

if (result === Verdict.Malicious) {
  return res.status(400).json({ error: 'File rejected.' });
}

No daemon needed by default. No runtime dependencies. No regex. Cross-platform.
If ClamAV runs in a container, pass host and port and the API stays identical.

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 code…

View on GitHub

Links:
npm install pompelmi — pompelmi.app

7. ofetch — fetch that behaves like you expect

What it is:
A better fetch wrapper from the UnJS team. Auto-parses JSON, smart retries, proper error throwing, and works in Node, browsers, and edge runtimes.

Why it matters:
Native fetch is fine until you need error handling, and then you realize you have to check res.ok yourself every single time. ofetch throws on non-2xx responses by default, handles JSON automatically, and adds retry logic with a single option.

import { ofetch } from 'ofetch';

const data = await ofetch('/api/users', {
  method: 'POST',
  body: { name: 'Tommy' },
  retry: 3,
});

Links:
npm install ofetch — github.com/unjs/ofetch

8. unstorage — one API for every storage backend

What it is:
A universal key-value storage layer. Same API whether you're writing to memory, Redis, Cloudflare KV, localStorage, the filesystem, or a database.

Why it matters:
You want to swap Redis for Cloudflare KV when you move to the edge — you shouldn't have to rewrite your caching layer. unstorage makes that a config change, not a refactor.

import { createStorage } from 'unstorage';
import redisDriver from 'unstorage/drivers/redis';

const storage = createStorage({
  driver: redisDriver({ url: process.env.REDIS_URL }),
});

await storage.setItem('session:abc', { userId: 42 });
const session = await storage.getItem('session:abc');

Links:
npm install unstorage — unstorage.unjs.io

9. tsx — run TypeScript without a build step

What it is:
A CLI tool that runs .ts files directly in Node.js. Drop-in replacement for node, powered by esbuild.

Why it matters:
ts-node is slow. tsx is fast. Starts instantly, handles modern ESM TypeScript, and requires zero configuration.

npx tsx src/index.ts
# or
tsx watch src/index.ts

Replace this in your package.json:

"scripts": {
  "dev": "tsx watch src/index.ts"
}

Links:
npm install -D tsx — tsx.is

10. oslo — auth primitives without the framework lock-in

What it is:
A collection of small, focused auth utilities: CSRF tokens, OTP generation, cookie handling, encoding, timing-safe comparison. From the Lucia auth team.

Why it matters:
Full auth libraries (NextAuth, Lucia) make assumptions about your framework and database. oslo gives you the low-level primitives — the pieces auth is built from — so you can compose exactly what you need.

import { generateRandomString, alphabet } from 'oslo/crypto';
import { TOTP } from 'oslo/otp';

const code = generateRandomString(8, alphabet('0-9'));
const totp = new TOTP('SHA-1', 6, 30);
const isValid = await totp.verify(userInput, secret);

Links:
npm install oslo — oslo.js.org

The list at a glance

Package	Category	One-liner
`hono`	Framework	Edge-native, framework-agnostic web server
`drizzle-orm`	Database	Type-safe ORM, no codegen
`zod`	Validation	Schema → TypeScript type + runtime validation
`vitest`	Testing	Fast Jest-compatible test runner
`effect`	Reliability	Type-safe errors and async composition
`pompelmi`	Security	File antivirus scanning via ClamAV
`ofetch`	HTTP	fetch that handles errors and JSON automatically
`unstorage`	Storage	Universal key-value storage across backends
`tsx`	DX	Run TypeScript files instantly, no config
`oslo`	Auth	Low-level auth primitives, no framework assumptions

Which of these are already in your stack — and which ones are you trying next?

I'm especially curious if anyone has a better alternative to effect for typed error handling without the learning curve.

I tried every Node.js antivirus library. Here's what I found.

Tommaso Bertocchi — Wed, 15 Apr 2026 17:58:49 +0000

Most Node.js file upload handlers look something like this:

app.post('/upload', upload.single('file'), (req, res) => {
  res.json({ ok: true });
});

No scan. No check. Just trust.

That's fine until someone uploads a malware-laced PDF to your SaaS and your enterprise customer's IT team starts asking questions.

I went looking for a proper antivirus solution for Node.js. Here's everything I found — and why most of it is worse than it looks.

TL;DR: Most Node.js antivirus libraries are either abandoned, overly complex, or rely on fragile stdout parsing. pompelmi is the one that actually does it right — zero dependencies, typed verdicts, and direct ClamAV exit code mapping with no regex.

What I was actually looking for

Before I started, I wrote down my requirements:

Works in a real production Node.js app (not a script)
Doesn't require me to run a background daemon 24/7 for single-scan use cases
Returns typed results I can actually switch on
Actively maintained
Zero or minimal runtime dependencies

Spoiler: most libraries fail at least two of these.

The landscape (as of 2025)

1. `clamscan` (npm)

The oldest and most-starred option. Wraps ClamAV and has been around since 2014.

What it does: Spawns clamscan or connects to clamd daemon. Returns a result object.

The problem: It parses stdout with regex patterns. That's a brittle contract — ClamAV output format changes between versions, and your regex silently breaks. I've been burned by this in production. The library also has a handful of long-standing open issues around false negatives on certain output formats.

It works. But you're trusting regex to stand between you and malware.

2. `clamdjs`

Connects to a running clamd daemon via TCP.

The problem: You have to run a daemon. For many setups — serverless functions, ephemeral containers, low-traffic apps — spinning up a persistent background service just to occasionally scan a file is overkill. Also, clamdjs hasn't seen meaningful updates in years.

3. Random VirusTotal API wrappers

These exist. They send your files to VirusTotal's API and return scan results.

The problem: You're uploading potentially sensitive user files to a third-party service. For anything with PII, healthcare data, or enterprise contracts, that's a non-starter. Also rate limits, latency, and cost.

4. Cloud-native options (AWS Malware Protection, GCP Security Command Center)

If you're already deep in AWS or GCP, these exist and work well.

The problem: Vendor lock-in, cost, and setup complexity. Sometimes you just want to await scan(file) and move on.

pompelmi: the one I actually kept

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

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 code…

View on GitHub

pompelmi is a Node.js antivirus library built around one idea: don't parse stdout, map exit codes directly.

ClamAV already communicates via exit codes. 0 = clean. 1 = malware found. 2 = error. pompelmi maps these directly to typed verdict symbols. No regex. No stdout parsing. No silent failures.

Install

npm install @pompelmi/probe

ClamAV needs to be present on the host (one-time setup):

# macOS
brew install clamav && freshclam

# Ubuntu/Debian
sudo apt-get install -y clamav && sudo freshclam

# Windows
choco install clamav -y

pompelmi automatically detects whether your virus definitions are up-to-date and skips freshclam if they already are. No redundant downloads.

Usage

import { scan, Verdict } from '@pompelmi/probe';

const result = await scan('/path/to/uploaded-file.pdf');

switch (result) {
  case Verdict.Clean:
    // Safe to process
    break;
  case Verdict.Malicious:
    // Reject and alert
    break;
  case Verdict.ScanError:
    // Handle gracefully
    break;
}

That's it. Typed. Exhaustive. No strings to compare, no regex, no result.isInfected booleans with unclear semantics.

What makes it different

No stdout parsing.
Every other library I tested parses ClamAV's human-readable output. pompelmi uses exit codes exclusively — the stable, documented interface ClamAV actually exposes.

No daemon required.
pompelmi calls clamscan directly via Node's built-in child_process. No background process to manage. Works in Lambda, in Docker, in a plain old Express app.

Zero runtime dependencies.
The entire library relies on Node.js built-ins. Nothing to audit, nothing to patch, nothing that breaks on a minor version bump.

Cross-platform.
macOS, Linux, and Windows all work with the same code. The ClamAV install step varies per OS; the Node.js API doesn't.

Typed verdicts.
Verdict.Clean, Verdict.Malicious, Verdict.ScanError — symbols, not strings. TypeScript narrows correctly. You can't typo "malicous" at 2am and ship a broken check.

A realistic Express upload handler

import express from 'express';
import multer from 'multer';
import { scan, Verdict } from '@pompelmi/probe';
import path from 'path';
import fs from 'fs/promises';

const app = express();
const upload = multer({ dest: '/tmp/uploads' });

app.post('/upload', upload.single('file'), async (req, res) => {
  const filePath = req.file.path;

  try {
    const result = await scan(filePath);

    if (result === Verdict.Malicious) {
      await fs.unlink(filePath);
      return res.status(400).json({ error: 'File rejected: malware detected.' });
    }

    if (result === Verdict.ScanError) {
      await fs.unlink(filePath);
      return res.status(500).json({ error: 'Scan failed. Please retry.' });
    }

    // Verdict.Clean — proceed with processing
    const dest = path.join('/var/uploads', req.file.originalname);
    await fs.rename(filePath, dest);
    res.json({ ok: true, path: dest });

  } catch (err) {
    await fs.unlink(filePath).catch(() => {});
    res.status(500).json({ error: 'Unexpected error.' });
  }
});

Clean, safe, and explicit about every possible outcome.

The verdict (pun intended)

Library	Maintained	No daemon needed	Typed results	No stdout parsing	Zero deps
`clamscan`	Partially	Yes	No	No	No
`clamdjs`	No	No	No	No	No
VirusTotal wrappers	Varies	Yes	Varies	N/A	No
pompelmi	Yes	Yes	Yes	Yes	Yes

If you're building a Node.js app that handles file uploads in 2025, you should be scanning them.

pompelmi makes it as easy as it should be.

Are you scanning user uploads in your app? What's your current setup — and what's the biggest friction point you've hit?

Drop it in the comments. I'm curious whether anyone has a pattern I haven't seen.

it will be for all 2026

Tommaso Bertocchi — Sun, 12 Apr 2026 17:35:58 +0000

Tommaso Bertocchi

Mar 14

10 Open-Source Projects You’ll Actually Use in 2026

#ai #webdev #programming #opensource

Comments 1

7 min read

read this

Tommaso Bertocchi — Sun, 12 Apr 2026 17:27:09 +0000

Tommaso Bertocchi

Apr 12

I Spent 3 Hours Adding Antivirus to My Express App. Then I Reduced It to 3 Lines.

#javascript #node #security #beginners

Comments 2

3 min read

I Spent 3 Hours Adding Antivirus to My Express App. Then I Reduced It to 3 Lines.

Tommaso Bertocchi — Sun, 12 Apr 2026 09:51:23 +0000

Two years ago, I shipped my first production app with file uploads. A week later, my mentor asked: "Are you scanning those files for malware?"

I wasn't.

The Google Rabbit Hole

Like any developer, I Googled "node js antivirus file upload." Here's what I found:

ClamAV — the open-source standard. Great! Let's use it.
clamscan npm package — 47 configuration options.
clamav.js — requires running clamd daemon.
Various tutorials — "First, configure your socket connection..."

I just wanted to scan a file. Why did I need to understand Unix sockets?

My First Attempt

After an hour of reading docs, I had something like this:

const NodeClam = require('clamscan');

const clamscan = new NodeClam().init({
  removeInfected: false,
  quarantineInfected: false,
  scanLog: null,
  debugMode: false,
  fileList: null,
  scanRecursively: true,
  clamscan: {
    path: '/usr/bin/clamscan',
    db: null,
    scanArchives: true,
    active: true
  },
  clamdscan: {
    socket: '/var/run/clamav/clamd.ctl',
    host: false,
    port: false,
    timeout: 60000,
    localFallback: true,
    path: '/usr/bin/clamdscan',
    configFile: null,
    multiscan: true,
    reloadDb: false,
    active: true,
    bypassTest: false,
  },
  preference: 'clamdscan'
});

// ... 30 more lines to actually scan a file

It didn't work. The socket path was wrong on my Mac. I spent another hour debugging.

The Daemon Problem

Most ClamAV wrappers assume you're running clamd — a background daemon that keeps virus definitions in memory for faster scanning.

This makes sense for high-throughput enterprise systems. But I was building a side project. I didn't want to manage a daemon. I didn't want to configure systemd. I didn't want to think about socket permissions.

I just wanted to answer one question: is this file safe?

What I Actually Needed

After three hours of frustration, I wrote down what I actually wanted:

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

const result = await scan('/path/to/upload.zip');
// Verdict.Clean | Verdict.Malicious | Verdict.ScanError — that's it

No daemon. No configuration object. No socket paths. Just a function that takes a file and returns an answer.

So I built it.

pompelmi: ClamAV for Humans

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

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

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

That's the entire API. One function. Three possible results — typed as Symbols, so no typos, no accidental string mismatches.

Here's the same Express middleware, before and after:

Before (47 lines)

const NodeClam = require('clamscan');
const multer = require('multer');

// ... 35 lines of configuration ...

app.post('/upload', upload.single('file'), async (req, res) => {
  try {
    const clam = await clamscan;
    const {isInfected, viruses} = await clam.isInfected(req.file.path);
    if (isInfected) {
      fs.unlinkSync(req.file.path);
      return res.status(400).json({ error: 'Malware detected', viruses });
    }
    res.json({ success: true });
  } catch (err) {
    // Is this a scan error or a config error? Who knows!
    res.status(500).json({ error: 'Scan failed' });
  }
});

After (12 lines)

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

app.post('/upload', upload.single('file'), async (req, res) => {
  const result = await scan(req.file.path);

  if (result === Verdict.Malicious) {
    fs.unlinkSync(req.file.path);
    return res.status(400).json({ error: 'Malware detected' });
  }

  if (result === Verdict.ScanError) {
    // Scan couldn't complete — treat as untrusted
    fs.unlinkSync(req.file.path);
    return res.status(400).json({ error: 'File rejected' });
  }

  res.json({ success: true });
});

How It Works (The Boring Way)

pompelmi doesn't do anything clever:

Check that the file exists
Spawn clamscan --no-summary <path> using Node's native child_process
Read the exit code
Map it to a Symbol

No stdout parsing. No regex. No daemon. No socket. No third-party spawn library. Just a child process and an exit code.

Exit 0 → Verdict.Clean
Exit 1 → Verdict.Malicious
Exit 2 → Verdict.ScanError

ClamAV has been doing this reliably for 20 years. I just wrapped it in a function.

Why Symbols, Not Strings?

Since v1.2.0, scan results are Symbols, not plain strings. This means:

// ✅ This works
if (result === Verdict.Malicious) { ... }

// ❌ This will never match — intentionally
if (result === 'Malicious') { ... }

It prevents a whole class of bugs where you typo a string comparison ('malicious' vs 'Malicious') and your security check silently does nothing. The compiler catches it for you.

If you need the verdict as a string for logging, each Symbol has a .description property:

console.log(result.description); // "Clean", "Malicious", or "ScanError"

Upgrading from v1.1.x? Replace any result === 'Clean' checks with result === Verdict.Clean (and same for Malicious and ScanError). Don't forget to import Verdict alongside scan.

"But What About Performance?"

Yes, spawning clamscan for every file is slower than using the daemon. Each scan loads the virus database from disk (~300MB).

For a side project handling 100 uploads/day? Doesn't matter.

For a startup processing 10,000 files/hour? You probably have a dedicated security engineer who knows how to configure clamd.

pompelmi is for the 99% of developers who just need something — and "slow but working" beats "fast but misconfigured."

The Point

Developer tools should meet you where you are.

When I was a junior developer, I didn't need 47 configuration options. I needed one function that worked. I needed to ship something on Friday and not think about Unix sockets.

If you're building something bigger, you'll outgrow pompelmi. That's fine. By then, you'll understand why you need the daemon, and configuring it won't feel like dark magic.

But if you're building your first app with file uploads, and you just want to scan for malware without a 3-hour detour — npm install pompelmi.

npm install pompelmi

GitHub · npm

pompelmi is Italian for "grapefruits." I named it that because I was eating one when I finally got the code working at 2am. Sometimes that's all the reason you need.

10 Tools That Will Instantly Make Your Coding Projects Better

Tommaso Bertocchi — Fri, 03 Apr 2026 09:03:50 +0000

Most coding projects do not fail because the idea was bad.

They fail because everything around the code is weak.

The deploy process is manual.

The API contract lives in someone's head.

Errors show up first in production.

Dependencies age quietly until they become a problem.

Uploads get trusted way too easily.

Nobody has a clean picture of how the system actually works.

That is the part a lot of teams underestimate.

Good projects are not just built with good code.

They are built with good systems around the code.

So this is not a random list of apps.

These are 10 tools that make coding projects feel more professional, more reliable, more secure, and much easier to ship.

TL;DR: Better projects usually come from stronger workflow, testing, observability, documentation, dependency hygiene, and security, not just smarter features.

The moment you realize the feature works, but the project still feels one bad deploy away from chaos. Source: South Park on Giphy

GitHub Actions
Postman
Docker
Sentry
Playwright
Swagger / OpenAPI
pompelmi
Dependabot
Excalidraw
Raycast

1) GitHub Actions — Stop shipping manually

What it is: GitHub's built-in automation layer for CI, CD, releases, scheduled jobs, and repo workflows.

Why it improves your project: It turns quality checks from a vague team habit into a repeatable system. Linting, tests, builds, previews, and deploy gates stop depending on who remembered what.

Best for: pull request checks, automated releases, scheduled maintenance jobs, deployment pipelines, repo housekeeping.

The fastest way to make a repo feel serious is to make every change prove itself before it lands. Even a small workflow that runs install, lint, test, and build on every PR removes a huge amount of avoidable drama.

Links: Official · Representative repo

actions / starter-workflows

Accelerating new GitHub Actions workflows

Starter Workflows

These are the workflow files for helping people get started with GitHub Actions. They're presented whenever you start to create a new GitHub Actions workflow.

If you want to get started with GitHub Actions, you can use these starter workflows by clicking the "Actions" tab in the repository where you want to create a workflow.

Note

Thank you for your interest in this GitHub repo, however, right now we are not taking contributions.

We continue to focus our resources on strategic areas that help our customers be successful while making developers' lives easier. While GitHub Actions remains a key part of this vision, we are allocating resources towards other areas of Actions and are not taking contributions to this repository at this time. The GitHub public roadmap is the best place to follow along for any updates on features we’re working on and what stage they’re in.

We…

View on GitHub

name: ci

on:
  pull_request:
  push:
    branches: [main]

jobs:
  verify:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run lint
      - run: npm test
      - run: npm run build

When the team discovers that "our deploy checklist" was actually just one person's memory. Source: Family Guy on Giphy

2) Postman — Make your API usable by more than its author

What it is: An API platform for sending requests, organizing collections, sharing environments, and testing real responses.

Why it improves your project: Good APIs are not just endpoints that return JSON. They are endpoints people can inspect, replay, debug, and hand to teammates without a 20-minute Slack explanation.

Best for: backend teams, QA workflows, auth-heavy APIs, onboarding, partner integrations, manual verification.

Postman is useful because it turns one person's debugging setup into shared project knowledge. The moment auth headers, refresh flows, sample payloads, and odd edge-case requests are saved in a collection, your API stops feeling mysterious. And once those collections become something your team can rerun and share consistently, the project gets easier to trust.

Links: Official · Representative repo

postmanlabs / newman

Newman is a command-line collection runner for Postman

Manage all of your organization's APIs in Postman, with the industry's most complete API development environment.

newman the cli companion for postman

Newman is a command-line collection runner for Postman. It allows you to effortlessly run and test a Postman collection directly from the command-line. It is built with extensibility in mind so that you can easily integrate it with your continuous integration servers and build systems.

Getting started

…

View on GitHub

3) Docker — Kill environment roulette

What it is: A container platform for packaging your app and its dependencies into reproducible environments.

Why it improves your project: It reduces the classic "works on my machine" tax by making local, CI, staging, and production setups much more predictable.

Best for: apps with multiple services, onboarding, backend systems, consistent local environments, reproducible deployments.

Docker will not magically fix bad architecture, but it will stop the weekly ritual where one machine has the right runtime, another machine has the wrong system packages, and production is somehow "close enough." That alone makes a project calmer to ship.

Links: Official · Representative repo

docker / compose

Define and run multi-container applications with Docker

Docker Compose

Docker Compose is a tool for running multi-container applications on Docker defined using the Compose file format A Compose file is used to define how one or more containers that make up your application are configured. Once you have a Compose file, you can create and start your application with a single command: docker compose up.

Note: About Docker Swarm Docker Swarm used to rely on the legacy compose file format but did not adopt the compose specification so is missing some of the recent enhancements in the compose syntax. After acquisition by Mirantis swarm isn't maintained by Docker Inc, and as such some Docker Compose features aren't accessible to swarm users.

Where to get Docker Compose

Windows and macOS

Docker Compose is included in Docker Desktop…

View on GitHub

services:
  app:
    build: .
    ports:
      - "3000:3000"
    environment:
      NODE_ENV: production
    depends_on:
      - postgres

  postgres:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: postgres

Trying to explain why local, staging, and production are "basically the same" when they absolutely are not. Source: The Simpsons on Giphy

4) Sentry — Catch the breakage before users do

What it is: Error tracking and performance monitoring for apps, APIs, and background jobs.

Why it improves your project: It gives failures context instead of vibes. You get stack traces, release correlation, breadcrumbs, request metadata, and performance signals that help you fix the right thing faster.

Best for: production apps, APIs, workers, frontend error tracking, release monitoring, performance debugging.

Projects get better the minute production stops feeling like a blindfold. Sentry shortens the distance between "something is broken" and "here is the exact release, route, and error path that caused it."

Links: Official · GitHub

getsentry / sentry

Developer-first error tracking and performance monitoring

Users and logs provide clues. Sentry provides answers.

What's Sentry?

Sentry is the debugging platform that helps every developer detect, trace, and fix issues. Code breaks, fix it faster.

Official Sentry SDKs

Resources

Documentation
Discussions (Bugs, feature requests, general questions)
Discord
Contributing
Bug Tracker
Code
Transifex (Translate Sentry!)

View on GitHub

import * as Sentry from '@sentry/node';

Sentry.init({
  dsn: process.env.SENTRY_DSN,
  environment: process.env.NODE_ENV,
  tracesSampleRate: 0.2,
});

5) Playwright — Test the flows that actually make or break products

What it is: A browser automation and end-to-end testing framework for real user journeys.

Why it improves your project: Unit tests are great for logic. Playwright is how you protect the stuff people actually click, type, submit, and depend on.

Best for: login flows, checkout paths, onboarding, regression prevention, cross-browser testing, critical UI journeys.

A lot of products feel stable right up until somebody runs the real flow. One solid Playwright test for auth, payments, or signup often prevents the kind of regression that makes a team lose confidence in every release.

Links: Official · GitHub

microsoft / playwright

Playwright is a framework for Web Testing and Automation. It allows testing Chromium, Firefox and WebKit with a single API.

🎭 Playwright

Documentation | API reference

Playwright is a framework for web automation and testing. It drives Chromium, Firefox, and WebKit with a single API — in your tests, in your scripts, and as a tool for AI agents.

Get Started

Choose the path that fits your workflow:

Best for	Install
Playwright Test	End-to-end testing	`npm init playwright@latest`
Playwright CLI	Coding agents (Claude Code, Copilot)	`npm i -g @playwright/cli@latest`
Playwright MCP	AI agents and LLM-driven automation	`npx @playwright/mcp@latest`
Playwright Library	Browser automation scripts	`npm i playwright`
VS Code Extension	Test authoring and debugging in VS Code	Install from Marketplace

Playwright Test

Playwright Test is a full-featured test runner built for end-to-end testing. It runs tests across Chromium, Firefox, and WebKit with full browser isolation, auto-waiting, and web-first assertions.

Install

npm init playwright@latest

Or add manually:

npm i -D @playwright/test
npx playwright install

Write a test

import { test, expect

…

View on GitHub

import { test, expect } from '@playwright/test';

test('checkout completes successfully', async ({ page }) => {
  await page.goto('/checkout');
  await page.getByLabel('Email').fill('dev@example.com');
  await page.getByRole('button', { name: 'Pay now' }).click();
  await expect(page.getByText('Payment confirmed')).toBeVisible();
});

The exact moment your one "probably fine" user flow turns out to be the one thing that definitely needed an end-to-end test. Source: South Park on Giphy

6) Swagger / OpenAPI — Turn your API into a real contract

What it is: A specification-driven way to describe routes, payloads, auth requirements, and responses.

Why it improves your project: It makes your API explicit. That means better docs, fewer frontend/backend misunderstandings, easier integrations, and less behavior hidden in memory or tribal knowledge.

Best for: internal APIs, public APIs, SDK generation, backend teams, frontend handoff, partner integrations.

When the contract is written down, fewer things depend on guessing. That helps new teammates onboard faster, frontend work unblock earlier, and backend changes stop surprising everybody else.

Links: Official spec · Swagger UI · Representative repo

swagger-api / swagger-ui

Swagger UI is a collection of HTML, JavaScript, and CSS assets that dynamically generate beautiful documentation from a Swagger-compliant API.

Introduction

Swagger UI allows anyone — be it your development team or your end consumers — to visualize and interact with the API’s resources without having any of the implementation logic in place. It’s automatically generated from your OpenAPI (formerly known as Swagger) Specification, with the visual documentation making it easy for back end implementation and client side consumption.

General

👉🏼 Want to score an easy open-source contribution? Check out our Good first issue label.

🕰️ Looking for the older version of Swagger UI? Refer to the 2.x branch.

This repository publishes three different NPM modules:

swagger-ui is a traditional npm module intended for use in single-page applications that are capable of resolving dependencies (via Webpack, Browserify, etc.).
swagger-ui-dist is a dependency-free module that includes everything you need to serve Swagger UI in a server-side project, or a single-page application that can't resolve npm module dependencies.
swagger-ui-react is Swagger…

View on GitHub

openapi: 3.1.0
info:
  title: "Example API"
  version: 1.0.0
paths:
  /users/{id}:
    get:
      summary: Fetch a user
      parameters:
        - in: path
          name: id
          required: true
          schema:
            type: string
      responses:
        "200":
          description: "User returned successfully"

Frontend, backend, and QA when the API shape is finally written down in one place instead of floating around in chat history. Source: The Simpsons on Giphy

7) pompelmi — Secure the upload edge before it bites you

What it is: A Node.js file upload security tool that scans uploads in-process before you accept them.

Why it improves your project: Upload handling is one of the most underestimated attack surfaces in web apps. Extensions lie, MIME types can be spoofed, archives can be risky, and "we'll validate later" is how tiny assumptions become expensive incidents.

Best for: Express, Fastify, Koa, NestJS, Next.js, privacy-sensitive products, public upload flows, moderation-heavy apps.

Most teams spend more time styling the upload button than defending the upload pipeline. That is backwards. A tool like pompelmi helps you make verdict-based decisions before a file becomes your problem, which is exactly the kind of boring guardrail mature projects quietly rely on.

Repo: GitHub

Site: Project site

Demo: Live demo

import { scanBytes, STRICT_PUBLIC_UPLOAD } from 'pompelmi';

const report = await scanBytes(file.buffer, {
  filename: file.originalname,
  mimeType: file.mimetype,
  policy: STRICT_PUBLIC_UPLOAD,
  failClosed: true,
});

if (report.verdict !== 'clean') {
  return res.status(422).json({
    error: 'Upload blocked',
    verdict: report.verdict,
    reasons: report.reasons,
  });
}

If you handle user uploads in Node.js, this is the kind of layer that makes your project feel much more intentional. It is not just about malware. It is about treating MIME spoofing, risky archives, and uncertain files as security decisions instead of wishful thinking.

Repository preview

pompelmi / pompelmi

Open-source file upload security for Node.js. Scan files before storage to detect malware, MIME spoofing, and risky archives.

Pompelmi

In-process file upload security for Node.js. Inspect untrusted files before storage so your application can reject, quarantine, or accept with context.

Pompelmi helps reduce:

MIME / extension spoofing and magic-byte mismatches
risky archive structures such as ZIP bombs, traversal, and deep nesting
risky document and binary patterns such as PDF actions, Office macro hints, PE signatures, and polyglot files
store-first upload flows that need a clean / suspicious / malicious verdict before persistence
known malicious matches when you plug in YARA or another scanner

Install: npm install pompelmi

Quick Start

import { scanBytes, STRICT_PUBLIC_UPLOAD } from 'pompelmi';
const report = await scanBytes(file.buffer, {
  filename: file.originalname,
  mimeType: file.mimetype,
  policy: STRICT_PUBLIC_UPLOAD,
  failClosed: true,
});

if (report.verdict !== 'clean') {
  return res.status(422)

…

View on GitHub

Upload security usually feels optional right until it really, really is not.

8) Dependabot — Keep dependency drift from turning into real risk

What it is: GitHub's automated dependency update system for packages, containers, and workflow versions.

Why it improves your project: It keeps security and maintenance work moving in small increments instead of one painful cleanup sprint after months of neglect.

Best for: npm repos, Docker images, GitHub Actions workflows, libraries, apps with busy dependency trees.

Most dependency risk is boring right until it is suddenly not. Dependabot makes updates reviewable, visible, and routine, which is much better than discovering six months of drift during an incident or release crunch.

Links: Docs · GitHub

dependabot / dependabot-core

🤖 Dependabot's core logic for creating update PRs.

Welcome to the public home of Dependabot .

What is Dependabot-Core?

Dependabot-Core is the library at the heart of Dependabot security / version updates.

Use it to generate automated pull requests updating dependencies for projects written in Ruby, JavaScript, Python, PHP, Dart, Elixir, Elm, Go, Rust, Java, Julia, and .NET. It can also update git submodules, Docker files, Opentofu, Terraform files and Pre-Commit hooks. Features include:

Check for the latest version of a dependency that's resolvable given a project's other dependencies
Generate updated manifest and lockfiles for a new dependency version
Generate PR descriptions that include the updated dependency's changelogs, release notes, and commits

How to

…

View on GitHub

version: 2
updates:
  - package-ecosystem: npm
    directory: /
    schedule:
      interval: weekly
    open-pull-requests-limit: 5
  - package-ecosystem: github-actions
    directory: /
    schedule:
      interval: weekly

The face you make when a stale dependency turns into tonight's emergency patch window. Source: Family Guy on Giphy

9) Excalidraw — Think clearly before you build expensively

What it is: A fast, low-friction whiteboard for architecture sketches, flows, states, and system diagrams.

Why it improves your project: It helps teams see the system before they commit to the system. That reduces misalignment, hand-wavy assumptions, and long explanations nobody remembers later.

Best for: architecture reviews, sequence diagrams, onboarding docs, RFCs, async collaboration, state-flow discussions.

A five-minute sketch can save hours of wrong implementation. Excalidraw is especially good when a project keeps getting explained verbally but never gets turned into something the whole team can point at and improve together.

Links: Official · GitHub

excalidraw / excalidraw

Virtual whiteboard for sketching hand-drawn like diagrams

Excalidraw Editor | Blog | Documentation | Excalidraw+

An open source virtual hand-drawn style whiteboard.
Collaborative and end-to-end encrypted.

Create beautiful hand-drawn like diagrams, wireframes, or whatever you like.

Features

The Excalidraw editor (npm package) supports:

💯 Free & open-source.
🎨 Infinite, canvas-based whiteboard.
✍️ Hand-drawn like style.
🌓 Dark mode.
🏗️ Customizable.
📷 Image support.
😀 Shape libraries support.
🌐 Localization (i18n) support.
🖼️ Export to PNG, SVG & clipboard.
💾 Open format - export drawings as an .excalidraw json file.
⚒️ Wide range of tools - rectangle, circle, diamond, arrow, line, free-draw, eraser...
➡️ Arrow-binding & labeled arrows.
🔙 Undo / Redo.
🔍 Zoom and panning support.

Excalidraw.com

The app hosted at excalidraw.com is a minimal showcase of what you can build with Excalidraw. Its source code is part of this repository as well, and the app features:

📡 PWA support (works offline).
🤼 Real-time collaboration.
🔒 End-to-end…

View on GitHub

10) Raycast — Remove friction from the machine itself

What it is: A keyboard-first launcher and automation layer for local developer workflows.

Why it improves your project: Not every project improvement lives in the repo. Faster local execution means less context-switching, fewer tiny interruptions, and more energy left for the work that actually matters.

Best for: macOS-based developers, snippets, quick scripts, search, clipboard workflows, window control, micro-automation.

Raycast is one of those tools that quietly improves everything around your coding day. Opening the right folders, jumping to tickets, searching docs, running snippets, and triggering scripts faster sounds small until you notice how much time you stop wasting.

Links: Official · GitHub

raycast / extensions

Everything you need to extend Raycast.

Raycast Extensions

Raycast lets you control your tools with a few keystrokes. This repository contains all extensions that are available in the Raycast Store. It also includes documentation and examples of how to extend Raycast using React.

Getting Started

Visit https://developers.raycast.com to get started with our API. If you want to discover and install extensions, check out our Store.

Be sure to read and follow our Community and Extension guidelines and Acceptable Use Policy when submitting your extension and interacting with other folks in this repository.

Feedback

Raycast wouldn't be where it is without the feedback from our community, so we would be happy to hear what you think of the API / DevX and how we can improve. Please use GitHub issues for everything API related (bugs, improvements suggestions, developer experience, docs, etc). We have a few templates that should help you get started.

Community

Join our…

View on GitHub

What your laptop sees after you finally replace ten tiny daily interruptions with one keyboard-first workflow. Source: South Park on Giphy

Final thoughts

The projects people trust are rarely the ones with the flashiest feature list.

They are the ones where:

deploys are repeatable
APIs are easy to test
user flows are protected
production failures are visible
docs are explicit
uploads are treated like a real security boundary
dependencies do not rot quietly
ideas are clarified before code gets expensive

That is why good tooling matters so much.

It does not just make developers faster.
It makes projects better.

If you could add only one of these to your stack this week, which one would make the biggest difference?

7 Real Workflows That Actually Save Developers Hours

Tommaso Bertocchi — Thu, 02 Apr 2026 13:50:09 +0000

Most developers are still using AI like a novelty keyboard shortcut.

They ask it for regexes, toy apps, or random refactors, then wonder why the payoff feels small.

That is the wrong mental model.

The real value is not "write code for me." The real value is "remove the friction around engineering work."

GIF source: Salesforce on Giphy

The code itself is often not the slow part. The slow part is turning messy human input into something the codebase can actually absorb.

Bug reports are vague. Product requests are fuzzy. PRs hide edge cases. Logs are noisy. Meetings are chaos. Docs get written last. Migrations start with "should be fine" and end with regret.

That is where AI earns its keep.

TL;DR

Stop using AI for one-off tricks and start using it for repeatable engineering workflows.
The best workflows sit before coding or after coding, not just inside the editor.
AI is great at turning messy input into structured output.
Good outputs include test cases, checklists, review notes, implementation plans, and docs.
You still own the judgment.
You let the model handle the formatting, sorting, summarizing, and first-pass synthesis.
AI stops feeling like a toy when it becomes part of your process.

AI stops being impressive when you demo it.

It starts being useful when it handles the annoying parts of engineering.

1. Turn rough bug reports into reproducible test cases

The problem: most bug reports are written like crime scene poetry.

"Checkout is broken on mobile sometimes" is not a useful input. Neither is "I clicked around and it failed."

How AI helps: give it the report, any stack trace, and a bit of context. Ask it to turn that mess into a reproducible path, a test matrix, and candidate assertions.

Practical example: a PM drops this into Slack:

User says password reset fails after they open the email on iPhone and go back to the app.

That is not ready for engineering. AI can turn it into:

likely repro conditions
assumptions to verify
exact steps to test
likely layers involved
candidate integration or E2E test cases

Turn this bug report into a reproducible test plan.

Output:
- assumptions
- exact repro steps
- likely affected layers
- edge cases to test
- one candidate automated test

Bug report:
"User says password reset fails after they open the email on iPhone and go back to the app."

Why it saves time: you stop spending the first 30 minutes translating vague human language into engineer language.

2. Generate first-draft docs right after shipping a feature

The problem: docs are always "we'll do it after this PR lands." Then nobody does it.

How AI helps: after the feature ships, feed it the PR description, commit summary, config changes, and a couple of examples. Let it draft internal docs, release notes, or onboarding notes while the context is still fresh.

Practical example: you shipped a webhook retry system. You already have the raw ingredients:

PR summary
env vars added
retry rules
failure behavior
sample payloads

Turn that into a first draft immediately.

Turn these shipping notes into internal docs.

Output:
- what changed
- why it exists
- new config or env vars
- failure behavior
- examples
- what support/devs should know

Notes:
[paste PR description, commit summary, examples]

Why it saves time: blank-page writing is slow. Editing a decent first draft is fast.

3. Turn giant log dumps into structured debugging notes

The problem: logs are full of repetition, noise, and timing confusion. You end up scrolling forever and still do not have a clean theory.

How AI helps: ask it to cluster repeated errors, reconstruct the timeline, and separate symptoms from likely root causes.

Practical example: you paste in request logs, app errors, and one queue worker trace. Instead of "look through this," you ask for structure:

Analyze these logs and turn them into debugging notes.

Output:
- timeline of events
- repeated errors grouped together
- likely root causes
- signals that may be red herrings
- next 5 checks to run

Logs:
[paste logs]

Why it saves time: the model is doing triage, not fixing production. That is exactly where it is useful.

Optional deeper example
Instead of rereading 400 lines of logs, ask for output in this shape:

Timeline: request received, cache miss, DB timeout, retry, downstream 502
Recurring patterns: same tenant, same endpoint, same timeout window
Most likely causes: connection pool exhaustion, retry storm, slow downstream dependency
Checks to run now: inspect pool metrics, compare healthy tenant timings, sample failed request IDs, verify retry backoff, look for deploy correlation

That gives you a debugging worksheet instead of a wall of text.

4. Extract action items from messy meetings or issue threads

The problem: a single GitHub issue or Slack thread can contain decisions, half-decisions, contradictions, and silent assumptions.

How AI helps: make it extract owners, blockers, decisions, and unanswered questions in a format your team can actually act on.

Practical example: after a product meeting, you have rough notes plus a noisy thread with frontend, backend, and design comments mixed together. Ask AI to convert it into a clean action list.

Read this meeting transcript and issue thread.

Extract:
- decisions made
- open questions
- blockers
- owners if identifiable
- next actions

Format it as a concise engineering handoff.

Why it saves time: you stop rewriting the same conversation into tickets by hand.

5. Create migration checklists before touching code

The problem: upgrades fail because teams start with code changes instead of scope control.

How AI helps: before you touch the repo, use AI to generate a migration checklist that covers dependency risks, config changes, affected app areas, test plan, rollout risks, and rollback points.

GIF source: Microsoft Cloud on Giphy

Practical example: you need to upgrade a framework, SDK, or ORM. Do not begin with "let's bump the version and see what breaks."

Start here:

Create a migration checklist for this upgrade.

Context:
- current version: X
- target version: Y
- package list
- build/test scripts
- app patterns in use

Output:
- risky areas
- code patterns to audit
- config changes
- test plan
- rollout plan
- rollback plan

Why it saves time: migrations get expensive when you discover risk too late. A checklist is cheaper than a surprise.

6. Review PRs for edge cases and missing tests

The problem: most AI PR reviews are too polite and too shallow. "Looks good" is useless.

How AI helps: give it a diff and ask it to act like a skeptical reviewer. Not a cheerleader. Not a linter. A reviewer looking for behavioral gaps.

Practical example: a PR claims to "fix duplicate invoice sending." AI can inspect the patch and ask the questions a rushed human reviewer might miss:

what happens on retries?
what if the process crashes after write but before send?
what if two workers race?
where is the regression test?

Review this PR diff like a skeptical staff engineer.

Focus on:
- edge cases
- behavior changes not mentioned in the title
- missing tests
- rollback risk
- race conditions
- failure states

Diff:
[paste diff or summary]

Why it saves time: it gives you a second set of eyes on the logic, not just the syntax.

7. Turn vague product requests into implementation plans

The problem: product asks are often written at the wrong altitude. Too vague to estimate. Too specific to question. Dangerous combination.

How AI helps: use it to turn the request into an engineering plan with assumptions, scope boundaries, data changes, states, risks, and open questions.

Practical example: "We need users to pause subscriptions temporarily."

That sounds simple until you ask the obvious follow-ups:

billing implications?
proration?
expiration?
admin override?
analytics?
email flows?
API contract?
mobile states?
edge case when payment fails during resume?

Turn this product request into an implementation plan.

Output:
- assumptions
- open questions
- API/data model changes
- frontend states
- edge cases
- telemetry
- smallest shippable version
- risks

Request:
"We need users to pause subscriptions temporarily."

Why it saves time: you walk into planning with something sharper than vibes.

Toy Use vs Real Workflow

Toy use	Real workflow	Why the workflow wins
"Build me a Snake game"	Turn a product request into an implementation plan	It reduces ambiguity before code starts
"Write a regex for me"	Turn a vague bug report into a test case plan	It helps you reproduce and verify real bugs
"Summarize this file"	Review a PR for missing tests and edge cases	It finds risk, not just words
"Explain Docker like I'm five"	Create a migration checklist before an upgrade	It prevents expensive mistakes
"What does this stack trace mean?"	Convert logs into structured debugging notes	It gives you a path to investigate
"Write release notes"	Generate docs right after shipping from real changes	It captures context before it disappears
"Brainstorm app ideas"	Extract action items from meetings and issue threads	It turns conversation into execution

What Changed for Me

I stopped asking AI for brilliance.

I started asking it for leverage.

That changed everything.

I use it less like a genius intern and more like a formatting engine for engineering work. It is great at turning messy input into clean output:

vague report into test plan
raw logs into debugging notes
shipped code into docs
discussion into actions
request into scope

That is the pattern.

AI is not most useful in the middle of coding. It is often most useful at the handoff points around coding.

FAQ

Is this just ChatGPT with better prompts?

Not really. The important part is not the prompt text. It is the workflow shape. You are feeding AI messy inputs that already exist in your day and asking for structured outputs you actually use.

Should AI write production code too?

Sometimes, yes. But that is not the biggest unlocked value for most teams. Code generation gets attention. Workflow acceleration saves time more reliably.

What about privacy and security?

Use your brain. Do not paste secrets, private customer data, or sensitive production material into tools that are not approved for it. Redact first. Use the right environment. Treat AI like any other external system.

Won't this create more cleanup work?

Only if you ask for finished answers when you really need first drafts. The trick is to use AI for scaffolding, synthesis, and structure. You do the final judgment.

Conclusion

A lot of developers are disappointed by AI because they are using it for low-stakes parlor tricks.

The better use is boring on purpose.

It helps with the stuff that slows real work down: clarifying, organizing, checking, summarizing, planning, and documenting.

That is how it stops being a toy.

What workflow saves you the most time? Share it in the comments.

If you already have a workflow like this, I want to hear it. And if you think one of these is overrated, even better. Those are usually the best comment sections.

Most file upload security in Node.js is still just extension checks. That’s not enough. Pompelmi scans uploads before storage for MIME spoofing, risky archives, suspicious structures, and optional YARA. OSS, MIT. GitHub https://github.com/pompelmi/pompelmi

Tommaso Bertocchi — Thu, 02 Apr 2026 07:54:59 +0000

GitHub - pompelmi/pompelmi: Open-source file upload security for Node.js. Scan files before storage to detect malware, MIME spoofing, and risky archives. · GitHub

Open-source file upload security for Node.js. Scan files before storage to detect malware, MIME spoofing, and risky archives. - pompelmi/pompelmi

github.com

How I promoted my open-source security repo to 575 GitHub stars by treating it like a real product

Tommaso Bertocchi — Mon, 30 Mar 2026 10:37:49 +0000

When people talk about growing an open-source project, the advice usually sounds vague:

post on social media
share it on Reddit
write blog posts
keep shipping

That advice is not wrong, but it is incomplete.

What worked for me with Pompelmi was not “being everywhere.”
It was making the project easy to understand, easy to trust, and easy to discover in places where the right developers were already looking.

Pompelmi is an open-source file upload security tool for Node.js. It scans files before storage to help detect malware, MIME spoofing, risky archives, and other upload-related problems. It works with frameworks like Express, Next.js, NestJS, Fastify, and Koa.

At the time of writing, the repo has grown to hundreds of stars and picked up mentions from places like Stack Overflow, Help Net Security, Node Weekly, Detection Engineering Weekly, and Bytes.

I did not get there with paid ads.
I did not get there with a huge audience.
And I definitely did not get there from one viral post.

I got there by treating an open-source repo like a product that deserved positioning, packaging, distribution, and trust.

Here is exactly how I approached it.

1. I built around a painful problem that is easy to explain

A lot of open-source projects struggle because they are technically interesting but hard to describe in one sentence.

Pompelmi was different.

The core message is simple:

Your file upload endpoint is part of your attack surface.

That is something backend and security developers immediately understand.
A surprising number of apps still treat file uploads as a basic “accept file, save file” workflow, when in reality uploads can introduce malware, MIME spoofing, archive abuse, and downstream processing risks.

The project became easier to promote once I stopped describing it as a collection of scanning features and started describing it as a clear security layer for file uploads.

That positioning matters a lot.
If your project solves a problem people already worry about, distribution gets much easier.

2. I made the GitHub repo do the selling for me

A lot of traffic is wasted because people land on a repo and still do not understand:

what the project does
who it is for
why it matters
how to try it quickly

So I tried to make the repository itself act like a landing page.

That meant focusing on:

a clear headline
a sharp one-line value proposition
framework-specific examples
visible badges and trust signals
a social preview image
relevant GitHub topics
mentions from recognizable sources

In my experience, stars usually come after comprehension.
If someone has to read too much to understand the value, conversion drops.

A good open-source repo should answer this in seconds:

“Why should I care about this right now?”

If it cannot, growth gets harder no matter how good the code is.

3. I stopped thinking only about “promotion” and focused on distribution channels with intent

Not all traffic is equal.

A random viral post can bring views.
A highly relevant placement can bring users, stars, issues, contributors, and long-term trust.

For Pompelmi, the best distribution channels were not generic “look at my repo” posts.
They were places where developers were already thinking about:

file uploads
backend frameworks
Node.js security
web application security
malware scanning
upload validation

That changed how I spent my time.

Instead of chasing broad attention, I focused on channels where Pompelmi was obviously useful.

That included:

framework ecosystem pages and docs
developer newsletters
practical tutorials
curated lists
security-focused publications
posts that answer real implementation questions

This was slower than hype marketing, but much more durable.

4. I wrote for existing ecosystems instead of waiting for people to “find” the project

One of the best things I did was to move closer to where developers already work.

If someone is building with Fastify, Next.js, Express, Koa, or another Node.js framework, they are much more likely to adopt a tool when they discover it in a context they already trust.

That is why ecosystem visibility matters so much.

For an open-source dev tool, this can mean:

integration docs
example apps
framework-specific packages
PRs to community pages
entries in ecosystem lists
guides that show the tool inside real workflows

This is more effective than generic promotion because it reduces friction.
The user no longer has to imagine how your project fits into their stack.
You already showed them.

That has been especially important for Pompelmi, because it is not a standalone product people browse for fun. It is infrastructure. It has to feel practical, easy to slot in, and low-risk to try.

5. I treated every mention as leverage, not as a one-day win

One mistake I see often is that a project gets featured somewhere and the maintainer celebrates for 24 hours, then moves on.

A better approach is to turn every mention into a permanent trust asset.

Once Pompelmi started getting mentioned by recognizable publications and newsletters, I made sure to surface that credibility.

Why this matters:

it reassures first-time visitors
it increases perceived legitimacy
it gives future outreach more credibility
it compounds over time

When a new reader sees that your project has already been noticed by respected people or publications, they are more likely to take it seriously.

Trust is one of the biggest bottlenecks in open-source growth, especially in security.
If your project touches something sensitive like file scanning, people want reasons to believe it is real, maintained, and worth trying.

Mentions help with that.
But only if you actually use them well.

6. I wrote articles that create curiosity first, then route people into the repo

Another thing that helped a lot was writing content that was broader than the project itself.

If every post is “here is my repo,” people tune out.

But if the post is genuinely useful on its own, it can attract a wider audience and still send qualified traffic back to your work.

For example, list-style articles can work surprisingly well when done right.
Not because they are magical, but because they have built-in clarity:

readers know what they are getting
they are easy to skim
they create curiosity
they naturally expose multiple projects and ideas

That is especially useful on developer platforms where attention is competitive.

For Pompelmi, I found it better to mix different types of content:

practical tutorials
list articles
launch/update posts
ecosystem-specific examples
opinionated posts about a real problem

A tutorial can bring search traffic.
A list article can bring discovery.
An update post can re-activate existing followers.
Together, they create a loop.

7. I learned that consistency beats one big launch

A lot of people want one giant post that changes everything.
Sometimes that happens.
Usually it does not.

What usually works better is repeated exposure across relevant channels.

For an open-source project, that can look like:

shipping releases consistently
improving docs regularly
posting new examples
publishing tutorials
sharing integration updates
reaching out to relevant newsletters or blogs
submitting to framework/community pages

Each action on its own may look small.
Together, they create the feeling that the project is alive.

That feeling matters.
Developers do not just star code. They star momentum.

A maintained repo with fresh releases, better docs, ecosystem integrations, and outside mentions feels safer to trust than a clever repo that looks abandoned.

8. I made the project easier to adopt, not just easier to admire

A star is nice, but the things that usually create long-term growth are:

usage
word of mouth
references
integration into real apps

That means adoption matters more than aesthetics alone.

So beyond promotion, I tried to reduce practical friction:

make the README clearer
provide examples
support popular Node.js frameworks
keep the messaging concrete
show the exact use case quickly

This is especially important for technical tools.

If someone sees a repo and thinks “cool project,” that is nice.
If they think “I can add this to my upload pipeline today,” that is much better.

The second reaction is what creates compounding growth.

9. I leaned into credibility because security projects need it more than most

Security tooling has a higher trust bar than a casual utility library.

If your project claims to make file uploads safer, people naturally ask themselves:

is this maintained?
is this serious?
is this just marketing?
who is using it?
has anyone reputable noticed it?

That means credibility is part of distribution.
Not just code quality.

For me, credibility came from a mix of things:

consistent releases
clear scope
practical documentation
presence in real developer ecosystems
recognition from publications and newsletters
visible maintenance

The more serious the problem you are solving, the more important this becomes.

10. What I would tell someone trying to grow an open-source repo today

If I had to summarize the whole strategy in a few points, it would be this:

Build something with a sharp problem statement

If people cannot repeat what your project does in one sentence, growth will be harder.

Treat the repo like a product page

Your README, social preview, examples, and topics all matter.

Go where intent already exists

Ecosystem pages, newsletters, practical searches, tutorials, and framework communities are better than random exposure.

Turn every small win into a trust multiplier

A mention, a PR merge, a tutorial, a release, an integration: each one should strengthen the next.

Focus on repeated relevance

One post can help. A system of useful distribution points helps more.

What I would do next for Pompelmi

If I were pushing the project even harder from here, I would double down on five things:

More framework-specific tutorials

Not just “what Pompelmi is,” but “how to secure uploads in Express / Next.js / Fastify.”
More ecosystem placements

Community pages, official docs, plugin directories, curated security lists.
More comparison-driven content

For example: why file type validation is not enough, or why extension checks fail.
More proof-driven trust

Mentions, examples, case studies, and implementation patterns.
More discoverable educational content

Articles that solve the reader’s problem first, then naturally introduce the repo.

That is the real lesson I learned from promoting an open-source project:

Growth is rarely about shouting louder.
It is usually about making the project easier to understand, easier to trust, and easier to encounter in the right places.

And once that starts working, every new article, PR, mention, release, and integration becomes part of the same flywheel.

Final thought

A lot of people think open source “speaks for itself.”
Sometimes it does.
Usually it needs help.

If you built something genuinely useful, promoting it is not fake and it is not selfish.
It is part of the work.

That was the biggest shift for me.

I stopped thinking:

“How do I get people to notice my repo?”

And started thinking:

“How do I make this project impossible to ignore for the specific developers who need it?”

That mindset made everything else easier.

If you want to check out Pompelmi, the repo is here:

GitHub: github.com/pompelmi/pompelmi

How to Secure File Uploads in Next.js

Tommaso Bertocchi — Mon, 30 Mar 2026 08:14:09 +0000

File uploads are one of those features that look simple until you think about the security side.

A user uploads a file, your route accepts it, and everything seems fine.

But what if that file is not what it claims to be?

A renamed executable can look like a harmless PDF. A ZIP archive can hide traversal tricks or resource-exhaustion problems. A document can carry risky structures you would never catch by checking only the filename extension.

That is why upload endpoints are part of your attack surface.

In this article, I will show you how to secure file uploads in a Next.js App Router application by scanning them before storage with pompelmi, an open-source upload security tool for Node.js.

We will build a minimal example that:

accepts a file from a browser form
scans it on the server
returns a verdict
blocks suspicious or malicious uploads before they reach storage

Why file upload validation is usually too weak

A lot of upload handlers still rely on checks like these:

file.name.endsWith('.pdf')
file.type === 'application/pdf'
maximum size limits only

Those checks are still useful, but they are not enough.

The browser-provided MIME type can be wrong or misleading. The filename can be changed by the client. And some dangerous files look harmless until you inspect the actual bytes or the archive structure.

A safer model is:

receive the upload
inspect the file in-process
decide whether to allow, quarantine, or reject it
store only what passed the gate

That is exactly the role Pompelmi is designed for.

What we are going to build

We will use:

Next.js App Router
@pompelmi/next-upload for the upload route
pompelmi for the scanning logic and policy

At the end, you will have:

app/api/upload/route.ts
lib/security.ts
app/page.tsx

Install the packages

Inside your Next.js project, install the core package and the Next.js adapter:

npm install pompelmi @pompelmi/next-upload

Pompelmi requires Node.js 18+, and for Next.js uploads you should use the Node runtime, not the Edge runtime.

Create the security config

Create lib/security.ts:

import {
  CommonHeuristicsScanner,
  composeScanners,
  createZipBombGuard,
} from 'pompelmi';

export const policy = {
  includeExtensions: ['pdf', 'png', 'jpg', 'jpeg', 'zip', 'txt'],
  allowedMimeTypes: [
    'application/pdf',
    'image/png',
    'image/jpeg',
    'application/zip',
    'text/plain',
  ],
  maxFileSizeBytes: 20 * 1024 * 1024,
  timeoutMs: 5000,
  concurrency: 4,
  failClosed: true,
};

export const scanner = composeScanners(
  [
    [
      'zipGuard',
      createZipBombGuard({
        maxEntries: 512,
        maxTotalUncompressedBytes: 100 * 1024 * 1024,
        maxCompressionRatio: 12,
      }),
    ],
    ['heuristics', CommonHeuristicsScanner],
    // ['yara', YourYaraScanner],
  ],
  {
    parallel: false,
    stopOn: 'suspicious',
    timeoutMsPerScanner: 1500,
    tagSourceName: true,
  }
);

What this does

This setup gives you a practical upload gate:

includeExtensions limits which file extensions you accept
allowedMimeTypes defines which MIME types are allowed
maxFileSizeBytes blocks very large files early
failClosed: true makes the route safer if scanning fails or times out
createZipBombGuard(...) adds protection against hostile ZIP archives
CommonHeuristicsScanner adds built-in heuristic checks
composeScanners(...) lets you combine multiple scanners into one pipeline

You can keep this small at first and harden it later.

Create the upload route

Now create app/api/upload/route.ts:

import { createNextUploadHandler } from '@pompelmi/next-upload';
import { policy, scanner } from '@/lib/security';

export const runtime = 'nodejs';
export const dynamic = 'force-dynamic';

export const POST = createNextUploadHandler({
  ...policy,
  scanner,
});

That is the core of the integration.

The important part is this line:

export const POST = createNextUploadHandler({
  ...policy,
  scanner,
});

This creates a ready-to-use upload handler for your App Router route. It applies your policy and scanner before you decide to persist or process the file elsewhere.

Why `runtime = 'nodejs'` matters

The route must run in the Node.js runtime because file inspection is a server-side concern and the package is built for Node.js upload flows.

Create a minimal upload page

Now create app/page.tsx:

'use client';

import { useState } from 'react';

export default function HomePage() {
  const [result, setResult] = useState<any>(null);
  const [loading, setLoading] = useState(false);

  async function handleSubmit(event: React.FormEvent<HTMLFormElement>) {
    event.preventDefault();

    const form = event.currentTarget;
    const input = form.elements.namedItem('file') as HTMLInputElement;

    if (!input.files?.length) {
      return;
    }

    const formData = new FormData();
    formData.append('file', input.files[0]);

    setLoading(true);
    setResult(null);

    try {
      const response = await fetch('/api/upload', {
        method: 'POST',
        body: formData,
      });

      const data = await response.json();
      setResult({ status: response.status, data });
    } catch (error) {
      setResult({
        status: 500,
        data: { error: 'Request failed' },
      });
    } finally {
      setLoading(false);
    }
  }

  return (
    <main style={{ maxWidth: 720, margin: '40px auto', fontFamily: 'sans-serif' }}>
      <h1>Secure file upload demo</h1>
      <p>Upload a file and let the server inspect it before storage.</p>

      <form onSubmit={handleSubmit}>
        <input type="file" name="file" required />
        <button type="submit" disabled={loading} style={{ marginLeft: 12 }}>
          {loading ? 'Scanning...' : 'Upload'}
        </button>
      </form>

      {result && (
        <pre
          style={{
            marginTop: 24,
            padding: 16,
            border: '1px solid #ddd',
            borderRadius: 8,
            overflowX: 'auto',
          }}
        >
          {JSON.stringify(result, null, 2)}
        </pre>
      )}
    </main>
  );
}

This is intentionally simple.

It sends one file as multipart/form-data to /api/upload and prints the JSON response from the server.

What the response looks like

The exact shape can vary depending on your policy and scanner setup, but the important part is the verdict.

Typical verdicts are:

clean
suspicious
malicious

For example, a blocked upload might look conceptually like this:

{
  "ok": false,
  "error": "Upload blocked",
  "verdict": "suspicious",
  "reasons": [
    "MIME mismatch detected"
  ]
}

A clean upload may return something like:

{
  "ok": true,
  "verdict": "clean"
}

The key idea is that your application gets a policy decision at the upload boundary instead of blindly trusting the file.

Where to store the file

A common mistake is to store the file first and scan it later.

A safer pattern is:

receive upload
scan it immediately
only then write it to disk, object storage, or downstream processing

That way, unsafe files do not quietly enter the rest of your system.

In real apps, you would typically:

scan in the route
store only if the verdict is clean
log blocked attempts
surface a generic error to the client

Hardening ideas for production

This example is intentionally minimal, but here are the next things I would tighten in production.

1. Narrow the allowlist

Do not accept more file types than you actually need.

If your product only needs PDFs and PNGs, do not allow ZIP, TXT, or JPEG just because it is convenient.

2. Keep file size limits strict

Large uploads increase cost and risk.

Set the smallest maxFileSizeBytes that still works for your business case.

3. Fail closed

If scanning times out or a scanner crashes, the safe default is to reject the upload.

That is why failClosed: true is such a useful default for public-facing uploads.

4. Add signature scanning later if needed

The example above uses ZIP guards and heuristics. If your threat model requires deeper detection, you can extend the scanner pipeline with your own YARA-based scanner.

5. Keep upload routes on the server only

Do not move this logic into the client. The browser can help with UX, but the security decision belongs to the server.

Why this approach fits Next.js well

One thing I like about this setup is that it matches the way modern Next.js apps are built.

You do not need a separate scanning service just to get started.

You define:

one server route
one policy object
one scanner pipeline

And you can iterate from there.

That makes it practical for:

internal tools
SaaS dashboards
file submission forms
CMS-like workflows
apps that accept PDFs, images, or ZIP uploads

Final thoughts

If your application accepts file uploads, security should not start after the file has already been stored.

It should start at the upload gate.

With Next.js App Router and Pompelmi, you can add that decision point with a small amount of code and a much safer default.

The idea is simple:

inspect first
store later

If you want, I can also write follow-up articles such as:

How to secure file uploads in NestJS
How to secure file uploads in Fastify
Magic bytes vs MIME type for file uploads
How to protect against ZIP bombs in Node.js

Full example recap

`lib/security.ts`

import {
  CommonHeuristicsScanner,
  composeScanners,
  createZipBombGuard,
} from 'pompelmi';

export const policy = {
  includeExtensions: ['pdf', 'png', 'jpg', 'jpeg', 'zip', 'txt'],
  allowedMimeTypes: [
    'application/pdf',
    'image/png',
    'image/jpeg',
    'application/zip',
    'text/plain',
  ],
  maxFileSizeBytes: 20 * 1024 * 1024,
  timeoutMs: 5000,
  concurrency: 4,
  failClosed: true,
};

export const scanner = composeScanners(
  [
    [
      'zipGuard',
      createZipBombGuard({
        maxEntries: 512,
        maxTotalUncompressedBytes: 100 * 1024 * 1024,
        maxCompressionRatio: 12,
      }),
    ],
    ['heuristics', CommonHeuristicsScanner],
  ],
  {
    parallel: false,
    stopOn: 'suspicious',
    timeoutMsPerScanner: 1500,
    tagSourceName: true,
  }
);

`app/api/upload/route.ts`

import { createNextUploadHandler } from '@pompelmi/next-upload';
import { policy, scanner } from '@/lib/security';

export const runtime = 'nodejs';
export const dynamic = 'force-dynamic';

export const POST = createNextUploadHandler({
  ...policy,
  scanner,
});

`app/page.tsx`

'use client';

import { useState } from 'react';

export default function HomePage() {
  const [result, setResult] = useState<any>(null);
  const [loading, setLoading] = useState(false);

  async function handleSubmit(event: React.FormEvent<HTMLFormElement>) {
    event.preventDefault();

    const form = event.currentTarget;
    const input = form.elements.namedItem('file') as HTMLInputElement;

    if (!input.files?.length) {
      return;
    }

    const formData = new FormData();
    formData.append('file', input.files[0]);

    setLoading(true);
    setResult(null);

    try {
      const response = await fetch('/api/upload', {
        method: 'POST',
        body: formData,
      });

      const data = await response.json();
      setResult({ status: response.status, data });
    } finally {
      setLoading(false);
    }
  }

  return (
    <main style={{ maxWidth: 720, margin: '40px auto', fontFamily: 'sans-serif' }}>
      <h1>Secure file upload demo</h1>
      <p>Upload a file and let the server inspect it before storage.</p>

      <form onSubmit={handleSubmit}>
        <input type="file" name="file" required />
        <button type="submit" disabled={loading} style={{ marginLeft: 12 }}>
          {loading ? 'Scanning...' : 'Upload'}
        </button>
      </form>

      {result && <pre>{JSON.stringify(result, null, 2)}</pre>}
    </main>
  );
}

How to Scan File Uploads in Express

Tommaso Bertocchi — Sun, 29 Mar 2026 16:29:39 +0000

Many Express apps let users upload files.

That usually starts as a product feature:

profile pictures
resumes
PDFs
invoices
ZIP archives
documents sent to internal workflows

But an upload endpoint is also part of your attack surface.

A file can look harmless from its extension alone and still be risky once your app stores it, serves it, unzips it, or sends it to another system.

In this tutorial, we’ll build a simple Express upload route that scans files before storage using:

Express for the API
Multer for multipart/form-data
Pompelmi for file inspection

By the end, you’ll have a route that:

accepts a file upload
inspects the uploaded bytes
blocks suspicious or malicious files
only saves files that pass your policy

Why file uploads need scanning

A lot of upload pipelines still trust checks that are too shallow, such as:

the filename extension
the client-provided MIME type
a simple allowlist like .pdf, .jpg, .zip

That is not enough.

A safer pattern is:

receive the file
inspect it immediately
decide whether it is safe enough for your route
only then store or process it

That “inspect first, store later” approach is exactly what we’ll implement here.

What we’re using

Express

Express is the HTTP layer for our upload endpoint.

Multer

Multer is a Node.js middleware for handling multipart/form-data, which is the format commonly used for file uploads in Express apps.

For this tutorial, we’ll use memory storage so Multer gives us a Buffer in req.file.buffer. That makes it easy to scan the file before writing anything to disk.

Pompelmi

Pompelmi is an open-source file upload security library for Node.js. It can inspect uploaded files before storage and report a verdict such as clean, suspicious, or malicious.

It is designed to help catch issues such as:

MIME spoofing and magic-byte mismatches
risky archives
deep nesting and archive abuse
polyglot files
optional YARA-based matches

Project setup

Create a new folder and install the dependencies:

mkdir express-upload-scan
cd express-upload-scan
npm init -y
npm install express multer pompelmi

This tutorial assumes you are running a recent Node.js version supported by Pompelmi.

Build the upload route

Create a file named server.mjs:

import express from "express";
import multer from "multer";
import { mkdir, writeFile } from "node:fs/promises";
import { join } from "node:path";
import { randomUUID } from "node:crypto";
import { scanBytes, STRICT_PUBLIC_UPLOAD } from "pompelmi";

const app = express();
const port = process.env.PORT || 3000;

const upload = multer({
  storage: multer.memoryStorage(),
  limits: {
    fileSize: 10 * 1024 * 1024, // 10 MB
    files: 1,
  },
});

app.get("/", (_req, res) => {
  res.type("html").send(`
    <h1>Upload a file</h1>
    <form action="/upload" method="post" enctype="multipart/form-data">
      <input type="file" name="file" required />
      <button type="submit">Upload</button>
    </form>
  `);
});

app.post("/upload", upload.single("file"), async (req, res, next) => {
  try {
    if (!req.file) {
      return res.status(400).json({ error: "No file uploaded" });
    }

    const report = await scanBytes(req.file.buffer, {
      filename: req.file.originalname,
      mimeType: req.file.mimetype,
      policy: STRICT_PUBLIC_UPLOAD,
      failClosed: true,
    });

    if (report.verdict !== "clean") {
      return res.status(422).json({
        error: "Upload blocked",
        verdict: report.verdict,
        reasons: report.reasons,
      });
    }

    const uploadsDir = join(process.cwd(), "uploads");
    await mkdir(uploadsDir, { recursive: true });

    const safeName = `${randomUUID()}-${req.file.originalname}`;
    const destination = join(uploadsDir, safeName);

    await writeFile(destination, req.file.buffer);

    return res.status(201).json({
      ok: true,
      verdict: report.verdict,
      filename: safeName,
      size: req.file.size,
    });
  } catch (error) {
    next(error);
  }
});

app.use((err, _req, res, _next) => {
  if (err instanceof multer.MulterError) {
    return res.status(400).json({
      error: "Upload rejected by Multer",
      code: err.code,
      message: err.message,
    });
  }

  console.error(err);
  return res.status(500).json({ error: "Internal server error" });
});

app.listen(port, () => {
  console.log(`Server listening on http://localhost:${port}`);
});

Run it with:

node server.mjs

Then open http://localhost:3000 and upload a file.

How this works

Let’s break down the important parts.

1. Multer parses `multipart/form-data`

This line creates the upload middleware:

const upload = multer({
  storage: multer.memoryStorage(),
  limits: {
    fileSize: 10 * 1024 * 1024,
    files: 1,
  },
});

We are doing three useful things here:

using memory storage so the file is available as req.file.buffer
limiting the upload size to 10 MB
only allowing one file on this route

That matters because if you scan after writing to disk, you’ve already accepted and stored the file. In this example, we keep the file in memory long enough to inspect it first.

2. Pompelmi scans the uploaded bytes

This is the core step:

const report = await scanBytes(req.file.buffer, {
  filename: req.file.originalname,
  mimeType: req.file.mimetype,
  policy: STRICT_PUBLIC_UPLOAD,
  failClosed: true,
});

Here’s what each option is doing:

req.file.buffer: the actual uploaded file bytes
filename: useful metadata for policy checks and reporting
mimeType: the MIME type supplied by the upload layer
policy: STRICT_PUBLIC_UPLOAD: a strict policy suitable for untrusted public uploads
failClosed: true: if inspection fails unexpectedly, block the upload instead of letting it through

This is a much safer default than “best effort” validation on a public endpoint.

3. Only clean files get stored

This condition is the boundary between accepted and rejected uploads:

if (report.verdict !== "clean") {
  return res.status(422).json({
    error: "Upload blocked",
    verdict: report.verdict,
    reasons: report.reasons,
  });
}

If the verdict is not clean, the request stops there.

Only after the scan passes do we create the uploads/ directory and write the file to disk.

That ordering is the key idea of the whole tutorial.

Example responses

Clean upload

{
  "ok": true,
  "verdict": "clean",
  "filename": "a9f7f5f9-06d2-4aa9-a73e-31bcb84d9b29-document.pdf",
  "size": 48213
}

Blocked upload

{
  "error": "Upload blocked",
  "verdict": "suspicious",
  "reasons": [
    {
      "code": "mime-mismatch",
      "message": "Detected file signature does not match the declared MIME type"
    }
  ]
}

Your exact reasons output will depend on the file and the policy.

Test it with `curl`

You can also test the route from the terminal:

curl -F "file=@./test.pdf" http://localhost:3000/upload

Try it with:

a normal PDF
a renamed file with a misleading extension
a ZIP archive
a file that should be blocked by your policy

That gives you a quick way to verify the decision boundary of your route.

Why this pattern is better than extension checks

A lot of apps still do something like this:

const allowed = [".jpg", ".png", ".pdf"];

That is useful as a UX hint, but it is not a security boundary.

File names can be changed easily.

Client-provided MIME types can also be misleading.

A real upload defense should look at the file itself, not just the label attached to it.

Production notes

The example above is intentionally simple, but here are a few things you should think about before using this in production.

Set tight Multer limits

If you use memory storage, size limits matter.

Keep fileSize, files, and route-specific constraints as small as your product allows.

Keep error handling explicit

Multer and your scanner can fail for different reasons.

Return clear errors to clients, but avoid leaking unnecessary internal details.

Store only after inspection

Do not move the write-to-disk step before the scan.

Otherwise you lose the main security benefit.

Match policy to route risk

A public document upload endpoint, an internal admin tool, and an image-only avatar route do not all need the same policy.

Choose the strictness based on the trust level and the downstream processing pipeline.

Consider what happens after upload

Scanning at the boundary is a strong first layer, but also think about what your app does next:

Will the file be served back to users?
Will another service parse it?
Will you unzip it?
Will a worker transform it?

The more processing a file triggers, the more important your upload boundary becomes.

A smaller version if you already have `req.file`

If your app already uses Multer somewhere else, the minimal scanning step is just this:

import { scanBytes, STRICT_PUBLIC_UPLOAD } from "pompelmi";

const report = await scanBytes(req.file.buffer, {
  filename: req.file.originalname,
  mimeType: req.file.mimetype,
  policy: STRICT_PUBLIC_UPLOAD,
  failClosed: true,
});

if (report.verdict !== "clean") {
  return res.status(422).json({
    error: "Upload blocked",
    verdict: report.verdict,
    reasons: report.reasons,
  });
}

That is the core integration.

Final thoughts

If your Express app accepts user uploads, don’t treat that endpoint as a boring plumbing detail.

Treat it like a security boundary.

The simplest safe flow is:

receive the file
scan the bytes
block anything that is not clean
store only the files you trust enough to keep

That single change can make your upload pipeline much safer without turning your app architecture upside down.

If you want to try this approach, take a look at Pompelmi here:

GitHub: github.com/pompelmi/pompelmi
Docs: pompelmi.github.io/pompelmi

Forem: Tommaso Bertocchi

10 Best Cybersecurity Tools Every Developer Should Know (Including One You've Never Heard Of)

1. 🍋 pompelmi — Antivirus Scanning for Node.js

2. 🔍 Snyk — Find and Fix Vulnerabilities in Your Code

3. 🛡️ OWASP ZAP — The Classic Web App Scanner

4. 🔐 Vault by HashiCorp — Secrets Management

5. 🧱 Helmet.js — HTTP Security Headers for Express

6. 🕵️ Trivy — Container & IaC Vulnerability Scanner

7. 🔎 Semgrep — Static Analysis That Doesn't Suck

8. 🌐 Burp Suite Community Edition — Manual Pen Testing

9. 🔑 age — Modern File Encryption

10. 📋 npm audit — The One You're Already Ignoring

Summary Table

Final Thoughts

10 npm packages you will use in 2026

1. Hono — the web framework that actually stays out of your way

2. Drizzle ORM — SQL without losing your mind

3. Zod — runtime validation that TypeScript actually trusts

4. Vitest — tests that don't slow you down

5. Effect — error handling the way it should work

6. pompelmi — antivirus scanning for Node.js that actually works

pompelmi / pompelmi

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

pompelmi

Table of contents

Quickstart

How it works

7. ofetch — fetch that behaves like you expect

8. unstorage — one API for every storage backend

9. tsx — run TypeScript without a build step

10. oslo — auth primitives without the framework lock-in

The list at a glance

I tried every Node.js antivirus library. Here's what I found.

What I was actually looking for

The landscape (as of 2025)

1. clamscan (npm)

2. clamdjs

3. Random VirusTotal API wrappers

4. Cloud-native options (AWS Malware Protection, GCP Security Command Center)

pompelmi: the one I actually kept

pompelmi / pompelmi

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

pompelmi

Table of contents

Quickstart

How it works

Install

Usage

What makes it different

A realistic Express upload handler

The verdict (pun intended)

it will be for all 2026

10 Open-Source Projects You’ll Actually Use in 2026

read this

I Spent 3 Hours Adding Antivirus to My Express App. Then I Reduced It to 3 Lines.

I Spent 3 Hours Adding Antivirus to My Express App. Then I Reduced It to 3 Lines.

The Google Rabbit Hole

My First Attempt

The Daemon Problem

What I Actually Needed

pompelmi: ClamAV for Humans

Before (47 lines)

After (12 lines)

How It Works (The Boring Way)

Why Symbols, Not Strings?

"But What About Performance?"

The Point

10 Tools That Will Instantly Make Your Coding Projects Better

Table of Contents

1) GitHub Actions — Stop shipping manually

actions / starter-workflows

Accelerating new GitHub Actions workflows

Starter Workflows

Note

2) Postman — Make your API usable by more than its author

postmanlabs / newman

Newman is a command-line collection runner for Postman

newman the cli companion for postman

Table of contents

Getting started

1. `clamscan` (npm)

2. `clamdjs`

An open source virtual hand-drawn style whiteboard.
Collaborative and end-to-end encrypted.