Introducing SigNoz Foundry for your One Config, One Command Deployment

Our open source version of SigNoz powers mission-critical observability for thousands of engineering teams across the globe. We're constantly shipping things that make it easier to adopt, run, and trust SigNoz in production.

Installation is the first impression users have of your software. We've always wanted ours to match the quality of the product itself, and today, we're taking it several notches up. We're proud to announce Foundry, a centralized hub for deploying and managing self-hosted SigNoz across all supported platforms.

Why Was Foundry Needed?

Self-hosting SigNoz, depending on your platform, could involve dozens of commands and configuring multiple files by hand. Take Linux as an example — installing SigNoz on it required roughly 50 commands and 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 maintained 15 installation surfaces, 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, our platform team conceptualized Foundry: a single CLI to deploy to 10 curated deployment targets, replacing the sprawl of disparate installation surfaces.

What is SigNoz Foundry?

Foundry is a CLI tool that lets you declare your entire SigNoz deployment — across any supported platform — in a single configuration file (casting.yaml). From that one file, Foundry generates all the required platform-specific manifests 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.

"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 10 deployment targets. 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.

Beyond Manifests: Infrastructure-as-Code Integration

As engineering teams scale, they often rely on Infrastructure-as-Code (IaC) to manage their cloud infrastructure. Fiddling with YAML manifests becomes unfeasible at scale, and manually translating a complex observability stack into these native cloud primitives is a massive headache.

Foundry solves this by generating ready-to-apply IaC modules for self-managed cloud deployments.

Consider the AWS ECS target: instead of forcing you to figure out how to translate our architecture into AWS concepts, Foundry generates the complete Terraform configuration.
It automatically wires up the ECS Task Definitions, configures AWS Cloud Map for service discovery, provisions the ECS Services, and handles S3-based configuration management.

You simply include ECS infrastructure details such as the Task Roles, VPC and Subnet IDs in your casting.yaml, and point Foundry to that manifest. Foundry will then generate the complete Terraform configuration for your ECS cluster, and run the entire pipeline end-to-end.

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.
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, Foundry's equivalent at just 7 lines of YAML is as minimal as it gets.

Quick Start

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 confidently distribute SigNoz across more platforms in the future.

To start using Foundry right away, you can download the latest release and run your first deployment.

1. Install foundryctl

Download a release from GitHub Releases, or use the command line:

# Linux
curl -L "https://github.com/SigNoz/foundry/releases/latest/download/foundry_linux_$(uname -m | sed 's/x86_64/amd64/g' | sed 's/aarch64/arm64/g').tar.gz" -o foundry.tar.gz
tar -xzf foundry.tar.gz

# macOS
curl -L "https://github.com/SigNoz/foundry/releases/latest/download/foundry_darwin_$(uname -m | sed 's/x86_64/amd64/g' | sed 's/arm64/arm64/g').tar.gz" -o foundry.tar.gz
tar -xzf foundry.tar.gz

# Windows

$ARCH = if ($env:PROCESSOR_ARCHITECTURE -eq "ARM64") { "arm64" } else { "amd64" }
Invoke-WebRequest -Uri "https://github.com/SigNoz/foundry/releases/latest/download/foundry_windows_${ARCH}.tar.gz" -OutFile foundry.tar.gz -UseBasicParsing
tar -xzf foundry.tar.gz

2. Create a casting.yaml

apiVersion: v1alpha1
metadata:
  name: signoz
spec:
  deployment:
    mode: docker
    flavor: compose

3. Deploy

foundryctl cast -f casting.yaml

And that is it. You now have a complete observability stack, ready to begin ingesting your telemetry data.

Try It, Cast It, Tell Us

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.

If something does not work for your specific use case, start a discussion or open an issue on the Foundry GitHub repo. 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.