By Maxx Glans October 8, 2025
Emanuel Palm works as a Cloud Specialist at Unwonted AB, helping organizations manage and optimize their Azure environments. He was recently invited to speak at an international conference, and during his preparations, he sent us a Teams message asking if we could test a new tool of his. “What tool?” you might ask. Yeah, so did we! When he couldn’t find a good way to demo his presentation, he decided to build his own. That tool is now live, it’s called bARGE, and it’s awesome!
We had to sit down with Emanuel to ask: WHY, WHAT, and HOW.
To start off, what exactly is bARGE? ⚓
Strongly stated, it’s a boosted Azure Resource Graph Explorer for Visual Studio Code! People working in Azure are likely familiar with Azure Resource Graph (ARG), a powerful tool that allows us to query our own resources and infrastructure in Azure for insights and details. We can use ARG in multiple ways such as dashboards and alerts, but the most common and interactive way is through the ARG Explorer in the Azure Portal.
The goal of bARGE is to offer the same functionality and more (boosted!), but without ever having to leave your code editor.
What sparked the idea? 💡
When Nordic Infrastructure Conference (NIC) in Oslo accepted my session called Treasure Hunting in Azure with KQL as Your Map for October 2025, I knew that I wanted to keep it demo-heavy and hands-on. People use Azure Resource Graph in a multitude of ways, and I know that querying directly in the Azure Portal doesn’t always reflect the way that people write or run them.
I wanted a way to utilize the great tools available for demos in VS Code, while still offering the snappy visual experience of testing queries in the Azure Portal. When I looked around, I was surprised to only find extensions with support for Azure Data Explorer and full Kusto Query Language (KQL), but none for ARG or the subset of KQL that it supports. At that point I had the naive idea of building it myself (haha), I think that sometimes you need to dive into it before knowing how much work it might be.
You could say that the idea was born for this specific presentation, what better way to follow a treasure map than to do so on a bARGE on the cloudy sea?
How does bARGE compare to the Azure Portal? 🔍
I’m a big believer in reducing context switching and minimizing cognitive load, that’s also one of the reasons why I like the GitHub Copilot integration in VS Code. The purpose of bARGE follows the same reasoning.
Ideally the user will never have to leave VS Code to do something in the Azure Portal, which of course means that bARGE should support the same features as a minimum. After hammering out most of the existing features, I started adding small things I wished was made simpler in the Azure Portal, like:
- Sorting and re-ordering columns
- Comparing query results by property
- Changing accounts and scopes
But one of the most powerful things about having it directly in VS Code is that we can utilize a whole other ecosystem of functionality.
Which feature are you personally most proud of? ⭐️
I’m very happy with the recent addition of full KQL language support with syntax highlighting and intellisense, but what I’m personally most excited about is the ability to extend to do more things than strictly sticking to ARG functionality.
One clear example of this is that bARGE can look up identities found in results and match them against identities or groups in Entra ID, something that isn’t possible in the Azure Portal.
What was the most challenging part of building it? 🛠️
I think the biggest challenge for me was tackling the unfamiliar ecosystem of JavaScript and TypeScript, as someone who prefers .NET when building tools. That said, I was pleasantly surprised at how well the VS Code API is documented, there are lots of great guides on getting started.
A tricky thing was to decide how best to implement the language support, since the only available language tooling is for all of KQL while ARG only supports a subset of it. Figuring out which parts to keep and which parts to exclude will be ongoing improvement.
How do you approach designing tools for developers? 🎨
I want functions to be within reach without lots of clicks, but I also want them to stay out of the way when not needed. I’ve tried to keep the design elements practical and minimalistic, and I’ve added options to tweak behavior through settings when needed. For example, one person might like a popup when successfully logged in, while someone else would find it annoying. It’s the same reasoning behind the adaptive layout, bARGE should adapt to your setup.
The status bar indicator which shows which account is logged into bARGE was the result of me getting tired of popups when debugging!
How does this project tie into your work at Unwonted? 🌈
We really like Azure Resource Graph at Unwonted, and I would say the use cases are only increasing. Whether it’s for deploying alerts with Bicep, exporting infrastructure configuration for requested reports or gaining insights into a new environment, being able to write and test queries directly from VS Code is valuable when working code-first and often storing our authored queries in git repositories.
What has the community response been like so far? 🤝
I’ve received a lot of good feedback so far! I love the ideas that have come up during discussions. Some have already been implemented, such as the quick query buttons that was a suggestion on GitHub.
It’s been a reminder of why I love open source, the fact that anyone can contribute ideas or input to things you use day to day never stops being magical to me.
What’s next on the horizon? 🧭
I’m really intrigued by the possibilities of extending bARGE into other sections of Azure and neighboring services. Just like how we can look up an id in the results to find identities and groups in Entra ID, what if we could export a Bicep template for a resource id? I think there’s a lot of potential.
Why don’t you try out bARGE - boosted Azure Resource Graph Explorer and see if you have any ideas or feedback?