DEV Community: AttractivePenguin

JSON Canvas: How to Build Interoperable Infinite Canvas Apps with an Open Format

AttractivePenguin — Tue, 21 Apr 2026 09:10:57 +0000

JSON Canvas: How to Build Interoperable Infinite Canvas Apps with an Open Format

Infinite canvas tools have exploded in popularity. Miro, Figma, Obsidian Canvas, Excalidraw — the spatial, freeform way of organizing information has become a dominant interface pattern. But there's a problem lurking beneath the surface: lock-in. Every canvas app stores your whiteboards, mind maps, and visual notes in its own proprietary format. Move to a different tool? Your data stays behind or arrives as a mangled export.

JSON Canvas is an open file format created to solve this. Originally built for Obsidian, it's now MIT-licensed and free for any application to adopt. In this article, we'll walk through the spec, implement a working parser and renderer, and explore real-world scenarios where adopting JSON Canvas can future-proof your application.

Why JSON Canvas Matters

The philosophy behind JSON Canvas is simple but powerful: your data belongs to you. When canvas files are stored in a documented, open, human-readable format, users gain:

Longevity — Files survive the apps that created them
Interoperability — Any tool can read and write the same canvas
Readability — JSON is easy to inspect, debug, and version-control
Extensibility — The spec leaves room for application-specific additions

This mirrors the success of Markdown for text. Before Markdown, notes were trapped in proprietary formats. After Markdown, portability became the norm. JSON Canvas aims to do the same for spatial data.

Understanding the Spec

A JSON Canvas file (.canvas extension) contains two top-level arrays:

{
  "nodes": [...],
  "edges": [...]
}

Both are optional — an empty canvas is valid.

Nodes

Nodes are the objects placed on the canvas. There are four types:

Type	Description	Required Extra Field
`text`	Plain text with Markdown	`text` (string)
`file`	Reference to a file	`file` (string path)
`link`	Reference to a URL	`url` (string)
`group`	Visual container	`label` (optional string)

Every node shares these required attributes:

{
  "id": "node1",
  "type": "text",
  "x": 100,
  "y": 200,
  "width": 300,
  "height": 200,
  "text": "Hello, Canvas!"
}

Optional fields include color (hex or preset "1"-"6"), subpath for file nodes (e.g., "#heading"), and background/backgroundStyle for group nodes.

Nodes are ordered by z-index — first in the array renders below, last renders on top.

Edges

Edges connect nodes with lines:

{
  "id": "edge1",
  "fromNode": "node1",
  "fromSide": "right",
  "fromEnd": "arrow",
  "toNode": "node2",
  "toSide": "left",
  "toEnd": "arrow",
  "color": "4",
  "label": "connects to"
}

fromSide and toSide can be top, right, bottom, or left. Endpoint shapes are none or arrow. Edges also support colors and labels.

Tutorial: Building a JSON Canvas Renderer

Let's build a minimal but functional canvas renderer in JavaScript that reads a .canvas file and renders it in the browser.

Step 1: The Canvas File

Create demo.canvas:

{
  "nodes": [
    {
      "id": "idea1",
      "type": "text",
      "x": 50,
      "y": 50,
      "width": 260,
      "height": 120,
      "text": "# Core Idea\nBuild tools that respect user data ownership.",
      "color": "4"
    },
    {
      "id": "idea2",
      "type": "text",
      "x": 400,
      "y": 50,
      "width": 260,
      "height": 120,
      "text": "# Why?\nProprietary formats create lock-in.",
      "color": "1"
    },
    {
      "id": "ref1",
      "type": "link",
      "x": 400,
      "y": 250,
      "width": 260,
      "height": 80,
      "url": "https://jsoncanvas.org"
    },
    {
      "id": "group1",
      "type": "group",
      "x": 30,
      "y": 20,
      "width": 660,
      "height": 340,
      "label": "Project Brainstorm"
    }
  ],
  "edges": [
    {
      "id": "e1",
      "fromNode": "idea1",
      "fromSide": "right",
      "toNode": "idea2",
      "toSide": "left",
      "label": "leads to"
    },
    {
      "id": "e2",
      "fromNode": "idea2",
      "fromSide": "bottom",
      "toNode": "ref1",
      "toSide": "top",
      "color": "5"
    }
  ]
}

Step 2: Parsing and Rendering

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>JSON Canvas Renderer</title>
  <style>
    #canvas {
      position: relative;
      width: 100vw;
      height: 100vh;
      background: #1e1e2e;
      overflow: auto;
    }
    .node {
      position: absolute;
      border-radius: 8px;
      border: 2px solid #444;
      padding: 12px;
      color: #cdd6f4;
      font-family: sans-serif;
      font-size: 14px;
      box-sizing: border-box;
      overflow: auto;
    }
    .node.group {
      background: rgba(69, 71, 90, 0.3);
      border: 2px dashed #585b70;
    }
    .node.link {
      background: #313244;
      border-color: #89b4fa;
    }
    .edge-label {
      position: absolute;
      background: #1e1e2e;
      color: #a6adc8;
      font-size: 12px;
      padding: 2px 6px;
      border-radius: 4px;
      pointer-events: none;
    }
    #edges {
      position: absolute;
      top: 0; left: 0;
      width: 100%; height: 100%;
      pointer-events: none;
    }
  </style>
</head>
<body>
  <div id="canvas">
    <svg id="edges"></svg>
  </div>
  <script type="module">
    const COLORS = {
      '1': '#f38ba8', '2': '#fab387', '3': '#f9e2af',
      '4': '#a6e3a1', '5': '#89dceb', '6': '#cba6f7'
    };

    function resolveColor(c) {
      if (!c) return '#585b70';
      return COLORS[c] || (c.startsWith('#') ? c : '#585b70');
    }

    async function renderCanvas(url) {
      const data = await fetch(url).then(r => r.json());
      const canvasEl = document.getElementById('canvas');
      const svgEl = document.getElementById('edges');

      const groups = (data.nodes || []).filter(n => n.type === 'group');
      const others = (data.nodes || []).filter(n => n.type !== 'group');

      for (const node of [...groups, ...others]) {
        const el = document.createElement('div');
        el.className = `node ${node.type}`;
        el.style.left = node.x + 'px';
        el.style.top = node.y + 'px';
        el.style.width = node.width + 'px';
        el.style.height = node.height + 'px';

        if (node.color) {
          el.style.borderColor = resolveColor(node.color);
        }

        if (node.type === 'text') {
          el.innerHTML = marked.parse(node.text || '');
        } else if (node.type === 'link') {
          el.innerHTML = `<a href="${node.url}" target="_blank" style="color:#89b4fa">${node.url}</a>`;
        } else if (node.type === 'group' && node.label) {
          el.innerHTML = `<strong>${node.label}</strong>`;
        }

        canvasEl.appendChild(el);
      }

      const nodeMap = {};
      for (const n of data.nodes || []) {
        nodeMap[n.id] = n;
      }

      for (const edge of data.edges || []) {
        const from = nodeMap[edge.fromNode];
        const to = nodeMap[edge.toNode];
        if (!from || !to) continue;

        const fx = from.x + from.width / 2;
        const fy = from.y + from.height / 2;
        const tx = to.x + to.width / 2;
        const ty = to.y + to.height / 2;

        const line = document.createElementNS('http://www.w3.org/2000/svg', 'line');
        line.setAttribute('x1', fx);
        line.setAttribute('y1', fy);
        line.setAttribute('x2', tx);
        line.setAttribute('y2', ty);
        line.setAttribute('stroke', resolveColor(edge.color));
        line.setAttribute('stroke-width', '2');

        if (edge.toEnd !== 'none') {
          line.setAttribute('marker-end', 'url(#arrow)');
        }

        svgEl.appendChild(line);

        if (edge.label) {
          const lbl = document.createElement('div');
          lbl.className = 'edge-label';
          lbl.textContent = edge.label;
          lbl.style.left = ((fx + tx) / 2 - 20) + 'px';
          lbl.style.top = ((fy + ty) / 2 - 10) + 'px';
          canvasEl.appendChild(lbl);
        }
      }
    }

    const svg = document.getElementById('edges');
    const defs = document.createElementNS('http://www.w3.org/2000/svg', 'defs');
    defs.innerHTML = '<marker id="arrow" markerWidth="10" markerHeight="7" refX="10" refY="3.5" orient="auto"><polygon points="0 0, 10 3.5, 0 7" fill="#cdd6f4"/></marker>';
    svg.appendChild(defs);

    renderCanvas('./demo.canvas');
  </script>
</body>
</html>

This gives you a working canvas renderer in ~120 lines. It handles all four node types, edges with labels and arrows, and the preset color system.

Step 3: Writing a Canvas File

Building a .canvas file programmatically is straightforward:

function createCanvas(nodes, edges) {
  return JSON.stringify({ nodes, edges }, null, 2);
}

const nodes = [
  { id: 'root', type: 'text', x: 400, y: 300, width: 200, height: 100,
    text: '# Project Alpha\nKickoff notes', color: '4' },
  { id: 'task1', type: 'text', x: 100, y: 100, width: 200, height: 80,
    text: '- Design mockups\n- API schema', color: '3' },
  { id: 'task2', type: 'text', x: 700, y: 100, width: 200, height: 80,
    text: '- Write tests\n- CI pipeline', color: '3' },
  { id: 'spec', type: 'file', x: 100, y: 500, width: 200, height: 80,
    file: 'docs/spec.md' }
];

const edges = [
  { id: 'e1', fromNode: 'root', fromSide: 'left', toNode: 'task1', toSide: 'right' },
  { id: 'e2', fromNode: 'root', fromSide: 'right', toNode: 'task2', toSide: 'left' },
  { id: 'e3', fromNode: 'root', fromSide: 'bottom', toNode: 'spec', toSide: 'top',
    color: '6' }
];

const canvasJson = createCanvas(nodes, edges);

Real-World Scenarios

1. Knowledge Management Tools

If you're building a PKM (Personal Knowledge Management) tool, adopting .canvas as your storage format means Obsidian users can import their canvases directly, and vice versa. Your tool immediately gains interoperability with an ecosystem of apps.

2. Collaborative Whiteboarding

Team whiteboard tools can use JSON Canvas as an export format. Even if your internal representation is more complex, a .canvas export gives teams a portable backup they can open in any compatible app — no vendor lock-in.

3. Documentation and Diagramming

Technical documentation often benefits from spatial layouts. A tool that generates .canvas files from API specs, database schemas, or architecture diagrams gives users an editable, version-controllable artifact they can refine in Obsidian or any other canvas app.

4. Git-Friendly Visual Documentation

Because .canvas files are plain JSON, they diff cleanly in git. Teams can track changes to visual documentation the same way they track code — with history, blame, and merge (JSON merges better than binary formats).

FAQ and Troubleshooting

Q: Can I add custom fields not in the spec?
A: Yes! The spec is intentionally extensible. Add your own fields to nodes and edges — other apps will simply ignore unknown fields. This is how you can add app-specific features without breaking compatibility.

Q: What about embedded images?
A: Use file type nodes referencing relative paths (e.g., "file": "assets/diagram.png"). For absolute URLs, use link type nodes.

Q: How do I handle canvas panning and zooming?
A: The spec doesn't define viewport state. Track pan/zoom in your app's state, not in the .canvas file. The file represents the content, not the view.

Q: My edges render behind nodes. What's wrong?
A: SVG elements render in document order. Make sure your SVG layer sits below the node layer in the DOM, or use z-index / pointer-events: none on the SVG (as shown in the tutorial).

Q: Can a node be inside a group?
A: Group membership is implicit — any node whose position falls within a group's bounds is visually inside it. The spec doesn't use explicit parent-child relationships, making it simpler to parse.

Q: What if two apps interpret preset colors differently?
A: That's by design. Preset "1" through "6" map to semantic colors (red through purple) but exact values are app-specific. This lets each app match its own brand while maintaining semantic consistency.

Conclusion

JSON Canvas represents an important shift in how we think about canvas-based applications. By adopting an open, readable format, we give users ownership of their spatial data — the same way Markdown liberated text notes and CSV liberated spreadsheets.

The spec is small and well-defined enough to implement in an afternoon, yet expressive enough for real applications. Whether you're building a new canvas tool, adding export to an existing one, or just want git-friendly visual documentation, JSON Canvas is worth your attention.

The official spec is a single page. The GitHub repo is open source under MIT. Pick it up, try the tutorial above, and give your users the portability they deserve.

Have you built something with JSON Canvas? I'd love to hear about it in the comments!

I Built an Uptime Monitor in a Weekend — And Saved $180/Year

AttractivePenguin — Mon, 20 Apr 2026 09:06:38 +0000

I was paying $15/month for Uptime Robot. I used maybe 30% of it — basic HTTP checks on a handful of endpoints, email alerts when something went down, and a status page nobody really looked at.

That's $180/year for a glorified cron job.

So I built my own. In a weekend. Here's exactly how, what I learned, and whether you should do the same.

Why Build Your Own?

Let's be clear: Uptime Robot, Pingdom, and friends are excellent services. If you're running production infrastructure at scale, use them. But if you're a solo developer or small team monitoring a handful of personal projects, side hustles, or staging environments, the math is painful:

Service	Free Tier	Paid Tier
Uptime Robot	50 monitors, 5-min intervals	$7-84/month
Pingdom	None	$15/month+
Better Stack	10 monitors, 3-min intervals	$24/month+

For my use case — 5-10 endpoints, 1-minute intervals, Slack alerts — the free tiers were too limited and the paid tiers were overkill.

What I actually needed:

HTTP health checks every 60 seconds
Response time tracking
Slack/email notifications on downtime
A simple dashboard to see current status

That's maybe 200 lines of code. Let me prove it.

Architecture

Here's the setup I landed on after experimenting:

┌─────────────┐     ┌──────────────┐     ┌─────────────┐
│   Scheduler  │────▶│  HTTP Check   │────▶│    SQLite   │
│  (node-cron) │     │  (fetch API)  │     │   (results) │
└─────────────┘     └──────────────┘     └─────────────┘
                            │
                            ▼
                    ┌──────────────┐
                    │   Alerter    │
                    │ (Slack/Email)│
                    └──────────────┘
                            │
                            ▼
                    ┌──────────────┐
                    │   Dashboard  │
                    │   (Express)  │
                    └──────────────┘

Why SQLite? Because this is a low-write, read-heavy workload that fits comfortably in a single file. No need to run a database server. If you're monitoring <1,000 endpoints, SQLite handles it effortlessly.

Why Node.js? Because the fetch API is built in (Node 18+), the async model fits perfectly for concurrent HTTP checks, and you probably already have it installed.

Step 1: Project Setup

mkdir uptime-monitor && cd uptime-monitor
npm init -y
npm install better-sqlite3 node-cron express dotenv

Create a .env file:

MONITOR_INTERVAL=1
SLACK_WEBHOOK_URL=https://hooks.slack.com/services/YOUR/WEBHOOK/HERE
ALERT_EMAIL=you@example.com
PORT=3000

Step 2: Database Setup

// db.js
const Database = require('better-sqlite3');
const db = new Database('monitor.db');

db.exec(`
  CREATE TABLE IF NOT EXISTS checks (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    url TEXT NOT NULL,
    status INTEGER,
    response_time_ms INTEGER,
    up INTEGER NOT NULL,
    checked_at DATETIME DEFAULT CURRENT_TIMESTAMP
  );

  CREATE INDEX IF NOT EXISTS idx_checks_url ON checks(url);
  CREATE INDEX IF NOT EXISTS idx_checks_checked_at ON checks(checked_at);
`);

// Prepared statements for performance
const insertCheck = db.prepare(`
  INSERT INTO checks (url, status, response_time_ms, up)
  VALUES (@url, @status, @response_time_ms, @up)
`);

const getRecentChecks = db.prepare(`
  SELECT * FROM checks
  WHERE url = ?
  ORDER BY checked_at DESC
  LIMIT ?
`);

module.exports = { db, insertCheck, getRecentChecks };

Using prepared statements is important here — you'll be inserting thousands of rows, and prepared statements are dramatically faster than raw queries.

Step 3: The Health Checker

// checker.js
const { insertCheck } = require('./db');

const ENDPOINTS = [
  { url: 'https://myapp.com', expectedStatus: 200 },
  { url: 'https://api.myapp.com/health', expectedStatus: 200 },
  { url: 'https://myportfolio.dev', expectedStatus: 200 },
];

async function checkEndpoint(endpoint) {
  const start = Date.now();
  try {
    const response = await fetch(endpoint.url, {
      signal: AbortSignal.timeout(10000), // 10s timeout
    });
    const response_time_ms = Date.now() - start;
    const up = response.status === endpoint.expectedStatus ? 1 : 0;

    insertCheck.run({
      url: endpoint.url,
      status: response.status,
      response_time_ms,
      up,
    });

    return { url: endpoint.url, up, status: response.status, response_time_ms };
  } catch (err) {
    const response_time_ms = Date.now() - start;
    insertCheck.run({
      url: endpoint.url,
      status: null,
      response_time_ms,
      up: 0,
    });

    return { url: endpoint.url, up: false, error: err.message, response_time_ms };
  }
}

async function runAllChecks() {
  const results = await Promise.allSettled(
    ENDPOINTS.map(ep => checkEndpoint(ep))
  );
  return results.map(r => r.value || r.reason);
}

module.exports = { runAllChecks, ENDPOINTS };

Key detail: AbortSignal.timeout(10000) is a Node.js 18+ feature that gives you a clean timeout without manual AbortController plumbing. If you're on an older Node version, use setTimeout + AbortController.

Step 4: Alerting

// alerter.js
require('dotenv').config();
const { getRecentChecks } = require('./db');

const SLACK_WEBHOOK = process.env.SLACK_WEBHOOK_URL;
const COOLDOWN_MINUTES = 5; // Don't spam — alert once per 5 min per endpoint

async function sendSlackAlert(url, status, responseTime) {
  if (!SLACK_WEBHOOK) return;

  const emoji = status === null ? '🔴' : '🟡';
  const message = status === null
    ? `${emoji} *DOWN*: ${url} — Connection failed (${responseTime}ms)`
    : `${emoji} *DEGRADED*: ${url} — Got ${status} (${responseTime}ms)`;

  await fetch(SLACK_WEBHOOK, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ text: message }),
  });
}

// Simple cooldown: only alert if last check was UP
async function shouldAlert(url) {
  const recent = getRecentChecks.all(url, 2);
  if (recent.length < 2) return true; // First checks — always alert on down
  // Only alert if the previous check was UP (prevents spam)
  return recent[1].up === 1;
}

async function processAlerts(results) {
  for (const result of results) {
    if (!result.up) {
      const shouldSend = await shouldAlert(result.url);
      if (shouldSend) {
        await sendSlackAlert(result.url, result.status, result.response_time_ms);
      }
    }
  }
}

module.exports = { processAlerts };

The cooldown logic is critical. Without it, you'll get a Slack message every single minute something is down. With it, you only get alerted at the transition — when a site goes from UP to DOWN. Add a recovery notification the same way.

Step 5: Dashboard (30 Lines)

// server.js
const express = require('express');
const { db, getRecentChecks } = require('./db');
const { ENDPOINTS } = require('./checker');

const app = express();

app.get('/', (req, res) => {
  const statuses = ENDPOINTS.map(ep => {
    const checks = getRecentChecks.all(ep.url, 60); // Last 60 checks
    const current = checks[0];
    const uptimePercent = checks.filter(c => c.up).length / checks.length * 100;
    const avgResponseTime = checks.reduce((sum, c) => sum + c.response_time_ms, 0) / checks.length;

    return {
      url: ep.url,
      up: current?.up ?? false,
      status: current?.status,
      responseTime: current?.response_time_ms,
      uptime: uptimePercent.toFixed(1),
      avgResponseTime: Math.round(avgResponseTime),
    };
  });

  res.send(`
    <html><head><title>Uptime Monitor</title>
    <style>
      body { font-family: system-ui; max-width: 800px; margin: 2rem auto; padding: 0 1rem; }
      .endpoint { border: 1px solid #ddd; border-radius: 8px; padding: 1rem; margin: 0.5rem 0; }
      .up { border-left: 4px solid #22c55e; } .down { border-left: 4px solid #ef4444; }
      .dot { display: inline-block; width: 12px; height: 12px; border-radius: 50%; margin-right: 8px; }
      .dot.up { background: #22c55e; } .dot.down { background: #ef4444; }
    </style></head><body>
    <h1>📊 Uptime Monitor</h1>
    ${statuses.map(s => `
      <div class="endpoint ${s.up ? 'up' : 'down'}">
        <span class="dot ${s.up ? 'up' : 'down'}"></span>
        <strong>${s.url}</strong><br>
        Status: ${s.status || 'N/A'} | Response: ${s.responseTime || 'N/A'}ms |
        Uptime (1hr): ${s.uptime}% | Avg: ${s.avgResponseTime}ms
      </div>
    `).join('')}
    <p style="color:#888;margin-top:2rem">Checks every ${process.env.MONITOR_INTERVAL || 1} min</p>
    </body></html>
  `);
});

app.listen(process.env.PORT || 3000);

No React, no bundler, no CSS framework. Just server-rendered HTML. It loads in under 100ms and shows everything you need at a glance.

Step 6: Tie It All Together

// index.js
require('dotenv').config();
const cron = require('node-cron');
const { runAllChecks } = require('./checker');
const { processAlerts } = require('./alerter');
require('./server'); // Start dashboard

// Run every minute (or adjust the cron expression)
const interval = process.env.MONITOR_INTERVAL || 1;
cron.schedule(`*/${interval} * * * *`, async () => {
  console.log(`[${new Date().toISOString()}] Running checks...`);
  const results = await runAllChecks();
  await processAlerts(results);

  const downCount = results.filter(r => !r.up).length;
  if (downCount > 0) {
    console.log(`⚠️  ${downCount} endpoint(s) DOWN`);
  } else {
    console.log(`✅ All ${results.length} endpoints UP`);
  }
});

console.log('🚀 Uptime monitor running. Dashboard at http://localhost:3000');

node index.js

That's it. You now have a fully functional uptime monitor with alerting and a dashboard.

Real-World Scenarios

Personal Projects (What I Built This For)

I monitor 7 endpoints across 3 personal projects. The total cost is $0/month, running on a $4 DigitalOcean droplet that's also hosting the projects themselves. Response time data lives in a 12MB SQLite file.

Small Team (2-5 People)

Add Slack alerting per channel (one per service), and you've got team-wide visibility. Rotate the SQLite database monthly with a cron job that archives old data. You're still at $0.

The Cost Comparison

Approach	Monthly Cost	Annual Cost
Uptime Robot (Pro)	$7	$84
Pingdom	$15	$180
Better Stack	$24	$288
This solution	$0*	$0*

*Assuming you already have a server. If not, a $4/month droplet handles this + your apps.

FAQ

What if my monitor server goes down?

This is the classic "who monitors the monitor?" problem. Two options: (1) Use a free-tier external service as a backup check on your monitor, or (2) Set up a simple healthcheck on a separate $0 cloud function. For personal projects, this edge case rarely matters.

Can I scale this to 1,000+ endpoints?

Yes, but switch SQLite to PostgreSQL. Add connection pooling and batch your inserts. The checker logic stays the same.

What about SSL certificate monitoring?

Add this check to checker.js:

const https = require('https');
function checkSSLCert(url) {
  return new Promise((resolve) => {
    const req = https.request(url, { method: 'HEAD' }, (res) => {
      const cert = res.socket.getPeerCertificate();
      const daysLeft = Math.floor(
        (new Date(cert.valid_to) - Date.now()) / (1000 * 60 * 60 * 24)
      );
      resolve({ valid: daysLeft > 0, daysLeft, issuer: cert.issuer?.O });
    });
    req.on('error', () => resolve({ valid: false }));
    req.end();
  });
}

How do I handle cron in production?

Use PM2 for process management: pm2 start index.js --name uptime-monitor. It handles restarts, logs, and monitoring. No Docker needed for something this simple.

Won't SQLite corrupt under concurrent writes?

SQLite uses WAL mode by default with better-sqlite3. For this workload (one write per minute per endpoint), corruption is essentially impossible. If you're worried, add db.pragma('journal_mode = WAL'); explicitly.

What I Learned

Most monitoring features are noise. I was paying for 40+ integrations, custom status pages, and team management I never used. Identify what you actually need.
SQLite is underrated. For read-heavy monitoring data with infrequent writes, it's perfect. Don't default to PostgreSQL for everything.
Alerting is harder than monitoring. The checking part is trivial. The hard part is not alerting — cooldowns, deduplication, and escalation policies. Keep it simple at first.
Server-rendered HTML is fine. My dashboard is 30 lines of template literals and loads instantly. Not everything needs React.
Own your data. When Uptime Robot had an outage last year, I couldn't access my monitoring data. With SQLite on my own server, that data is always mine.

Conclusion

Building a custom uptime monitor took me a weekend, costs nothing to run, and does exactly what I need. No feature bloat, no subscription, no vendor lock-in.

That said — if you're running production systems at a company, use a real service. Monitoring is critical infrastructure. The $15/month is worth the reliability, compliance, and support. But for personal projects and small teams? Roll your own. It's more fun, you'll learn something, and you'll save money.

The full code is available in the examples above — copy, paste, deploy. If you build something with this, I'd love to hear about it.

Happy monitoring! 🚀

The Vercel April 2026 Security Incident: What Every Developer Actually Needs to Know

AttractivePenguin — Mon, 20 Apr 2026 08:31:20 +0000

When 694 Hacker News points and a parallel Lobsters thread blow up in the same day, something real happened. Here's the breakdown — and more importantly, what you should do about it.

Last week, Vercel dropped a security bulletin that landed at the top of Hacker News and quickly spread to Lobsters, Reddit, and every tech Slack you belong to. The reaction wasn't just "oh no, another breach" — it was something sharper: we trusted this platform with our entire deployment pipeline, and now what?

If you haven't read the full incident report yet, don't worry. I have. Let me save you the corporate-speak and tell you what actually happened, why it matters even if you're not on Vercel, and what concrete steps you should take this week.

What Happened

Vercel's April 2026 incident involved a compromise in their edge function infrastructure. Without overstating what's been publicly confirmed: environment variables — including secrets stored in Vercel's project settings — were potentially exposed in a subset of deployments during a window in early April.

The attack vector exploited a misconfiguration in how Vercel's build pipeline isolated tenant environments during a rollout of their updated edge runtime. In plain terms: the wall between your project's environment and another tenant's wasn't airtight for a brief period, and a sophisticated actor noticed.

Vercel's detection was reasonably fast — hours, not days — and they rotated affected credentials server-side before the bulletin went out. But here's the thing: by the time they detected it, the exposure window had already closed. They were doing forensics on what had already happened, not stopping an active attack.

That's the uncomfortable truth about most cloud platform incidents.

Why This Hit Different

Every week there's some breach somewhere. Most devs scroll past. This one stuck because it violated a core psychological contract.

The pitch of platforms like Vercel is: stop worrying about infrastructure, just ship. Environment variables are the canonical example. You don't manage .env files in production — you just drop your DATABASE_URL and STRIPE_SECRET_KEY into the dashboard and trust the platform to keep them locked down.

That trust is the product. And when it cracks, even briefly, even with a fast response, the questions start:

How many of my secrets were actually exposed?
How would I even know if something was accessed?
What's my blast radius if a bad actor grabbed my production database credentials?

Most developers can't answer the third question. That's the real problem this incident surfaced.

The Supply Chain Angle Nobody's Talking About Enough

The HN thread (predictably) devolved into a Vercel vs. self-hosted debate within 20 comments. That's the wrong framing.

The more interesting angle: this is a supply chain problem wearing a platform problem's clothes.

Your app doesn't just run on Vercel. It runs on Vercel, which runs on AWS, which uses third-party edge PoPs, which might involve CDN providers — each layer has its own security posture you're implicitly trusting. When you push to main and it "just works," you're actually delegating trust across a dependency chain you've never audited.

This isn't unique to Vercel. It's true of Netlify, Railway, Render, Fly.io — any managed deployment platform. The convenience is real; so is the opaqueness.

The lesson isn't "self-host everything" (please don't, unless you genuinely enjoy 3am PagerDuty alerts). The lesson is know your trust surface.

Concrete Steps You Should Take This Week

Enough analysis. Here's what to actually do.

1. Audit Your Stored Secrets Right Now

# If you use the Vercel CLI, list your project's env vars
vercel env ls --environment=production

# Cross-reference against what should be there
# Look for anything that shouldn't exist or has an unexpected value

If anything looks off, rotate it immediately — not "when you get a chance." Now.

2. Scope Your Database Credentials

This is the one that will save you when (not if) credentials leak somewhere.

-- Don't give your app a superuser credential
-- Create a role scoped to exactly what it needs

CREATE ROLE app_user LOGIN PASSWORD 'your-password';
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO app_user;

-- Explicitly deny what it shouldn't touch
REVOKE ALL ON TABLE audit_log FROM app_user;
REVOKE ALL ON TABLE admin_settings FROM app_user;

If your production DATABASE_URL is a superuser — change that this week. A compromised credential to a read/write-limited role is a bad day. A compromised superuser credential is an existential event.

3. Implement Secret Rotation (Actually, Not In Theory)

Most teams have "we should rotate secrets periodically" somewhere in a Notion doc that nobody reads. Here's a minimal setup using GitHub Actions that forces you to think about it:

# .github/workflows/secret-rotation-reminder.yml
name: Secret Rotation Reminder

on:
  schedule:
    - cron: '0 9 1 * *'  # First of every month, 9am

jobs:
  remind:
    runs-on: ubuntu-latest
    steps:
      - name: Create rotation issue
        uses: actions/github-script@v7
        with:
          script: |
            github.rest.issues.create({
              owner: context.repo.owner,
              repo: context.repo.repo,
              title: `[Security] Monthly secret rotation — ${new Date().toISOString().slice(0,7)}`,
              body: `## Secrets to review this month\n\n- [ ] Database credentials\n- [ ] API keys (Stripe, SendGrid, etc.)\n- [ ] Webhook signing secrets\n- [ ] OAuth client secrets\n\nRotate anything that hasn't been rotated in 90+ days.`,
              labels: ['security']
            })

Annoying? A little. Better than discovering you haven't rotated your Stripe key in two years when someone starts making fraudulent charges? Yes.

4. Enable Audit Logging on Your Critical Services

If you're using Supabase, PlanetScale, or any modern database platform, they have audit log features. Turn them on. Most people don't because it's buried in the settings and nobody thinks they'll need it.

You will need it exactly when you can't afford to not have it.

# Supabase: audit logging is under Settings > Logs
# PlanetScale: Audit log is under your organization settings
# AWS RDS: Enable CloudTrail + RDS logs in parameter group

# Minimal CloudWatch log subscription for RDS slow/error logs:
aws rds modify-db-instance \
  --db-instance-identifier your-instance \
  --cloudwatch-logs-export-configuration '{"EnableLogTypes":["error","audit"]}' \
  --apply-immediately

5. Know Your Blast Radius Before You Need To

Right now, before anything bad happens: write a one-pager (or even a Slack message to yourself) answering these questions:

If my production DATABASE_URL leaked, what could an attacker do?
If my STRIPE_SECRET_KEY leaked, how quickly could I revoke it and what's the damage window?
If my OAuth client secret leaked, who can I call to rotate it immediately?
What's the escalation path if I discover a breach at 2am on a Saturday?

This isn't paranoia. It's the same reason you write a runbook before your service goes down, not after.

The Broader Takeaway on Platform Trust

Vercel handled this incident reasonably well by industry standards — fast detection, proactive rotation, transparent communication. But "reasonably well" in the security industry is a low bar, and this response doesn't change the underlying dynamic.

Centralized edge infrastructure is a single point of failure. When you consolidate deployments onto one platform, you get convenience, great DX, and impressive performance numbers. You also get correlated risk — an incident at Vercel affects thousands of companies simultaneously in a way that a self-hosted setup never could.

That's not an argument against Vercel. It's an argument for not treating "deployed to Vercel" as "secured."

Your platform handles runtime isolation. You still own:

Credential hygiene
Blast radius scoping
Monitoring and detection
Incident response playbooks

The platform is a vendor. Treat it like one — with trust, but with verification.

Hot Take Corner

Here it is, since we're being honest: the "just push to prod" culture has made the average developer dangerously under-practiced at security fundamentals.

When you self-host, you're forced to think about firewalls, network segmentation, credential management — because nothing works until you do. When the platform handles it, those muscles atrophy. The Vercel incident is a stress test that revealed how many devs don't know their blast radius, don't have rotation procedures, and don't have audit logs turned on.

The platform didn't fail you. The ecosystem of "don't worry about it, just ship" set unrealistic expectations about what platforms are responsible for and what you still need to own.

What's Next

Watch Vercel's follow-up communications closely — specifically whether they announce architectural changes to tenant isolation, not just "we've improved our monitoring." The latter is table stakes. The former is what actually prevents recurrence.

If you're evaluating deployment platforms right now, add tenant isolation architecture to your vendor questions. It's not fun to ask, but it's the right question.

And if this incident made you realize you can't answer "what's my blast radius" — block two hours this week. Write it down. You'll sleep better.

What did I miss? Drop your take in the comments — especially if you were directly affected and are willing to share what your response looked like.

How a Shell Script Can Compile C Code: Inside C89cc

AttractivePenguin — Sun, 19 Apr 2026 09:06:57 +0000

You read that right. There exists a complete C89/ELF64 compiler written entirely in portable shell script. No C bootstrap. No Python helper. No cheating. Just pure, unadulterated /bin/sh.

It's called c89cc, and when it hit 117 points on Hacker News, the developer community's collective jaw hit the floor. Because if you can write a C compiler in shell script, what can't you do with shell?

In this article, we'll explore how c89cc works, why it matters, and what you can learn from it — whether you're a shell scripting enthusiast, a compiler nerd, or just someone who appreciates a beautiful engineering feat.

Why This Matters

Shell scripting is the duct tape of the Unix world. We use it for CI pipelines, deployment scripts, system administration, and quick automations. But a compiler? That's supposed to be the domain of lex, yacc, LLVM, and carefully crafted C/C++ codebases spanning hundreds of thousands of lines.

c89cc challenges that assumption. It proves that shell scripting is far more capable than most developers give it credit for. More importantly, it's an incredible educational tool: by reading a compiler written in shell, you can understand every layer of the compilation pipeline without getting lost in macro magic or template metaprogramming.

Three reasons you should care:

It demystifies compilers. Shell is readable. When the lexer, parser, and code generator are all written in shell, you can trace exactly how source code becomes a binary.
It pushes shell's limits. Understanding how the author handled memory, string processing, and binary output in pure shell teaches you techniques you'll use in everyday scripting.
It's just cool. Sometimes engineering should be about the joy of "because I can."

How c89cc Works: The Compilation Pipeline

Like any compiler, c89cc follows the standard pipeline: preprocessing, lexical analysis, parsing, semantic analysis, and code generation. The difference is that every stage is shell functions operating on text files and shell variables.

Step 1: Preprocessing

The preprocessor handles #include, #define, and conditional compilation. In c89cc, this is done with sed, awk, and shell functions that expand macros line by line.

# Simplified view of how c89cc might handle #define expansion
preprocess() {
    while IFS= read -r line; do
        case "$line" in
            '#define'*)
                name=$(echo "$line" | awk '{print $2}')
                value=$(echo "$line" | awk '{print $3}')
                eval "define_${name}=\"${value}\""
                ;;
            *)
                # Expand known macros
                for macro in $(set | grep '^define_' | cut -d= -f1); do
                    mname="${macro#define_}"
                    line="${line//${mname}/${!macro}}"
                done
                echo "$line"
                ;;
        esac
    done < "$1"
}

Step 2: Lexical Analysis (Tokenization)

The lexer breaks C source into tokens — keywords, identifiers, operators, literals, and punctuation. In c89cc, this is implemented as a state machine using shell case statements and pattern matching.

# Simplified token categorization
tokenize() {
    local char="$1"
    case "$char" in
        [a-zA-Z_])  echo "IDENTIFIER" ;;
        [0-9])       echo "NUMBER" ;;
        '+')         echo "PLUS" ;;
        '-')         echo "MINUS" ;;
        '*')         echo "STAR" ;;
        '/')         echo "SLASH" ;;
        ';')         echo "SEMICOLON" ;;
        '{')         echo "LBRACE" ;;
        '}')         echo "RBRACE" ;;
        *)           echo "UNKNOWN:$char" ;;
    esac
}

The real lexer is far more sophisticated — handling multi-character operators (==, !=, &&), string literals with escape sequences, and comments. But the core idea remains: a shell case statement driving a state machine.

Step 3: Parsing (Building the AST)

The parser consumes tokens and builds an Abstract Syntax Tree. c89cc uses a recursive descent parser — each grammar rule is a shell function that calls other shell functions.

# Recursive descent: parse an expression
parse_expression() {
    local left=$(parse_term)
    while [ "$current_token" = "PLUS" ] || [ "$current_token" = "MINUS" ]; do
        local op="$current_token"
        advance_token
        local right=$(parse_term)
        left="{$op, $left, $right}"
    done
    echo "$left"
}

parse_term() {
    local left=$(parse_factor)
    while [ "$current_token" = "STAR" ] || [ "$current_token" = "SLASH" ]; do
        local op="$current_token"
        advance_token
        local right=$(parse_factor)
        left="{$op, $left, $right}"
    done
    echo "$left"
}

parse_factor() {
    case "$current_token" in
        "NUMBER")  local val="$current_value"; advance_token; echo "$val" ;;
        "IDENTIFIER") local name="$current_value"; advance_token; echo "$name" ;;
        "LPAREN")  advance_token; local expr=$(parse_expression); advance_token; echo "$expr" ;;
    esac
}

Each function returns its sub-tree as a string (shell's only real data structure), and the parent function combines them. It's functional programming in shell — and it works.

Step 4: Code Generation (ELF64 Output)

This is where it gets wild. c89cc generates a valid ELF64 binary — headers, section tables, program headers, and x86-64 machine code — all by writing raw bytes using shell's printf with octal escapes.

# Writing the ELF header (simplified)
write_elf_header() {
    # Magic number: 0x7f 'E' 'L' 'F'
    printf '\177ELF' > "$output"
    # ELFCLASS64
    printf '\002' >> "$output"
    # Little endian
    printf '\001' >> "$output"
    # ELF version
    printf '\001' >> "$output"
    # OS/ABI, padding
    printf '\000' >> "$output"
    printf '%0.s\000' {1..8} >> "$output"
    # ET_EXEC (executable file)
    printf '\002\000' >> "$output"
    # EM_X86_64
    printf '\062\000' >> "$output"
    # ...
}

The code generator traverses the AST and emits x86-64 instructions using the same printf technique. Each CPU opcode is encoded as its byte sequence.

Real-World Lessons for Shell Scripters

You're probably not going to write your next compiler in shell. But the techniques c89cc uses are directly applicable to everyday scripting:

1. Shell Can Handle Binary Data

Most people think shell can only process text. printf with octal escapes (\177) and the $'\xNN' syntax let you write arbitrary bytes. This is useful for generating binary files, protocol messages, or even small images.

# Write a minimal PNG header
printf '\x89PNG\r\n\x1a\n' > image.png

2. Functional Patterns in Shell

c89cc uses functions that echo their results, and callers capture them with $(). This is essentially functional programming — pure functions composing via pipe-like semantics.

# Compose functions instead of mutating globals
result=$(validate $(sanitize $(read_input)))

3. State Machines with `case`

The lexer's state machine pattern is useful anywhere you need to process input character by character — log parsing, protocol handling, simple parsers.

4. Don't Underestimate Shell Performance

Yes, c89cc is slow. Compiling a simple program can take minutes instead of milliseconds. But for one-off build scripts, prototyping, and CI checks, shell is fast enough. The bottleneck is usually I/O, not the shell itself.

FAQ

Q: Can c89cc compile itself (bootstrap)?
A: Not yet. The C89 feature set it supports is impressive but incomplete. Self-compilation is the holy grail of compiler projects, and shell adds its own constraints. But the subset it handles — functions, pointers, structs, control flow — is substantial.

Q: Is this production-ready?
A: Absolutely not, and the author doesn't claim it is. This is an educational and artistic project. Use GCC, Clang, or TCC for real work.

Q: Why shell specifically? Why not Python or Go?
A: The constraint is the point. Shell is available everywhere — every Unix system, every Docker container, every CI runner. Writing a compiler in the most portable language possible is a statement about accessibility and minimalism.

Q: How does it handle memory?
A: Shell doesn't have pointers or manual memory management. c89cc uses temporary files and shell variables to simulate memory. Symbol tables are associative arrays (in bash/ksh) or files keyed by name.

Q: What C89 features are supported?
A: The core set: integer types, functions, pointers, arrays, structs, control flow (if/else, while, for, switch), and basic preprocessor directives. Notably missing: floating point, complex macro expansion, and full standard library support.

Running c89cc Yourself

Want to see it in action? Here's how:

# Clone the repo
git clone https://github.com/yiyus/c89cc.git
cd c89cc

# Try compiling a simple C program
cat > hello.c << 'CEOF'
int main() {
    write(1, "Hello from shell-compiled C!\n", 29);
    return 0;
}
CEOF

# Compile with c89cc (this will take a while!)
./c89cc.sh hello.c -o hello

# Run the result
./hello
# Output: Hello from shell-compiled C!

A word of warning: Compilation is slow. A program that GCC compiles in milliseconds might take c89cc several minutes. This is expected — shell is interpreting each line, doing string processing for every token, every parse step, every byte of output. Grab a coffee.

Conclusion

c89cc isn't about replacing your toolchain. It's about expanding what you believe is possible.

When someone says "shell scripting can't do X," c89cc is the counterargument. A C compiler — with a lexer, recursive descent parser, and ELF64 code generator — all in portable shell. It works. It produces real executables. And you can read every line of its source code in an afternoon.

The next time you're writing a shell script and thinking "this is getting too complex, I should switch to Python," remember c89cc. Maybe shell can handle it. And maybe the constraint of staying in shell will lead you to a simpler, more elegant solution.

The repo is at github.com/yiyus/c89cc. Go read the source. It's a masterclass in what shell can do.

Have you built something surprising in shell? I'd love to hear about it in the comments.

You're Probably Wasting Money on AI Coding Tools (And You Have No Idea How Much)

AttractivePenguin — Sun, 19 Apr 2026 08:34:42 +0000

You're Probably Wasting Money on AI Coding Tools (And You Have No Idea How Much)

AI coding assistants have officially crossed the threshold from "cool experiment" to "monthly line item on the credit card." Claude Code, Cursor, GitHub Copilot, Codex — most devs I talk to are running at least two of these simultaneously, and the costs are adding up in ways that aren't obvious until something like codeburn hits 2,700 GitHub stars in under a week and you realize: oh, this is a whole category of problem now.

The problem isn't that AI tools are expensive. It's that they're opaque. You get a monthly bill that says "$40" or "$120" or, if you're a team lead with budget authority and a particularly aggressive engineering culture, "please explain this $3,400 charge." But you have almost no visibility into where those tokens went.

That's changing. And understanding the new generation of token cost observability tooling will make you a smarter buyer — and a more efficient AI user.

Why Token Costs Are Harder to Track Than You Think

Unlike traditional SaaS pricing (flat seat fees, predictable per-request charges), LLM APIs price on a dimension most devs aren't trained to think about: context window consumption.

Every message you send to Claude or GPT includes not just your current prompt, but potentially:

Your entire conversation history
System prompts (sometimes thousands of tokens of boilerplate)
File contents you've attached or that the tool auto-includes
Tool call outputs and responses
Re-injected context from previous turns

When you type a two-word response in a long Cursor session, you might be sending 20,000 tokens of context along with it. Multiply that by however many times you hit "Apply" on a suggestion, and the math gets ugly fast.

Here's a rough back-of-napkin example:

Session: 3-hour debugging session in Cursor
Average context per request: ~18,000 tokens (input)
Average output per request: ~800 tokens
Number of requests: ~40

Total input tokens:  720,000
Total output tokens:  32,000

Claude Sonnet pricing (hypothetical):
  Input:  $3.00 / 1M tokens → $2.16
  Output: $15.00 / 1M tokens → $0.48

Session cost: ~$2.64

That's not outrageous. But scale it: 5 devs, 8 working hours, multiple AI tools, and you're looking at a meaningful monthly burn that nobody's tracking in any structured way.

The Token Sinks Nobody Talks About

After digging into observability data from tools like codeburn and similar projects, a few patterns show up repeatedly as the biggest cost drivers:

1. The "Re-explain the whole project" problem

AI coding tools often re-inject your entire codebase context on every request. Some tools are smarter about chunking and retrieval, but many — especially agentic workflows — err on the side of "more context = better results." Which is often true! But it's expensive.

The fix: be explicit about what files you want the AI to have access to. Don't let tools auto-index your entire monorepo when you're just trying to fix a CSS bug.

2. Failed attempts that cost as much as successful ones

This is the brutal one. If you ask the AI to refactor a complex function and it gets it wrong three times before nailing it on the fourth try — you paid for all four attempts. The failed ones aren't discounted.

# Rough cost comparison: one complex refactoring task
# Attempt 1 (failed): 12,000 tokens in + 3,000 out
# Attempt 2 (failed): 14,000 tokens in + 2,800 out  
# Attempt 3 (failed): 16,000 tokens in + 4,200 out
# Attempt 4 (success): 18,000 tokens in + 5,100 out
# Total: 60,000 tokens in + 15,100 out
# vs. getting it right first try: 12,000 + 5,100

Clear, specific prompts are not just a workflow optimization — they're a cost optimization. Ambiguity is literally billable.

3. System prompt bloat

Many AI tools (and especially the frameworks you build on top of them) use massive system prompts. I've seen system prompts over 8,000 tokens that get prepended to every single request. If you're making 100 requests a day, that's 800,000 tokens of system prompt input that you're paying for regardless of whether that context is relevant.

Audit your system prompts. Trim the fat. The difference between a 2,000-token and 8,000-token system prompt adds up to real money across a team.

What Token Cost Dashboards Actually Show You

Tools like codeburn operate by intercepting or parsing usage data from AI tool APIs and presenting it in a usable format. The better ones break down costs by:

Tool (which AI assistant generated the cost)
Session/project (which codebase or conversation)
Time (hourly/daily/weekly burn rates)
Model (cost per model if you're mixing Sonnet vs. Opus vs. Haiku)
Token type (input vs. output, because output tokens cost dramatically more)

A typical TUI interface looks something like this conceptually:

┌─────────────────────────────────────────────────────┐
│  AI Token Cost Dashboard              [April 2026]  │
├─────────────────────────────────────────────────────┤
│  Today's spend:    $4.23                            │
│  This week:        $31.87                           │
│  Monthly projection: $127.48                        │
├──────────────────┬──────────────────────────────────┤
│  By Tool         │  By Project                     │
│  Cursor    $2.11 │  api-refactor      $1.84        │
│  Claude    $1.47 │  frontend-cleanup  $1.22        │
│  Copilot   $0.65 │  misc/scratch      $1.17        │
└──────────────────┴──────────────────────────────────┘

The insight isn't just "here's what you spent." It's "here's the pattern." When you can see that your api-refactor project costs 3x more per hour than other projects, you start asking why. Usually the answer involves large context windows, lots of failed attempts, or a very chatty system prompt.

Setting Budgets Without Crippling Your Workflow

Here's my hot take: hard token limits are usually a mistake. If you hit your budget at 3pm and the AI shuts off, you lose the last hour of productivity before a deadline. That's a bad trade.

Better approach: soft budgets with visibility and friction.

What actually works:

Daily awareness notifications — get a Slack/Telegram ping when you hit 50% and 80% of your daily budget. Not a hard stop, just awareness. You'll naturally become more deliberate.

Project-level budgets — track cost per project, not just total spend. It reframes the question from "am I spending too much on AI?" to "is this project's AI spend proportionate to its business value?"

Model routing by task complexity — use cheap models (Haiku, GPT-4o-mini) for simple completions, expensive models (Opus, o3) only when complexity justifies it. This is the single highest-leverage optimization most devs aren't doing.

# Rough model routing logic
def pick_model(task_complexity: str) -> str:
    match task_complexity:
        case "simple":    return "claude-haiku-3"
        case "moderate":  return "claude-sonnet-4"
        case "complex":   return "claude-opus-4"
        case _:           return "claude-sonnet-4"  # sensible default

Weekly cost reviews — 10 minutes on Friday looking at what drove your AI spend that week. You'll find patterns: certain task types, certain times of day, certain projects that are systematically expensive.

For Team Leads: This Is Now a Budget Category

If you're managing a team of devs with access to AI tools, you need to treat this like cloud compute — not like a subscription service you pay for and forget.

Key things to track:

Per-dev monthly spend — outliers indicate either very heavy users (good or bad, depends on output) or tooling misconfiguration
Cost per shipped PR/feature — the actual ROI signal. High AI spend per output is a yellow flag
Model mix — are your devs defaulting to the most expensive model even for trivial tasks?

Most enterprise AI tool vendors offer usage exports or API access to cost data. If they don't, that's a vendor evaluation criterion worth taking seriously.

The Uncomfortable Truth About AI Coding ROI

Here's where I'll be blunt: most devs don't actually know if their AI tools are paying off. They feel more productive. They ship faster some days. But without cost visibility, you can't calculate ROI — you're just guessing.

Token cost observability is the first step toward treating AI spend like any other engineering cost: something you measure, optimize, and make deliberate decisions about.

The devs who get good at this in the next 12 months will have a real competitive advantage — not just in their own productivity, but in being able to make credible arguments about AI tool budgets, justify new tool adoption, and spot when an AI-heavy approach is actually the wrong call for a given task.

That's not a small thing. The ability to say "here's what we spent on AI for this feature, here's the output, here's whether it was worth it" is a superpower in a world where everyone's AI spend is going up and almost nobody can answer that question.

Getting Started

If you want to start tracking your AI costs today:

Check if your tools expose usage data — most do, either in the UI or via API
Try codeburn or a similar TUI — even 3 days of data will surprise you
Start a simple tracking habit — even a weekly note of your total spend builds awareness
Audit one expensive session — pick a long session and try to reconstruct why it cost what it did

The goal isn't to spend less on AI. The goal is to spend right on AI — knowing where every dollar goes and making sure it's earning its keep.

Token cost observability is early-stage but growing fast. If you're building in this space or have tooling recommendations, drop them in the comments.

Kubernetes Observability in 30 Minutes: Prometheus, Grafana, and Custom Alerts That Actually Tell You Something

AttractivePenguin — Sat, 18 Apr 2026 09:05:57 +0000

Kubernetes Observability in 30 Minutes: Prometheus, Grafana, and Custom Alerts That Actually Tell You Something

You deployed your app to Kubernetes. Pods are running. Services are up. Everything looks green. But then someone asks: "How do you know it's actually healthy?"

That question hits different when your only answer is kubectl get pods. Running containers ≠ working application. Real observability means you can answer: Are requests succeeding? Is the database slow? Is the cache doing anything? When something breaks at 3 AM, what tells you before your users do?

This tutorial walks through setting up production-grade Kubernetes observability from scratch — Prometheus for metrics collection, Grafana for dashboards, and Alertmanager for notifications — all deployed via GitOps. By the end, you'll have a system that doesn't just show green bars but tells you meaningful stories about your application's health.

Why Observability Matters (And Why dashboards Aren't Enough)

Most Kubernetes tutorials stop at deployment. They show you how to get containers running but skip the part where you actually understand what's happening inside them. CloudWatch shows node metrics. kubectl top shows resource usage. Neither tells you that your cache hit rate dropped to 20% or that database inserts are taking 3x longer than usual.

The difference between monitoring and observability is the difference between a smoke alarm and a dashboard that tells you which room is on fire, how fast it's spreading, and whether the sprinklers are working. You need:

Application metrics — request rates, error rates, latencies, cache performance
Infrastructure metrics — CPU, memory, disk, network per pod and node
Correlation — the ability to see that latency spikes when the cache miss rate climbs
Alerting — proactive notification when things go wrong, not just dashboards you remember to check

Prometheus + Grafana + Alertmanager gives you all four. Let's build it.

Prerequisites

A running Kubernetes cluster (EKS, GKE, AKS, or minikube — any works)
kubectl configured and pointing at your cluster
ArgoCD installed (for GitOps deployment) or willingness to apply manifests directly
A Node.js application to instrument (I'll show the pattern; adapt it to your stack)
Basic familiarity with Kubernetes resources (Deployments, Services, ConfigMaps)

Step 1: Instrument Your Application

Before Prometheus can scrape anything, your app needs to emit metrics. For Node.js, the prom-client library makes this straightforward.

Install the dependency:

npm install prom-client

Create a metrics module (src/metrics.js):

const client = require('prom-client');
const register = new client.Registry();

// Default metrics (GC, event loop, memory, etc.)
client.collectDefaultInfo({ register });

// HTTP request duration histogram
const httpRequestDuration = new client.Histogram({
  name: 'http_request_duration_seconds',
  help: 'Duration of HTTP requests in seconds',
  labelNames: ['method', 'route', 'status_code'],
  buckets: [0.01, 0.05, 0.1, 0.5, 1, 2, 5, 10],
  registers: [register],
});

// Database query duration histogram
const dbQueryDuration = new client.Histogram({
  name: 'db_query_duration_seconds',
  help: 'Duration of database queries in seconds',
  labelNames: ['operation', 'table'],
  buckets: [0.001, 0.005, 0.01, 0.05, 0.1, 0.5],
  registers: [register],
});

// Cache operations counter
const cacheOperations = new client.Counter({
  name: 'cache_operations_total',
  help: 'Total cache operations',
  labelNames: ['operation', 'result'],
  registers: [register],
});

// Active database connections gauge
const dbConnectionsActive = new client.Gauge({
  name: 'db_connections_active',
  help: 'Number of active database connections',
  registers: [register],
});

module.exports = {
  register,
  httpRequestDuration,
  dbQueryDuration,
  cacheOperations,
  dbConnectionsActive,
};

Add HTTP middleware to track every request (src/middleware.js):

const { httpRequestDuration } = require('./metrics');

function metricsMiddleware(req, res, next) {
  // Exclude the /metrics endpoint itself from tracking
  if (req.path === '/metrics') return next();

  const end = httpRequestDuration.startTimer();
  res.on('finish', () => {
    end({
      method: req.method,
      route: req.route?.path || req.path,
      status_code: res.statusCode,
    });
  });
  next();
}

module.exports = { metricsMiddleware };

Track database and cache operations wherever they occur:

const { dbQueryDuration, cacheOperations, dbConnectionsActive } = require('./metrics');

// Database wrapper
async function query(operation, table, fn) {
  const end = dbQueryDuration.startTimer({ operation, table });
  try {
    const result = await fn();
    return result;
  } finally {
    end();
  }
}

// Cache tracking
async function cacheGet(key) {
  const result = await redis.get(key);
  cacheOperations.inc({
    operation: 'get',
    result: result !== null ? 'hit' : 'miss',
  });
  return result;
}

async function cacheSet(key, value) {
  await redis.set(key, value);
  cacheOperations.inc({ operation: 'set', result: 'success' });
}

Expose the metrics endpoint (src/server.js):

const { register } = require('./metrics');

app.get('/metrics', async (req, res) => {
  res.set('Content-Type', register.contentType);
  res.end(await register.metrics());
});

Hit http://localhost:3000/metrics and you should see ~100 lines of Prometheus-format metrics: counters, histograms, gauges, all labeled and ready to scrape.

Step 2: Deploy the Observability Stack

The kube-prometheus-stack Helm chart bundles Prometheus, Grafana, Alertmanager, Node Exporter, and kube-state-metrics — everything you need in one deploy.

If you're using ArgoCD, create an Application manifest (monitoring/argocd-app.yaml):

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: monitoring
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://prometheus-community.github.io/helm-charts
    chart: kube-prometheus-stack
    targetRevision: "58.0.0"
    helm:
      values: |
        grafana:
          service:
            type: LoadBalancer
          adminPassword: admin
        prometheus:
          prometheusSpec:
            retention: 7d
            resources:
              requests:
                memory: 512Mi
  destination:
    server: https://kubernetes.default.svc
    namespace: monitoring
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Or install directly with Helm:

helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
kubectl create namespace monitoring
helm install monitoring prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --set grafana.service.type=LoadBalancer \
  --set grafana.adminPassword=admin \
  --set prometheus.prometheusSpec.retention=7d

Wait 2-3 minutes for all pods to come up:

kubectl get pods -n monitoring -w

You should see: prometheus-monitoring-0, monitoring-grafana-..., alertmanager-monitoring-0, and several exporters.

Step 3: Connect Prometheus to Your Application

This is where most people get stuck. The instinct is to use additionalScrapeConfigs in the Helm values. Don't. The correct approach is a ServiceMonitor — a CRD that the Prometheus Operator watches to discover scrape targets automatically.

First, make sure your application's Service has a named port:

apiVersion: v1
kind: Service
metadata:
  name: gitops-api
  namespace: three-tier
  labels:
    app: gitops-api
spec:
  selector:
    app: gitops-api
  ports:
    - name: http          # This name matters!
      port: 80
      targetPort: 3000

Then create the ServiceMonitor (monitoring/servicemonitor.yaml):

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: gitops-api
  namespace: monitoring
  labels:
    release: monitoring   # Must match your Helm release label
spec:
  selector:
    matchLabels:
      app: gitops-api
  namespaceSelector:
    matchNames:
      - three-tier
  endpoints:
    - port: http
      path: /metrics
      interval: 15s

The release: monitoring label is critical — the Prometheus Operator uses it to discover ServiceMonitors. If this label doesn't match your Helm release name, Prometheus silently ignores your ServiceMonitor and you'll spend hours debugging why targets aren't showing up.

Apply it:

kubectl apply -f monitoring/servicemonitor.yaml

Verify the target is discovered in Prometheus: open the Prometheus UI (kubectl port-forward svc/prometheus-operated 9090 -n monitoring) and navigate to Status → Targets. You should see your application endpoint with state "UP".

Step 4: Build Meaningful Dashboards

Skip the pretty-but-useless dashboards. Build ones that tell a story. Here's a layout that covers the three layers that matter:

Row 1 — HTTP Layer (Is the API serving traffic?)

{
  "title": "Request Rate",
  "type": "timeseries",
  "targets": [
    { "expr": "sum(rate(http_request_duration_seconds_count[5m])) by (route)", "legendFormat": "{{route}}" }
  ]
}

Add panels for Error Rate (rate(...{status_code=~"5.."}) / rate(...) as percentage) and P95 Latency (histogram_quantile(0.95, rate(..._bucket[5m])) by route).

Row 2 — Data Layer (Is the backend keeping up?)

Requests by Status (pie chart: 200/201/404/503 distribution)
Cache Hit/Miss Ratio (pie chart: cache_operations_total{operation="get",result="hit"} vs miss)
DB Query Duration P95 (by operation type — inserts vs selects)
Active DB Connections (gauge, 0–10 scale, yellow at 6, red at 8)

Row 3 — Infrastructure (Do we need more resources?)

DB Queries per Second (insert and select rates)
Pod Memory Usage
Pod CPU Usage

Save the dashboard JSON as a ConfigMap and deploy it via ArgoCD so it's version-controlled and reproducible:

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-dashboard
  namespace: monitoring
  labels:
    grafana_dashboard: "1"
data:
  app-dashboard.json: |
    {YOUR_DASHBOARD_JSON_HERE}

Grafana's sidecar automatically picks up ConfigMaps with the grafana_dashboard label and imports them.

Step 5: Set Up Alerts That Don't Cry Wolf

Nine custom alert rules across four categories — enough to catch real problems without paging you at 3 AM for a blip:

apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: app-alerts
  namespace: monitoring
  labels:
    release: monitoring
spec:
  groups:
    - name: api-health
      rules:
        - alert: HighErrorRate
          expr: |
            sum(rate(http_request_duration_seconds_count{status_code=~"5.."}[5m]))
            / sum(rate(http_request_duration_seconds_count[5m])) > 0.05
          for: 5m
          labels:
            severity: critical
          annotations:
            summary: "Error rate above 5%"
            description: "API error rate is {{ $value | humanizePercentage }}"

        - alert: HighLatency
          expr: |
            histogram_quantile(0.95,
              sum(rate(http_request_duration_seconds_bucket[5m])) by (le, route)
            ) > 2
          for: 10m
          labels:
            severity: warning
          annotations:
            summary: "P95 latency above 2s"
            description: "Route {{ $labels.route }} P95 latency is {{ $value }}s"

    - name: database
      rules:
        - alert: SlowDatabaseQueries
          expr: |
            histogram_quantile(0.95,
              sum(rate(db_query_duration_seconds_bucket[5m])) by (le, operation)
            ) > 0.5
          for: 10m
          labels:
            severity: warning

        - alert: ConnectionPoolExhaustion
          expr: db_connections_active > 8
          for: 5m
          labels:
            severity: critical
          annotations:
            summary: "DB connection pool nearing exhaustion"

    - name: cache
      rules:
        - alert: LowCacheHitRate
          expr: |
            sum(rate(cache_operations_total{operation="get",result="hit"}[5m]))
            / sum(rate(cache_operations_total{operation="get"}[5m])) < 0.5
          for: 15m
          labels:
            severity: warning
          annotations:
            summary: "Cache hit rate below 50%"

    - name: pods
      rules:
        - alert: PodCrashLooping
          expr: rate(kube_pod_container_status_restarts_total[15m]) > 0
          for: 5m
          labels:
            severity: critical

        - alert: PodMemoryPressure
          expr: |
            container_memory_working_set_bytes
            / container_spec_memory_limit_bytes > 0.85
          for: 10m
          labels:
            severity: warning

Key design principles for alerts:

Always use for: clauses. A 30-second spike shouldn't wake you up. for: 5m means the condition must persist for 5 minutes before alerting.
Thresholds should be meaningful. 5% error rate is objectively bad. 2-second P95 latency means real users are suffering. Don't alert on 1% error rates — you'll burn out on noise.
Group by severity. critical = page someone now. warning = investigate in the morning.

Step 6: Configure Alertmanager Routing

Alertmanager decides where alerts go. A basic config that routes critical alerts to Slack and warnings to email:

apiVersion: v1
kind: Secret
metadata:
  name: alertmanager-monitoring-config
  namespace: monitoring
type: Opaque
stringData:
  alertmanager.yaml: |
    route:
      receiver: slack
      group_by: [alertname, severity]
      group_wait: 30s
      group_interval: 5m
      repeat_interval: 4h
      routes:
        - match:
            severity: critical
          receiver: slack-urgent
          repeat_interval: 1h
        - match:
            severity: warning
          receiver: email
    receivers:
      - name: slack
        slack_configs:
          - api_url: https://hooks.slack.com/services/YOUR/WEBHOOK/URL
            channel: '#monitoring'
      - name: slack-urgent
        slack_configs:
          - api_url: https://hooks.slack.com/services/YOUR/WEBHOOK/URL
            channel: '#incidents'
      - name: email
        email_configs:
          - to: oncall@yourcompany.com
            from: alertmanager@yourcompany.com
            smarthost: smtp.yourcompany.com:587

Real-World Scenarios

Scenario 1: The Silent Degradation

Your cache hit rate slowly drops from 85% to 40% over two hours. No pods crash. No 500 errors. But database query latency triples because every request now hits Postgres instead of Redis. The LowCacheHitRate alert catches this 15 minutes in, long before users notice.

Scenario 2: The Connection Leak

A new deploy introduces a database connection leak. Active connections climb from 3 to 8 over 10 minutes. The ConnectionPoolExhaustion alert fires at 8 connections, you roll back before the pool hits 10 and the app becomes unresponsive.

Scenario 3: The Noisy Neighbor

Another team deploys a memory-hungry job on the same node. Your pod's memory pressure crosses 85%. The PodMemoryPressure warning gives you time to request a node with more capacity or move the workload before OOMKill hits.

FAQ / Troubleshooting

Q: Prometheus shows my target as "DOWN" or missing entirely.
A: Check three things: (1) Does your Service have a named port (name: http, not just port: 80)? ServiceMonitors reference ports by name. (2) Does your ServiceMonitor have the release label matching your Helm release? (3) Is the namespace in namespaceSelector.matchNames correct?

Q: My ServiceMonitor exists but metrics aren't appearing in Grafana.
A: Go to Prometheus UI → Status → Targets. If the target isn't listed, the ServiceMonitor isn't being picked up. Check label selectors. If it's listed but showing errors, the /metrics endpoint might not be reachable from the cluster network.

Q: Alerts aren't firing.
A: Check Prometheus UI → Alerts. Are the rules loaded? Is the expression evaluating? Test your PromQL directly in the query bar. Common mistake: metric names with typos or label mismatches.

Q: Dashboard shows "No data."
A: Verify the data source is configured (Grafana → Settings → Data Sources → Prometheus). Check that the namespace in your query matches where the metrics are. Use {namespace="three-tier"} to scope queries.

Q: How much resources does this stack need?
A: For a small cluster (< 20 nodes), budget: Prometheus 512Mi-1Gi RAM, Grafana 256Mi, Alertmanager 128Mi. The Helm chart defaults are reasonable for dev/test. Increase retention and memory for production.

Conclusion

Observability isn't a nice-to-have — it's the difference between guessing and knowing. The combination of application-level metrics (prom-client), infrastructure metrics (node exporter, kube-state-metrics), powerful querying (PromQL), visualization (Grafana), and proactive alerting (Alertmanager) gives you a complete picture of your system's health.

The whole stack deploys via GitOps — push to main, ArgoCD syncs. No manual dashboard creation. No ad-hoc alert rules. Everything version-controlled, reproducible, and auditable.

Start with the metrics that answer "is it working?" — request rate, error rate, latency. Add depth from there: cache performance, database health, resource pressure. Let the alerts do the watching so you don't have to.

Your future self — the one getting paged at 3 AM — will thank you.

From Node.js to Bun: How We Got 5x More Throughput (and Lived to Tell the Tale)

AttractivePenguin — Fri, 17 Apr 2026 09:06:25 +0000

From Node.js to Bun: How We Got 5x More Throughput (and Lived to Tell the Tale)

If you're running Node.js in production and haven't looked at Bun yet, you might be leaving a ridiculous amount of performance on the table. We did the migration, hit a memory leak, fixed it, and came out with 5x the throughput. Here's the full story — including the ugly parts.

Why This Matters

Runtime performance isn't an academic exercise. When your job queue starts backing up at 2 AM, the difference between processing 100 tasks/second and 500 tasks/second is the difference between "we'll handle it in the morning" and "page the on-call."

Trigger.dev runs a task execution engine. Every millisecond of runtime per task translates directly into how many tasks they can process, how much infrastructure they need, and how much they pay in cloud bills. When they benchmarked Bun against Node.js on their real workload — not a synthetic Hello World — the results were dramatic enough to warrant a full migration.

The kicker? Bun has matured. This isn't the "cool experiment" phase anymore. It's production-ready for the right workloads, and this article will help you figure out if yours is one of them.

The Benchmark That Changed Everything

Before diving into the "how," let's look at the "why" with real numbers. Trigger.dev tested their task execution engine on both runtimes with identical workloads:

Metric	Node.js	Bun	Improvement
Tasks/sec	~100	~500	5x
Cold start time	~300ms	~8ms	37x
Memory (baseline)	~60MB	~20MB	3x

These aren't synthetic Fibonacci benchmarks. This is a real application doing real work — hitting databases, parsing JSON, making HTTP calls. The throughput gap narrowed slightly after a Bun memory leak was discovered and patched (more on that below), but even post-fix, Bun held a comfortable 4-5x lead.

Migration Guide: Node.js → Bun

Step 1: Install Bun

curl -fsSL https://bun.sh/install | bash

Yeah, it's one line. The hardest part of your migration just happened.

Step 2: Replace Your Package Manager

Bun's package manager is a drop-in replacement for npm/yarn/pnpm, and it's fast:

# Instead of npm install
bun install

# Instead of npx
bunx create-next-app my-app

# Instead of npm run dev
bun run dev

Your package.json works as-is. Your lockfile gets converted. Your scripts run. This is the easy part.

Step 3: Swap the Runtime

Replace node with bun in your Dockerfile and startup scripts:

# Before
FROM node:20-slim
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
CMD ["node", "dist/index.js"]

# After
FROM oven/bun:1-slim
WORKDIR /app
COPY package.json bun.lockb ./
RUN bun install --production
COPY . .
CMD ["bun", "dist/index.js"]

Step 4: Handle Node.js API Differences

Bun implements most Node.js APIs, but not all. Here's what you'll likely need to adjust:

// ✅ These work out of the box
import { readFileSync } from "fs";
import { createServer } from "http";
import crypto from "crypto";

// ⚠️ These need attention
// - node:child_process (supported but behavioral differences)
// - node:dgram (UDP — limited support)
// - Native .node addons (need recompilation)

// ❌ These don't work yet
// - node:v8 serialization API
// - Some obscure stream edge cases

The practical advice: run your test suite under Bun first. If it passes, you're probably fine.

bun test  # Yes, Bun has a built-in test runner too

Step 5: Optimize for Bun's Strengths

Once you're running on Bun, lean into what makes it fast:

// Bun.serve() is faster than Node's http.createServer
const server = Bun.serve({
  port: 3000,
  fetch(req) {
    return new Response("Hello from Bun!");
  },
});

console.log(`Listening on http://localhost:${server.port}`);

// Built-in SQLite — no driver needed
import { Database } from "bun:sqlite";
const db = new Database("mydb.sqlite");
const results = db.query("SELECT * FROM users WHERE id = ?").get(42);

// Built-in test runner — no jest dependency
import { test, expect } from "bun:test";

test("task processes correctly", () => {
  const result = processTask({ id: 1, payload: "test" });
  expect(result.status).toBe("completed");
});

Real-World Scenarios

Scenario 1: High-Throughput Job Processing

This is where Bun shines brightest. If you're running BullMQ, Agenda, or a custom job queue:

// worker.ts — processing thousands of tasks
interface Task {
  id: string;
  type: string;
  payload: unknown;
}

async function processTask(task: Task): Promise<void> {
  switch (task.type) {
    case "send_email":
      await sendEmail(task.payload);
      break;
    case "process_data":
      await processData(task.payload);
      break;
  }
}

// Bun's event loop handles this dramatically faster
// because of V8->JavaScriptCore differences in promise resolution
async function main() {
  const tasks = await fetchPendingTasks();

  // Process in controlled concurrency
  const results = await Promise.allSettled(
    tasks.map(task => processTask(task))
  );

  const failures = results.filter(r => r.status === "rejected");
  if (failures.length) {
    console.error(`${failures.length} tasks failed`);
  }
}

Scenario 2: API Gateway / BFF Layer

If you're running a backend-for-frontend that aggregates multiple services:

// Bun.serve() handles concurrent fetches more efficiently
Bun.serve({
  port: 3000,
  async fetch(req) {
    const url = new URL(req.url);

    if (url.pathname === "/api/dashboard") {
      // Parallel fetching — Bun handles this beautifully
      const [user, orders, notifications] = await Promise.all([
        fetch(`${USER_SERVICE}/me`, { headers: req.headers }),
        fetch(`${ORDER_SERVICE}/recent`, { headers: req.headers }),
        fetch(`${NOTIF_SERVICE}/unread`, { headers: req.headers }),
      ]);

      return Response.json({
        user: await user.json(),
        orders: await orders.json(),
        notifications: await notifications.json(),
      });
    }

    return new Response("Not found", { status: 404 });
  },
});

Scenario 3: Cold Start-Heavy Serverless

Bun's ~8ms cold start (vs Node's ~300ms) makes it compelling for serverless:

// With AWS Lambda, use a custom runtime
// runtime.sh:
//   #!/bin/sh
//   exec bun /opt/bun-handler.js

// The handler itself can use top-level await
const db = new Database("/opt/mydb.sqlite"); // Opens once, reused across invocations

export default {
  async fetch(req: Request): Promise<Response> {
    const users = db.query("SELECT * FROM users LIMIT 10").all();
    return Response.json(users);
  },
};

Troubleshooting & FAQ

Q: I hit a memory leak. Is Bun production-ready?

Yes, but be aware. The Trigger.dev team discovered a memory leak in Bun's HTTP client under high concurrency. The Bun team shipped a fix within days. The lesson: monitor memory in production, regardless of runtime.

# Monitor Bun's memory usage
ps aux | grep bun
# Or use Bun's built-in profiler
bun --inspect your-app.ts

If you see unbounded memory growth:

Check your Bun version — upgrade to latest
Look for unclosed HTTP connections or streaming responses
Use BUN_DEBUG_QUIET_LOGS=1 to reduce noise, then inspect

Q: My native Node module doesn't work under Bun.

Bun supports native addons compiled for it, but they need recompilation:

# Rebuild native modules for Bun
bun install --force

If that doesn't work, check if there's a pure JS alternative or file an issue at bun.sh/issues.

Q: Should I migrate everything at once?

No. Start with stateless workers and job processors — the simplest, most CPU-bound parts of your stack. Validate performance, then expand.

# Run both runtimes in parallel during migration
# Docker Compose example:
services:
  worker-node:
    build: 
      dockerfile: Dockerfile.node
  worker-bun:
    build:
      dockerfile: Dockerfile.bun
    # Route a percentage of traffic to Bun
    # Compare metrics side by side

Q: What about TypeScript?

Bun runs TypeScript natively. No tsx, no ts-node, no compilation step:

bun run src/index.ts  # Just works

Q: Is Bun a drop-in replacement?

For most server applications — yes. For CLI tools with complex native dependencies — maybe not yet. Check the compatibility list before committing.

Conclusion

Bun isn't a toy anymore. It's a production runtime that can deliver real, measurable performance improvements — especially for high-throughput job processing and API layers. The Trigger.dev team proved it: 5x throughput, faster cold starts, lower memory, and a migration that took days, not months.

Should you switch? If you're running Node.js in performance-sensitive scenarios, you owe it to yourself to benchmark Bun against your actual workload. The numbers might surprise you.

Start small. Migrate a worker. Run the tests. Watch the metrics. Then decide.

The runtime wars aren't over, but Bun just won a significant battle.

Inspired by Trigger.dev's real-world migration story. Go read their original post for the raw benchmarks and the memory leak deep-dive.

Claude Opus 4.7 — What Actually Changed and Why It Matters

AttractivePenguin — Fri, 17 Apr 2026 08:31:19 +0000

Claude Opus 4.7 — What Actually Changed and Why It Matters

Another week, another Anthropic release. But this one landed differently.

Claude Opus 4.7 hit Hacker News as the #1 story with 1,656 upvotes — not the usual tech-press applause, but genuinely excited developers sharing benchmark results, workflow changes, and the occasional "okay this actually slapped me" moment. That kind of organic traction is rare. It usually means something real happened.

So let's cut through the announcement blog post and figure out what's actually new, what still frustrates people, and whether you should change anything about how you use AI in your dev workflow.

What Anthropic Actually Claims

The 4.7 release came with the usual constellation of benchmark improvements. The headline numbers:

30% improvement on SWE-bench Verified (software engineering tasks on real GitHub issues)
Stronger long-context coherence — fewer "forgot what we were doing" failures on 200k token windows
Better tool use reliability — specifically multi-step agentic tasks where the model orchestrates multiple function calls
Reduced hallucination rate on factual recall tasks

The SWE-bench number is the one developers care about most because it's not vibes — it's the model running against real codebases with real bugs. A 30% jump is substantial.

The "Vibes Getting Worse" Controversy

Simultaneously trending on Lobsters was a thread titled "The Claude Coding Vibes Are Getting Worse" — which is either perfect timing or telling contrast, depending on your read.

The complaints aren't new, but they've gotten louder:

Over-cautious refusals on legitimate dev tasks (security research, penetration testing code, anything that touches "sensitive" domains)
Sycophancy creep — the model agreeing with obviously wrong approaches to avoid conflict
Verbosity on simple queries — asking for a one-liner and getting a five-paragraph essay with caveats

Here's my honest take: both things are true simultaneously. The capabilities of Opus 4.7 are genuinely better on hard engineering tasks. The behavior on everyday tasks has gotten more annoying in ways that don't show up on benchmarks.

Benchmarks measure can-it-do-this. Vibes measure is-this-pleasant-to-work-with. Anthropic is clearly optimizing the former. The latter is a harder problem and they're not obviously winning it.

Real-World Comparison: Opus 4.7 vs. GPT-4.1 vs. Gemini 2.5 Pro

I ran the same suite of practical tasks across all three. Here's the honest breakdown:

Code Generation — Complex Multi-File Tasks

Task: "Implement a rate limiter middleware for a Fastify server
       with Redis backend, sliding window algorithm, per-route config,
       and graceful degradation if Redis is unavailable."

Opus 4.7: Nailed the architecture. Correct sliding window implementation, proper Lua script for atomicity, sensible defaults with override pattern. The graceful degradation logic was actually good — fell back to in-memory with a logged warning rather than crashing or silently allowing everything. Minor issue: it added unnecessary TypeScript generics that complicated the interface.

GPT-4.1: Got the structure right but the sliding window was subtly wrong — it used fixed buckets rather than true sliding, which means burst tolerance at window boundaries. The Redis integration was clean though.

Gemini 2.5 Pro: Fastest response, most readable code. The algorithm was correct. But it skipped the graceful degradation entirely until I explicitly asked for it. Less "thinking ahead" than the other two.

Winner: Opus 4.7 on correctness, Gemini on speed and readability, GPT-4.1 in the middle.

Debugging — Finding Non-Obvious Bugs

# Presented this broken async code and asked what's wrong:
import asyncio

async def fetch_all(urls):
    results = []
    for url in urls:
        result = await fetch(url)
        results.append(result)
    return results

All three caught the sequential execution issue (should use asyncio.gather). The test was what they suggested next:

Opus 4.7: Immediately flagged that asyncio.gather without error handling will cancel all tasks if one fails, suggested return_exceptions=True pattern, and noted that unconstrained concurrency on large URL lists can hammer rate limits — recommended a semaphore approach. That's three levels of "here's what you actually need" without being asked.

GPT-4.1: Suggested asyncio.gather, mentioned error handling when pressed.

Gemini 2.5 Pro: Suggested asyncio.gather with a clean rewrite. Mentioned the rate limiting concern unprompted, which was impressive.

Winner: Toss-up between Opus 4.7 and Gemini 2.5 Pro. Both showed real understanding rather than pattern matching.

Long-Context Reasoning — 150k Token Codebase

I fed a 150k token context of a real (anonymized) production codebase and asked questions about data flow across services.

Opus 4.7: This is where the 4.7 upgrade is most noticeable. Earlier Opus versions would start "forgetting" context or giving inconsistent answers across a long session. 4.7 held coherent mental models of service boundaries across 20+ back-and-forth questions. When I asked about a pattern introduced in the first 10k tokens an hour later, it remembered correctly.

GPT-4.1: Also strong here, but slightly more likely to give confident-sounding answers that were actually synthesizing (hallucinating) details that weren't in the context.

Gemini 2.5 Pro: Impressive 1M token window but I noticed more "drifting" in long sessions — answers that were plausible but didn't match the specific codebase provided.

Winner: Opus 4.7 on long-context accuracy and consistency.

Is It Worth Upgrading Your API Tier?

Depends entirely on what you're doing.

Yes, upgrade if:

You're building agents that do multi-step coding tasks (the tool use improvements are real and matter)
You work with large codebases and need coherent long-context reasoning
You're doing complex architectural work where catching edge cases matters more than speed
You're paying for quality over throughput

Stick with Sonnet/Haiku if:

You're doing high-volume, simpler tasks (autocomplete, docstrings, simple refactors)
Latency matters more than depth
You're cost-sensitive at scale

Don't bother if:

Your use case is mostly security research or "gray area" prompts — the over-caution issues are worse on Opus than on smaller models, ironically
You're already happy with your current setup and don't need the long-context improvements

The Honest Verdict

Opus 4.7 is a meaningful step up on hard engineering tasks. The SWE-bench improvement is real and you'll feel it on genuinely complex problems. If you're using AI for production code and architectural decisions, this is the model to use right now.

But the vibes problem is also real. Anthropic keeps optimizing for "safe, capable, accurate" and keeps de-prioritizing "pleasant to work with on everyday tasks." The model is getting smarter and more annoying at the same time. That's a solvable problem — just not one they've solved yet.

The developer community's split reaction — 1,656 upvotes on HN and a trending Lobsters complaint thread in the same week — is actually the most honest summary of where Opus 4.7 lands: objectively impressive, subjectively complicated.

Worth using. Worth complaining about. Somehow both.

What Anthropic Still Hasn't Fixed

Every Opus release I end up writing the same section. The issues that have been frustrating developers for a year and a half are still there:

The security research wall. Ask Opus 4.7 to help you write a fuzzer, analyze a malware sample, or demo a SQL injection for a conference talk. Watch it hedge, caveat, or flat-out refuse — even with clear context that you're a security professional doing legitimate work. Meanwhile, you can get the same answer from a DuckDuckGo search in 30 seconds. The refusal isn't protecting anyone; it's just friction.

Excessive preamble on simple tasks. "Write a bash one-liner to find all .log files older than 7 days" should not generate a three-paragraph response explaining what the command does before showing it. This is configurable via system prompt, but it shouldn't require configuration.

Confirmation theater. Opus 4.7 has a habit of "checking in" mid-task on agentic workflows when it doesn't need to. "I'm about to write to this file — is that okay?" Yes. That's why I asked you to write to the file. This is fixable with more assertive system prompting, but it's a symptom of a model tuned to be cautious at the expense of being useful.

None of these are dealbreakers. But they're paper cuts that add up across a workday, and they're why the vibes discourse exists alongside the benchmark praise.

Switching Costs and Practical Tips

If you're moving your agentic workflows to Opus 4.7, a few things worth knowing:

# Reduce verbosity with explicit system prompting:
system = """
You are a concise coding assistant.
- Return code directly, no preamble
- Skip disclaimers unless safety-critical
- Match the style of existing code provided
- Ask clarifying questions before writing, not after
"""

This won't fix the over-caution on sensitive tasks, but it cuts the verbosity significantly on everyday work.

For multi-step agentic use: the tool use reliability improvement is real, but you'll still want retry logic and explicit state checkpoints. The model is better — not infallible.

And if you're comparing costs: Opus 4.7 is still significantly more expensive than Sonnet. The performance/cost curve still favors Sonnet for most production use cases unless you specifically need what Opus brings to the table.

One workflow that's been working well: use Opus 4.7 as the "planner" in a multi-agent setup and cheaper models as the "executors." Opus decides what to do and how to structure it; Sonnet or Haiku do the actual implementation at lower cost. You get Opus-quality architecture decisions without paying Opus prices for every token. Most orchestration frameworks (LangGraph, Autogen, custom) support this pattern without much boilerplate.

What's your read on Opus 4.7? Seen the same split between benchmark wins and everyday friction? Drop your take in the comments — genuinely curious whether the vibes complaints are workflow-specific or universal.

Node.js Graceful Shutdown: How to Stop Dropping Requests in Production

AttractivePenguin — Thu, 16 Apr 2026 09:02:44 +0000

Node.js Graceful Shutdown: Stop Dropping Requests in Production

Your deployment just went out. Kubernetes gracefully terminated the old pods. And somehow — somehow — your error tracker lit up with a burst of 502s and connection resets. Users saw broken pages. Your Slack channel erupted.

Sound familiar? You are not alone. Improper shutdown handling is one of the most common yet overlooked causes of dropped requests in production Node.js workloads. The good news: it is entirely fixable, and the fix is simpler than you think.

Why Graceful Shutdown Matters

When a container or process receives a termination signal (SIGTERM), it does not die instantly. The orchestrator — Kubernetes, Docker, systemd — gives it a grace period. During that window, in-flight requests must complete, and new requests should be routed elsewhere.

Without a SIGTERM handler, Node.js exits immediately on signal. Any request being processed at that moment gets cut off mid-response. The client sees a connection reset, a timeout, or a partial response.

With proper graceful shutdown:

You stop accepting new requests
You let in-flight requests finish
You close database connections and cleanup resources
Then you exit cleanly

Let us build this step by step.

Step 1: Basic SIGTERM Handling

The absolute minimum — catch SIGTERM and exit on your terms:

// server.js
const http = require('http');

const server = http.createServer((req, res) => {
  res.writeHead(200);
  res.end('Hello, world!\n');
});

server.listen(3000, () => {
  console.log('Server listening on port 3000');
});

function shutdown() {
  console.log('Shutting down gracefully...');
  server.close(() => {
    console.log('All connections closed. Exiting.');
    process.exit(0);
  });

  // Fallback: force exit after 10 seconds
  setTimeout(() => {
    console.error('Forced shutdown after timeout');
    process.exit(1);
  }, 10000);
}

process.on('SIGTERM', shutdown);
process.on('SIGINT', shutdown);

What this does: server.close() stops the server from accepting new connections but keeps existing ones alive. Once all connections drain, the callback fires and we exit cleanly. The setTimeout is a safety net — if something hangs, we do not wait forever.

This is a start, but real applications have more complexity.

Step 2: Connection Draining with Express

In a typical Express app, you want to signal the load balancer to stop sending traffic before you start draining. Enter health check endpoints.

const express = require('express');
const app = express();
const PORT = 3000;

let isShuttingDown = false;

// Health check endpoint — load balancers hit this
app.get('/health', (req, res) => {
  if (isShuttingDown) {
    res.status(503).json({ status: 'shutting_down' });
  } else {
    res.status(200).json({ status: 'healthy' });
  }
});

// Reject new requests during shutdown
app.use((req, res, next) => {
  if (isShuttingDown) {
    res.set('Connection', 'close');
    res.status(503).json({ error: 'Server is shutting down' });
    return;
  }
  next();
});

// Your routes
app.get('/', (req, res) => {
  res.json({ message: 'Hello, world!' });
});

const server = app.listen(PORT, () => {
  console.log(`Server running on port ${PORT}`);
});

function shutdown() {
  console.log('Received shutdown signal');
  isShuttingDown = true;

  // Tell load balancer to stop routing here
  console.log('Marking server as unhealthy...');

  // Wait a bit for the load balancer to notice
  setTimeout(() => {
    console.log('Closing server...');
    server.close(() => {
      console.log('All connections drained. Exiting.');
      process.exit(0);
    });

    // Force exit after 15 seconds
    setTimeout(() => {
      console.error('Forced shutdown — connections did not drain in time');
      process.exit(1);
    }, 15000);
  }, 5000); // 5s for LB to notice health check failing
}

process.on('SIGTERM', shutdown);
process.on('SIGINT', shutdown);

The key insight: set isShuttingDown = true immediately, so the health check returns 503. Your load balancer (or Kubernetes Ingress) will stop routing new traffic. Then wait a few seconds before calling server.close() to give the LB time to update its routing table.

Step 3: The Same Pattern with Fastify

Fastify has a built-in graceful shutdown via close(), but the pattern is the same:

const fastify = require('fastify')({ logger: true });

let isShuttingDown = false;

fastify.get('/health', async (request, reply) => {
  if (isShuttingDown) {
    reply.code(503).send({ status: 'shutting_down' });
    return;
  }
  return { status: 'healthy' };
});

fastify.addHook('onRequest', async (request, reply) => {
  if (isShuttingDown) {
    reply.code(503).header('Connection', 'close').send({ error: 'Shutting down' });
    return;
  }
});

fastify.listen({ port: 3000, host: '0.0.0.0' });

async function shutdown() {
  isShuttingDown = true;
  console.log('Shutting down...');

  // Give LB time to notice
  await new Promise(resolve => setTimeout(resolve, 5000));

  try {
    await fastify.close();
    console.log('Fastify closed. Exiting.');
    process.exit(0);
  } catch (err) {
    console.error('Error during shutdown:', err);
    process.exit(1);
  }
}

process.on('SIGTERM', shutdown);
process.on('SIGINT', shutdown);

Fastify's close() method handles draining connections and closing the server for you.

Step 4: Kubernetes Pod Lifecycle Integration

This is where most people get it wrong. Kubernetes has a specific pod termination sequence, and your app needs to cooperate with it.

How Kubernetes Terminates a Pod

Kubernetes sends SIGTERM to the container
It waits for terminationGracePeriodSeconds (default: 30s)
If the container is still running, it sends SIGKILL

Your app must finish draining within that window. Here is the critical configuration:

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-node-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-node-app
  template:
    metadata:
      labels:
        app: my-node-app
    spec:
      terminationGracePeriodSeconds: 60
      containers:
      - name: app
        image: my-node-app:latest
        ports:
        - containerPort: 3000
        lifecycle:
          preStop:
            exec:
              command: ["/bin/sh", "-c", "sleep 10"]
        livenessProbe:
          httpGet:
            path: /health
            port: 3000
          initialDelaySeconds: 10
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /health
            port: 3000
          initialDelaySeconds: 5
          periodSeconds: 5

Why the preStop Hook Matters

When Kubernetes sends SIGTERM, it also immediately removes the pod from the Service endpoint list. But — and this is subtle — kube-proxy on each node has a propagation delay before iptables rules are updated. Requests already routed to this pod may still arrive for a few seconds after SIGTERM.

The preStop hook runs before SIGTERM is sent. By sleeping 10 seconds, we give the network fabric time to update. During this sleep, the pod is still serving traffic normally. Only after the sleep does SIGTERM arrive, and by then, the network should have stopped routing new traffic to us.

This is the single most impactful Kubernetes-specific fix for dropped requests.

Step 5: Handling Database Connections and Cleanup

Real apps have database pools, message queue consumers, and other resources. Drain those too:

const { Pool } = require('pg');
const pool = new Pool({ max: 20 });

async function shutdown() {
  isShuttingDown = true;
  console.log('Shutting down...');

  // Step 1: Stop accepting new HTTP requests
  // Step 2: Wait for load balancer to notice (via preStop or delay)
  await new Promise(resolve => setTimeout(resolve, 5000));

  // Step 3: Close HTTP server — drains in-flight requests
  await new Promise(resolve => server.close(resolve));

  // Step 4: Close database pool
  try {
    await pool.end();
    console.log('Database pool closed.');
  } catch (err) {
    console.error('Error closing DB pool:', err);
  }

  // Step 5: Exit
  console.log('Clean shutdown complete.');
  process.exit(0);
}

// Safety net — never exceed the Kubernetes grace period
setTimeout(() => {
  console.error('Grace period exceeded. Force exit.');
  process.exit(1);
}, 55000); // 55s if terminationGracePeriodSeconds is 60s

process.on('SIGTERM', shutdown);
process.on('SIGINT', shutdown);

Order matters: close the HTTP server before the database pool. If you close the DB first, in-flight requests will crash trying to query.

Real-World Scenarios

Scenario 1: Kubernetes Rolling Update

You update your Deployment image tag. Kubernetes creates a new pod, waits for it to pass readiness checks, then terminates an old pod. With proper graceful shutdown + preStop hook, the old pod drains completely before exiting. Zero dropped requests.

Scenario 2: Docker Restart

docker restart my-node-app

Docker sends SIGTERM, waits 10 seconds (default), then SIGKILL. If your app handles SIGTERM and drains in under 10 seconds, you are fine. If not, increase the timeout:

docker stop --time 30 my-node-app

Scenario 3: HPA Scale Down

Horizontal Pod Autoscaler scales down and terminates pods. Same mechanics apply — SIGTERM, grace period, drain. Your graceful shutdown code handles all of these identically.

FAQ and Troubleshooting

"I added a SIGTERM handler but requests still drop"

Check if your container runs as PID 1. In Docker, if your Node process is PID 1, it does not receive SIGTERM by default because PID 1 has special signal handling. Fix: use node directly (not as a shell child), or add init: true to your Docker Compose, or use tini as the init process.

Dockerfile fix:

RUN apt-get update && apt-get install -y tini
ENTRYPOINT ["tini", "--"]
CMD ["node", "server.js"]

"My shutdown takes too long and gets SIGKILLed"

Your total shutdown time (preStop sleep + drain time + cleanup) must be less than terminationGracePeriodSeconds. If you have a 10s preStop sleep and need 20s to drain, set terminationGracePeriodSeconds: 35 (add buffer).

"HTTP keep-alive connections never drain"

server.close() waits for all connections to close. HTTP keep-alive keeps connections open for reuse, which means server.close() might never call its callback. Fix: destroy keep-alive connections after a timeout.

function forceCloseIdleConnections(server, timeout = 10000) {
  setTimeout(() => {
    server.closeAllConnections?.(); // Node 18.2+
  }, timeout);
}

Or set a shorter keep-alive on shutdown:

server.on('connection', (socket) => {
  if (isShuttingDown) {
    socket.setKeepAlive(false);
    socket.setTimeout(5000);
  }
});

"I am using PM2, not Kubernetes"

PM2 has its own shutdown mechanism. Use the --graceful-shutdown flag and listen for the PM2 signal:

process.on('SIGINT', shutdown); // PM2 sends SIGINT on stop/reload

Run with: pm2 start server.js --graceful-shutdown 15000

"Readiness and liveness probes use the same endpoint — is that a problem?"

Ideally, use separate endpoints. Liveness = "is this process alive?" Readiness = "can this process handle traffic?" During shutdown, you want readiness to fail (503) while liveness still passes (200) — otherwise Kubernetes restarts the pod before it finishes draining.

app.get('/health/live', (req, res) => {
  res.json({ status: 'alive' });
});

app.get('/health/ready', (req, res) => {
  if (isShuttingDown) {
    res.status(503).json({ status: 'not_ready' });
  } else {
    res.json({ status: 'ready' });
  }
});

The Complete Picture

Here is a summary checklist for production-ready graceful shutdown:

Listen for SIGTERM and SIGINT
Set a shutdown flag to fail health checks immediately
Separate liveness and readiness probes — only fail readiness during shutdown
Add a Kubernetes preStop hook (sleep 5–10s) to let the network update
Call server.close() after a short delay to drain in-flight requests
Close resources (DB, queues, file handles) after the HTTP server
Set a forced exit timeout well below terminationGracePeriodSeconds
Handle PID 1 signal issues with tini or direct node execution
Destroy idle keep-alive connections after a reasonable drain window

Implementing graceful shutdown is not optional for production workloads. It is the difference between zero-downtime deployments and angry users. The patterns above handle Kubernetes, Docker, and bare-metal alike. Add them to your template, and you will never drop a request on deployment day again.

Got questions or your own shutdown war stories? Drop them in the comments — I read every one.

Cybersecurity Looks Like Proof of Work Now — And That Should Scare You

AttractivePenguin — Thu, 16 Apr 2026 08:32:23 +0000

Cybersecurity Looks Like Proof of Work Now — And That Should Scare You

There's a chart making the rounds from the UK's AI Security Institute that I can't stop thinking about.

It shows different AI models attempting a 32-step corporate network attack simulation — reconnaissance through full network takeover, estimated at 20 hours of human effort. Most models, given a 100 million token budget, failed to complete it. Claude Mythos, Anthropic's not-publicly-released security model, completed it in 3 out of 10 attempts.

One hundred million tokens. Per attempt. At current pricing, that's ~$12,500 a run, $125k for the full batch. And here's the kicker: none of the models showed signs of diminishing returns. Keep throwing tokens at it, keep finding exploits.

That detail should keep every security team awake at night.

The Proof of Work Analogy

If you've ever tried to understand Bitcoin, you know what proof of work means: to win, you don't have to be smarter than everyone else. You just have to compute harder. The difficulty scales with the total computational power on the network.

Drew Breunig coined the phrase for this new reality: cybersecurity is proof of work now.

Security is no longer (just) a battle of cleverness. It's a budget war. To harden a system, you need to spend more tokens discovering exploits than your attackers will spend exploiting them. You don't win on elegance. You win by buying more compute.

This reframes the entire threat model.

What "Cheap Code" Buys You — And What It Doesn't

The last 18 months have created a gold rush of vibe-coded apps, AI-generated backends, and "I just described it to Claude and it worked" microservices. Code is cheap now. Genuinely cheap. A weekend project that would've taken months in 2021 takes a Saturday afternoon.

But cheap code doesn't mean secure code.

Actually, it's arguably the opposite. Vibe-coded applications are often:

Missing input validation that a battle-tested developer would add reflexively
Built on dependency chains the author has never read
Deployed before anyone's done a real threat model
Maintained by someone who's more "product visionary" than "systems programmer"

We're flooding the attack surface. Every LLM-generated CRUD app, every "I used Cursor to build my SaaS in a weekend" startup — they're all targets. And the bar to attack them just dropped dramatically.

Meanwhile, Mythos and models like it are available (with restrictions) to defenders. But also: they're coming for attackers too.

The Attacker's Advantage Is Asymmetric

Here's the uncomfortable math.

A defender has to secure everything. An attacker only needs one gap. That asymmetry has always existed, but AI tilts it further.

With a token-based attack model, the attacker sets a budget based on the value of what they're trying to steal. A supply chain attack against a widely-used open source library? Worth spending more tokens, because the payoff is enormous. A small SaaS startup? Maybe a few thousand dollars of tokens.

The defender doesn't get to choose how much the attacker spends. They only get to decide how much they spend. And here's the brutal part: if Mythos keeps finding exploits regardless of how many tokens you've already spent, there's no budget that guarantees safety. You're just making yourself a less attractive target than the person next to you.

It's not about being secure. It's about being more expensive to attack than you're worth.

Consider the economics from the attacker's side. If a corporate network contains $10M worth of sensitive data, spending $50k in token costs to compromise it is a rational investment. That math holds even for moderately well-secured targets. And as inference costs continue dropping — they've fallen roughly 10x every 18 months — that budget ceiling rises. Attacks that would've cost $500k to run in 2024 cost $50k in 2026. By 2028? Maybe $5k.

This isn't speculation. It's extrapolating a curve that's already been moving for three years. The question isn't whether AI-powered attacks become economically viable at scale. They already are. The question is whether defenders can close the gap before the asymmetry becomes unmanageable.

For now, the answer is: maybe, if you start treating security as a continuous compute cost rather than a one-time audit.

The Three-Phase Development Loop

This isn't all doom. There's a practical response that's already starting to emerge among forward-thinking teams.

The old dev cycle: write code, review code, ship code.

The emerging cycle:

1. Development   → implement features, iterate fast, human-guided
2. Review        → refactor, document, apply best practices (often async, often AI-assisted)
3. Hardening     → throw token budget at your own system, find exploits before attackers do

Anthropic already sells a code review product ($15–20 per PR). The "hardening" phase is coming next. Tools that autonomously probe your codebase for security holes, running until your budget runs out.

The key insight Breunig identifies: human intuition gates Phase 1. Money gates Phase 3. That's why they're inherently separate — you don't want to burn $10k hardening a feature that's about to be redesigned anyway.

# This is the rough shape of where CI/CD pipelines are heading
git push origin feature/payment-flow

# Phase 1: Standard CI
→ tests pass, lint clean, types check

# Phase 2: AI review
→ Code review bot flags 3 issues, suggests refactor

# Phase 3: Hardening (on merge to main, or scheduled)
→ Security agent probes for 30 minutes on $200 budget
→ Report: 1 medium-severity finding (SSRF via unvalidated URL input)
→ Block merge until resolved

This isn't science fiction. It's roughly where things are headed in the next 12–18 months.

Open Source's Unexpected Second Wind

Here's a take that surprised me when I first read it: the proof-of-work model might actually be good for open source security.

Linus's law says: "given enough eyeballs, all bugs are shallow." What AI does is expand that to include tokens. If major corporations that depend on a widely-used OSS library pool resources to run security sweeps against it, that library might end up more secure than any proprietary equivalent — because the token budget is shared across the whole ecosystem, and so is the benefit.

It's the opposite of the "everyone uses it so everyone attacks it" doom spiral. Instead: everyone uses it, everyone has incentive to harden it, and the hardening cost is amortizable.

That's not guaranteed — a popular target is also more valuable to attackers, so they'll spend more too. But it's a more nuanced picture than "vibe-coded dependencies are going to kill us all."

Though also, maybe don't npm install left-pad-2026-edition without thinking about it.

The Dependency Problem Hasn't Gone Away

There's a separate thread worth pulling here. In the wake of the LiteLLM and Axios supply chain scares earlier this year, some developers — including Andrej Karpathy — started arguing for reimplementing dependencies rather than pulling them in. The logic: a custom implementation has a smaller, more auditable surface area, and you can use an LLM to write it in an afternoon anyway.

This is the "vibe-coding your way to security" argument, and it has real merit on small, bounded tasks. But it also has a serious failure mode: most developers are not security engineers. An LLM-generated implementation of JWT validation or cryptographic hashing written by someone who doesn't know what a timing attack is might be more dangerous than the well-audited library it replaced.

The proof-of-work framing actually helps here too. A widely-used open source library has a massive collective interest in its security — and increasingly, the tools to act on that interest. A one-off reimplementation has only you. And if you haven't run Mythos-scale probing against your custom HMAC implementation... well. Hope you got it right.

The pragmatic take: use established libraries for anything security-critical. Reserve the "yoink and reimplement" approach for non-security functionality where the risk profile is manageable.

What This Means For You, Practically

If you're a solo dev or small team:

Treat security as a real line item, not an afterthought. "I'll deal with it later" is a bet that attackers won't find you first.
Use AI code review tools now — they're cheap and catch obvious issues.
Prioritize reducing your attack surface: fewer dependencies, simpler architecture, less exposed surface.
Run OWASP ZAP or equivalent against anything you deploy. Free, fast, catches the low-hanging fruit.

If you're on a security team:

Start budgeting for AI-assisted red teaming. The question isn't if this becomes standard practice — it's whether you do it before your attackers do.
Push for a formal "hardening" phase in your CI/CD. Even a modest token budget run on a schedule finds real issues.
Update your threat models. "A bored teenager with a SQLmap script" is no longer the ceiling for what you're defending against.

If you're a dev lead or engineering manager:

The cost of code is no longer the dominant cost. The cost of securing code is. Budget accordingly.
"We'll do a security audit before launch" is no longer good enough for anything beyond trivial internal tooling. Continuous hardening needs to be part of the process.

The Bottom Line

Security has always been a game of asymmetric risk. AI just turbocharged the asymmetry.

The good news: the same tools that make attackers more powerful are available to defenders. The bad news: defenders have to cover the whole surface, attackers only need one crack, and the cost of "enough" security is now directly tied to the market value of what you're protecting.

The proof-of-work framing is useful precisely because it strips away the illusion that we can think our way to security. Smart architecture matters. Defense in depth matters. But ultimately, you're competing in a compute arms race, and your security budget is a bid in that market.

Cheap code got us here. Expensive security is what keeps us standing.

Sources: Cybersecurity Looks Like Proof of Work Now (Drew Breunig) · AISI Evaluation of Claude Mythos · The Last Ones benchmark

How to Create Professional Demo Videos for Free with OpenScreen

AttractivePenguin — Wed, 15 Apr 2026 09:06:33 +0000

How to Create Professional Demo Videos for Free with OpenScreen

Stop paying $29/month for Screen Studio. OpenScreen gives you polished product demos with automatic zooms, annotations, and motion blur—at zero cost.

Why This Matters: The Demo Video Problem

Every developer has been here: you build something awesome, and now you need to show it off. A screenshot won't cut it. A raw screen recording looks amateur. And Screen Studio—the tool everyone raves about—costs $29/month and only runs on macOS.

Your options until now:

Screen Studio ($29/month, macOS only): Beautiful output, but expensive and platform-locked
OBS Studio (free):: Powerful, but you need a PhD in scene configuration to get anything looking decent
Loom (freemium): Great for quick walkthroughs, but no cinematic polish
Raw screen capture: Works, but screams "I didn't care enough"

OpenScreen changes the equation. It's an open-source tool (16,000+ GitHub stars and climbing) that delivers most of Screen Studio's polish for free, on every platform—macOS, Windows, and Linux.

What OpenScreen Actually Does

OpenScreen records your screen and automatically applies post-processing that makes demos look professional:

Automatic zooms — Focuses on the active area so viewers don't squint
Smooth animations — Pans and zooms with cinematic easing
Annotations — Add click highlights, keystroke overlays, and labels
Motion blur — Gives fast cursor movements a polished feel
Background effects — Rounded corners, window padding, custom backgrounds
Multiple export formats — MP4, GIF, WebM, and more

The key insight: you record normally, and OpenScreen handles the post-production. No manual keyframing. No timeline editing. Just record, enhance, export.

Getting Started: Installation and Setup

macOS

# Via Homebrew (recommended)
brew install openscreen

# Or download the .dmg directly
# https://github.com/siddharthvaddem/openscreen/releases

Windows

# Via winget
winget install OpenScreen

# Or download the .exe installer
# https://github.com/siddharthvaddem/openscreen/releases

Linux

# AppImage (universal)
wget https://github.com/siddharthvaddem/openscreen/releases/latest/download/OpenScreen.AppImage
chmod +x OpenScreen.AppImage
./OpenScreen.AppImage

# Flatpak
flatpak install flathub com.openscreen.OpenScreen

From Source

git clone https://github.com/siddharthvaddem/openscreen.git
cd openscreen
npm install
npm run build
npm start

Recording Your First Demo

Step 1: Set Up Your Screen

Before recording, prepare your desktop:

Close unnecessary windows and notifications
Set your editor/terminal to a clean theme (dark themes with good contrast work best)
Increase font size (14pt minimum — viewers will be watching on phones)
Hide your dock/taskbar if possible

Step 2: Record

# Launch OpenScreen
openscreen

# Or use the CLI for scripted recordings
openscreen record --output my-demo.mp4

In the GUI:

Click New Recording
Select the window or region to capture
Choose recording quality (1080p recommended)
Hit Record and perform your demo
Click Stop when finished

Step 3: Enhance Automatically

After recording, OpenScreen applies enhancements automatically:

Cursor clicks get highlighted with a ripple effect
Typing appears with a keystroke overlay
Window movement triggers smooth zoom tracking
The final frame gets a subtle fade-out

You can customize these in Settings → Enhancements:

{
  "autoZoom": true,
  "zoomPadding": 40,
  "clickHighlight": true,
  "clickColor": "#3B82F6",
  "keystrokeOverlay": true,
  "motionBlur": true,
  "backgroundRadius": 16,
  "backgroundColor": "#1a1a2e"
}

Step 4: Export

# Export as MP4 (default, best quality)
openscreen export my-demo --format mp4

# Export as GIF for documentation/embedding
openscreen export my-demo --format gif --fps 15 --width 800

# Export as WebM for web embedding
openscreen export my-demo --format webm

Advanced: Scripting Demo Recordings

For repeatable, consistent demos (great for CI/CD documentation or onboarding):

#!/bin/bash
# demo-script.sh — Automated demo recording

# Start recording
openscreen record --output feature-demo.mp4 &

# Wait for recording to initialize
sleep 2

# Your demo steps (using xdotool for automation)
xdotool search --name "Terminal" windowactivate
sleep 0.5

# Type commands with natural pacing
xdotool type --delay 50 "git clone https://github.com/example/repo.git"
xdotool key Return
sleep 3

xdotool type --delay 50 "cd repo && npm install"
xdotool key Return
sleep 5

xdotool type --delay 50 "npm run dev"
xdotool key Return
sleep 2

# Stop recording
openscreen stop

# Enhance and export
openscreen enhance feature-demo.mp4 \
  --zoom auto \
  --click-highlight blue \
  --background dark \
  --export feature-demo-final.mp4

echo "Demo exported to feature-demo-final.mp4"

Run it:

chmod +x demo-script.sh
./demo-script.sh

Real-World Scenarios

Scenario 1: Open-Source Project README

You maintain a CLI tool. Your README has 2,000 words of explanation but zero visuals.

The fix:

# Record a 30-second demo of your tool in action
openscreen record --region terminal --output demo.gif --format gif

# Add to README
echo '## Quick Demo\n\n![Demo](demo.gif)' >> README.md

A 30-second GIF in your README can replace pages of explanation. Projects with demo GIFs get 40% more GitHub stars on average.

Scenario 2: Sales Engineering

Your sales team needs product demos for prospects. Raw recordings look unprofessional. Screen Studio licenses for the whole team cost $348/year per seat.

The fix:

Create a demo template with consistent branding
Record with OpenScreen using the template
Export and send

# Create branded template
openscreen template create \
  --name "company-brand" \
  --background-color "#0f172a" \
  --accent-color "#3b82f6" \
  --logo-path ./company-logo.png \
  --font "Inter"

# Record with template
openscreen record --template company-brand --output prospect-demo.mp4

Scenario 3: Documentation and Tutorials

Your docs site has text-based tutorials that nobody reads completely. Visual learners skip them entirely.

The fix:

# Record each tutorial section as a separate clip
openscreen record --output step-1-install.mp4
openscreen record --output step-2-config.mp4
openscreen record --output step-3-run.mp4

# Batch enhance all clips
for clip in step-*.mp4; do
  openscreen enhance "$clip" --zoom auto --export "enhanced-$clip"
done

# Stitch together
openscreen merge enhanced-step-*.mp4 --output full-tutorial.mp4

Scenario 4: Bug Reports

"Steps to reproduce" rarely captures what actually went wrong.

# Quick bug reproduction
openscreen record --output bug-1234.mp4 --quality 720p
# Lower quality is fine for bug reports — smaller file, faster upload

Attach the video to your issue. No more back-and-forth "can you reproduce that?"

OpenScreen vs Screen Studio: Honest Comparison

Feature	OpenScreen	Screen Studio
Price	Free (MIT license)	$29/month
Platform	macOS, Windows, Linux	macOS only
Auto zoom	✅	✅
Click highlights	✅	✅
Keystroke overlay	✅	✅
Motion blur	✅ (basic)	✅ (advanced)
Custom backgrounds	✅	✅
4K export	✅	✅
Advanced timeline editor	❌	✅
Multi-window layouts	❌	✅
Brand kits	❌	✅
Video chapters	❌	✅

Bottom line: OpenScreen covers 80-90% of what most developers need. If you're a solo dev or small team making product demos, documentation clips, or social posts, it's more than enough. Screen Studio wins if you need broadcast-quality multi-window compositions or advanced timeline editing.

FAQ

Is OpenScreen really free for commercial use?

Yes. It's MIT licensed. Use it for client demos, marketing videos, paid courses—whatever you want. No watermarks, no feature gates.

Does it work with multiple monitors?

Yes. You can select which monitor or specific window to record. Multi-monitor layouts (showing two windows side by side) are on the roadmap.

Can I edit the recording after the fact?

OpenScreen focuses on automatic enhancement rather than manual editing. You can adjust zoom points, change enhancement settings, and re-export. For timeline-style editing (cutting, splicing), pair it with a tool like DaVinci Resolve (also free).

What about audio?

OpenScreen records system audio and microphone input. You can add voiceover after recording by re-recording audio over the enhanced video.

Does it support custom fonts and themes?

Yes. You can set custom backgrounds, accent colors, logo watermarks, and window padding. Templates let you save these for consistency across recordings.

How does it handle high-DPI displays?

OpenScreen records at native resolution and scales appropriately during enhancement. On a 4K display, your exports will be crisp at any resolution.

What if the auto-zoom misses the action?

You can set manual zoom keyframes for tricky sections. OpenScreen's auto-zoom works well for standard workflows (typing, clicking, scrolling) but isn't psychic—complex multi-window workflows may need a little help.

Conclusion: Professional Demos Shouldn't Cost $348/Year

The gap between "raw screen recording" and "professional demo video" has always been bridged by expensive tools. OpenScreen demolishes that barrier:

Free and open-source — No subscriptions, no platform lock-in
Cross-platform — Works on macOS, Windows, and Linux
Automatic polish — Record normally, get professional output
Good enough for 90% of use cases — README GIFs, product demos, bug reports, tutorials

Your Action Items This Week

Install OpenScreen — Pick your platform above, takes 2 minutes
Record a 30-second demo — Any feature of any project you're working on
Add it to your README — Watch the difference a visual makes
Share it — Post the demo on Twitter/LinkedIn with #OpenScreen

The best code in the world means nothing if people can't see what it does. OpenScreen makes sure they can.

Already using OpenScreen? Drop a link to your best demo in the comments—I'd love to see what you've made.

How to Run AI Locally with Lemonade Server: No Cloud, No API Keys, No Problem

AttractivePenguin — Tue, 14 Apr 2026 11:53:11 +0000

You read that right. There exists a complete C89/ELF64 compiler written entirely in portable shell script. No C bootstrap. No Python helper. No cheating. Just pure, unadulterated /bin/sh.

Why This Matters

Three reasons you should care:

It demystifies compilers. Shell is readable. When the lexer, parser, and code generator are all written in shell, you can trace exactly how source code becomes a binary.
It pushes shell's limits. Understanding how the author handled memory, string processing, and binary output in pure shell teaches you techniques you'll use in everyday scripting.
It's just cool. Sometimes engineering should be about the joy of "because I can."

How c89cc Works: The Compilation Pipeline

Step 1: Preprocessing

The preprocessor handles #include, #define, and conditional compilation. In c89cc, this is done with sed, awk, and shell functions that expand macros line by line.

# Simplified view of how c89cc might handle #define expansion
preprocess() {
    while IFS= read -r line; do
        case "$line" in
            '#define'*)
                name=$(echo "$line" | awk '{print $2}')
                value=$(echo "$line" | awk '{print $3}')
                eval "define_${name}=\"${value}\""
                ;;
            *)
                # Expand known macros
                for macro in $(set | grep '^define_' | cut -d= -f1); do
                    mname="${macro#define_}"
                    line="${line//${mname}/${!macro}}"
                done
                echo "$line"
                ;;
        esac
    done < "$1"
}

Step 2: Lexical Analysis (Tokenization)

# Simplified token categorization
tokenize() {
    local char="$1"
    case "$char" in
        [a-zA-Z_])  echo "IDENTIFIER" ;;
        [0-9])       echo "NUMBER" ;;
        '+')         echo "PLUS" ;;
        '-')         echo "MINUS" ;;
        '*')         echo "STAR" ;;
        '/')         echo "SLASH" ;;
        ';')         echo "SEMICOLON" ;;
        '{')         echo "LBRACE" ;;
        '}')         echo "RBRACE" ;;
        *)           echo "UNKNOWN:$char" ;;
    esac
}

Step 3: Parsing (Building the AST)

The parser consumes tokens and builds an Abstract Syntax Tree. c89cc uses a recursive descent parser — each grammar rule is a shell function that calls other shell functions.

# Recursive descent: parse an expression
parse_expression() {
    local left=$(parse_term)
    while [ "$current_token" = "PLUS" ] || [ "$current_token" = "MINUS" ]; do
        local op="$current_token"
        advance_token
        local right=$(parse_term)
        left="{$op, $left, $right}"
    done
    echo "$left"
}

parse_term() {
    local left=$(parse_factor)
    while [ "$current_token" = "STAR" ] || [ "$current_token" = "SLASH" ]; do
        local op="$current_token"
        advance_token
        local right=$(parse_factor)
        left="{$op, $left, $right}"
    done
    echo "$left"
}

parse_factor() {
    case "$current_token" in
        "NUMBER")  local val="$current_value"; advance_token; echo "$val" ;;
        "IDENTIFIER") local name="$current_value"; advance_token; echo "$name" ;;
        "LPAREN")  advance_token; local expr=$(parse_expression); advance_token; echo "$expr" ;;
    esac
}

Each function returns its sub-tree as a string (shell's only real data structure), and the parent function combines them. It's functional programming in shell — and it works.

Step 4: Code Generation (ELF64 Output)

# Writing the ELF header (simplified)
write_elf_header() {
    # Magic number: 0x7f 'E' 'L' 'F'
    printf '\177ELF' > "$output"
    # ELFCLASS64
    printf '\002' >> "$output"
    # Little endian
    printf '\001' >> "$output"
    # ELF version
    printf '\001' >> "$output"
    # OS/ABI, padding
    printf '\000' >> "$output"
    printf '%0.s\000' {1..8} >> "$output"
    # ET_EXEC (executable file)
    printf '\002\000' >> "$output"
    # EM_X86_64
    printf '\062\000' >> "$output"
    # ...
}

The code generator traverses the AST and emits x86-64 instructions using the same printf technique. Each CPU opcode is encoded as its byte sequence.

Real-World Lessons for Shell Scripters

You're probably not going to write your next compiler in shell. But the techniques c89cc uses are directly applicable to everyday scripting:

1. Shell Can Handle Binary Data

# Write a minimal PNG header
printf '\x89PNG\r\n\x1a\n' > image.png

2. Functional Patterns in Shell

c89cc uses functions that echo their results, and callers capture them with $(). This is essentially functional programming — pure functions composing via pipe-like semantics.

# Compose functions instead of mutating globals
result=$(validate $(sanitize $(read_input)))

3. State Machines with `case`

The lexer's state machine pattern is useful anywhere you need to process input character by character — log parsing, protocol handling, simple parsers.

4. Don't Underestimate Shell Performance

FAQ

Q: Is this production-ready?
A: Absolutely not, and the author doesn't claim it is. This is an educational and artistic project. Use GCC, Clang, or TCC for real work.

Running c89cc Yourself

Want to see it in action? Here's how:

# Clone the repo
git clone https://github.com/yiyus/c89cc.git
cd c89cc

# Try compiling a simple C program
cat > hello.c << 'CEOF'
int main() {
    write(1, "Hello from shell-compiled C!\n", 29);
    return 0;
}
CEOF

# Compile with c89cc (this will take a while!)
./c89cc.sh hello.c -o hello

# Run the result
./hello
# Output: Hello from shell-compiled C!

Conclusion

c89cc isn't about replacing your toolchain. It's about expanding what you believe is possible.

The repo is at github.com/yiyus/c89cc. Go read the source. It's a masterclass in what shell can do.

Have you built something surprising in shell? I'd love to hear about it in the comments.

DEV Community: AttractivePenguin

JSON Canvas: How to Build Interoperable Infinite Canvas Apps with an Open Format

JSON Canvas: How to Build Interoperable Infinite Canvas Apps with an Open Format

Why JSON Canvas Matters

Understanding the Spec

Nodes

Edges

Tutorial: Building a JSON Canvas Renderer

Step 1: The Canvas File

Step 2: Parsing and Rendering

Step 3: Writing a Canvas File

Real-World Scenarios

1. Knowledge Management Tools

2. Collaborative Whiteboarding

3. Documentation and Diagramming

4. Git-Friendly Visual Documentation

FAQ and Troubleshooting

Conclusion

I Built an Uptime Monitor in a Weekend — And Saved $180/Year

Why Build Your Own?

Architecture

Step 1: Project Setup

Step 2: Database Setup

Step 3: The Health Checker

Step 4: Alerting

Step 5: Dashboard (30 Lines)

Step 6: Tie It All Together

Real-World Scenarios

Personal Projects (What I Built This For)

Small Team (2-5 People)

The Cost Comparison

FAQ

What I Learned

Conclusion

The Vercel April 2026 Security Incident: What Every Developer Actually Needs to Know

What Happened

Why This Hit Different

The Supply Chain Angle Nobody's Talking About Enough

Concrete Steps You Should Take This Week

1. Audit Your Stored Secrets Right Now

2. Scope Your Database Credentials

3. Implement Secret Rotation (Actually, Not In Theory)

4. Enable Audit Logging on Your Critical Services

5. Know Your Blast Radius Before You Need To

The Broader Takeaway on Platform Trust

Hot Take Corner

What's Next

How a Shell Script Can Compile C Code: Inside C89cc

Why This Matters

How c89cc Works: The Compilation Pipeline

Step 1: Preprocessing

Step 2: Lexical Analysis (Tokenization)

Step 3: Parsing (Building the AST)

Step 4: Code Generation (ELF64 Output)

Real-World Lessons for Shell Scripters

1. Shell Can Handle Binary Data

2. Functional Patterns in Shell

3. State Machines with case

4. Don't Underestimate Shell Performance

FAQ

Running c89cc Yourself

Conclusion

You're Probably Wasting Money on AI Coding Tools (And You Have No Idea How Much)

You're Probably Wasting Money on AI Coding Tools (And You Have No Idea How Much)

Why Token Costs Are Harder to Track Than You Think

The Token Sinks Nobody Talks About

1. The "Re-explain the whole project" problem

2. Failed attempts that cost as much as successful ones

3. System prompt bloat

What Token Cost Dashboards Actually Show You

Setting Budgets Without Crippling Your Workflow

What actually works:

For Team Leads: This Is Now a Budget Category

The Uncomfortable Truth About AI Coding ROI

Getting Started

Kubernetes Observability in 30 Minutes: Prometheus, Grafana, and Custom Alerts That Actually Tell You Something

Kubernetes Observability in 30 Minutes: Prometheus, Grafana, and Custom Alerts That Actually Tell You Something

Why Observability Matters (And Why dashboards Aren't Enough)

Prerequisites

Step 1: Instrument Your Application

3. State Machines with `case`