DEV Community: Boris Barac

When JavaScript Isn't Fast Enough

Boris Barac — Fri, 12 Jun 2026 16:41:52 +0000

500 requests per second. One minute. An Express endpoint computing BTC technical indicators over 3.6 million data points.

Node.js folded. Average latency: 3,318 ms. p95: 8.4 seconds. 15.5% of requests failed. The median response crawled in at 1.6 seconds. The JavaScript computation pipeline couldn't keep up.

Same server. Same load. Same data. One change: the /price-rust endpoint, backed by a Rust addon compiled to a .node binary via NAPI.RS. Average latency: 660 ms. p95: 2 seconds. Zero errors. Peak RSS: 283 MB — less memory than the JS path.

Same Express process, same port, same payload. The only difference was who did the math.

What the API BENCHMARK actually does

The benchmark is a BTC price analysis endpoint. We synthetically generate 360 000 datapoints.
On that dataset the server computes SMA (25/50/100/200-day windows), RSI (14-period), MACD (12/26/9), Bollinger Bands (20-period), and a composite trading signal built from golden/death crosses, RSI divergence, MACD crossovers, and Bollinger squeeze detection.

Branching, windowing, stateful accumulation, multi-indicator correlation. The kind of workload that makes a runtime earn its keep — or not.

The full picture

The HTTP benchmark shows what happens under real load. The function benchmark isolates raw computation from HTTP overhead, request queuing, and GC pressure.

HTTP — k6, 500 req/s, 1 minute

Runtime	Endpoint	Avg latency	p95	Throughput	Errors	Peak RSS
Node.js	`/price` (JS)	3,318 ms	8,437 ms	62.4 rps	15.5%	292 MB
Node.js	`/price-rust` (N-API)	660 ms	2,061 ms	35.6 rps	0%	283 MB
Bun	`/price` (JS)	1,845 ms	5,146 ms	33.4 rps	0%	470 MB
Bun	`/price-rust` (N-API)	642 ms	2,412 ms	32.1 rps	0%	259 MB

Node.js on JS is the only combination that failed requests. Every other configuration held — including Bun running the exact same JavaScript. Bun's JS path is 1.8x faster than Node's and dropped zero requests.

The Rust paths are nearly identical across runtimes: 660 ms on Node, 642 ms on Bun. The runtime barely matters when Rust is doing the work.

Function — mitata, 366K data points

Variant	Runtime	ops/sec	Avg (ms)	Speedup vs JS
JS	Node.js	20	49.11	1x
Native (N-API)	Node.js	63	15.95	3.1x
JS	Bun	28	36.10	1x
Native (N-API)	Bun	69	14.51	2.5x
JS	Browser (Chromium)	26	38.04	1x
Native (WASM)	Browser (Chromium)	56	17.71	2.2x

Three runtimes, three JS baselines, all within a narrow band: 20–28 ops/sec. The Rust speedup is consistent — ~3x on Node, ~2.5x on Bun, ~2.2x on WASM.

WASM in the browser hits 56 ops/sec — closer to native N-API (63–69) than to any JS baseline. That's worth sitting with for a moment.

Sync vs async N-API made no measurable difference (63 vs 63 on Node, 69 vs 68 on Bun). The async variant offloads to a Tokio thread pool via spawn_blocking, but the bottleneck is the math, not the calling convention.

How a Rust function becomes a Node endpoint

The binding layer is thinner than you'd expect. napi-rs is the bridge: annotate a Rust function with #[napi], compile to a .node binary, and Node can require() it like any other module.

Here's the JS moving average function — the one that runs in every request to /price:

export function calculateMovingAverages(prices, smaWindows, cutoffYears = 9) {
  const cutoffIndex = Math.max(0, prices.length - cutoffYears * 365);
  const movingAverages = [];
  const runningSums = new Array(smaWindows.length).fill(0);

  for (let i = 0; i < prices.length; i++) {
    const price = prices[i][1];
    for (let wi = 0; wi < smaWindows.length; wi++) {
      const w = smaWindows[wi];
      runningSums[wi] += price;
      if (i >= w) runningSums[wi] -= prices[i - w][1];
    }
    if (i < cutoffIndex) continue;
    // ... build entry with date, price, SMA values
  }
  return movingAverages;
}

And here's the Rust equivalent, exposed to Node:

#[napi]
pub fn calculate_moving_averages(
    prices: Float64Array,
    sma_windows: Vec<u32>,
    cutoff_years: Option<u32>,
) -> Buffer {
    let cutoff_years = cutoff_years.unwrap_or(9);
    let dates = crate::utils::precompute_dates(&prices);
    let result = calc_ma(&prices, &sma_windows, cutoff_years, &dates);
    Buffer::from(serde_json::to_vec(&result).unwrap())
}

That #[napi] macro generates the C FFI glue Node's N-API runtime expects. It handles type conversion between V8 values and Rust types, and registers the function as a module export.

Float64Array comes in as a borrowed &[f64] slice with no copy. Buffer goes out as raw bytes, skipping V8's UTF-16 string conversion entirely.

On the JS side, loading the addon is one line:

const native = require("./napibench-native.node");

Then native.calculateMovingAverages(prices, [25, 50, 100, 200]) calls directly into compiled Rust. No HTTP, no IPC, no child process. Same call stack, same thread.

Need async? The async variant parks the work on a Tokio thread pool and returns a Promise. Same function, different concurrency model.

The server wires it into Express the same way the JS endpoint is wired. Same req → compute → res flow. The handler just calls a different function.

Same Rust, different planet

The Cargo.toml has a feature gate:

[features]
default = ["napi", "napi-derive", "rayon", "napi-build"]
wasm = ["wasm-bindgen", "js-sys"]

Build with the default features, you get napi_impl.rs — N-API bindings, rayon parallelism, tokio async. Build with --no-default-features --features wasm, you get wasm.rs — the same indicator logic compiled to WebAssembly via wasm-bindgen.

The WASM build strips away some optimizations. No rayon, no async thread pool, no Buffer returns — the WASM function returns a JSON string. It's the simpler, less-tuned version of the Rust code.

And it still hits 56 ops/sec in headless Chromium. That's 2.2x faster than Chromium's own JS engine running the same algorithms, and it's closer to native N-API performance (63–69 ops/sec) than to any JS baseline (20–28 ops/sec).

The bulk of the speedup comes from Rust's compiler — LLVM optimizing tight loops, stack-allocated structs, no GC pauses, no hidden type checks — not from rayon or async thread pools. Those help, but the floor is already high.

The browser benchmark ran in headless Chromium via Playwright: the WASM module and JS indicator code, same 366K-data-point pipeline, same 5-second window. The WASM binary is produced by wasm-pack build --target web.

Because napi-rs makes Rust functions callable like JS functions, the existing JS test suite doubles as a parity test for Rust. The test imports the JS indicator functions alongside the native addon, runs the same input through both, and asserts the outputs match field by field:

const jsMa = calculateMovingAverages(pricesJs, [25, 50, 100, 200], 1);
const rustMa = decode(native.calculateMovingAverages(prices, [25, 50, 100, 200], 1));
expect(rustMa).toHaveLength(jsMa.length);
for (let i = 0; i < jsMa.length; i++) {
  expect(rustMa[i].price).toBe(jsMa[i].price);
}

The JS implementation becomes the test oracle for the Rust implementation. The test runner (vitest) doesn't know or care that one side is native.

When to reach for Rust

Three runtimes. Two languages. One workload. Here's what the numbers actually say.

Reach for Rust when you're CPU-bound. This workload is arithmetic-heavy, loop-heavy, and largely sequential — the kind of thing V8 and JavaScriptCore optimize well but can't match against LLVM.

The 2.2–3x speedup appeared across every runtime, calling convention, and optimization level. If your server spends most of its time computing — parsing, transforming, aggregating, encrypting — a native addon pays for itself.

But N-API has a floor. The FFI boundary between V8 and native code adds fixed overhead per call. On small datasets — a few hundred data points — that overhead erases the compute savings. Node/Bun JS outperforms Node/Bun + Rust N-API at that scale. The native path only wins once the dataset is large enough to amortize the crossing cost.

Don't reach for Rust for I/O. The 3x raw compute speedup became a 5x latency reduction under HTTP load because the JS endpoint was past its breaking point. But the Rust endpoints on Node and Bun had nearly identical latencies (660 ms vs 642 ms).

The runtime's HTTP stack, event loop, and memory management dominate when computation is fast. Rust made the compute a non-factor; then the runtime didn't matter.

Bun is a cheaper upgrade than Rust. If you're on Node.js and your JS code is too slow, switching to Bun gives you a 40% speedup with zero code changes. Same JavaScript, same endpoints, different binary.

In this benchmark, Bun's JS path avoided errors entirely where Node.js failed 15.5% of requests. That might be enough. Rust is the bigger hammer, but Bun is the one you don't have to think about.

WASM is viable. Not a curiosity — genuinely competitive. 56 ops/sec in a browser tab, 2.2x faster than the browser's own JS, built from the same Rust codebase with a feature flag.

Unlike NODE/BUN, WASM's speedup holds even at small workloads. The calling convention is lighter — no FFI boundary to cross, the module runs inside the same engine. Where N-API needs a large dataset to amortize its overhead, WASM delivers from the start.

If you're running heavy computation in the browser — image processing, data analysis, simulations — WASM is the answer, and you don't need a separate codebase to get there.

The binding layer is not the bottleneck. napi-rs adds almost nothing to call overhead. Sync and async variants performed identically. The FFI boundary — V8 to Rust and back — is cheap enough that it doesn't appear in the numbers.

What matters is what happens on the other side of that boundary.

#rust #nodejs #bun #napi #webassembly #performance #benchmark

You Might Not Need Docker: The Case for Lightweight, Headless VMs

Boris Barac — Fri, 12 Jun 2026 16:38:04 +0000

Lately, whenever I need to run a quick experiment or spin up a localized environment with multiple moving pieces, I've completely stopped using Docker. Instead, I've been running full, headless Ubuntu virtual machines directly from my host terminal using Canonical's Multipass. And I love it.

It is using your native hypervisor (KVM on Linux, Hyper-V on Windows, or QEMU on macOS), it drops a clean Ubuntu environment onto your laptop with next to zero performance overhead.

The Zero-Friction Sandbox

Instead of wrestling with installation mirrors and configuration screens, Multipass treats virtual machines as disposable command-line primitives.

To spin up a basic machine (we'll name it devbox) and jump inside, the standard baseline looks like this:

# Spin up a fresh Ubuntu instance instantly
multipass launch --name devbox

# Drop straight into the VM's interactive bash shell
multipass shell devbox

Running Headless Commands Directly

You don't actually have to open an interactive shell session just to execute a single task. If you want to fire off commands and capture the output straight back to your host terminal, you can leverage exec:

# Check the VM's kernel version without entering the shell
multipass exec devbox -- uname -a

# Remotely trigger an update and install packages
multipass exec devbox -- sudo apt update
multipass exec devbox -- sudo apt install -y nginx

# this is usually needed to run custom tools out of the shell
multipass exec devbox -- bash -c "source ~/.profile && command"

Moving Files Between Host and VM

When you are experimenting with local scripts or configuration files, moving data in and out of the isolated environment shouldn't require setting up network shares or SSH keys. Multipass handles this natively with a built-in transfer primitive:

# Copy a local configuration script from your host into the VM
multipass transfer ./setup.sh devbox:/home/ubuntu/setup.sh

# Pull a generated log file or benchmark report back out to your host
multipass transfer devbox:/home/ubuntu/output.log ./output.log

If a testing session gets messy or you corrupt a system-level networking rule, you don't spend hours debugging. You simply nuke the instance and wipe the slate clean:

# Obliterate the broken VM and purge its allocated storage
multipass delete devbox
multipass purge

Infrastructure as Code: Local Automation via Cloud-Init

For more advanced experiments requiring multiple pre-installed binaries or specific user permissions, you can bypass manual setup entirely using cloud-init. This is the exact same industry-standard engine used by major cloud providers to bootstrap instances at launch.

If we need a repeatable baseline containing Redis and Git, we can define the required environment state inside a standard cloud-config.yaml file:

#cloud-config
users:
  - name: devuser
    sudo: ALL=(ALL) NOPASSWD:ALL
    shell: /bin/bash
packages:
  - redis-server
  - git
runcmd:
  - systemctl enable redis-server
  - systemctl start redis-server

To parse this configuration block directly during the VM's hardware initialization phase, pass the file using the --cloud-init flag:

# Launch a fully customized, automated instance using the configuration file
multipass launch --name cache-layer --cloud-init cloud-config.yaml

Instead of spending ten minutes manually running configuration commands every time you need a new sandbox, dropping this YAML into a directory gives you an identical baseline whenever you need it. If the configuration breaks or the environment gets contaminated, you just destroy the VM and re-run the exact same launch command.

Architecture Breakdown: Multipass vs. Docker

A common question that comes up is why use Multipass when you could just run a Docker container. The core distinction lies entirely in where the isolation boundaries are drawn across the system stack.

+-----------------------------------+     +-----------------------------------+
|          DOCKER ARCHITECTURE      |     |       MULTIPASS ARCHITECTURE      |
|                                   |     |                                   |
|  [App A]   [App B]   (Containers) |     |  [Systemd] [Kernel]  (Full VM)    |
|  +-----------------------------+  |     |  +-----------------------------+  |
|  |    Shared Host Kernel       |  |     |  |     Native Hypervisor       |  |
+--+-----------------------------+--+     +--+-----------------------------+--+

Docker isolates user-space processes. The containers sit directly on top of your host machine's operating system kernel. This makes them incredibly fast and resource-efficient for deploying standardized applications or microservices, but they don't have true system autonomy.

Multipass isolates the entire operating system block. It boots a completely independent Linux kernel, initializes a standalone virtual network loop, and runs its own init system (systemd).

If your experiment requires testing firewall structures (iptables), adjusting low-level network parameters, running background daemons orchestrated by systemd, or managing separate kernel modules, a Docker container requires fragile workarounds. Multipass gives you a true server abstraction directly on your laptop. Or even if you just want to spin up 5 things.

Hope it was interesting, I hope you learned something new. Thx for reading.

Linkloom - AIWebReader

Boris Barac — Fri, 12 Jun 2026 16:24:17 +0000

LinkLoom

A web scraping and content extraction toolkit for TypeScript/Bun.

Pass a URL, get clean markdown. That's the core. But LinkLoom also handles the cases that break simple scrapers: JavaScript-heavy pages rendered through a stealth browser, PDFs parsed into structured text, iframes pulled from nested frames, HTML tables converted to markdown tables, links extracted and classified. It exposes a library API, a CLI, and an MCP server — so you can use it from code, from the terminal, or from an AI client like Claude Desktop or Cursor.

The full list: URL-to-markdown conversion, HTML-to-markdown via Readability + Turndown, PDF-to-markdown via pdf.js, headless browser rendering through Camoufox (stealth Firefox on Playwright), iframe extraction with configurable wait strategies, link extraction and classification, table scraping, text embeddings via OpenAI or Gemini, a CLI for every feature, and an MCP server for AI tool-use workflows.

Built with Bun, Camoufox, JSDOM, Readability, Turndown, and pdf.js-extract. Optional embedding support through LangChain.

import { convertLinkToMarkdown } from "linkloom";

const markdown = await convertLinkToMarkdown("https://example.com");

That's it. One import, one call. The function auto-detects whether the URL points to an HTML page or a PDF and routes it to the right converter. You get back a string of clean markdown — no boilerplate, no configuration objects, no setup ceremony.

The CLI equivalent:

bunx @boris.barac/linkloom scrape https://example.com

Same result, different interface. Pipe it, redirect it, pass -o output.md to write to a file.

But plenty of pages don't hand you their content on the first request. They render everything with JavaScript — SPAs, dashboards, dynamically loaded articles. A simple fetch returns an empty shell. LinkLoom handles this through headless browser rendering via Camoufox, a stealth Firefox build on Playwright that avoids bot detection.

import { renderers } from "linkloom";

const browser = await renderers.puppeterRendered.initialize();
const result = await renderers.puppeterRendered.renderPage(browser, url, {
  timeout: 15000,
  waitUntil: "networkidle",
  viewport: { width: 1920, height: 1080 },
  frames: { enabled: true, timeout: 5000 },
});
await browser.close();

The renderPage function loads the URL in a real browser, waits for the network to settle (or for a specific event), and returns the rendered HTML. The frames option tells it to also extract content from nested iframes — with its own timeout, because iframes load on their own schedule and you don't want one slow frame to block everything.

The CLI version:

bunx @boris.barac/linkloom render https://example.com --wait-until networkidle --timeout 15000

Add --selector "table.stats" to extract only a specific element instead of the full page. Useful when you know exactly what you're after.

Then there are PDFs. Research papers, technical reports, product documentation — a surprising amount of the web's useful content lives in PDFs, not HTML pages. The same convertLinkToMarkdown call handles both, but you can also convert PDFs directly:

import { pdfConverter } from "linkloom";
import { readFile } from "node:fs/promises";

const buffer = await readFile("document.pdf");
const markdown = await pdfConverter.convertPdfToMarkdown(buffer);
const text = await pdfConverter.convertPdfToText(buffer);

Two output modes: convertPdfToMarkdown preserves structure (headings, lists, formatting), while convertPdfToText strips everything down to plain text. Pick whichever fits your pipeline.

The CLI:

bunx @boris.barac/linkloom pdf document.pdf -o output.md

Under the hood it uses pdf.js-extract to parse the binary, so there's no external dependency on system tools like pdftotext. It works out of the box.

Content conversion is half the job. The other half is pulling structured data out of pages — links, tables, the things that aren't prose.

Link extraction finds and classifies URLs from plain text or HTML. Feed it a string and it returns every link, tagged as a PDF or a regular page:

import { linkExtraction } from "linkloom";

const links = linkExtraction.extractLinks("check https://example.com/doc.pdf");
const pdfLinks = await linkExtraction.extractDownloadLinksFromHtml(htmlContent);

extractLinks works on raw text — it finds URLs and classifies them. extractDownloadLinksFromHtml parses an HTML document and pulls out links that point to downloadable files (PDFs, mostly). Useful when you're crawling a page and want to know which links lead to documents worth converting.

Table extraction renders a page in the headless browser and pulls out HTML tables as structured data:

import { tableExtraction, renderers } from "linkloom";

const browser = await renderers.puppeterRendered.initialize();
const data = await tableExtraction.extractTableData(browser, url, "table");
const md = tableExtraction.tableDataToMarkdownTable(data);
await browser.close();

The third argument is a CSS selector — pass "table" for all tables, or "table.stats" for a specific one. The output is a markdown table string, ready to drop into a document.

The CLI shortcuts:

bunx @boris.barac/linkloom links https://example.com
bunx @boris.barac/linkloom tables https://example.com/data --selector "table.stats"

All of this is also available as an MCP server. If you use Claude Desktop, Cursor, or any MCP-compatible client, you can expose LinkLoom's tools without writing code — the AI calls them directly.

Six tools: scrape, html_to_markdown, pdf_to_markdown, render_page, extract_links, extract_tables. Same capabilities as the library and CLI, but surfaced as tool calls an AI agent can use autonomously.

Configuration is a few lines of JSON. For Claude Desktop, edit ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "linkloom": {
      "command": "bun",
      "args": ["x", "@boris.barac/linkloom", "mcp"]
    }
  }
}

For Cursor, add the same block to .cursor/mcp.json in your project or ~/.cursor/mcp.json globally. Any MCP client — point it at bun x @boris.barac/linkloom mcp and it works.

The server communicates over stdio. It reads JSON-RPC from stdin and writes responses to stdout. You don't run it directly; MCP clients spawn it as a child process. If you want to test it interactively, there's the MCP Inspector:

bunx @modelcontextprotocol/inspector bunx @boris.barac/linkloom mcp

That opens a web UI where you can browse the available tools, call them with custom parameters, and inspect the JSON-RPC messages going back and forth.

Get started

bun add @boris.barac/linkloom

Or skip the install and use it directly:

bunx @boris.barac/linkloom scrape https://example.com

No API keys needed for the core scraping pipeline. Only the optional text embedding feature requires an OpenAI or Gemini key.

A Practical Guide to Local Lambda Debugging: Using SAM CLI with Terraform and VS Code

Boris Barac — Fri, 12 Jun 2026 16:21:04 +0000

A practical guide to debugging Lambda functions locally using SAM CLI and VS Code — no more deploying just to test a print() statement.

What You'll Learn

How to invoke a Lambda function locally from the command line
How to spin up a local API that mirrors your API Gateway
How to attach a debugger in VS Code and step through your code
How to hit a deployed Lambda from your machine

The Project

Github repo

This repo deploys a simple serverless stack:

Resource	Purpose
Lambda Function	Python function that writes a timestamp to S3
S3 Bucket	Stores timestamp files
API Gateway (HTTP)	Exposes the Lambda at `GET /timestamp`

All infrastructure is defined in Terraform. The Lambda source lives in lambda_function/lambda_function.py:

import time
import boto3
import os


def lambda_handler(event, context):
    """
    AWS Lambda function that stores current timestamp in S3.
    """
    current_timestamp = int(time.time())

    s3 = boto3.client("s3")
    bucket_name = os.environ["S3_BUCKET_NAME"]
    file_name = f"timestamp-{current_timestamp}.txt"

    s3.put_object(Bucket=bucket_name, Key=file_name, Body=str(current_timestamp))

    return {
        "statusCode": 200,
        "body": {
            "message": "Timestamp saved successfully",
            "timestamp": current_timestamp,
            "file": file_name,
        },
    }

Prerequisites

Make sure these are installed and working before you start: Terraform, AWS SAM CLI, Docker, Python, VSCode. Verify everything is in place:

terraform version
sam --version
docker ps
python3 --version

Note: docker ps should run without error. If Docker isn't running, SAM CLI will fail when trying to build or invoke locally.

Project File Map

Here's what matters for debugging:

.
├── main.tf                         # All Terraform infra (Lambda, S3, API Gateway, IAM)
├── lambda_function/
│   ├── lambda_function.py          # Your Lambda handler
│   └── requirements.txt            # Python dependencies
├── ev.json                         # Sample event payload for local invoke
├── .vscode/
│   └── launch.json                 # VS Code debug configurations
└── cli_helper.txt                  # Quick reference CLI commands

Method 1: Debugging with SAM CLI (Command Line)

SAM CLI can read your Terraform project directly using the --hook-name terraform flag. No SAM template needed.

Step 1 — Build

SAM needs to prepare a local build of your function (it resolves dependencies and packages the code):

sam build --hook-name terraform

You'll see output like:

Building codeuri: /Users/you/tf-sam-play-master/lambda_function runtime: python3.13
metadata: {} functions: my_lambda
Running PythonPipBuilder:ResolveDependencies
Running PythonPipBuilder:CopySource

Build Succeeded

Built Artifacts  : .aws-sam-iacs/build
Built Template   : .aws-sam-iacs/build/template.yaml

Tip: Re-run this every time you change your Python code or dependencies.

Step 2 — Invoke Locally with a Custom Event

The repo includes ev.json — a sample S3 event payload. You can use it to simulate an invocation:

sam local invoke --event ./ev.json --hook-name terraform --debug

--event ./ev.json — feeds the event payload to your handler
--hook-name terraform — tells SAM to read from Terraform, not a SAM template
--debug — prints verbose logs (Docker commands, environment, etc.)

Expected output:

{
  "statusCode": 200,
  "body": {
    "message": "Timestamp saved successfully",
    "timestamp": 1745232000,
    "file": "timestamp-1745232000.txt"
  }
}

Important: The s3 put_object call will fail locally unless you have real AWS credentials that can reach the S3 bucket. For offline-only testing, you'd mock boto3 (covered in the Troubleshooting section).

Step 3 — Run a Local API

If you want to test through the API Gateway path (not just direct invoke):

sam local start-api --hook-name terraform --debug

SAM starts a local HTTP server. You'll see:

Mounting my_lambda at http://127.0.0.1:3000/{path+}
You can now browse to the above endpoints to invoke your functions.
Running on http://127.0.0.1:3000 (Press CTRL+C to quit)

Now hit it from another terminal:

curl http://127.0.0.1:3000/timestamp

This is useful for verifying that the API Gateway integration is wired correctly and that event routing works.

Step 4 — Remote Invoke (Hit the Deployed Lambda)

Once you've deployed with terraform apply, you can invoke the live Lambda from your machine:

sam remote invoke my_lambda --stack-name terraform-2025 --event '{"test": "data"}'

This sends a real event to the deployed function in AWS. Useful for comparing local vs. remote behavior.

Method 2: Debugging in VS Code

Step 1 — Install the AWS Toolkit Extension

Open VS Code
Go to Extensions (Cmd+Shift+X)
Search for AWS Toolkit and install it

This extension understands SAM projects and provides the aws-sam debug type.

Step 2 — Understand the Launch Config

The repo ships with .vscode/launch.json containing three configurations:

{
    "version": "0.2.0",
    "configurations": [
        {
            "type": "aws-sam",
            "request": "direct-invoke",
            "name": "lambda_function:lambda_function.lambda_handler (python3.13)",
            "invokeTarget": {
                "target": "code",
                "projectRoot": "${workspaceFolder}/lambda_function",
                "lambdaHandler": "lambda_function.lambda_handler"
            },
            "lambda": {
                "runtime": "python3.13",
                "payload": {
                    "json": {
                        "fake": "event"
                    }
                },
                "environmentVariables": {}
            }
        },
        {
            "name": "Attach to SAM Local",
            "type": "debugpy",
            "request": "attach",
            "listen": {
                "host": "127.0.0.1",
                "port": 3000
            },
            "pathMappings": [
                {
                    "localRoot": "${workspaceFolder}/lambda_function/lambda_function",
                    "remoteRoot": "/timestamp "
                }
            ]
        },
        {
            "name": "Python: Current File",
            "type": "debugpy",
            "request": "launch",
            "program": "${file}",
            "console": "integratedTerminal",
            "justMyCode": true
        }
    ]
}

Here's what each one does:

Config Name	When to Use
Direct Invoke (`aws-sam`)	Quick one-click invoke. Builds and runs in Docker.
Attach to SAM Local (`debugpy`)	Start API from CLI, then attach debugger. Full breakpoints.
Python: Current File	Run the Python file directly (no Lambda context).

Step 3 — Set a Breakpoint and Debug

Option A — Direct Invoke (quickest)

Open lambda_function/lambda_function.py
Click the gutter to the left of line 11 (current_timestamp = ...) to set a breakpoint (red dot)
Press F5 or go to Run → Start Debugging
Select "lambda_function:lambda_function.lambda_handler (python3.13)"
VS Code builds a Docker container, invokes the handler, and pauses at your breakpoint

You can now inspect event, context, and all local variables in the Variables panel.

Option B — Attach to a Running Local API

This is the most realistic debugging setup because it mirrors the full request flow:

Terminal 1 — Start SAM's local API with the debug port open:

sam local start-api --hook-name terraform --debug-port 3000

VS Code — Attach the debugger:

Set your breakpoints in lambda_function.py
Press F5 and select "Attach to SAM Local"
The debugger connects and waits

Terminal 2 — Trigger a request:

curl http://127.0.0.1:3000/timestamp

VS Code pauses execution at your breakpoints. Step through the handler line by line.

Step 4 — Customize the Event Payload

In the Direct Invoke config, change the payload to match a real event:

"payload": {
    "json": {
        "queryStringParameters": {
            "key": "value"
        },
        "pathParameters": {},
        "body": null
    }
}

Or point it to a file:

"payload": {
    "jsonPath": "${workspaceFolder}/ev.json"
}

Working with Events

Generate Sample Events with SAM

Don't hand-write event payloads. SAM can generate them for you:

# Generate an S3 Put event
sam local generate-event s3 put --bucket my-bucket --key my-key

# Generate an API Gateway HTTP API event (proxy integration)
sam local generate-event apigateway http-api-proxy --method GET --path timestamp

# Save to a file
sam local generate-event s3 put > my-event.json

Then use it:

sam local invoke --event my-event.json --hook-name terraform --debug

5 AI Agents, 0 System Crashes: Secure Sandboxing for Free

Boris Barac — Fri, 12 Jun 2026 16:13:51 +0000

Everyone's hyped about running five agents at once, but hardly anyone talks about how to keep them secure without crashing your system. Daytona is a cool option, but it's paid. Here's a way to do it for free while leveling up your existing dev skills.

Docker Sandboxes can run AI agents or code inside isolated microVMs with their own Docker daemon, while mounting your local project into the sandbox at the same absolute path as on your host. That gives the agent real access to your code without exposing your host Docker environment directly.

Main points

Isolation: each sandbox has its own filesystem, network, and private Docker daemon.
Local machine link: your project is mounted directly, and host services are reachable from the sandbox via host.docker.internal.
Networking: outbound traffic is routed through host-controlled proxy/policy layers, and services inside the sandbox must be explicitly published to be reachable from your browser (easy to control and change).
Persistence: installed packages, images, and config changes stay until you remove the sandbox.
Customization: you can extend an agent base template, add tools like Bun, push the image to an OCI registry, and run the sandbox from that template.

Minimal workflow

Note this is not gonna pick up the global config but just the local one

brew install docker/tap/sbx
sbx login
cd ~/my-project
sbx run claude

Shell connect to Sandbox

# Agent sandbox
sbx exec -it <sandbox-name> bash

Run sandbox

sbx run shell

Run command in sandbox without connecting

sbx exec -it <sandbox-name> <your-command>

Template example (Bun)

Can not be used with local templates

You can also use the opencode keyword instead of Claude Code.

FROM docker/sandbox-templates:opencode

USER root
RUN apt-get update && apt-get install -y --no-install-recommends curl \
    && rm -rf /var/lib/apt/lists/*

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

ENV PATH="/home/agent/.bun/bin:${PATH}"

WORKDIR /app

RUN bun --version

# 1. Log in to Docker Hub (if you haven't already)
docker login docker.io

# 2. Build the image locally
docker build -t docker.io/my-org/my-bun-template:v1 .

# 3. Push the image to your registry
docker push docker.io/my-org/my-bun-template:v1

# 4. Run your sandbox environment
# add -name variable if you do not want to use the name of the folder
sbx run --template docker.io/my-org/my-bun-template:v1 claude

This is how to use a custom template. You can also just install stuff while in the sandbox — the sandbox has root access, and the changes are gonna stay in it.

More docs at: https://docs.docker.com/ai/sandboxes/

#AIAgents #Docker #CyberSecurity #SoftwareEngineering #DevOps #OpenSource #AIInfrastructure #LLMs #ClaudeCode #Sandboxing