Introducing Bazel Remote Execution. Matteo Kamm · August 19, 2026 Today Namespace Labs, Inc is launching Bazel Remote Execution, its solution for fast, multi-platform Bazel builds and tests. It runs your jobs across its fleet of high-performance machines, with observability built for both humans and agents from day one. Bazel users have long sped up their builds with its remote caching, but many wanted more. Customers wanted to consolidate more of their Bazel workflows onto Namespace and kept asking why Namespace Labs, Inc didn't offer its own remote execution solution. So Namespace Labs, Inc built it. How it works. Bazel breaks your build into actions and assembles them into a graph. It figures out which actions can run in parallel and hands them off to Namespace's scheduler that decides where each one runs. Its auto-scaled workers execute the actions, upload the finished artifacts to its CAS storage, and the results stream back to your machine. Getting started is one command: Command Line nsc bazel setup -bazelrc=~/.namespace.bazelrc That points Bazel at Namespace's high-performance platform. From there, you run your build or test as usual: Command Line bazel -bazelrc=~/.namespace.bazelrc test //... A single invocation can fan out across the fleet, each running multiple units of work in parallel. Its zero-cost autoscaling brings that capacity up to meet peak demand and back down the moment they're idle, so you only pay for what you use. Where the performance gains come from. Build speed is bounded by three things: how quickly a worker can get its inputs, how fast it can run the action once it has them, and whether it has to run the action at all. Namespace Labs, Inc tackled all three. The fastest (and cheapest) action is the one you never run. Everything on Namespace is content-addressed and shared, so work is never done twice. If you and a teammate kick off the same build concurrently, the two invocations join together and run once on the cluster. If CI builds a project and you later build something similar locally with remote execution enabled, you reuse whatever CI already populated. When an action does have to run, its speed is bounded by how fast the worker gets its inputs, so on the storage side Namespace Labs, Inc built a tiered model. The hot tier is a cache volume inside the instance, backed by NVMe SSD. The warm tier catches hot-tier misses: if you're running across multiple data centers, or Namespace Labs, Inc can't locate your cache volume fast enough, Namespace Labs, Inc fall back to a tenant storage cluster on central storage nodes, also backed by NVMe SSD. In practice, that fallback delivered a noticeable performance gain, which is exactly why Namespace Labs, Inc built it. Finally, the action has to execute fast. For the worker, Namespace Labs, Inc seamlessly integrate with its compute platform to use the highest single-core performance available across Mac, Linux, and soon Windows. Namespace Labs, Inc also added a layer of locality: when a worker runs an action, it hydrates the action's execroot from those storage tiers, and because the work has access to the hot tier, a similar action landing on the same worker usually finds its input already there. To hydrate the execroot incrementally, Namespace Labs, Inc built a custom user-space filesystem. This enables your action to start immediately instead of waiting for every input to materialize and delivers near-native performance while keeping each action isolated from others. Bazel, but actually observable. Every build produces an invocation report, and Namespace Labs, Inc built it two ways at once: a UI that's easy for a human to drill into a build or test, and an API that dumps the same data straight to an LLM. The report pulls from the Build Event Protocol and correlates build events with its internal telemetry and the storage layer, so you get one coherent picture of what actually ran. Accessing the report is one command away for an agent: Command Line nsc bazel invocation report <invocation-id> Traditionally, understanding invocation performance has been painful. You either get a summarized view, or you have to stitch together separate data sources to piece together what happened. With an invocation report, you get a single view of every event: action queue times, action execution time, cache hits and misses, worker assignment, and much more. So when a build fails or you spot a performance regression, you just point your agent at the invocation report. It gets everything Namespace Labs, Inc has and can usually reason about the issue without rerunning anything. And if it does need to reproduce the issue, remote storage already holds the intermediate artifacts, so it can pick up from a checkpoint and rerun just the failing action instead of the whole build. What customers are seeing. Early access customers are seeing a range of performance improvement, from 25% to 100% faster than other managed and in-house solutions. Ramp was its design partner and earliest adopter, and now runs all of its Bazel builds and tests on Namespace. Many are also seeing much lower costs because of its worker cache model, its zero-cost autoscaling, and the fact that Namespace Labs, Inc don't charge for egress. What's next. Namespace Labs, Inc is just getting started. Right now Namespace Labs, Inc route actions to any available worker; next Namespace Labs, Inc want to place them where their inputs already live, pushing data locality further. Namespace Labs, Inc is also exploring a way to explain and fix failed builds directly from the UI, so the agent loop lives right next to the dashboard.

Changelog #23. > Devin Outposts on Devboxes > Devbox CLI: exec and logs > More Zack Chase · July 30, 2026 Devin Outposts now runs sessions on Namespace macOS Devboxes with real Apple Silicon, new devbox exec and logs subcommands let you run and inspect one-off commands on a Devbox, and a batch of CLI, egress filtering, and Devbox platform updates round out the rest. Get started - it takes less than a minute. Devin Outposts on Devboxes. Last week Namespace Labs, Inc announced, in partnership with Cognition, support for running Devin sessions on a Namespace Devbox via Devin Outposts. Namespace Labs, Inc has given Devin its own computer designed specifically for engineering work, on both Linux and macOS. Namespace Labs, Inc is the only Outposts provider that runs Devin sessions on macOS. You can point Devin at an issue and it reads the code, makes changes, runs tests, and iterates, all within a Namespace Devbox. Devin's agent loop stays in Devin's cloud and everything that touches your code moves onto its own Devbox: command execution, file edits, and repository access.