# Komiser: a cloud inventory tool that reads nine providers at once

> A Go binary that walks AWS, Azure, GCP and six other clouds, builds an inventory of what you are paying for, and flags the resources nobody is using.

**mlabouardy/komiser** — Open-source cloud-environment inspector. Supporting AWS, GCP, Azure, and more! Your cloud resources will have nowhere to hide!

- Repository: https://github.com/mlabouardy/komiser
- Website: https://komiser.io
- Stars: 4,150 · Forks: 454
- Language: Go
- License: NOASSERTION
- Published: 2026-10-07 · Updated: 2026-10-07 · Language: en
- Canonical page: https://hysenlabs.com/projects/mlabouardy-komiser

## What Komiser reads out of a cloud account

Komiser's pitch is inventory first, cost second. The README states it as a project created to analyse and manage cloud cost, usage, security and governance in one place, and then lists what that means in practice: building an inventory of cloud infrastructure assets, controlling resource usage, detecting potential vulnerabilities, understanding how you spend on AWS, Azure, GCP, Civo, DigitalOcean and OCI, and uncovering idle and untagged resources.

That last item is the one with teeth. Idle and untagged resources are exactly the things that never appear in a Terraform state file because they were created by hand, by a console click, or by a service that provisioned a helper it later abandoned. A tool that lists every object the provider API will return gives you a floor for the cleanup work, which is a different and more useful number than whatever the monthly bill suggests.

The interface is a web dashboard rather than a report you read once. The README embeds a screenshot of it under the heading for what the tool is, and the repository tree backs that up: `dashboard/` sits next to `controller/`, `handlers/`, `models/` and `providers/`, which is the shape of a server-rendered or single page app talking to a Go backend over HTTP.

## Installing the CLI on Linux, macOS, Windows and Homebrew

Four install paths are documented, and three of them are a single download. On Linux the whole thing is one line:

```bash
wget https://cli.komiser.io/latest/komiser_Linux_x86_64 -O komiser
```

macOS is split by chip, which is the detail that trips people up on Apple Silicon:

```bash
wget https://cli.komiser.io/latest/komiser_Darwin_arm64 -O komiser
```

The Intel path uses the same command with `komiser_Darwin_x86_64`, and Windows is a zip that needs unpacking:

```bash
wget https://cli.komiser.io/latest/komiser_Windows_x86_64.zip
tar -xf komiser_Windows_x86_64.zip
```

Homebrew is the option with a tap and a reinstall dance, which tells you it is maintained as a packaged formula rather than a one-off script:

```bash
brew update
brew tap tailwarden/komiser
brew install komiser
```

Note what the URLs do not say. Every path points at `latest` on cli.komiser.io rather than a pinned version, so there is no checksum to verify and no way to reproduce a specific build from the README alone. If you want a fixed artifact, the Docker image or a release tarball is the more defensible route, and the Makefile is there for building your own.

## Nine provider adapters behind one inventory model

The README names its providers in a single sentence: AWS, Azure, Civo, Digital Ocean, OCI, Linode, Tencent, Scaleway and more. The configuration section then expands that into a table with a documentation link and often a video per provider, and the repository topics add GCP and Kubernetes to the list.

The dependency list in `go.mod` is where the real scope shows. Alongside `github.com/aws/aws-sdk-go-v2` packages for autoscaling, cloudfront, cloudtrail, cloudwatch, configservice and costexplorer, there is `cloud.google.com/go` for compute, container, bigquery, storage, redis, firestore, kms and alloydb, plus a set of `Azure/azure-sdk-for-go` packages for costmanagement, network, sql, storage and resources. That is the shape of a tool built by connecting to each provider's existing SDK rather than by shelling out to a CLI.

Kubernetes is treated as a provider of its own with its own configuration page, which is worth noting because a cluster inventory overlaps with what a cloud account inventory already reports. Running both without deduplication gives you node groups twice. The tree also carries `mocks/`, so the provider layer is built to be exercised in tests without live credentials, and `policy.json` at the root suggests some of the findings are rule driven.

## The tailwarden versus mlabouardy naming split

There is a naming inconsistency in this repository that you will hit within the first five minutes of using it, so it is worth stating plainly rather than discovering it later.

The first line of `go.mod` reads `module github.com/tailwarden/komiser`. The Makefile stamps build flags into that same path, setting version, build time and commit through linker variables under `github.com/tailwarden/komiser/internal`. The README's badge links point at `https://github.com/tailwarden/komiser/releases`, its community link points at `https://discord.tailwarden.com`, its Homebrew instruction says `brew tap tailwarden/komiser`, and the Docker pull count badge reads `mlabouardy/komiser`.

Meanwhile the repository you are reading this in is `mlabouardy/komiser`, and the Dockerfile's LABEL names `mlabouardy <mohamed@tailwarden.com>`. Both identities are real and both appear in the same file set. The practical consequence is narrow but real: if you are pinning a container image, grep for both names, and if you are importing the project as a Go module, expect `github.com/tailwarden/komiser` to be the import path rather than the URL you cloned from.

## Building and running it yourself with make and Docker

The Dockerfile is short enough to read in full, and it says the artifact is a static binary that gets copied into an Alpine base:

```docker
COPY komiser /usr/bin/komiser
RUN chmod +x /usr/bin/komiser && \
    mkdir /lib64 && ln -s /lib/libc.musl-x86_64.so.1 /lib64/ld-linux-x86-64.so.2

EXPOSE $PORT
ENTRYPOINT ["komiser", "start"]
```

That `ENTRYPOINT` is the command you need to know: a bare `komiser` with no argument does not start the server, so anyone wiring this into a compose file or a Kubernetes deployment has to pass `start` explicitly. The base image is `alpine:3.16` and the entrypoint expects `$PORT` to come from the environment. Build arguments carry a `SEGMENT_WRITE_KEY` and a `VERSION`, which tells you the official images report anonymous usage events.

The Makefile covers the local path. `make build` produces `bin/komiser` for the current platform with version metadata baked in, `make package` cross compiles to `windows_amd64`, `linux_amd64`, `darwin_amd64` and `darwin_arm64`, and `make test` runs `go test ./...` with the `dashboard/` path filtered out of the output. A `.goreleaser.yaml` at the root is consistent with those artifacts being the release channel.

## Release history versus recent commits

The newest tagged release in the repository is v3.1.22, published on 2024-12-02. The last push recorded for the repository is 2026-09-10. Both facts are true and they point in different directions, so it is worth being precise about what each one means.

A tag gap like this usually means one of three things. Work is landing on the default branch without a tag, which is what a `develop` branch suggests since that is the default branch here rather than `main`. Tags stopped being the release mechanism in favour of continuous image builds. Or the release cadence slowed while maintenance continued. The v3.1.22 notes themselves are almost entirely dependency bumps from Dependabot, plus one feature line, create local network gateway resource, which is typical of a mature tool that releases when a provider adds something worth seeing.

There is a `VERSION.md` at the repository root, which is usually a deliberate choice to keep one source of truth for the version. If you are pinning Komiser in CI, check that file and the recent commit history on the default branch rather than assuming the newest tag represents current behavior, and treat the two as separate signals.

## Conclusion

Komiser is at its best as a scheduled read-only sweep over accounts whose inventory nobody has ever written down, because the value is in the completeness of the walk rather than in any single provider's depth. The README is a launcher pad rather than a manual: credential handling, IAM roles, alert policy and the exact shape of each provider's checks all live on docs.komiser.io. Two facts to reconcile before you commit: the Go module is published as github.com/tailwarden/komiser while the repository you clone is mlabouardy/komiser, and the newest published tag is v3.1.22 from 2024-12-02 even though the last push was on 2026-09-10. Start with the Linux wget line and the per-provider configuration page for one account, then decide whether the Docker image or the Homebrew tap is the surface you want to automate.

## FAQ

### Does Komiser support Azure and Google Cloud as well as AWS?

Yes. The README lists AWS, Azure, Civo, Digital Ocean, OCI, Linode, Tencent and Scaleway, and the repository topics add GCP and Kubernetes. The dependencies in go.mod include Google Cloud client libraries for compute, container, storage and BigQuery alongside the AWS SDK v2 packages, so support is more than a name in a table.

### How do I install Komiser on an Apple Silicon Mac?

Use the arm64 build rather than the x86_64 one. The README gives: wget https://cli.komiser.io/latest/komiser_Darwin_arm64 -O komiser. Intel Macs use the same command with komiser_Darwin_x86_64 instead. Running the Intel build on an M-series Mac works only through translation, if at all.

### What cloud permissions does Komiser need to read an account?

The README does not enumerate roles or scopes. It links a separate configuration page for each provider under docs.komiser.io, and the audit logic depends on which services you enable, since scanning for unused resources needs read access to autoscaling, storage, databases and cost data. Start from the page for one provider rather than granting a broad role up front.

### What is the current Komiser version?

The newest published tag is v3.1.22, released on 2024-12-02, with notes consisting mostly of Dependabot dependency bumps. The repository's last push was on 2026-09-10 and its default branch is develop rather than main, so tags do not track every commit. A VERSION.md file at the repository root is worth checking for the version a given build reports.

## Sources

- [Issues](https://github.com/mlabouardy/komiser/issues)
- [mlabouardy/komiser on GitHub](https://github.com/mlabouardy/komiser)
- [Project website](https://komiser.io)
- [README](https://github.com/mlabouardy/komiser/blob/develop/README.md)
- [Releases](https://github.com/mlabouardy/komiser/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mlabouardy-komiser