Forem: Alex Voste

ForgeZero 3.1 “AEGIS”: Hardening a CLI Toolchain into a Secure Engineering Platform

Alex Voste — Thu, 21 May 2026 17:42:06 +0000

We’ve just released ForgeZero v3.1.0 “AEGIS” — the largest architectural update since the project began.

This release is not primarily about new features.

It’s about trust.

How do you make a build toolchain safer?
How do you prevent corrupted state?
How do you eliminate filesystem race conditions?
How do you support Windows natively without falling back to WSL?

AEGIS was our answer.

The Goal: Harden Everything

ForgeZero started as a sovereign build toolchain.

With AEGIS, the goal was to harden every critical path:

file access
process execution
path validation
manifest generation
checksum verification
supply-chain integrity
platform consistency

The result is a significantly more resilient engineering platform.

1. Native Windows Support (Without WSL)

One of the biggest milestones in this release:

ForgeZero now runs natively on Windows without requiring WSL.

That meant much more than “it builds on Windows.”

It required platform-aware security guarantees.

Implemented:

Native Windows Virtual FileSystem backend
Drive-letter normalization (C:\)
UNC path validation and unsafe network path rejection
.exe / .bat executable resolution
Retry-safe close-then-rename semantics
Reparse-point and symlink safety checks

Windows is now a first-class platform.

2. A Dedicated Virtual FileSystem Layer

We moved all filesystem operations behind a hardened abstraction:

internal/fs

This is more than an interface wrapper.

It provides:

verified file access
symlink rejection before open
TOCTOU race protection

Lstat → open → SameFile verification

atomic writes
fail-closed behavior
root-boundary enforcement
injectable mock filesystem for deterministic testing

If something looks unsafe, ForgeZero stops.

That’s intentional.

3. Hardened Command Execution

Every external process now goes through a unified execution pipeline:

RunCommand()
RunCommandOutput()
LookExecutable()

Security improvements:

no shell invocation
exec.CommandContext
deterministic environment
secure executable discovery
CLI path validation
traversal rejection (../)
constant-time checksum verification

This removed multiple raw execution paths across the codebase.

Before:

pkgman → raw git exec
linker → raw nm/objdump/readelf
builder → raw ar

After:

all external commands → hardened execution layer

4. Verified File Access & TOCTOU Protection

Race conditions in filesystem operations are easy to ignore.

They shouldn’t be.

AEGIS introduces verified reads:

OpenVerified()
OpenVerifiedRead()

The sequence:

1. Lstat()
2. Reject symlinks
3. Open file
4. SameFile() check

This prevents classic time-of-check/time-of-use attacks.

5. Atomic Everything

Interrupted writes can corrupt manifests, cache entries, or build artifacts.

Now all critical writes are atomic:

SecureWriteFile()
atomicWrite()

Pattern:

temp file → fsync → rename

On Windows, rename includes retry-safe logic to handle file locking behavior.

6. Supply Chain Hardening

We expanded integrity guarantees for:

verify
sbom
vendor scanning

Improvements:

secure manifest reads
atomic manifest generation
constant-time hash comparison
fail-closed symlink handling
explicit warnings for external vendor symlinks
degraded hashing instead of silent bypass

Supply-chain security should not be optional.

7. New: `fz doctor`

A new diagnostics command:

fz doctor

Checks:

zig
fasm
wasm-ld
root accessibility
filesystem permissions
recursive verified reads
active VFS backend
runtime environment

JSON mode:

fz doctor --json

This is especially useful in CI environments.

Testing & Reliability

Everything was validated through:

go test ./...
go test -race ./...
GOOS=windows go build ./...

All green.

Coverage highlights:

pkgman   91.5%
fs       91.7%
doctor   90.8%
config   91.7%
watcher  91.1%
verify   84.0%
utils    83.1%

We also added:

branch coverage suites
fault-injection testing
mock subprocess execution
mock HTTP flows
VFS failure-path testing

Why This Matters

Most CLI tools focus on functionality.

Fewer focus on resilience.

Even fewer guarantee:

predictable behavior
secure execution
cross-platform parity
race-condition resistance
fail-closed integrity

That’s what AEGIS is about.

Not just new capabilities.

A stronger foundation.

ForgeZero v3.1.0 “AEGIS” is live.

GitHub: https://github.com/forgezero-cli/forgezero
Author: https://github.com/alexvoste

I’d love feedback from anyone building:

developer tools
compilers
CI/CD systems
package managers
secure build pipelines

ForgeZero v3.0.0 “Gloria”: Building Toward Sovereign Engineering

Alex Voste — Wed, 20 May 2026 21:03:28 +0000

In modern software development, a build system is no longer just a file pipeline—it’s the foundation of project security, determinism, and independence.

Today, the ForgeZero team is introducing v3.0.0 “Gloria”, a major step forward in our mission toward sovereign engineering: a development process where engineers retain complete control over every byte, and external toolchains no longer dictate the rules.

This release delivers major architectural upgrades across toolchain sovereignty, supply chain security, deterministic builds, and developer tooling.

Sovereign Toolchain & Cross-Compilation

One of the most significant improvements in Gloria is the integration of a native Zig backend directly into the ForgeZero core.

This allows us to provide memory-safe cross-compilation for C/C++ projects without relying on system linkers, platform-specific libraries, or fragile host configurations.

With ForgeZero, building for any supported target becomes a clean, autonomous process—fully isolated from environment inconsistencies and external toolchain drift.

Key benefits

Native Zig-powered compilation backend
Memory-safe build orchestration
No dependency on system linker behavior
Reliable cross-platform output from a unified pipeline

Supply Chain Security by Default

Security in Gloria is not an optional plugin—it is a built-in standard.

SAST Audit Engine

We introduced a new Static Application Security Testing (SAST) engine that performs real-time project inspection during the build lifecycle.

It automatically:

Detects secret leaks and exposed credentials
Verifies license compliance, including MPL 2.0 conditions
Performs deep code pattern analysis for risky structures and anomalies

CycloneDX SBOM Generation

ForgeZero now automatically generates a Software Bill of Materials (SBOM) using the CycloneDX specification, providing full transparency into software composition.

To ensure artifact integrity, generated metadata and outputs are protected with BLAKE3 cryptographic hashing.

Reliability & Deterministic Builds

Reproducibility is a core principle of sovereign engineering.

Zero-Entropy Binaries

Gloria produces byte-for-byte identical binaries, independent of the underlying hardware used during compilation.

This hardware-independent determinism improves:

Build verification
Supply chain trust
CI/CD consistency
Long-term reproducibility

Thread-Safe Core

The ForgeZero core is now fully thread-safe and race-detected, ensuring predictable behavior even under high-concurrency workloads and large-scale build pipelines.

Expanded Developer Toolkit

Gloria also introduces new utilities designed for verification and performance-focused workflows.

`fz verify`

Instant integrity validation for the entire project structure.

`fz bench`

High-precision benchmarking with nanosecond-level profiling, built for engineers optimizing performance at instruction-level granularity.

FASM & WASM Support

We expanded target support with:

FASM (ELF64)
WASM (wasm32-wasi)

This makes ForgeZero even more flexible across systems, low-level tooling, and portable runtime environments.

Our Mission: Absolute Build Sovereignty

ForgeZero exists to give engineers complete sovereignty over the build process.

By eliminating reliance on external toolchains and enforcing binary integrity at every stage of the software lifecycle, we aim to make secure, deterministic engineering the default—not the exception.

We’d love feedback from developers who care deeply about clean architecture, reproducibility, and supply chain security.

Resources

GitHub: github.com/forgezero-cli/ForgeZero

Documentation and release notes have been fully updated in the repository.

fz 2.0.0 NEXUS — package manager, BLAKE3 cache, and cross-compilation for C/ASM

Alex Voste — Tue, 19 May 2026 22:39:23 +0000

Yesterday I shipped 1.9.0. Got a solid mix of hate and genuinely useful feedback. Didn't sleep. Took all of it personally. Built 2.0.0 instead.

No point dragging it out — here's everything I promised, shipped right now.

What's new

⚡ BLAKE3 file hashing — 7x faster cache

Dropped SHA256. Switched to BLAKE3 across the board.

File size	Before	After
10 MB	58 ms	8.7 ms

Package verification from the catalog uses BLAKE3 too.

📦 Package manager — fz pm

The big one. Dependency management for C/ASM projects that doesn't make you want to quit programming.

fz pm add <repository>
fz pm remove <package>
fz pm update
fz pm list
fz pm search <query>
fz pm install
fz pm catalog

Dependencies live in .fz.yaml. Removal cleans up empty parent directories automatically. Backed by a community-driven JSON package catalog.

🔌 Shared library support

New flags: -shared, -cc-flag, -ld-flag. Build .so and .dylib targets without wiring things up by hand.

🎯 Cross-compilation

fz -target arm-linux-gnueabihf
fz -target riscv64-linux-gnu
fz -target x86_64-w64-mingw32

ARM, RISC-V, x86_64, i386. Compiler, assembler, and linker are selected automatically for the target triple.

🗂 Static libraries

fz -type static -lib mylib

Builds .a archives from object files via ar.

🧠 LSP support

fz -compile-commands

Generates compile_commands.json for clangd and any compatible LSP client. Autocomplete and go-to-definition, no manual config.

Improvements & fixes

Parallel builds with -j N
Linker scripts and text section address: -T, -Ttext
Fixed object file name collisions (hello.asm vs hello.s)
All golangci-lint warnings resolved: errcheck, govet, ineffassign
Context and timeouts for all network and git operations
Test coverage: utils 84%, linker 60%, assembler 60%, builder 56%

Install

go install github.com/forgezero-cli/ForgeZero/cmd/fz@latest

I haven't slept properly in days. I'm building a package manager for C. And I regret nothing.

Alex Voste — Tue, 19 May 2026 20:04:57 +0000

4 hours of sleep a night for the past few days. ForgeZero went from 1.0 to 1.9.0 in that time. This isn't work anymore. This is obsession.

Let me be real with you. Why would anyone spend their nights fighting linkers, allocators, and milliseconds?

Because I refuse to let C development die.

I'm obsessed with low-level programming. That feeling when it's just you and the bare metal. No fat abstractions. No lazy runtimes holding your hand. No GC randomly deciding now is a great time to pause everything. Just your logic, the CPU, and the truth.

C is an art form. It's honest. It's foundational. And the tooling around it is, frankly, a disaster.

Setting up dependencies in C feels like archaeology. The build systems look like they were designed to punish you. New devs touch it once and run back to npm. I get it. But I think we can fix this.

That's what ForgeZero 2.0: NEXUS is about.

What's coming

📦 A package manager that doesn't suck — fz pm

fz pm add and you're done. Pull C libraries and ASM modules the same way you'd import anything in a modern language. No more hunting down tarballs. No more copy-pasting compiler flags from Stack Overflow threads from 2009. No more dependency hell.

Just: point at a repo, let ForgeZero do the rest.

🔌 Compiler-agnostic core

Clang, GCC, NASM, FASM — whatever your stack is, ForgeZero wraps it. A couple lines of config and it knows how to talk to your toolchain. Exotic target hardware? Still fine.

🧠 Incremental builds that actually work

Stop rebuilding the entire project because you fixed a typo in a comment. NEXUS does deep header dependency analysis — it sees the full dep tree and only recompiles what actually changed. Your CPU will thank you.

The stack

Go for the core. Rust for the hot paths (yeah, I'm that guy now). Pure C for the parts where I want to feel things.

Is it overengineered? Maybe. Does it rip? Absolutely.

This isn't just a software update. It's a bet that the classics don't go stale — they just needed better tooling.

ForgeZero 2.0. NEXUS. Low-level lives.

Solo dev. All PRs and issues read personally. Come break things with me.

Documentation: https://github.com/forgezero-cli/forgezero

I built a build tool in Go — and now I'm slowly rewriting pieces in Rust (fz 1.9.0 release)

Alex Voste — Tue, 19 May 2026 18:31:36 +0000

So I've been solo-building fz — a fast, opinionated build tool for C/ASM projects written in Go. No Makefile hell, no CMake nightmares. Just a single binary that figures out your toolchain and gets out of the way.

Today I shipped 1.9.0 (and a quick 1.9.2 patch). Here's what changed — and why I started poking at Rust.

What's new in 1.9.0

Cross-compilation with `-target <triple>`

fz -target arm-linux-gnueabihf
fz -target riscv64-linux-gnu
fz -target x86_64-w64-mingw32

fz now auto-selects the right compiler, assembler, and linker for the target triple. ARM, RISC-V, x86_64, i386 — all supported out of the box.

Static libraries: `-type static` / `-lib`

fz -type static -lib mylib

Builds .a archives from object files via ar. Previously you had to wire this up yourself. Now it's a one-liner.

LSP support: `compile_commands.json`

fz -compile-commands

Generates compile_commands.json for clangd and any other LSP client. Finally get autocomplete and go-to-definition in your editor without configuring anything manually.

Other improvements

fz -shell now handles both single files and full directories
Fixed a long-standing bug where hello.asm and hello.s would produce conflicting object file names
Linker test coverage: 17% → 60% 🎉
Squashed dozens of golangci-lint warnings

1.9.2 patch — the boring-but-important stuff

Cleaned up every errcheck, govet, and ineffassign warning across the codebase:

Proper error handling for json.Encode, os.Rename, os.Chmod, storeCache
Error checks in tests: os.Chdir, os.MkdirAll, os.Create, buf.ReadFrom
Fixed an empty branch in builder_test.go and a wrong printf format
Updated go.mod / go.sum

Nothing glamorous, but the kind of hygiene that prevents weird bugs six months from now.

The Rust experiment: `rustcache`

⚠️ This lives in a separate branch and is not part of the release. Yet.

I've been curious about Rust FFI for a while, so I decided to try moving the caching layer — file hashing and copying — into a Rust static library.

Here's what I've built so far in rustcache/:

// SHA256 of a file, returned as a hex string over FFI
#[no_mangle]
pub extern "C" fn rust_hash_file(path: *const c_char) -> *mut c_char { ... }

// Simple file copy via std::fs::copy
#[no_mangle]
pub extern "C" fn rust_copy_file(src: *const c_char, dst: *const c_char) -> i32 { ... }

5 unit tests, all passing. Builds into librustcache.a.

The plan

Once I wire it into Go via cgo and build tags:

//go:build rustcache

// #cgo LDFLAGS: -L./rustcache/target/release -lrustcache
// #include "rustcache.h"
import "C"

...users will be able to opt in with -tags rustcache and I'll benchmark both paths. If the Rust version is meaningfully faster, it becomes the default.

For now: zero impact on existing fz users. The Go cache path is unchanged.

What's next

[ ] Finish the Rust → Go integration (cgo, build tags, benchmarks)
[ ] Dynamic library support (.so / .dylib)
[ ] Colored error and warning output
[ ] Remote cache (S3 / MinIO) for CI/CD speedups

If you're building C or ASM projects and tired of Makefile archaeology, give fz a try. Issues and PRs welcome — it's a solo project and I read everything.

Docs and install: https://github.com/forgezero-cli/forgezero

🚀 ForgeZero v1.9.0 — The "Architect" Update: LSP Integration, Cross-Compilation & Industrial-Grade Reliability

Alex Voste — Mon, 18 May 2026 23:10:31 +0000

If you've been sleeping on ForgeZero (fz) — the zero-config C build tool that actually respects your time — v1.9.0 just dropped and it's a proper glow-up. We're talking IDE superpowers, native cross-compilation, a critical bug squash, and enough test coverage to make your QA lead weep with joy. Let's break it down. 🧵

1. LSP & IDE Support — Your Editor Finally Gets It

fz -compile-commands

One flag. That's all it takes to spit out a compile_commands.json — the Compilation Database that every serious editor lives and breathes.

What this means in practice:

Neovim + clangd — full autocomplete, go-to-definition, find-references. Everything just works™
VSCode + clang — same story, zero manual config
Any LSP client — if it reads compile_commands.json, it's happy

fz went from "fast build runner" to a legit professional dev environment with this single addition. Your IDE will finally stop lying to you about missing includes.

2. Cross-Compilation — Build for ARM from Your x86 Couch

Embedded devs, this one's for you. fz now ships with full cross-compilation support out of the box:

fz -target arm-linux-gnuebihf

That's it. No hunting for toolchain paths, no manual -CC= gymnastics. fz auto-detects the correct prefixed compilers and linkers for your target triple.

Build for ARM while sitting on your x86 machine. One command. Shipped. 📦

Supported target examples:

arm-linux-gnuebihf — ARMv7 hard-float (Raspberry Pi and friends)
Any standard GNU cross-compilation triple

3. Industrial Reliability — The Boring Part That Actually Matters

Linker Coverage: 48% → 60%+

Nobody likes writing linker tests. We did it anyway. The darkest corners of the linking pipeline are now covered, which means fewer "works on my machine" surprises in CI.

🐛 Critical Bug Fix: Object Name Collisions

This one was nasty. Multi-file projects were silently producing _.o collisions — meaning files from different directories could stomp each other's object files. The result: corrupted builds that were sometimes correct, which is the worst kind of wrong.

The fix: every object file now gets a unique name derived from its full source path. No more _.o. No more collisions. Multi-file projects build reliably, every time.

Before: src/foo.c → _.o  (collision risk)
After:  src/foo.c → src_foo.o  (unique, always)

4. UX & Infrastructure — The QoL Stuff You'll Actually Notice

Smart Self-Update with Rollback

fz -update

Before: blew away your old binary and hoped for the best.

Now: backs up the old version to /usr/local/bin/fz.old before installing the new one. Broke something? Roll back in one move. Safe as it gets. 💊

Shell Mode Now Has Tests

The interactive shell (fz REPL mode) now has full test coverage for:

SplitCommand parsing
CmdSet handling
CmdBuild execution

Your in-tool console is no longer running on vibes and prayers.

5. Strict Coding Standards — `fz` Teaches You to Write Clean C

ForgeZero now ships with sane-by-default compiler flags in all docs and JSON command configs:

-Wall -Wextra -Werror -Wpedantic -Wshadow -Wconversion

This isn't gatekeeping — it's a forcing function. If your code compiles cleanly with these flags, it's genuinely clean code. fz has an opinion about code quality, and it's the right opinion.

Treat warnings as errors. Your future self will thank you. Your coworkers will thank you. The universe will be in slightly better order.

TL;DR — What Shipped in v1.9.0

Feature	What It Does
`-compile-commands`	Generates `compile_commands.json` for LSP/IDE
Cross-compilation	`-target <triple>` — auto-detects toolchain
Object name fix	Unique `.o` names, no more multi-file collisions
Linker coverage	48% → 60%+ test coverage
Smart update	`fz -update` backs up old binary to `fz.old`
Shell tests	`SplitCommand`, `CmdSet`, `CmdBuild` are tested
Default flags	`-Wall -Wextra -Werror -Wpedantic -Wshadow -Wconversion`

What's Next?

The "Architect" name wasn't chosen lightly. v1.9.0 lays the foundation for fz to become the go-to build tool for serious C projects — from single-file scripts to multi-target embedded systems.

Got feedback? Ran into an edge case? Drop it in the comments or open an issue. We read everything. 👇

Built with fz. Compiled cleanly. No warnings.

fz 1.6 & 1.7: build C, ASM and C++ without CMake hell

Alex Voste — Mon, 18 May 2026 00:19:15 +0000

We all know the pain: you have a tiny C or ASM project, and suddenly you're knee-deep in CMake syntax from 2003, googling why your target_link_libraries silently does nothing. I built ForgeZero so that building feels like go build — you just run it and it works.

Here's what landed in the last two releases.

v1.6 — daily quality of life

fz init scaffolds .fz.yaml, .fzignore and a README in one shot. No more copy-pasting boilerplate before writing a single line of actual code.

Speaking of .fz.yaml — yes, I added proper config file support, because large projects need it. Define your deps, flags, output format once and forget about it. .fzignore works exactly like .gitignore: tell fz what to skip, it skips it.

-format bin outputs flat binaries — no ELF headers, just raw bytes. Essential for bootloaders and firmware where the header is dead weight.

libs in config auto-injects -lm, -lc, whatever you need. flags.cc lets you drop in -O3 -march=native without touching a build script.

v1.7 — for when the project gets serious

-j N parallel builds. On a 12-core machine the compile spreads across threads faster than you can blink. If you're building system software where every file matters, this one's a relief.

Linker scripts (-T, -Ttext) for precise address control — without this, working on OSes and embedded targets was just not practical.

fz -shell drops you into an interactive mode: tweak params, build, clean, watch output — all live. Useful when you're deep in a debug loop and don't want to retype the same command 40 times.

Full C++ support — .cpp, .cc, .cxx now compile with the same strict flags as C. No shortcuts.

Get it

go install github.com/forgezero-cli/ForgeZero/cmd/fz@latest

Fully open source. Docs, examples and a forum at fzforum.duckdns.org — drop by if you're tired of heavyweight build systems. PRs welcome. documentation

I got tired of typing nasm/ld/gcc by hand, so I built a tool that does it for me

Alex Voste — Sun, 17 May 2026 16:11:51 +0000

If you've ever written assembly or C without CMake, Makefiles, or any build system — you know the ritual.

Open terminal. Remember the flags. Compile one file. Then another. Then link them. Then mess up the argument order. Then do it again. And again. Every. Single. Time.

I did this long enough to finally say: enough.

That's how fz (ForgeZero) was born — a small CLI tool written in Go that takes all the assembly/C build drudgery off your plate. No extra dependencies. No 300-line config files. It just works.

What it actually does

Build a single file — one command

fz -asm hello.asm
fz -cc main.c

No need to remember nasm, fasm, or gcc flags. fz figures out what it's looking at and spits out a binary.

Build an entire project — also one command

fz -dir ./src

Recursively finds all .asm, .s, .fasm, and .c files, compiles each into an object file, then links everything together. Object filenames are unique, so hello_asm.o and hello_s.o don't step on each other.

SHA256 caching — because waiting is pain

Incremental builds without changes are near-instant. fz hashes each source file + build flags, and if nothing changed, the compiler doesn't even get invoked. That's it.

Strict mode for C — no escape from quality

C files are compiled with the full warnings-as-errors suite:

-Wall -Wextra -Werror -Wpedantic -Wshadow -Wconversion

AddressSanitizer and UBSan are on by default. The -strict flag adds use-after-return and use-after-scope, and automatically prefers clang if it's available, falling back to gcc with limited support.

Don't want sanitizers? -no-sanitize. Done.

Watch mode — because hitting ↑ Enter is still too many keystrokes

fz -watch -dir ./src

Watches your source files and config for changes, rebuilds with a 500ms debounce. Save a file, and a second later you've got a fresh binary.

JSON output — for your CI/CD pipelines

fz -json -dir ./src

Returns structured JSON: status, exit code, build time, list of sources and object files, binary name, error message. Easy to parse in any pipeline, no string-scraping needed.

Config file — set it and forget it

Drop a .fz.yaml in your project root and stop passing flags every time:

source_dir: ./src
output: my_program
mode: auto
debug: false
keep_obj: false
exclude:
  - legacy/

Also accepts fz.yaml, .fz.yml, fz.yml — whatever you prefer.

Three linker modes

Not all projects are the same, so you can pick:

Mode	What it does
`auto`	Tries `gcc`, then `gcc -no-pie`, then `ld`
`c`	Only `gcc` (for C projects)
`raw`	Only `ld` (for pure assembly)

fz also checks for duplicate symbols before linking via nm / objdump, so you get a clean, readable error instead of a linker wall of text.

Linters & formatters

Since fz builds real C and assembly, it plays nicely with the tools you're already using:

clang-format — format your sources before/after build
clang-tidy — static analysis; pairs well with fz's strict mode
cppcheck — extra static checks on top of GCC/clang warnings
splint — if you're into really paranoid C checking

Assembly (NASM/GAS):

asmfmt — NASM formatter (like gofmt, but for asm)
nasm -E — preprocessor pass to inspect macro expansion
GAS has no official formatter, but indent-style scripts exist in the wild

Go (fz itself):

gofmt / goimports — standard Go formatting
golangci-lint — runs staticcheck, errcheck, govet and a bunch more in one shot
go vet — built-in static analysis

The philosophy: fz enforces quality at the compiler level (warnings as errors, sanitizers), and you layer your preferred linter on top.

Installation

go install github.com/forgezero-cli/ForgeZero/cmd/fz@latest

You just need Go, plus whatever compilers you're already using (nasm, gcc, fasm). That's it. No package manager drama.

Roadmap (v1.4.0 → v1.5.0)

Here's what's coming:

C++ support — .cpp files → g++, same strict flags
Custom flags — -asm-flag, -cc-flag, -ld-flag for when you need to pass something weird
Exclude patterns — -exclude in CLI and exclude: in config
Better error messages — with hints like "did you forget #include <stdio.h>?"
Colored output — errors in red, success in green, respects NO_COLOR
CI/CD matrix — automated tests on Linux, macOS, Windows
Packages — Homebrew tap and AUR package
Shell completions — bash, zsh, fish

Current state

Version 1.3.0 is stable, production-ready, with ~70% test coverage, a built-in man page (fz -man), and a colored --help with grouped options and examples.

If you write low-level code and this pain sounds familiar — give it a shot. Feedback and ⭐ on GitHub are always appreciated.

→ github.com/forgezero-cli/ForgeZero

ForgeZero v1.0 on Go: the assembly builder that gobbles up folders and doesn't whine

Alex Voste — Sat, 16 May 2026 21:16:45 +0000

Yo, AlexVoste back again.

Not long ago I wrote about my ForgeZero builder written in vanilla Node.js – zero dependencies, pure pain. Well, time flies, and I've moved to something lighter and more modern.

I rewrote the whole damn thing in Go, added new flags, the ability to link entire directories in one shot. Meet fz – the assembly Swiss Army knife that just works.

Why though?

If you ever touched assembly (NASM, GAS, FASM), you know the drill: run nasm, then gcc, then ld, don't forget the flags, and for multi‑file projects – manually list every object file. It gets old real fast.

fz boils it down to:

fz -asm boot.asm

or for a whole folder

fz -dir ./src

What's under the hood

Single file build – fz -asm file.asm → file.o + file (or .exe on Windows).
Recursive folder build – fz -dir ./kernel finds every .asm, .s, .fasm, assembles each into an object file, then links everything into one binary. Binary name = folder name + .out (or .exe).
Noise? Shut it – by default external commands (nasm, gcc, ld) stay silent. You only see Built: program.out. If something fails – a short error telling you to try -verbose.
Auto‑linking – first gcc, then gcc -no-pie, then ld (auto mode). You can force c (gcc only) or raw (ld only) if you're a control freak.
Debug flag – -debug passes -g down to the assembler.
Cleanup – fz -dir ./src -clean nukes all .o files, executables, and the .fz_objs temp folder in one go.
Unique object names – hello.asm and hello.s become hello_asm.o and hello_s.o so they don't step on each other's toes.

Show me the commands

Build a single NASM file with verbose output:

fz -asm hello.asm -verbose

Build a whole project folder into a custom binary:

fz -dir ./src -out myapp

Force raw linking (no libc, pure ld):

fz -asm boot.asm -mode raw

Clean up all artifacts generated by fz:

fz -dir . -clean

Install – two ways (one is super slick)

_ Via go install (recommended, because Go is awesome)_

go install github.com/alexvoste/ForgeZero/cmd/fz@latest

That drops the fz binary into $GOPATH/bin (usually ~/go/bin). Make sure that directory is in your PATH.

_ Old school clone & build_
git clone https://github.com/alexvoste/ForgeZero.git cd ForgeZero go build -o fz ./cmd/fz sudo mv fz /usr/local/bin/

Requirements: you need the tools you're actually using – nasm, gcc, fasm, ld must be in PATH. The builder will politely remind you if something is missing.
What's next

I'm planning to add custom linker scripts, JSON output for CI/CD pipelines, and maybe a watch mode that rebuilds automatically when source files change.

Try it out, open issues, send pull requests – all welcome.

Happy building!

Repo: https://github.com/alexvoste/forgezero/

ForgeZero: How I stopped fearing linkers and wrote a universal assembly builder (Node.js Go)

Alex Voste — Fri, 15 May 2026 22:35:47 +0000

Hey everyone, low-level programmers and fellow weirdos.

About two months ago, I was tinkering with a real-mode operating system that also had 64-bit support. Assembly was a daily grind: crypto protocols, syscalls, manual memory management. And I got tired of it. Tired of endlessly typing nasm ..., ld ..., babysitting flags, and cleaning up object file garbage.

So I decided to write my own builder. First in Node.js (just for fast prototyping), and now I'm in the middle of a full rewrite in Go. And no, it's not just because Go is trendy – it's because when you write a system tool, it should be fast, native, and not drag around a 100 MB runtime.

What it actually does

You write:

node index.js main.asm

And you get an executable. That's it. The builder does everything:

Finds all .asm (or .s, .fasm) files recursively.
Calls the right assembler with the right flags.
Picks the right linker for your OS (ld for Linux, gcc for Windows, ld for macOS).
Links with libraries if needed.
Optionally cleans up object files.

Why it's unique

1. Three assemblers in one bottle

Most builders are locked to one assembler — make with NASM rules, that's it. But here:

NASM (x86 standard):
node index.js program.asm

GAS (GNU Assembler, AT&T syntax):
node index.js --assembler gas program.s

FASM (flat assembler, custom syntax):
node index.js --assembler fasm program.fasm

No switching tools — one builder rules them all. Each assembler has its own flag quirks (NASM needs -f elf64, GAS just as, FASM wants format ELF64 in the source), but I made you forget about that. The --format flag works for NASM; for FASM it's… well, almost works, but you get it.

2. Cross‑platform linking, no headache

You know that on Linux the linker is ld, on Windows it's gcc (via MinGW), and on macOS it's also ld but with different flags? I do. The builder detects your platform and:

On Linux: adds -dynamic-linker /lib64/ld-linux-x86-64.so.2
On Windows: calls gcc (because ld can't handle PE formats properly)
On macOS: uses ld with native defaults

And you just run ./program — no #ifdef in your head.

Debugging is not a luxury

Ever tried debugging assembly without symbols? I have. It's pain. So there's a --debug flag:
bash

node index.js --debug factorial.asm gdb ./factorial (gdb) break main (gdb) run
It adds -g to the assembler (where supported) and to the linker. For FASM I had to hack it (-d DEBUG=1), but it works. Now you can set breakpoints and watch registers like a civilised person.

What else makes it cool (and why I'm honestly proud)

The code is split into args.js, assembler.js, linker.js, builder.js, logger.js. That's not just fancy talk — you can grab only the linker or only the argument parser for your own project. Or add your own assembler (YASM? FASM? LLVM? — let me know, I'll add it).

Protection from dumb mistakes

Once I accidentally overwrote my source code with the compiled binary because the builder named the output the same as the input. Since then, there's a check: if output == input, it either changes the name or throws an error. No more rm -rf of destiny.

The catch (honest truth)

The builder isn't perfect. Here's what it can't do yet:

Parallel compilation – builds one file at a time. On a hundred files, it's slow.
Windows without MinGW – if you have a bare Windows with no gcc, linking fails.
FASM is still finicky – with --debug it sometimes complains about "illegal instruction" (but I'm fixing it).
No config file – all flags come from the command line. That's also a plus for simplicity, though.

But for 99% of tasks — building one or two assembly files with or without libc — it works like a charm.

Why I wrote it

I got tired of fragmentation. Assembly is already low‑level — why should the tools around it be complicated? I wanted a "just run it" experience, like gcc main.c. Now I have it. And so do you.

Try it. If you find a bug, please tell me. I'll fix it.

What's next (Go version)

Right now I'm actively developing the new version in Go (separate branch). The core engine is rewritten, argument parsing and assembler invocations work. FASM + --debug is also being fixed (no more "illegal instruction" — I finally understood that FASM doesn't like -d without a value).

Once the Go version catches up with Node.js feature‑wise (in the next few weeks), I'll release 2.0. The Node.js version will stay as an archived prototype, but the main builder will be Go.

Repo: https://github.com/alexvoste/ForgeZero

Forem: Alex Voste

ForgeZero 3.1 “AEGIS”: Hardening a CLI Toolchain into a Secure Engineering Platform

The Goal: Harden Everything

1. Native Windows Support (Without WSL)

2. A Dedicated Virtual FileSystem Layer

3. Hardened Command Execution

4. Verified File Access & TOCTOU Protection

5. Atomic Everything

6. Supply Chain Hardening

7. New: fz doctor

Testing & Reliability

Why This Matters

ForgeZero v3.0.0 “Gloria”: Building Toward Sovereign Engineering

Sovereign Toolchain & Cross-Compilation

Key benefits

Supply Chain Security by Default

SAST Audit Engine

CycloneDX SBOM Generation

Reliability & Deterministic Builds

Zero-Entropy Binaries

Thread-Safe Core

Expanded Developer Toolkit

fz verify

fz bench

FASM & WASM Support

Our Mission: Absolute Build Sovereignty

Resources

fz 2.0.0 NEXUS — package manager, BLAKE3 cache, and cross-compilation for C/ASM

What's new

⚡ BLAKE3 file hashing — 7x faster cache

📦 Package manager — fz pm

🔌 Shared library support

🎯 Cross-compilation

🗂 Static libraries

🧠 LSP support

Improvements & fixes

Install

Links

I haven't slept properly in days. I'm building a package manager for C. And I regret nothing.

What's coming

📦 A package manager that doesn't suck — fz pm

🔌 Compiler-agnostic core

🧠 Incremental builds that actually work

The stack

I built a build tool in Go — and now I'm slowly rewriting pieces in Rust (fz 1.9.0 release)

What's new in 1.9.0

Cross-compilation with -target <triple>

Static libraries: -type static / -lib

LSP support: compile_commands.json

Other improvements

1.9.2 patch — the boring-but-important stuff

The Rust experiment: rustcache

The plan

What's next

🚀 ForgeZero v1.9.0 — The "Architect" Update: LSP Integration, Cross-Compilation & Industrial-Grade Reliability

1. LSP & IDE Support — Your Editor Finally Gets It

2. Cross-Compilation — Build for ARM from Your x86 Couch

3. Industrial Reliability — The Boring Part That Actually Matters

Linker Coverage: 48% → 60%+

🐛 Critical Bug Fix: Object Name Collisions

4. UX & Infrastructure — The QoL Stuff You'll Actually Notice

Smart Self-Update with Rollback

Shell Mode Now Has Tests

5. Strict Coding Standards — fz Teaches You to Write Clean C

TL;DR — What Shipped in v1.9.0

What's Next?

fz 1.6 & 1.7: build C, ASM and C++ without CMake hell

v1.6 — daily quality of life

v1.7 — for when the project gets serious

Get it

I got tired of typing nasm/ld/gcc by hand, so I built a tool that does it for me

What it actually does

Build a single file — one command

Build an entire project — also one command

SHA256 caching — because waiting is pain

Strict mode for C — no escape from quality

Watch mode — because hitting ↑ Enter is still too many keystrokes

JSON output — for your CI/CD pipelines

Config file — set it and forget it

Three linker modes

7. New: `fz doctor`

`fz verify`

`fz bench`

Cross-compilation with `-target <triple>`

Static libraries: `-type static` / `-lib`

LSP support: `compile_commands.json`

The Rust experiment: `rustcache`

5. Strict Coding Standards — `fz` Teaches You to Write Clean C