DEV Community

Just_a_kumar
Just_a_kumar

Posted on

Pushing SigNoz Foundry as a Complete DevOps Beginner Until My RAM Broke (and How I Fixed It)

Introduction

If you're a complete beginner, the backend of software feels like literal black magic. You click a single button on a sleek frontend interface, and suddenly a massive web of microservices starts yelling at each other, querying databases, and moving heavy data streams under the hood. Standard debugging tools rarely show you why a specific action is lagging or exactly where the architecture is screaming for help.

When the WeMakeDevs team dropped the "Agents of SigNoz" hackathon, I saw the perfect excuse to step outside my comfort zone and dive into open-source observability. My mission was simple on paper: self-host SigNoz on my local machine using their brand-new CLI installer, Foundry.

It did not go smoothly. Over the course of this deployment I hit a shell compatibility error, a broken Docker-to-WSL bridge, a permissions wall, and finally a hard out-of-memory crash that killed the whole process right as it was about to finish. But I didn't stop at the crash — I went back, found the actual root cause of each problem, fixed them properly instead of just working around them, and got SigNoz fully running with real trace data flowing into it. This post walks through every one of those failures in order, what actually caused each one, and exactly how I fixed it.

Prerequisites

BBefore you break things the way I did, make sure you have this on your Windows machine:

  • Docker Desktop, with the engine actually running (not just installed)
  • WSL 2 with an active Ubuntu distro
  • VS Code, mainly for its terminal profile switcher

Problem 1: The Wrong Shell

The hackathon explicitly required using SigNoz's new CLI tool, Foundry. The official docs gave a one-line install command:

curl -fsSL [https://signoz.io/foundry.sh](https://signoz.io/foundry.sh) | bash
Enter fullscreen mode Exit fullscreen mode

I pulled up my VS Code terminal, pasted it, hit Enter — and got an error saying it couldn't find a parameter matching -fsSL.

The cause: My default VS Code terminal was PowerShell, not a Linux shell. PowerShell aliases curl to Invoke-WebRequest, which has no idea what -fsSL means because those are curl-specific flags from Linux.

The fix: I switched the terminal profile in VS Code to Ubuntu (WSL) and re-ran the exact same command. It worked immediately.

Problem 2: The Broken Docker Bridge

With Foundry installed, I wrote a small YAML blueprint (casting.yaml) telling it to deploy SigNoz via Docker:

apiVersion: v1alpha1
kind: Installation
metadata:
  name: signoz
spec:
  deployment:
    flavor: compose
    mode: docker
Enter fullscreen mode Exit fullscreen mode

Running foundryctl cast -f casting.yaml immediately failed — the terminal said it couldn't find docker-compose. Docker Desktop was running fine on the Windows side, but WSL had no idea it existed.

The cause: Docker Desktop and WSL don't talk to each other by default. You have to explicitly bridge them.

The fix:Docker Desktop → Settings → Resources → WSL Integration → toggle on "Enable integration with my default WSL distro," enable Ubuntu specifically, then Apply & Restart.

Problem 3: The Permission Wall

With the bridge fixed, I re-ran the deploy and hit a new error:

unable to get image... permission denied while trying to connect to the Docker API at unix:///var/run/docker.sock
Enter fullscreen mode Exit fullscreen mode

The cause: My Linux user didn't have permission to talk to the Docker daemon's socket. This is standard Docker behavior on a fresh Linux setup — only root or members of the docker group can use the Docker CLI without extra steps.

The quick-and-dirty fix I used at first: I forced it through with sudo and the absolute path to the binary:

sudo /home/idiot/.local/bin/foundryctl cast -f casting.yaml
Enter fullscreen mode Exit fullscreen mode

That got the deploy moving again, but it's not the right long-term fix — running Docker commands as root for every single call isn't something you want to make a habit of.

Problem 4: The Out-of-Memory Crash

Past the permission wall, the deploy connected to the Docker registry and started pulling the backend images — Postgres, the OpenTelemetry collector, ClickHouse. Right at the finish line, it stopped dead:

"exception": {
  "message": "signal: killed"
}
Enter fullscreen mode Exit fullscreen mode

The cause: My machine ran out of RAM trying to unpack all those container layers at once — ClickHouse especially is not lightweight. Windows killed the process to protect itself before I could kill it myself.

At first I read this as a hardware limitation and wrote it off. It isn't. WSL 2 caps how much RAM it'll allocate to the Linux VM by default, and that cap is often too conservative for a multi-container stack like SigNoz's — it's a configuration ceiling, not a physical one.

The real fix: create (or edit) a .wslconfig file in the Windows user directory:

notepad "$env:USERPROFILE\.wslconfig"
Enter fullscreen mode Exit fullscreen mode

Notepad will offer to create it — say yes, then paste:

[wsl2]
memory=8GB
processors=4
swap=4GB
Enter fullscreen mode Exit fullscreen mode

Save, then restart WSL from PowerShell so the change actually applies:

wsl --shutdown
Enter fullscreen mode Exit fullscreen mode

Reopening the terminal and checking free -h confirmed the new memory ceiling had taken effect.

Fixing Problem 3 Properly

Before re-running the deploy, I went back and fixed the permissions issue the right way instead of relying on sudo:

sudo usermod -aG docker $USER
Enter fullscreen mode Exit fullscreen mode

Group membership changes don't apply to an already-open terminal session — I had to fully close the terminal tab and open a fresh one for it to take effect. After that, docker ps worked with no sudo and no permission error.

The Clean Re-Run

With the memory ceiling raised and permissions fixed properly, I cleared out any half-downloaded layers from the earlier crash:

docker system prune -a
Enter fullscreen mode Exit fullscreen mode

Then ran the deploy again, this time with no sudo and no workarounds:

foundryctl cast -f casting.yaml
Enter fullscreen mode Exit fullscreen mode

This time it completed cleanly — every image pulled, every container started or reported healthy, no OOM kill.

Getting Into the Dashboard

With everything running, I opened http://localhost:8080 and landed on SigNoz's account setup screen.

After creating an account, I was in — but the dashboard was empty, with a message saying no data had been sent yet. Standing the tool up was only half the job; nothing shows up in an observability platform until something is actually instrumented and pointed at it.

Getting Real Data Flowing

To generate real trace data without building a project from scratch, I used Jaeger's HotROD demo app — a small pre-built microservices app made specifically for testing tracing setups. My first attempt at running it didn't send any data anywhere, because I hadn't told it where SigNoz's collector actually was:

docker run --rm -d --name hotrod \
  --network signoz-network \
  -p 8081:8080 \
  jaegertracing/example-hotrod:latest \
  all
Enter fullscreen mode Exit fullscreen mode

The fix: HotROD needs to be told explicitly where to send its OTLP trace data. I found the right container name by listing what Foundry had actually deployed:

docker ps --format "table {{.Names}}"
Enter fullscreen mode Exit fullscreen mode

and pointed HotROD at the ingester service on the same Docker network:

docker stop hotrod

docker run --rm -d --name hotrod \
  --network signoz-network \
  -p 8081:8080 \
  --env OTEL_EXPORTER_OTLP_ENDPOINT=http://signoz-ingester-1:4318 \
  jaegertracing/example-hotrod:latest \
  all
Enter fullscreen mode Exit fullscreen mode

(Worth being upfront about: HotROD is Jaeger's example app, not something built by or for SigNoz — I used it purely as a traffic generator to prove the pipeline actually works end to end, not as part of a custom project.)

I opened http://localhost:8081 and clicked through a few "call a car" requests for different customers to generate multiple traces.

The Payoff

Back in SigNoz's Traces Explorer, real spans had landed — service names like route and frontend, real durations, real HTTP status codes. Not a mock, not a placeholder. An actual working observability pipeline, built from a machine that had OOM-crashed on the exact same deployment less than an hour earlier.

What I Learned

  • Shell context matters more than the command itself. The exact same string can fail or succeed depending on whether PowerShell or a real Linux shell is interpreting it.
  • Docker on WSL is really two systems shaking hands, and either side — the bridge, or the socket permissions — can quietly block you without an error message that points at the real cause.
  • "Out of memory" isn't always a hardware problem. On WSL 2 specifically, it's frequently a configuration default, not a physical limit. Checking .wslconfig costs two minutes and can save you from wrongly concluding your machine just isn't capable.
  • sudo is a workaround, not a fix. It got me unblocked in the moment, but usermod -aG docker is the version of that fix worth actually keeping.
  • Deploying the tool and using the tool are two different milestones. SigNoz being "up" and SigNoz actually showing you something are separated by one more step most tutorials skip past: getting real telemetry pointed at it.

Conclusion

I started this deployment expecting a quick CLI install and ended up debugging shell environments, Docker-to-WSL networking, Unix socket permissions, and a memory ceiling I initially mistook for a hardware wall — before finally watching real trace data land in a dashboard that, an hour earlier, hadn't even been able to finish installing. Every fix here came from actually reading the error instead of guessing, which is probably the most useful thing I'm walking away with — that, and a .wslconfig file I'm never deploying anything heavy without again.

Resources:

Top comments (0)