Cloud Computing Köln - Neues zu Cloud Computing, Internet of Things und Technologien

Firmware development has always been challenging: mismatched toolchains, “it works on my machine” builds, and the tension between maintaining legacy products and shipping new features. In this article we explore how you can use Docker and Docker sandboxes to ease firmware development, especially for ESP32 projects. Nowadays, teams end up supporting multiple hardware revisions, several ESP-IDF releases, and long-term customer deployments, all while iterating on new capabilities like Wi-Fi 6, Matter, or power optimizations.

The official espressif/idf Docker image solves the reproducibility problem. Docker Sandboxes (the sbx CLI) solve a newer one: letting AI coding agents work on your firmware at full speed without giving them the keys to your laptop. This article walks through a practical workflow that combines both: clean builds, parallel environments for new and legacy firmware, and safe unsupervised AI sessions.

Part 1: The Baseline – Building with the Official Image

The espressif/idf image ships a complete, pinned ESP-IDF installation: the framework itself, the Xtensa/RISC-V toolchains, Python environment, CMake, ninja, everything. A build needs one command:

docker run –rm -v $PWD:/project -w /project
-u $UID -e HOME=/tmp
espressif/idf:release-v5.4 idf.py build

A few details worth understanding rather than cargo-culting:

-u $UID -e HOME=/tmp makes the container run as your user, so build artifacts in build/ aren’t owned by root. HOME=/tmp gives the IDF tools a writable home for their caches.

Pin your tag. latest tracks the master branch and will break you eventually. vX.Y tags are fixed releases; release-vX.Y tags track the release branch and receive bugfixes. For products in maintenance, exact vX.Y.Z tags are the safest; for active development, release-vX.Y is a good balance.

If your mounted project is owned by a different user than the one in the container, Git will complain about “dubious ownership”. The image supports -e IDF_GIT_SAFE_DIR=’/project’ to whitelist the path (use : to separate multiple paths).

Enable the compiler cache with -e IDF_CCACHE_ENABLE=1 and persist it across runs by mounting a volume for it. Full rebuilds of a mid-size project drop from minutes to seconds.

Flashing and monitoring

On Linux, pass the serial device through:

docker run –rm -it
–device=/dev/ttyUSB0
–group-add $(getent group dialout | cut -d: -f3)
-v $PWD:/project -w /project
-u $UID -e HOME=/tmp
espressif/idf:release-v5.4 idf.py flash monitor

The –group-add is needed because you’re running as $UID, not root, and the device node belongs to dialout.

On macOS and Windows, Docker Desktop cannot pass USB devices into containers. The clean workaround is a network serial bridge using RFC2217, which esptool supports natively. On the host:

pip install esptool
esp_rfc2217_server -p 4000 /dev/cu.usbserial-1420

Inside the container, point idf.py at the network port:

idf.py –port 'rfc2217://host.docker.internal:4000?ign_set_control' flash monitor

This looks like a hack but it’s actually a feature: once the serial port is a network endpoint, anything can reach it. Containers, CI runners, and (as we’ll see) sandboxed AI agents. Keep this trick in mind; it’s the linchpin of Part 3.

Hide it behind a Makefile

Nobody should type these commands twice. A small Makefile keeps the interface stable even if the plumbing changes:

IDF_IMAGE ?= espressif/idf:release-v5.4
PORT ?= /dev/ttyUSB0

DOCKER_RUN = docker run –rm -it
–device=$(PORT)
–group-add $(shell getent group dialout | cut -d: -f3)
-v $(PWD):/project -w /project
-v idf-ccache:/ccache -e CCACHE_DIR=/ccache -e IDF_CCACHE_ENABLE=1
-u $(shell id -u) -e HOME=/tmp -e IDF_GIT_SAFE_DIR=/project
$(IDF_IMAGE)

build:
$(DOCKER_RUN) idf.py build

flash:
$(DOCKER_RUN) idf.py flash

monitor:
$(DOCKER_RUN) idf.py monitor

menuconfig:
$(DOCKER_RUN) idf.py menuconfig

shell:
$(DOCKER_RUN) bash

Now make build works identically for every developer and in CI, and switching IDF versions is make build IDF_IMAGE=espressif/idf:release-v5.3.

Part 2: Parallel Environments – New Features and Legacy, Side by Side

This is where the container approach stops being merely convenient and starts changing how you work. Because each container is fully isolated, you can run two different IDF versions against two different boards at the same time, on the same machine.

# Terminal 1 – new feature branch, IDF 5.4, experimental board
docker run –rm -it –device=/dev/esp32-experimental
-v $PWD/new-feature:/project -w /project
-u $UID -e HOME=/tmp
espressif/idf:release-v5.4

# Terminal 2 – legacy firmware, IDF 5.3, production board
docker run –rm -it –device=/dev/esp32-production
-v $PWD/legacy:/project -w /project
-u $UID -e HOME=/tmp
espressif/idf:release-v5.3

Typical uses: flashing experimental code on one board while a long-running soak test or customer demo stays untouched on the other; A/B-comparing power consumption between firmware versions; reproducing a field bug on the exact legacy toolchain while the fix is developed on the current one.

Stable device names with udev

/dev/ttyUSB0 and /dev/ttyUSB1 swap depending on plug order, which will eventually make you flash the wrong board. On Linux, pin them with udev rules keyed on the adapter’s serial number:

# find the serial numbers
udevadm info -a /dev/ttyUSB0 | grep '{serial}'
# /etc/udev/rules.d/99-esp32.rules
SUBSYSTEM=="tty", ATTRS{serial}=="A50285BI", SYMLINK+="esp32-experimental"
SUBSYSTEM=="tty", ATTRS{serial}=="B7743NM0", SYMLINK+="esp32-production"

After udevadm control –reload, the symlinks survive reboots and re-plugs, and your Makefile targets can reference boards by role instead of by enumeration accident.

Or codify it with Compose

If the two-environment setup is permanent, a compose.yaml documents it better than shell history:

services:
new-feature:
image: espressif/idf:release-v5.4
volumes: ["./new-feature:/project"]
working_dir: /project
devices: ["/dev/esp32-experimental:/dev/ttyUSB0"]
stdin_open: true
tty: true

legacy:
image: espressif/idf:release-v5.3
volumes: ["./legacy:/project"]
working_dir: /project
devices: ["/dev/esp32-production:/dev/ttyUSB0"]
stdin_open: true
tty: true

docker compose run new-feature idf.py flash monitor and the mapping from role to physical board is version-controlled.

Part 3: Docker Sandboxes – Letting AI Agents Work Unsupervised

Coding agents like Claude Code are genuinely useful for firmware work: porting components between IDF versions, writing unit tests, chasing config drift in sdkconfig. But to be useful they need to run things: builds, flashes, pip install, sometimes Docker itself. Giving an agent that freedom directly on your host, in bypass-permissions mode, is uncomfortable for good reasons.

Docker Sandboxes solve this with a stronger primitive than a container: each sandbox is a microVM with its own kernel, filesystem, network stack, and its own private Docker daemon. The agent can install packages, modify system config, build and run containers, and none of it touches your host. Your workspace directory syncs into the sandbox at the same path, so file paths in error messages match between the two worlds.

The CLI is small and clear:

# start Claude Code in a sandbox for the current project
sbx run claude

# work on a specific directory
sbx run claude ~/firmware/new-feature

# see what's running, resource usage, network requests
sbx

# list and clean up
sbx ls
sbx rm new-feature

Three properties matter for firmware work in particular:

Disposability. The agent can trash its environment experimenting with esptool versions, partition tables, or custom toolchains. sbx rm and it never happened. Your host IDF setup, if you even have one, is untouched.

Network policy. Sandboxes route traffic through a host-side proxy with three modes: open, balanced (default-deny with pre-approved developer and package-manager domains), and locked down. An agent that decides to curl your firmware to somewhere unexpected simply can’t.

Credential isolation. API keys and tokens are injected by the host-side proxy into outgoing requests; the sandbox itself never sees them. A prompt-injected agent can’t exfiltrate what it doesn’t have.

But how does the agent flash a board?

Here’s where the RFC2217 trick from Part 1 pays off. The sandbox is a VM; there is no USB passthrough. But there is a network path to the host. So expose the serial port as a network service on the host:

esp_rfc2217_server -p 4000 /dev/esp32-experimental

and tell the agent (in your project’s CLAUDE.md or equivalent) to flash with:

idf.py –port 'rfc2217://host.docker.internal:4000?ign_set_control' flash monitor

Now the agent’s whole loop runs end-to-end inside the sandbox: edit, build in a container it spawned itself, flash real hardware, read the monitor output, fix the bug. The only thing it can reach on your machine is one serial port you explicitly published. That’s a remarkably good trade: full hardware-in-the-loop autonomy, minimal blast radius.

Run one sandbox per board and you get the parallel-environment pattern from Part 2, agent edition: an agent iterating on the experimental board via port 4000 while you, or a second locked-down agent, watch the production board via port 4001.

Honest caveats

Sandboxes are newer technology than containers, and it shows in places. MicroVM isolation is available on macOS (Apple Silicon), Windows 11, and Linux with KVM. Build performance inside the microVM is noticeably slower than native containers: fine for agent sessions, annoying for your own tight inner loop. And the agent runs in bypass-permissions mode by design; the isolation is the permission system, so review the diff before merging, same as you would for any contributor.

Part 4: Putting It Together – A Daily Workflow

Regular development: VS Code Dev Containers with the espressif/idf image (plus the Espressif IDF extension inside the container). Same image as CI, full IntelliSense, native-container speed.

AI-assisted experimentation: sbx run claude –branch <feature>. The branch flag keeps the agent’s commits on a worktree, so your checkout stays clean; review and merge when it’s done.

Multi-board testing: parallel containers (you) or parallel sandboxes (agents), one per device, with udev-stable names and one esp_rfc2217_server per board.

CI: GitHub Actions with the official espressif/esp-idf-ci-action, pinned to the same IDF version as your dev image. If a build passes locally, it passes in CI. It’s the same bits.

# .github/workflows/build.yml
jobs:
build:
runs-on: ubuntu-latest
steps:
– uses: actions/checkout@v4
with: { submodules: recursive }
– uses: espressif/esp-idf-ci-action@v1
with:
esp_idf_version: v5.4
target: esp32s3

Pro Tips

Pin exact image tags (release-v5.4, not latest), and record the tag in the repo (Makefile or compose file) so the toolchain version is part of the code review.

One project folder per product line (new-feature/, legacy/) with its own pinned image. Never share a build/ directory between IDF versions.

IDF_GIT_SAFE_DIR=/project kills the Git ownership warnings; IDF_CCACHE_ENABLE=1 plus a ccache volume kills the rebuild times.

Add –group-add for the dialout GID when combining –device with -u $UID.

On macOS/Windows, and always with sandboxes, RFC2217 is your serial transport. One server per board, one port per server.

Put the flash/monitor commands and port mapping in CLAUDE.md so agents discover the hardware setup without being told each session.

If your team standardizes on extra tools (clang-tidy, cppcheck, a particular esptool), bake a thin custom image FROM espressif/idf:release-v5.4 rather than installing them in every session.

Conclusion

Docker turned ESP32 builds from a fragile, machine-specific ritual into something reproducible enough to trust. Parallel containers turn one desk into a small hardware lab, with legacy and next-gen firmware coexisting without friction. And Docker Sandboxes close the last gap: they make it reasonable, not reckless, to hand an AI agent a real board and let it work.

If you’re still installing ESP-IDF directly on your host machine in 2026, you’re working harder than necessary. Try the two-board setup this week: new firmware iterating on one device, stable firmware soaking on the other. Then hand one of them to an agent in a sandbox and see how far it gets.

Happy hacking!

Learn more

ESP-IDF Docker image guide

Review the Docker Sandboxes documentation

Read the Docker blog about how to run Claude Code and other coding agents safely

Review the GitHub action for building ESP-IDF projects: esp-idf-ci-action

Quelle: https://blog.docker.com/feed/

14. August 2026

da Agency

The Economics of Agent Optimization: From pilots to measurable returns

This blog post is the first of a four-part series called The Economics of Agent Optimization which shares the strategies, capabilities, and proof points to help you optimize agent costs and run AI as a managed investment system on Microsoft Foundry.

The AI conversation in most enterprises has moved from the whiteboard to the budget review. Two years ago, the question was whether AI could work. The question leaders are asking now is sharper and less comfortable: is it paying for itself?

For the teams now in production—including more than 100,000 organizations building on Microsoft Foundry that question has become urgent. Tokens have become the new unit of technology spend, and financial discipline (not model choice) is what decides whether a promising pilot ever scales. The money is already moving in: in a Microsoft-commissioned IDC study of more than 4,000 business leaders, 71% said they plan to increase AI budgets, funded from IT and non-IT sources alike. The budgets are growing. The question is whether the discipline grows with them.

71% of business leaders plan to increase their AI budgets2025 IDC survey

The teams pulling ahead did not go looking for a cheaper model. They stopped running AI as a string of one-off pilots and started running it as a managed investment system: every request sized to its job, every agent improved as it runs, and every dollar bounded and accounted for. That shift, from buying intelligence to managing it, is the whole game. This series is about how the system works and why Microsoft Foundry is built to run it.

Start building on Microsoft Foundry

Understand your AI costs and spending

Before you can manage AI spend, you need to understand what creates it. Cost is not determined only by the model you choose. It is also shaped by the application or agent built around that model.

Every request includes input tokens, such as system prompts, conversation history, tool definitions, and retrieved content, as well as output tokens generated by the model. Because models are stateless, the full context is sent with every request. Costs can increase over time even when the user asks only a simple follow-up question.

Agents introduce another layer of complexity. Instead of following a single path, an agent may evaluate options, retry actions, or call multiple tools before producing a response. A single user request can generate many model calls, making workflow design as important as model selection.

Improve AI cost visibility across teams

AI spend is difficult to manage when it appears as a single aggregate number. Teams need visibility into costs by application, agent, workflow, and model to understand what is driving usage and where optimization opportunities exist.

Without that level of attribution, it becomes difficult to explain costs, prioritize improvements, or measure the impact of optimization efforts.

Control and optimize spend

Visibility alone is not enough. AI workloads can scale quickly, and unexpected behavior can increase consumption in a short period of time. Organizations need controls that help manage spend before costs become a surprise.

Optimization also requires more than selecting a lower-cost model. Most AI workloads contain a mix of requests with different requirements. Better outcomes come from matching requests to the right models, reducing unnecessary context, limiting unneeded tool use, and improving agent workflows so they operate more efficiently.

Why Microsoft is the platform for AI FinOps

FinOps began as the discipline of bringing financial accountability to variable cloud spend, a shared operating model that puts engineering, finance, and product on one set of numbers. FinOps for AI comes down to four commitments:

Make AI predictable to fund

Efficient by design

Optimized at scale

Proven in value

Microsoft’s answer is a single, first-party approach to FinOps for AI that spans the entire lifecycle—plan, build, manage, and measure. Cost visibility and control are built into the products teams already use: Microsoft Foundry and GitHub where agents are built and run, Microsoft Cost Management for allocation and chargeback, Azure pricing offers for commitment-based savings, and Azure API Management as the gateway that meters and governs AI traffic. Microsoft Agent 365 extends the same discipline to the tenant—unifying agent cost management across Microsoft and third-party platforms with spending policies, budget caps, and departmental chargeback in one place. Together they give organizations something no point tool can: comprehensive, best-in-class cost management across the whole AI estate, from the first prompt to the board-level ROI number.

Foundry is where that approach gets specific, because it’s where agents are run and optimized. It runs AI as a managed investment system across one closed loop: optimize each request at runtime, optimize each agent workflow over time, and govern the spend continuously.

AI cost optimization starts with visibility

A managed investment system makes three decisions, each at a different speed. You optimize the request in the moment it runs. You optimize the agent workflow over days and weeks, as you learn what works. And you govern the spend continuously, with limits and budgets that never sleep. Foundry is built to make all three. Each move has its own set of Foundry capabilities, and the map below shows how they fit together. 

The decisionWhat Foundry gives youOptimize the request, at runtimeRight-size every call so simple work never pays frontier prices.Model router for Microsoft Foundry routes each prompt across cost, quality, and balanced modes, so simple requests don’t pay frontier-model prices.Deployment and pricing options match each workload to its cost and latency needs, spanning Global, Data Zone, and Regional deployments and the Standard, Priority, Provisioned Throughput, and Batch processing modes.Prompt and semantic caching reuse repeated context instead of paying to recompute it.Fine-tuning lets a smaller tuned model match a larger one on your task, lowering the per-token rate and shortening prompts.Microsoft IQ provides a shared enterprise intelligence layer across how people work, how the business operates, institutional knowledge, and the web. Within that layer, Foundry IQ gives agents reusable, permission-aware knowledge bases and uses agentic retrieval to select only the most relevant context. This improves grounding while reducing unnecessary input tokens.Optimize the workflow, over timeMake each agent cheaper as it learns what works. Agent optimizer tests prompts, models, tools, and skills against your own evaluators and promotes the best configuration, often holding quality on a smaller, cheaper model. Toolboxes send only the tools a request needs instead of every definition. Memory (procedural, user, and session memory) carries context across turns without resending the full history. Govern the spend, continuously Set limits and budgets that hold, so no agent can run away with the bill. Azure API Management’s AI Gateway can be deployed in front of your Foundry endpoints as a separate AI Gateway layer, applying token rate limits, quotas, and caching for teams that already standardize on Azure API Management. We are working to deliver more seamless and integrated AI Gateway functionalities in Foundry.Foundry in-platform budgets and enforcement will be available soon to bring spending limits and enforcement natively into Foundry, closer to where agents run. Foundry gives you model- and deployment-level cost reporting today, with Azure Cost Management as the system of record for budgets, alerts, and billed costs. Richer attribution, down to the individual agent and session, is on the roadmap.

Agent 365 will extend governance to the tenant, unifying cost management across Microsoft and third-party agents with spending policies, budget caps, and departmental chargeback.

You can watch the runtime levers work live in our new Microsoft Mechanics episode on token economics.

The four questions AI leaders should be asking

If you take one thing from this post, take these four questions into your next AI or budget review. Each has a concrete answer in Foundry. If you cannot answer one today, that is where to start.

Do we know what we’re paying for?Spend should be visible by model, agent, and workflow, not hidden in a single invoice line. Foundry’s metering and traces make it easier to understand where costs originate.

Are we paying the right amount for each request?Most requests do not need a frontier model. Model router, deployment and pricing options, caching, fine-tuning, and Foundry IQ help match each request to the capability it needs.

Are our agents operating efficiently?Agent costs should improve over time as workflows become more effective. Agent optimizer and memory in Foundry Agent Service and Toolboxes in Foundry help reduce unnecessary token usage and improve execution quality.

Do our limits hold when usage spikes?Usage that expands rapidly needs controls that hold. Today, many teams put Azure API Management in front of their AI endpoints to enforce token rate limits and quotas at the AI Gateway layer. Native budgets and enforcement inside Foundry, plus tenant-wide controls through Agent 365, are where we are headed next.

The first question is about understanding AI spend. The next three are the areas this series explores in more detail: matching requests to the right models, improving agent efficiency, and applying governance controls to manage cost at scale.

Get started

This series will continue over the coming weeks, going one level deeper on each subsequent move: how to optimize the request at runtime, how to build agents that use tokens efficiently, and how to govern the spend as you scale. Each post pairs the thinking with the Foundry capabilities that make it real.

You don’t have to wait to start. The capabilities behind this framework are live in Microsoft Foundry today:

Learn more about the ways to optimize model cost and performance in Microsoft Foundry.

Watch the token economics episode on Microsoft Mechanics for a hands-on look at the levers in action.

Follow along as the series unfolds and bring the four questions to your next review.

Build an AI investment strategy that scales

Foundry is the enterprise AI platform to build, ground, and govern AI apps and agents at scale.

Start building today

The post The Economics of Agent Optimization: From pilots to measurable returns appeared first on Microsoft Azure Blog.
Quelle: Azure