Self-Hosting SigNoz with Foundry on Windows ARM64 (and the WSL2 wall that almost stopped me)

sai krishna chowdary — Fri, 17 Jul 2026 12:19:48 +0000

My laptop is a Windows ARM64 machine. Most self-hosted observability tooling assumes you're on Linux, macOS, or at worst regular x86 Windows — so when I sat down to self-host SigNoz for the Agents of SigNoz hackathon, I genuinely didn't know if it would work at all before I'd tried. An hour later I had a fully healthy stack, an MCP server responding, and one very specific error message that taught me something the docs don't spell out.

Why self-host, and why Foundry

I'm building an autonomous incident-response agent for this hackathon, and my first instinct was to reach for SigNoz Cloud — no infrastructure to babysit, one less thing to break mid-week. But the hackathon's own field requirements are specific: install via Foundry, and include the resulting casting.yaml/casting.yaml.lock in your repo so judges can reproduce the deployment. That's a self-hosted-only requirement — Foundry doesn't target Cloud at all. So before committing to that architecture for the real project, I wanted to know: does this actually work cleanly on my hardware, or am I about to spend Day 1 fighting Docker instead of building?

Getting Foundry running

Foundry is SigNoz's newer install path — it replaced the old install script, and the whole idea is config-as-code: one file describes your deployment, one command stands it up. The minimal casting.yaml is small enough to read in full:

yamlapiVersion: v1alpha1
kind: Installation
metadata:
name: signoz
spec:
deployment:
flavor: compose
mode: docker

Then:

bashfoundryctl cast -f casting.yaml

That single command checks your environment, generates the actual Compose files, and brings up ClickHouse, ClickHouse Keeper, Postgres, the OTel collector, and the SigNoz UI. Watching everything land on Healthy in one pass, on an ARM64 machine I half-expected to fight with, was a genuinely good moment.

The wall: "docker: command not found"

Everything worked — until I stopped the containers to test a clean restart, and came back to this:

The command 'docker' could not be found in this WSL 2 distro.
We recommend to activate the WSL integration in Docker Desktop settings.

This confused me for longer than I'd like to admit, because Docker had just worked, in the same terminal, minutes earlier. The actual cause: Docker Desktop's WSL integration isn't a single global switch — it's enabled per distro, individually, and I hadn't noticed my specific distro (Dicky) had its own toggle sitting separately in Docker Desktop → Settings → Resources → WSL Integration. Flipping that on and hitting Apply & Restart fixed it immediately.

The lesson that's easy to miss from the docs alone: "enable WSL integration" doesn't mean "flip it on once." If you're running multiple WSL distros, or reinstalled/renamed yours, check that your specific distro is checked, not just that integration is on in general.

Turning on the MCP server

The feature I actually wanted to test was SigNoz's own MCP (Model Context Protocol) server — since my hackathon project is an agent that needs to query telemetry programmatically, and SigNoz shipping this as a first-class, one-flag addition to Foundry is directly relevant. Adding it meant one small edit to casting.yaml:

yamlspec:
mcp:
spec:
enabled: true

Re-running foundryctl cast added the signoz-mcp container without disturbing anything already running — no downtime for the rest of the stack, which I wasn't expecting from a config-as-code tool on a first try. A health check confirmed it:

bashcurl -fsS localhost:8000/livez && echo " OK"

ok OK

That means any MCP-compatible client — Claude Code, Cursor, or the custom agent I'm building — can query real traces, logs, and metrics using the same schema a human sees in the UI, without a separate integration project. For a hackathon track built specifically around agent-native observability, that's a meaningfully lower barrier than I expected.

Setting up API access

Last piece: a Service Account, created under Settings → Identity & Access → Service Accounts (not the account dropdown at the top, which is just your personal profile — took me a minute to find the right menu). Generating a key from its Keys tab gave me the credential both the MCP server and SigNoz's regular query API use for programmatic access.

What I'd tell someone else trying this

If you're on Windows, check Docker Desktop's WSL integration toggle is on for your specific distro, not just enabled generally — this cost me the most confusion for the least actual problem.
The MCP flag costs nothing to enable up front, even if you're not sure yet whether you'll use it.
Foundry's pitch — one config file, one command, reproducible via casting.yaml.lock — held up under a genuinely awkward hardware combination (Windows, ARM64, WSL2). Total time from zero to a fully healthy stack, WSL hiccup included: under an hour.

Conclusion

Self-hosting SigNoz via Foundry on Windows ARM64 works, and works cleanly, once you know where the one Windows-specific gotcha is hiding. Next up: instrumenting real services with OpenTelemetry and building the actual incident-response agent this was all in service of.

DEV Community: sai krishna chowdary

Self-Hosting SigNoz with Foundry on Windows ARM64 (and the WSL2 wall that almost stopped me)

ok OK