A Go Build Failed. I Wanted to Replay It Without the Original Project.

Alimkhan Slambek — Tue, 13 Oct 2026 14:54:13 +0000

A build log tells you what went wrong. It doesn't always give you what you need to reproduce it.

If a Go build fails on another machine, you might need the exact source files, module dependencies, toolchain, and build settings before you can investigate the same failure locally.

I started building REW to explore a simple idea:

What if you could save a failed build as a file, move it to another machine, and replay it without the original checkout?

It's an open-source CLI written in Go. The first public release is available now, although it's still a pretty limited alpha.

The idea

I wanted a workflow that looks like this:

Build fails → Capture → Transfer → Replay → Compare

Instead of saving only the compiler output, REW collects selected inputs involved in the failed build and packages them into a portable .bfc capsule.

That includes selected workspace files, verified Go module artifacts, build environment metadata, stdout, stderr, and the original exit code.

The capsule can then be verified and replayed inside a Docker container with networking disabled.

The important distinction is that this isn't a VM snapshot or a complete copy of the original machine. REW captures a specific, bounded set of build inputs.

A real example

To test the current alpha, I used a controlled compiler failure in the open-source Cobra project.

I intentionally introduced a compilation error, captured the failed build with REW, and replayed the resulting capsule using Docker without relying on the original checkout.

The failure reproduced in that test.

Here's the terminal recording:

It's a deliberately broken build, not a production incident. I wanted to establish that the basic workflow worked before asking other developers to try it.

Trying it yourself

Here's a smaller example you can reproduce locally.

You'll need REW v0.1.0-alpha.5, Go 1.26.6, and Docker with Linux AMD64 container support.

Installation instructions and downloadable binaries for macOS ARM64 and Linux AMD64 are in the README.

Once REW is installed, set REW_BIN to the absolute path of its executable.

First, create a minimal project:

mkdir rew-example
cd rew-example

cat > go.mod <<'EOF'
module example.com/rew-quickstart

go 1.26.0
EOF

cat > main.go <<'EOF'
package main

func main() {
    undefinedFunction()
}
EOF

The build will fail because undefinedFunction doesn't exist.

Now capture that failure:

CGO_ENABLED=0 GOOS=linux GOARCH=amd64 GOFLAGS='' \
GOWORK=off GOTOOLCHAIN=local GOPROXY=off GOSUMDB=off \
"$REW_BIN" capture --v3 \
  --include-go-sources \
  -- go build ./...

REW records the failed execution in failure.bfc.

The capture command normally returns the same nonzero exit code as the original failed build. That's expected.

Next, replay the capsule:

"$REW_BIN" replay --v3 --allow-command --memory 1g failure.bfc

For this example, the expected result is:

Original exit code: 1
Replay exit code:   1
Outcome:            reproduced
Replay memory:      1 GiB

REW considers the failure reproduced when its current comparison checks match the original exit code and complete stderr.

It doesn't mean every detail of the original environment was reconstructed.

What happens inside the capsule?

This was one of the more interesting parts of building REW.

A compiler error is usually easy to save as text. The harder part is figuring out what needs to travel with that error so the build can run again elsewhere.

REW's current capture workflow selects Go source files, module metadata, and dependency artifacts under explicit limits.

For external Go modules, it verifies the relevant cached artifacts before including them.

The capsule also contains a manifest and integrity metadata, so replay can check the packaged contents before using them.

For replay, REW reconstructs the selected workspace and dependency inputs inside a Linux AMD64 Docker environment, without depending on the original host checkout.

The build then runs inside a Linux AMD64 Docker container with networking disabled.

This doesn't turn Docker into a security sandbox. A capsule still contains executable instructions, and you should only replay capsules from sources you trust.

What doesn't work yet

I'm keeping the first release intentionally narrow.

Right now, the supported workflow is:

Go 1.26.6
The exact command go build ./...
Linux AMD64 Docker replay
Selected workspace files and verified external module artifacts
Offline replay once the required Docker image is available

There are important limitations.

Active go.work workspaces aren't supported. CGO and custom build tags aren't supported in this workflow either. Some module configurations and build inputs need additional work.

REW also has limits on capsule size, workspace files, and dependency artifacts.

It isn't intended to capture arbitrary CI jobs, and it won't reproduce every build failure.

There's another trade-off: a capsule may contain source code and build metadata. That makes it useful for debugging, but it also means you need to review its contents before sharing it.

The README documents the current limitations in more detail.

What I'm trying to learn next

The controlled examples work, but I still don't know how well REW handles Go projects I haven't tested myself.

I'm especially interested in unusual module layouts, embedded resources, missing build inputs, or cases where replay produces a different error.

There's also a bigger question I'm trying to answer: is saving a failed build as a capsule actually useful, or is running the same build in Docker with the original checkout usually enough?

I don't have a good answer to that yet.

If you're working with Go and have 10–15 minutes, I'd really appreciate you trying the alpha.5 quickstart.

You don't need to get a successful replay. If capture fails, a dependency is missing, or something behaves unexpectedly, that's useful feedback too.

You can leave the result here:

Alpha testing — GitHub Issue #59

And if the whole approach doesn't seem useful for your workflow, I'd be interested in hearing why.

REW is open source under Apache 2.0:

https://github.com/rewtools/rew

I'm still figuring out where this approach makes sense and where it doesn't.

DEV Community: Alimkhan Slambek

[Boost]