Introducing SigNoz Foundry - One Config, One Command Deployment

At SigNoz, we’re always trying to democratize observability as part of our open-source efforts. Previously, we had launched SigNoz as a single binary around this time to reduce the sprawl and maintenance overhead for self-hosted SigNoz.

Building on the same effort, we are proud to announce Foundry, a centralized hub for managing and deploying self-hosted SigNoz instances across all supported platforms.

Why Was Foundry Needed?

Even after we shipped a single binary for the core application, installing SigNoz on Linux took roughly 50 commands and required configuring 9 files by hand. A single typo, a misconfiguration, or a silent failure meant losing precious developer time.

On the other hand, our engineering team faced its own share of problems. We currently maintain 15 installation sources, each of which became a potential point of failure each time the application evolved or the source platform underwent changes.

Further, there was no central schema—changes had to be manually integrated because there was no automatic propagation mechanism in place.
As we continued to expand on the deployment targets, managing releases and preventing configuration drifts took significant developer bandwidth and became an ever-increasing burden.

To resolve the frequent challenges faced by users relying on open-source SigNoz, and to untangle the growing complexity of distributing to multiple platforms, Nagesh and Miguel (aka Mike, we have two Miguels in our team) from the platform team built Foundry.

What is SigNoz Foundry?

Foundry is a CLI tool that allows you to write a single configuration file (foundry.yaml, also known as a casting). From this single file, Foundry generates all the required deployment files and brings SigNoz online. Think of it as Terraform, but purpose-built for managing SigNoz deployments.

Instead of manually installing dependencies, editing ClickHouse configurations, OpenTelemetry Collector pipelines, and systemd units, you define your intent and platform-specific overrides in one place. Foundry handles the complexity of translating that intent into the correct platform-specific manifests.

Foundry simplifies the SigNoz setup process, so you can spend time actually using SigNoz.

"Couldn't this just be a Docker Compose file?"

We already distribute Docker Compose manifests for SigNoz, so building a new deployment tool might seem redundant. We agree that Compose is great for many use cases. However, as seen above, not everyone runs SigNoz using standard Docker containers.

Users operate under different constraints, require specific architectural patterns, and deploy on varied platforms. Supporting all these variations manually adds massive maintenance overhead. By centralizing the logic into Foundry, we reduce setup friction.

This is also a structural improvement for our open-source roadmap. Centralizing our deployment logic means we save time on debugging edge cases across 15 different platforms. That translates directly to more engineering bandwidth for shipping new observability features.

Further, users now have the flexibility to generate the configuration for any target platform or deployment method from a single CLI. Simply update the existing config, or point Foundry to a new YAML manifest and you’re good to go.

Reproducibility and Version Guardrails

Reproducibility

Because Foundry separates your declarative config (the cast) from the output manifests (the pour), it integrates directly into GitOps workflows. This enables teams to manage version-controlled configurations with per-environment patches.

A tech lead could prepare a Docker-based pour with memory limits for local development environments, and commit that output to a shared Git repository. Any developer on the team can then pull from the repository and spin up an identical, pre-configured local instance.

Version Guardrails

A common problem when managing self-hosted deployments is dealing with version drifts over time. For complex dependencies like ClickHouse, Foundry pins the image to a tested, stable default version out of the box to guarantee compatibility.

Before and After: Running Foundry Locally

The Docker Setup Experience

Although Docker already makes application management simple, there are still notable benefits to using Foundry for the Docker stack.

The existing steps to run SigNoz via Docker require cloning the SigNoz GitHub repo and running a script that checks for Docker’s presence, pulls the images and starts the containers.
This is already seamless enough, but if you are setting up SigNoz from scratch, Foundry can save you some time.

As you can see above, you install Foundry once on your system, create a casting manifest, and point the foundryctl cast command to this manifest. The casting.yaml manifest referenced in the image contains less than 10 lines of code.

That is the ease of setup you can expect from Foundry for all your deployments, regardless of the target environment.

Streamlining the Linux Setup (or How We Slew the Goliath)

As discussed initially, the setup process for SigNoz on Linux stands out as particularly complex and error-prone. Given its complexity, a developer might spend a good chunk of the day just getting their SigNoz instance up and running.

It was the proverbial Goliath that we needed to defeat, to consider Foundry a success.

Earlier, you would have to follow each step in our comprehensive installation guide (which amounts to 13kb of Markdown if you’re feeding it to an LLM), while you dealt with any roadblocks that came along the way.

With Foundry, all you need is a minimal configuration and one command to get a locally running SigNoz instance with the correct permissions, restart policies, and ClickHouse migrations all taken care of!

Compared to the massive requirement of 9 config files, the Foundry-equivalent is an minimal as it gets:

apiVersion: v1alpha1
metadata:
  name: signoz
spec:
  deployment:
    flavor: binary
    mode: systemd

Try It, Cast It, Tell Us

Foundry is a big step towards simplifying open-source observability for our users. It has laid the groundwork that will enable us not only to ship features and bug fixes faster but also to distribute SigNoz across more platforms confidently.

With that said, we are actively developing Foundry and want to hear how it fits into your infrastructure and workflows. Learning from real user experiences will help us build features that matter to you, our users.

Your feedback is the roadmap.

Try out the latest release at the Foundry GitHub repo. If something does not work for your specific use case, feel free to start a discussion or open an issue. We will actively work with you to gather feedback, and help resolve your issues.

You can also join our slack community to interact with SigNoz maintainers and other community users.