Author: Craig Risi

Vercel has enhanced its observability platform by integrating external API caching insights, enabling developers to track how many requests to third-party APIs are served from the Vercel Data Cache versus being routed to the origin server. As of May 22, 2025, users can view caching behavior at the hostname level, with those on Observability Plus gaining more granular path-level metrics in the dashboard.

Vercel’s Data Cache is a specialized layer designed to work with frameworks like Next.js, storing fetch responses per region with support for time-based and tag-based invalidation. By exposing cache hit data, Vercel helps teams pinpoint areas where they can further leverage caching to reduce latency, decrease origin requests, and enhance application performance.

This feature builds on the broader rollout of “Observability“, initially launched in beta in October 2024 and generally available since December, which offers comprehensive insights into function invocations, edge requests, build diagnostics, and external API calls. The addition aligns with Vercel’s focus on visibility and performance for frontend and serverless workloads.

On Vercel’s official changelog account, they highlighted that their CDN now “caches proxied responses using the CDN-Cache-Control and Vercel-CDN-Cache-Control headers”, an essential precursor to deeper caching analytics in Observability.

Developers interested in using this feature can visit the External APIs tab in the Observability dashboard to view cache hit metrics for deployed projects and evaluate opportunities for efficiency gains in API usage.

While Vercel’s native integration of external API caching metrics into its observability suite is a notable step forward, other companies also offer solutions, albeit often with more manual setup or third-party integrations. Netlify, for instance, supports caching strategies at the CDN level, but support for observability into external API calls often requires pairing with tools like New Relic, Datadog, or Grafana for custom dashboards and telemetry pipelines. These platforms can ingest logs and metrics from API calls; however, developers must manually configure them or do so via SDKs.

Cloudflare, meanwhile, offers advanced caching rules and Cache Analytics as part of its Enterprise plans. While it can show cache hit ratios and performance metrics, detailed visibility into external API usage typically requires correlating data from other sources, such as log push services or API gateways like Kong or Apigee, which can add operational overhead. Cloudflare Workers users can log external fetches, but the depth of insights depends on how comprehensively telemetry is captured.

AWS and Google Cloud offer more granular API Gateway and CDN logging, with services like Amazon CloudWatch, X-Ray, and Cloud Monitoring providing observability. Still, surfacing high-level caching insights across external APIs often requires stitching together telemetry from multiple services and instruments, unlike the streamlined integration Vercel now offers out of the box.

The key difference lies in developer experience: whereas traditional approaches require integration effort and expertise in observability tooling, Vercel bundles relevant metrics into the same surface where developers already monitor functions and deployments. This simplification could serve as a model for other developer-first platforms looking to unify caching, observability, and performance optimization into a cohesive experience.

Zendesk has unveiled its new Foundation Interface, a unified platform designed to transform infrastructure provisioning into a fully self-service experience. This platform enables engineers to request infrastructure components, such as databases, object storage, compute resources, and secrets, by simply defining requirements in a declarative YAML file. These requests are then automatically validated, provisioned, and monitored through a seamless workflow integrated with Spinnaker and Kubernetes. The result is a major reduction in the time, friction, and uncertainty that previously accompanied infrastructure requests.

At the heart of this transformation lies a robust internal architecture that Zendesk engineers describe as a “genie and helpers” model. The Gatekeeper acts as the initial validator of requests, ensuring correct syntax, resource definitions, and permission scopes. Once approved, requests are routed to the Orchestrator, which breaks them down into Kubernetes-native constructs, specifically, Custom Resources (CRs). These CRs are then handled by domain-specific Kubernetes operators. The Watchdog component continuously monitors the state of these Custom Resources, ensuring all provisioning tasks succeed and signaling Spinnaker when it is safe to proceed with application deployments.

Kubernetes operators are central to this process. An operator is a software extension that uses Kubernetes APIs and the controller pattern to manage complex, stateful applications or infrastructure services.

Operators are typically implemented using controller frameworks such as the Operator SDK, Kubebuilder, or Metacontroller. These frameworks enable teams to define Custom Resource Definitions (CRDs) that extend the Kubernetes API to include new object types, for example, an Aurora Database or a Redis instance. Paired with each CRD is a controller loop that watches for changes to these resources and reconciles the desired state with the actual cluster state.

In practice, this means that when an engineer requests a database through the Foundation Interface, the corresponding operator provisions that database by interfacing with cloud provider APIs, applies configuration, and monitors for success or failure, all without human intervention.

This model ensures that each infrastructure component, be it S3 buckets, RDS instances, or more bespoke services, has a dedicated operator that knows how to provision, configure, and manage its lifecycle. Operators are designed to be idempotent, meaning they can safely reapply the desired state if conditions change, and they can handle edge cases or error recovery without manual intervention. The use of Kubernetes-native tools also means that Zendesk benefits from observability, auditability, and consistency across all provisioned resources.

By integrating this architecture with Spinnaker pipelines, Zendesk engineers can now deploy applications alongside their supporting infrastructure in a single, repeatable flow. The Foundation Interface ensures that infrastructure is provisioned securely and consistently, with automated checks and centralized tracking. Developers are no longer required to submit tickets or wait for manual approvals; they simply write a YAML file and trigger a deployment. The system handles everything else, from validation and resource creation to health checks and status reporting.

Darragh Kennedy, Director of Software Engineering at Zendesk, shared on LinkedIn that the journey toward a self-service infrastructure began years ago with the creation of the Foundation group. He highlighted how the team “built this from the ground up and iterated on it over the years to create a flexible and robust entry point”, underscoring the carefully engineered foundation behind the platform.

His post illustrates the long-term commitment and internal evolution leading to the current system:

“It seems like an age ago that we created the Zendesk Foundation group… we built this from the ground up and iterated on it over the years to create a flexible and robust entry point.”

This commentary reflects a deeper understanding of the engineering effort behind the Foundation Interface, emphasizing that it’s not a quick fix but a mature, iterative platform designed to scale with Zendesk’s engineering needs.

However, functionality like this is not unique to Zendesk. A recent example is Pulumi IDP, launched in May 2025. It offers a “golden path” through standardized infrastructure components and a private registry. This allows developers to consume reusable, policy‑approved configurations (in YAML) for provisioning infrastructure safely and efficiently. Unlike portal‑centric platforms, Pulumi IDP focuses tightly on infrastructure delivery patterns shaped and consumed via platform engineering practices.

The broader industry trend toward Internal Developer Platforms (IDPs) built on Kubernetes is gaining momentum. These platforms abstract Kubernetes complexity behind declarative interfaces and pre‑packaged workflows, enabling teams to self‑serve environments, deploy apps, and manage resources without needing to learn Kubernetes internals. Analysts highlight that success depends not only on technology but also on clear documentation, developer education, and strong platform governance Platform Engineering.

These parallels demonstrate that Zendesk’s choice to define infrastructure through YAML, validated via Kubernetes CustomResources and orchestrated through operators and pipelines, aligns closely with a growing movement. Organizations across sectors are adopting Kubernetes‑based self‑service platforms that abstract complexity, enforce policy, and promote developer productivity, just as Zendesk’s Foundation Interface aims to do.

Docker Inc. released Docker Desktop 4.42 on June 10, 2025, enhancing networking flexibility, AI workflow integration, and model distribution. Native IPv6 support now enables users to choose between dual-stack, IPv4-only, or IPv6-only modes with intelligent DNS resolution. Docker claims that the improved connectivity options make Docker Desktop more adaptable to diverse enterprise network environments.

The release incorporates the Model, Client, Protocol (MCP) Toolkit directly into Docker Desktop, enabling users to discover and manage over 100 MCP servers, such as GitHub, MongoDB, and HashiCorp, without requiring the installation of extensions.

These tools run in isolated containers with signed images and built-in secret management, ensuring a secure and sandboxed environment. Developers can start or stop these servers with a single click or use the new Docker MCP CLI to list, start, or manage services programmatically. For example, commands like docker mcp list, docker mcp start github, or docker mcp stop github offer quick access and integration into automated workflows. Docker’s AI assistant, Gordon, is also integrated directly with MCP, enabling developers to interact with these services using natural language or command-driven prompts, simplifying DevOps setup and infrastructure troubleshooting.

AI workflows receive further enhancements as Model Runner gains support for Qualcomm-based Windows devices, integration with Docker Engine on Linux, and an upgraded GUI featuring Local, Docker Hub, and Logs tabs Developers can now package GGUF-format AI models into OCI-compliant images using the new docker model package CLI command for secure distribution to Docker Hub or private registries.

To do this, a model (such as mistral.gguf) is placed into a directory and packaged using the Docker model package command. This creates an image tagged for reuse, such as username/mistral-model:1.0, which can then be pushed to Docker Hub or another container registry. Once stored, the model can be run locally using standard Docker commands or managed through Docker’s Model Runner GUI, which now includes tabs for local models, Docker Hub integration, and real-time logs. These features allow developers to securely build, run, and distribute AI workloads while maintaining portability and compliance across environments.

On social media, Docker advocate Ajeet Singh Raina highlighted the release as “powerful new capabilities with native IPv6 support, a fully integrated MCP Toolkit, and major upgrades to Docker Model Runner and our AI agent Gordon”.

However, some challenges with the new release have also been reported. Since the release of Docker Desktop 4.42, many macOS users have reported significant instability. On Reddit, one user reported that containers became unresponsive and failed with networking errors, including frequent cURL error 35: OpenSSL SSL_connect: SSL_ERROR_SYSCALL messages. They traced the problem to automatic proxy settings; containers worked when proxy detection was disabled, but macOS kept re-enabling it under corporate policies. Reverting to Docker Desktop 4.41.2 reportedly resolved the issue.

On GitHub issue #7698, several users reported that Docker Desktop simply fails to launch after upgrading to version 4.42.0. One user observed that after installation, the Docker daemon wouldn’t start, and attempts to do so returned errors about the daemon socket. Additional open issues reference failures to expose container ports when running behind connection managers like Traefik, suggesting deeper integration problems with Docker’s network layer.

Some feedback on Reddit suggests that Docker has fundamental performance issues inherent to macOS. One Reddit user noted that Docker Desktop’s excessive memory usage, beyond assigned limits, even occurs when only a single container is running, and macOS swap usage has ballooned over time. While this behavior is partly due to Docker’s VM-based architecture, community members suggest alternatives like Colima or Orbstack to bypass Docker Desktop’s overhead.

A Docker team member acknowledged the proxy-related errors and requested diagnostic logs to expedite troubleshooting. Meanwhile, GitHub threads remain active, tracking widespread issues with startup failures, window hangs, and networking faults under versions 4.42.x. The volume and breadth of these reports suggest that broader regression testing and swift patches may be needed to restore confidence in Docker Desktop on macOS.

These errors do appear to have been largely addressed by the Docker team, and so most new users should be able to utilize the full benefits of the update without facing many of these challenges.

Grafana released Tempo 2.8 on June 12, 2025, introducing substantial memory optimizations and expanded functionality in its trace query language, TraceQL. This update is part of an ongoing effort to make distributed tracing more performant and accessible within observability stacks.

The most notable improvement is a greater than 50% reduction in peak memory consumption for the Tempo compactor. By profiling with Pyroscope flame graphs, Grafana engineers traced high memory usage to aggressive pooling. Replacing it with lighter pooling strategies and leveraging Go’s garbage collector led to significantly lower memory pressure, particularly under high-throughput workloads. This improvement directly benefits teams operating large-scale, latency-sensitive systems by reducing infrastructure costs and improving stability.

On the query side, TraceQL gains several new features. A new most_recent=true hint enables users to retrieve the latest traces in a deterministic way, which is particularly useful for debugging or identifying recent anomalies. Support for span:parentID filters adds more power to hierarchical trace analysis, allowing users to understand causal relationships in complex request chains. New metric functions like sum_over_time, topk, and bottomk expand Tempo’s analytical capabilities, allowing teams to identify performance bottlenecks or underutilized paths across their trace datasets.

Operational changes include a safer default HTTP port (3200 instead of 80), concurrent flushing for faster ingestion, iterator performance improvements, and tighter constraints on attribute sizes. Additionally, Tempo 2.8 includes stricter security defaults, with support for Go 1.24 and the use of distroless container images to reduce potential attack surfaces.

Community response has been broadly positive. Grafana’s X account stated the release brings memory improvements, new TraceQL features, bug fixes, and some breaking changes, while Deutsche Bank’s Florin Lungu commented on LinkedIn that Tempo 2.8 showcases Grafana’s commitment to optimizing user experience through performance gains and enhanced query capabilities. Grafana team member Mike McGovern highlighted new TraceQL functions, memory optimizations, and updated defaults in his post:

This update packs powerful TraceQL enhancements, significant memory optimizations, and smart configuration updates to improve performance and usability.

As organizations continue scaling observability infrastructure, Tempo 2.8 presents a compelling update, offering leaner performance, more expressive trace queries, and improved defaults out of the box. The full changelog and upgrade guidance are available on the official blog post and release notes.

A new benchmark study from observability platform Coroot has shed light on the performance costs of implementing OpenTelemetry in high-throughput Go applications. The findings show that while OpenTelemetry delivers valuable trace-level insights, it introduces notable overhead, increasing CPU usage by approximately 35% and increasing network traffic and latency under load.

Using a simple HTTP service backed by an in-memory database, the study compared baseline performance with full OpenTelemetry instrumentation under identical load conditions (10,000 requests per second). Runs occurring in Docker containers across four Linux hosts revealed several findings: enabling tracing increased CPU usage from 2 to 2.7 cores (roughly 35%), memory usage rose by 5–8 MB, and 99th-percentile latency increased modestly from approximately 10 ms to 15 ms. Additionally, tracing data resulted in approximately 4 MB/s of outbound network traffic, highlighting the resource implications of full request-level telemetry.

The study also contrasted SDK-based tracing with eBPF-based approaches, although caution should be noted, as Coroot sells an eBPF-based observability solution. eBPF, which avoids modifying application code, exhibited lower resource consumption—under 0.3 cores—even under heavy load when only metrics were collected. Coroot concluded that while OpenTelemetry’s SDK offers detailed trace visibility, it comes with measurable overhead that must be weighed against observability needs. They argue that for use cases prioritizing low latency and running with capped resources, an eBPF-based implementation may be a more suitable compromise.

This evaluation sparked conversations in the Go community. A discussion on Hacker News suggested performance gains could be achieved by optimizing SDK internals, such as using faster time functions, replacing mutexes with atomics, or marshaling methodically. On Reddit, users noted that even with zero sampling, significant overhead remains due to context propagation and span management. These perspectives underscore a broader recognition that while OpenTelemetry brings essential insights, it also introduces resource tradeoffs that require careful implementation and tuning.

One user, FZambia, stated the following:

“I was initially skeptical about tracing with its overhead (both resource-wise and instrumentation process-wise) vs properly instrumented app using metrics. As time goes, I have more and more examples when tracing helped to diagnose the issue, investigating incidents. The visualization helps a lot here – cross-team communication simplifies a lot when you have a trace. Still, I see how spans contains so much unnecessary data in tags, and collecting them on every request seems so much work to do while you are not using 99.999% of those spans. Turning on sampling is again controversial – you won’t find span when it’s needed (sometimes it’s required even if the request was successful). So reading such detailed investigations of tracing overhead is really useful, thanks!”

Coroot’s benchmarks provide valuable data showing that OpenTelemetry in Go delivers powerful observability at a measurable cost, with approximately 35% CPU overhead, and increased latency under load. The community response suggests that optimizations are underway, yet teams should still balance the need for trace-level visibility against performance constraints and explore lighter-weight options like eBPF-based metrics when appropriate.

Cloudflare has unveiled thirteen new Model Context Protocol (MCP) servers, enhancing the integration of AI agents with its platform. These servers allow AI clients to interact with Cloudflare’s services through natural language, streamlining tasks such as debugging, data analysis, and security monitoring.

An MCP server is a specialized type of server introduced by Cloudflare as part of their infrastructure to support AI agents in executing, debugging, and managing tasks securely and efficiently.

The concept of MCP servers is built around the idea of providing AI agents (such as those used in autonomous workflows or natural language interfaces) safe, controlled access to the tools and data they need to operate effectively. These servers don’t just run arbitrary workloads; they are tightly scoped, auditable environments that expose specific capabilities to AI models.

The new MCP servers from Cloudflare introduce several key features designed to enhance the capabilities of AI agents interfacing with cloud infrastructure. The thirteen new servers and what they do are described below, as detailed in Cloudflare’s blog post.

Cloudflare Documentation Server provides direct access to the most current Cloudflare Developer Documentation. It serves as a reliable reference point for developers working with Cloudflare products, offering guidance on APIs, Workers, networking configurations, Zero Trust solutions, and more. This server helps streamline development and troubleshooting by making technical documentation readily available within the development workflow.

Workers Bindings Server is designed to support the development of Cloudflare Workers applications by enabling integration with core primitives like storage (KV, R2, Durable Objects), secrets, and AI models. It allows developers to interact with these bindings as they would in production, making it easier to test and build serverless applications that depend on Cloudflare’s edge compute environment.

Workers Observability Server offers debugging and performance monitoring tools for Cloudflare Workers applications. It allows developers and operators to access logs, analytics, and error traces, providing essential insights into how Workers behave during execution. This observability helps troubleshoot bugs, optimize performance, and maintain reliable production applications.

Container Server creates sandboxed development environments on demand, giving developers isolated containers to run and test their code. These environments simulate realistic conditions without affecting local setups or production systems. It’s a convenient tool for experimentation, CI/CD workflows, and running ephemeral services safely and cleanly.

Browser Rendering Server enables headless browser functionality for fetching and rendering web pages. It can convert page content to markdown or capture screenshots, making it useful for automation workflows, content extraction, UI validation, and generating previews. This server is especially valuable for developers building tools that need to interact with web UIs programmatically

Radar Server connects to Cloudflare Radar, a global intelligence platform that provides insights into internet traffic trends, regional outages, domain scans, and overall web health. This server allows developers and network analysts to query real-time or historical data to assess internet stability, understand global events, or identify suspicious activity across the web.

The Logpush Server provides status summaries and health checks for Logpush jobs, Cloudflare’s mechanism for streaming logs to external storage destinations like AWS S3 or Google BigQuery. It ensures that critical observability and compliance data are flowing correctly, helping teams quickly identify failures or misconfigurations in their logging pipelines.

AI Gateway Server allows teams to search logs and trace prompt-response cycles made through Cloudflare’s AI Gateway. It provides detailed telemetry on AI requests, including token usage, response times, and prompt contents. This is valuable for teams building or monitoring AI-driven applications, especially those concerned with privacy, cost, and quality of AI interactions.

AutoRAG Server is used to manage and query documents stored in AutoRAG, Cloudflare’s retrieval-augmented generation systems. It lets developers list ingested documents and search across them to verify availability and correctness. This is crucial for AI applications that rely on external documents to provide accurate, context-rich responses to user queries.

Audit Logs Server grants access to audit logs that capture user actions and configuration changes across Cloudflare services. These logs are essential for security reviews, compliance reporting, and change tracking, offering a transparent record of activity within an organization’s Cloudflare environment. Reports can be generated and filtered for easier review.

DNS Analytics Server offers tools to analyze DNS resolution performance and troubleshoot configuration issues. It provides data such as query volumes, response times, and error rates, helping network administrators identify bottlenecks, optimize routing, and ensure DNS infrastructure is functioning efficiently and securely.

Digital Experience Monitoring (DEM) Server delivers insights into the end-user experience of web and SaaS applications. Using real-user and synthetic monitoring data, it helps organizations track performance metrics like latency, uptime, and error rates across geographic locations. This server supports IT teams in ensuring application reliability and user satisfaction.

Lastly, Cloudflare One CASB Server functions as a Cloud Access Security Broker for Cloudflare’s Zero Trust suite. It scans connected SaaS applications for security misconfigurations and potential compliance issues. This helps organizations secure their data and users by identifying risky configurations in platforms like Google Workspace or Microsoft 365, aligning with modern zero-trust principles.

The MCP server code and documentation can be found in Cloudflare’s mcp-server-cloudflare GitHub repo. These servers are accessible to any MCP client supporting remote connections, including platforms like Claude.ai. This development signifies a step towards more seamless integration between AI agents and cloud services, promoting efficiency and automation in various operational tasks.

On April 23, 2025, the Cloud Native Computing Foundation (CNCF) announced the graduation of in‑toto, a framework designed to enforce supply chain integrity by ensuring that every step in the software development lifecycle, such as building, signing, and deployment, is properly authorized and verifiable. This move signifies that in‑toto has achieved full maturity and stability, joining other graduated CNCF projects that are widely adopted and ready for production at scale.

Developed primarily by researchers at NYU Tandon School of Engineering, in‑toto provides a declarative framework enabling organizations to define policies that ensure only authorized actors perform specific build steps in the correct sequence. It uses signed metadata to create a traceable record from source code through to the final software artifact. This model helps prevent tampering, unauthorized actions, and insider threats, addressing the rising number and sophistication of software supply chain attacks.

Chris Aniszczyk, CTO of CNCF, emphasized its timely impact:

in‑toto addresses a critical and growing need in our ecosystem, ensuring trust and integrity in how software is built and delivered. As software supply chain threats grow in scale and complexity, in‑toto enables organizations to confidently verify their development workflows, reducing risk, enabling compliance, and ultimately accelerating secure innovation.

The graduation follows in-toto’s journey from a Sandbox project in 2019 to Incubation in early 2022 to a stable 1.0 specification in mid-2023. It is backed by major US federal agencies, including the National Science Foundation, DARPA, and the Air Force Research Laboratory have contributed funding and research support.It is already in use by organizations like Autodesk and SolarWinds, and integrated with standards such as OpenVEX and SLSA, in‑toto is gaining traction across sectors.

Tools such as Witness and Archivista make in‑toto easier to implement for developers to adopt in-toto. Jesse Sanford, Software Architect at Autodesk, noted:

The fact that Witness and Archivista have reduced developer friction so significantly has really set the in‑toto framework apart for us… we can now run securely by default.

Graduation from the CNCF marks a significant moment: in‑toto is now recognized by them as production‑ready, offering a systematic way to defend against supply chain threats and meet regulatory standards via verifiable workflows. The CNCF plans to continue advancing the project, including enhancements to policy language support and developer experience.

In a move to streamline developer workflows around MongoDB‑compatible databases, Microsoft has released an open‑source DocumentDB extension for Visual Studio Code alongside DocumentDB Local, a lightweight local emulator. Designed for use with Azure Cosmos DB’s MongoDB API and standard MongoDB instances, this toolset empowers developers to manage, query, and edit document databases directly within VS Code without relying on external tools or cloud resources.

Install the extension via the VS Code Marketplace to browse collections, inspect documents, and run find() queries using an intelligent editor with syntax highlighting and autocomplete. Data can be viewed in table, tree, or JSON formats, with seamless pagination for large datasets. Developers can import and export JSON datasets, facilitating efficient prototyping and testing.

DocumentDB Local complements the extension by providing a containerized MongoDB‑compatible engine perfect for integration testing and local development. It supports the MongoDB wire protocol and behaves consistently with Azure Cosmos DB, ensuring parity between local and production environments.

This unified toolkit eliminates workflow friction by enabling local-first development while maintaining compatibility with cloud databases. Developers can switch environments effortlessly, reduce context switching, and accelerate prototype iteration. The ability to test end‑to‑end – from local container to cloud deployment – without leaving the editor significantly boosts efficiency and productivity.

This functionality is not unique to VSCode, though. MongoDB support has matured for those using JetBrains IDEs like IntelliJ IDEA or DataGrip, including MongoDB Shell integration. Developers can view and edit documents, execute shell commands, and leverage database navigation and completion features directly in their IDE.

Additionally, third‑party tools such as DBCode also bring database management into VS Code, providing a unified interface for connecting to MongoDB, querying data, and handling schema, reflecting a growing trend toward embedding database workflows in code‑centric environments.

By combining a polished VS Code experience with a lightweight local database emulator, Microsoft is looking to deliver a powerful and flexible foundation for MongoDB developers. An environment that they claim can support fast prototyping, consistent testing, and efficient migration between local and cloud environments, all from a single interface.

In April 2025, GitHub announced an update to its Command Line Interface (CLI), introducing enhanced support for triangular workflows – a common pattern among open-source contributors who work with forked repositories.

Triangular workflows involve three key components: the original repository (upstream), a personal fork (origin), and the local development environment. Developers typically clone their fork, set the upstream remote to the original repository, and configure their Git settings to pull updates from upstream while pushing changes to their fork. This setup allows contributors to stay synchronized with the main project while working independently.

Prior to this update, the GitHub CLI’s gh pr commands did not fully align with Git’s handling of such configurations, resulting in challenges with managing pull requests within triangular workflows. The latest enhancement ensures that the CLI respects Git’s push and pull configurations, allowing for seamless creation and management of pull requests from a fork to the upstream repository.

This improvement has been well-received by the developer community. On LinkedIn, GitHub highlighted the update, stating:

“Streamline your fork-based contributions with the latest GitHub CLI update! There’s now more support for triangular workflows, which means managing pull requests between your fork and the original repo is now significantly smoother and more efficient.”

A user, N8Group, responded with:

“It’s great to see the GitHub CLI finally supporting triangular workflows! This solves a long-standing pain point for teams with forks and complex branch strategies.”

For developers engaged in open-source projects or those who frequently work with forked repositories, this enhancement to the GitHub CLI simplifies the workflow, reducing friction and aligning command-line operations more closely with Git’s native behavior.

Triangular workflows – where developers fork a repository, make changes locally, and submit pull requests back to the original repository – are common in open-source and collaborative development. Outside of this new GitHub approach, Continuous Integration/Continuous Deployment (CI/CD) platforms have varying levels of support for these workflows, each with its own set of features and limitations.

GitLab facilitates triangular workflows by allowing users to fork repositories and create merge requests that return changes to the upstream project. CI/CD pipelines can be configured to run for these merge requests, providing a seamless integration experience. Additionally, GitLab offers features like fork synchronization and pull mirroring to keep forks up-to-date with the upstream repository.

Bitbucket also supports pipelines for pull requests from forks, but there are some caveats. By default, pipelines do not run automatically for pull requests from forks to prevent unauthorized access to secrets and other sensitive data. Repository administrators must explicitly enable this feature and carefully manage permissions to strike a balance between security and contributor convenience.

Interested readers can learn more at the GitHub blog and download the CLI via their favourite package manager or the cli.github.com website.

On May 15, 2025, AWS announced a significant enhancement to its CodeBuild service: the Docker Server capability. This new feature allows developers to provision a dedicated and persistent Docker server within their CodeBuild projects, aiming to streamline and expedite the Docker image build process.

Traditionally, building Docker images in CI/CD pipelines can be time-consuming, especially when dealing with multi-layered images. With the Docker Server capability, AWS addresses this challenge by centralizing image building to a remote host. This approach reduces wait times and increases overall efficiency by maintaining a persistent Docker layer cache. In practical terms, AWS reports a dramatic reduction in build times when utilizing this feature.

The persistent Docker server supports multiple concurrent build operations, with all builds benefiting from the shared centralized cache. This setup not only accelerates the build process, but also ensures consistency across builds, which is crucial for maintaining reliable deployment pipelines.

To leverage this capability, developers can enable the Docker Server option within their CodeBuild project settings. Once activated, CodeBuild provisions the dedicated Docker server with persistent storage, facilitating faster and more efficient builds.

To set up the new Docker Server capability in AWS CodeBuild (as detailed in the AWS blog), begin by creating a new CodeBuild project or editing an existing one in the AWS Management Console. In the environment configuration, select “Managed image” and choose Amazon Linux 2 as the operating system. Then, within the new Docker configuration section (available for supported standard images such as aws/codebuild/standard:7.0 or later), enable the “Docker Server mode” option. This activates a lightweight Docker daemon without the performance drawbacks typically associated with Docker-in-Docker (DinD). Next, update your buildspec.yml file to include Docker commands- for example, building and pushing images to Amazon ECR – just as you would in a local Docker setup.

The instructions remind you to make sure the IAM role used by CodeBuild has the necessary permissions to interact with services like Amazon ECR. Once everything is configured, you can then trigger your build.

The introduction of the Docker Server capability in AWS CodeBuild has sparked some discussion among developers and DevOps professionals. While there is appreciation for significantly reduced build times, there are currently limitations in integration with infrastructure-as-code tools.

For instance, a GitHub issue in the AWS Cloud Development Kit (CDK) repository highlights that:

“As of now, the AWS CDK does not support this capability because CloudFormation also does not expose it yet. CDK can only provide support once CloudFormation does.”

This suggests that while the feature is promising, its adoption may be hindered until full support is available in tools such as CloudFormation and CDK.

Despite these integration challenges, the Docker Server capability has been lauded for its performance improvements. In the official AWS blog post, Donnie Prakoso shared benchmark results demonstrating a 98% reduction in build time, from nearly 25 minutes down to just 16 seconds, when utilizing this feature.

This new feature competes with existing solutions, such as Docker Inc’s Docker Build Cloud, GCP’s Cloud Build, and GitHub Actions Docker Layering.

This enhancement to AWS CodeBuild underscores AWS’s commitment to improving developer productivity and optimizing the CI/CD workflow. By reducing build times and streamlining the image creation process, the Docker Server capability enables development teams to deploy applications more rapidly and reliably.