How Caddy Serves a Static Site: The Request Flow
See how Caddy handles a request for a static site, from DNS resolution through container routing to file_server, and how TLS and redirects fit into the flow.
Loading…
Topic
Docker
83 posts about Docker. Every summary links to the original.
- 83 posts
- 13 companies
- 3 explainers
See the idea
Docker explainers
Anka CI Architecture: From Layered Images to Disposable macOS Builds
Anka is a Docker-like macOS virtualization layer for disposable CI environments. This architecture shows how images, Mac hosts, snapshots, build agents, and artifacts connect.
How Alpine Linux Reduces Container Size
Alpine Linux shrinks container images by replacing glibc with musl and using a minimal base, but introduces compatibility trade-offs you must evaluate before switching.
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
Newest first
Posts
How I hunt for vulnerabilities with AI
The author describes using AI-assisted code review to hunt for vulnerabilities in ClickHouse, a large C++ codebase, despite having limited bug-bounty experience. GitHub Copilot, Claude, ChatGPT, and Gemini models were used to inspect code, generate vulnerability hypotheses, explain unfamiliar subsystems, and identify older or newly introduced attack surfaces. Promising ideas were recorded, then investigated with Python scripts against a locally running ClickHouse Docker container, followed by manual review and reproduction to distinguish genuine findings from hallucinations and misconfigurations. The work produced a few real vulnerabilities that were reported to ClickHouse’s security team and bug bounty program, while the broader conclusion is that AI can accelerate exploration and validation but still requires persistent questioning and human verification.
Scaling out Distroless adoption With AI
Grab is migrating from heavy base images to Distroless images to reduce security risks, despite runtime failures caused by missing shared objects, utilities, or expected directory structures. Its medium tests run services in Docker, leave internal dependencies unmocked through Testcontainers, mock external dependencies with a network proxy, and execute in CI to catch Dockerfile regressions before deployment. For services without this setup, an agentic workflow detects candidates, scaffolds tests, fixes repository-specific failures, raises GitLab merge requests, and monitors CI while processing batches in parallel. Claude Code uses MCP integrations for GitLab, Glean, and Sourcegraph, with guardrails limiting changes to test files and CI configuration and humans reviewing every draft merge request. In roughly 1.5 months, the agent raised more than 100 medium-test merge requests and reduced work for 400 services from 400–1,200 engineer-days to approximately 0.1 days per service; Distroless adoption also grew substantially.
Migrating Your GitHub CI to Hugging Face Jobs
Trackio's GitHub Actions CI was limited by generic hosted machines, maintenance-related delays, and lack of readily available GPU runners, while the project needed CPU checks and CUDA-based tests. The setup keeps GitHub Actions as the CI coordinator and uses a dispatcher Space plus the huggingface/jobs-actions bridge to launch ephemeral GitHub runners inside Hugging Face Jobs, selected through labels such as hf-jobs-cpu-upgrade and hf-jobs-t4-small. The guide covers duplicating and configuring the dispatcher, creating a GitHub App, supplying runner credentials and an HF token, changing runs-on, choosing Docker images, and validating runs and logs; Playwright and NVIDIA CUDA images are used for CPU and GPU examples. In Trackio, the CPU job took 1m10s versus a 1m40s GitHub ubuntu-latest baseline, while the GPU check passed in 45s and cost less than a cent at the t4-small rate; logs were available through both systems.
The Open Source Community is backing OpenEnv for Agentic RL
OpenEnv is becoming a community-coordinated, open-source tool for building agentic execution environments such as terminals and browsers, with the stated goal of helping train open-source agents. Starting now, a committee including Meta-PyTorch, Reflection, Unsloth, Modal, Prime Intellect, Nvidia, Mercor, Fleet AI, Microsoft, Hugging Face, and RadixArk will coordinate the project, which now lives at huggingface/OpenEnv and is supported or adopted by numerous AI organizations. Technically, OpenEnv is being narrowed to an interoperability and protocol layer: environments expose a Gymnasium-style reset(), step(), and state() API through client/server deployments, standard HTTP or WebSocket protocols, Docker packaging, and MCP compatibility. It does not define rewards or training loops; those remain in specialized libraries, while OpenEnv connects harnesses, environments, and trainers across ecosystems. Planned work includes external rewards, dataset-backed tasksets, harness integrations, end-to-end examples, and automatic environment validation.
Logging, Metrics, and Distributed Tracing in .NET with OpenTelemetry and ClickStack
The post presents a walkthrough of instrumenting two ASP.NET services—an Order API and a Payment Service—with OpenTelemetry and sending traces, logs, and metrics to ClickStack. The demo uses SQLite for persistence, with Entity Framework Core instrumentation capturing database operations without manually creating spans. The configuration adds ASP.NET, HTTP client, and EF Core instrumentation, custom sources and meters, OpenTelemetry logging, and OTLP/gRPC exporters directed by OTEL_EXPORTER_OTLP_ENDPOINT. In ClickStack, the signals are correlated so a request can be followed across service boundaries, application work, and database calls, while the UI and ClickHouse SQL provide exploration options. The conclusion is that a relatively small ASP.NET setup replaces isolated timeout logs with an end-to-end view of timing, errors, logs, and database activity.
Mitigating CVE-2026-31431 (“Copy Fail”) in Docker Engine
CVE-2026-31431, dubbed Copy Fail, is a Linux kernel vulnerability in the AF_ALG crypto subsystem that allows unprivileged users to perform controlled writes to the page cache. Because default Docker Engine profiles permitted AF_ALG sockets, containers on unpatched host kernels could corrupt shared host page caches. Docker's initial mitigation in v29.4.2 blocked AF_ALG sockets and the socketcall syscall via seccomp, but entirely blocking socketcall broke 32-bit binaries and Go runtimes. To resolve compatibility issues, Docker Engine v29.4.3 reverted the seccomp socketcall block and adopted Linux Security Modules to enforce socket restrictions. The updated release configures AppArmor and SELinux policies to block AF_ALG creation across both direct and multiplexed syscall paths while retaining seccomp filtering for defense-in-depth.
Coding Agent Horror Stories: The Security Crisis Threatening Developer Infrastructure
Autonomous AI coding agents increasingly handle developer workflows, but their execution model introduces critical security risks. Operating with the executing user's full permissions, these agents can read ambient secrets, inherit cloud credentials, and run destructive shell commands without human intervention. Documented incidents between October 2024 and February 2026 reveal systemic hazards, including unintentional home directory deletions and increased security vulnerabilities in generated code. To address these vulnerabilities, Docker Sandboxes isolate agent execution within dedicated microVMs, preventing access to the host filesystem and blocking common credential paths by default. Routing changes through Git worktrees and restricting network egress ensures that agent actions remain strictly bounded and reviewable before affecting main branches or production infrastructure.
Development environments for your cloud agents
Cloud agents need development environments with repositories, dependencies, credentials, and build-system access to test, query services, and verify engineering work rather than merely write code. The release adds reusable multi-repo environments, allowing agents to work across microservices codebases and deliver, test, and verify changes spanning repositories. It also improves Dockerfile-based configuration with build secrets scoped to build steps and layer caching that makes cache hits run 70% faster. Cursor can inspect repositories, determine required tools and dependencies, and generate editable Dockerfile configurations, while its setup flow checks credentials and validates environments; this generator is in private beta. Governance features include environment-specific version history, rollback controls, audit logs, egress allowlists, and isolated secrets, while failed configurations fall back to a base image and work continues.
Development environments for cloud agents
Cloud agents need a laptop-like development environment with cloned repositories, installed dependencies, credentials, and build-system access to complete engineering tasks end-to-end. This release adds configurable multi-repo environments, Dockerfile-based configuration, and tools that let Cursor set up and maintain those environments. Build secrets remain scoped to build steps, while improved layer caching makes cache-hit builds run 70% faster; Cursor also asks setup questions, flags missing credentials, validates configuration, and falls back to a base image with warnings when setup fails. Version histories, admin-controlled rollback, audit logs, and environment-scoped egress and secrets provide governance and isolation across environments for teams running parallelized agents.
Structured Logging in .NET with Serilog and ClickHouse
Traditional logging solutions like Seq, ELK, and cloud platforms often face scaling bottlenecks, including slower queries, higher operational costs, and complex pipeline management. To address this, an ASP.NET service can write structured logs directly to ClickHouse using Serilog and the Serilog.Sinks.ClickHouse library. The sink transmits data over HTTP and provides a fluent C# builder to configure table schemas, typed JSON columns, full-text indexes, and MergeTree engine parameters. ClickHouse stores log data in a columnar format that delivers 10 to 20 times compression while enabling direct SQL queries, JSON property filtering, and real-time aggregations through materialized views. Furthermore, the sink includes an in-memory buffer to handle transient network drops with configurable batching, retry mechanisms, and callback hooks for failure alerting.
Docker lazy loading at Grab: Accelerating container startup times
Large Docker images for Airflow and Spark Connect caused minute-scale downloads, delaying cold starts and weakening autoscaling responsiveness. The post describes testing eStargz and Seekable OCI (SOCI) with containerd remote snapshotters, which expose registry-backed layers through a virtual lowerdir and fetch file content on demand. In production, SOCI delivered 30–40% faster startup times for Airflow and Spark Connect, while benchmark results showed SOCI matching standard images’ 5.0-second Airflow application startup; eStargz took 25.0 seconds. Configuration tuning increased download concurrency, unpack concurrency, and chunk size, reducing fresh-node image download time from 60 seconds to 24, a 60% improvement. Grab chose SOCI because Bottlerocket supports it natively, while noting that lazy loading redistributes rather than removes download work and requires workload-specific tuning.
Building the Open Agent Ecosystem Together: Introducing OpenEnv
Meta and Hugging Face have partnered to launch OpenEnv Hub, an open platform and specification designed for agentic AI environments. Large language models require external tools and APIs to complete tasks, but exposing broad toolsets directly introduces significant safety and semantic challenges. In response, OpenEnv establishes sandboxed environments providing defined APIs, authenticated tool access, and isolation for reinforcement learning post-training and deployment pipelines. The initial release includes the OpenEnv 0.1 RFC series covering component architecture, packaging, communication, and Model Context Protocol tool encapsulation. Creators can run local Docker-based environments using standard step, reset, and close interfaces while integrating with frameworks like TorchForge, TRL, verl, and SkyRL.
Using Kamal 2.0 in Production
Sam Ruby describes publishing an online guide to using Kamal 2.0 for production after finding existing material insufficient for deploying a real project. The guide grew from research for the Deployment and Production chapter of Agile Web Development with Rails 8, then was converted from Pragmatic Programming’s XML grammar to Markdown with GitHub Copilot and proofread with it. It presents an opinionated starter list with defaults and alternatives, covering seven initial requirements alongside Docker builders, container repositories, secret management, hosting choices, load balancing, and managed databases. It also treats production as including database backups, searchable logs, monitoring, and application security, and invites community corrections or additions under a CC0 license.
Our Best Customers Are Now Robots
Fly.io reports that users driving the platform’s most recent growth are robots rather than people, prompting a reconsideration of developer experience (DX) as the primary product lens. The post describes how vibe-coding workflows use Fly Machines—Docker containers running as hardware-isolated virtual machines—to create, modify, stop, and rapidly restart environments without paying during stopped periods. These workflows favor incremental filesystem state, object storage, and controllable routing for MCP connections, including potentially long-lived SSE connections that should reach the same stateful instance. Fly.io also proposes exposing its API through MCP and using sealed, tokenized secrets so isolated machines can substitute real OAuth credentials only when needed. It concludes that a useful robot experience (RX) will require more than an MCP interface, while managed Postgres remains the company’s most important engineering priority and the platform is still primarily designed for humans.
Creating reusable developer environments with Stripe Sandboxes
Setting up development machines with the correct tools, permissions, and dependencies can take weeks for new engineers, so the setup combines Stripe Sandboxes with development containers. Stripe Sandboxes provide isolated accounts with full Stripe API access for testing without real transactions, while sandbox settings remain independent and production customer, product, and transaction data is not copied. A C# example uses Bogus to generate ten fake products and Stripe.net’s ProductService to create them with metadata in the sandbox, and the text notes that SDKs can populate additional account data. The containerized workspace uses Docker development containers, a .NET 8 image, Redis via Docker Compose, environment variables, VS Code customizations, and a post-create script that installs Stripe CLI. Configuration files can then be checked into source control, giving team members an isolated and consistent workspace for exploring payment workflows without affecting live data.
Profile-guided optimisation (PGO) on Grab services
Profile-guided optimisation (PGO) improves Go application performance by feeding production CPU profile data into subsequent compiler builds. Teams evaluated PGO across multiple Grab services, including TalariaDB and an orchestrator within the Catwalk service, using Go 1.20 and Go 1.21 builds. TalariaDB saw substantial resource savings after compiling Docker images with a 360-second pprof profile, resulting in at least a 10% drop in CPU usage, a 30% drop in memory consumption, and a 38% reduction in persistent volume usage for event ingestion queues. Conversely, testing on Catwalk showed only a 5% performance gain after adjusting the profiling duration from 59 seconds to 6 minutes, an outcome deemed insufficient to justify pipeline modifications. Broader adoption across monorepo services remains constrained until the central build process supports PGO arguments and automated profile retrieval.
Fly With Alpine
Alpine Linux can reduce container image sizes compared with Debian slim, but switching distributions involves compatibility and ecosystem trade-offs. The post compares Fly.io’s Debian-based baseline across Bun, Node, Python, and Ruby, then reports smaller Alpine base and application images, including 304MB versus 428MB for a minimal Rails/Postgresql/esbuild application. Migration consists of changing Dockerfile base images from -slim to -alpine, replacing apt-get with apk, and reviewing package-name differences; recent Bun, Node, and Rails generators can make these changes with an --alpine option. Alpine uses musl rather than Debian’s glibc, and issues can involve DNS, missing commands or packages, precompiled binaries, insufficient testing of release candidates, and software such as Chrome. Fly.io will retain Debian as its default while keeping Alpine available.
Transcribing on Fly GPU Machines
Fly GPU Machines are used to run Whisper Webservice for audio transcription, with the post noting that Fly GPUs are deprecated and unavailable after August 1. The setup uses a GPU-friendly Docker image, an a100-pcie-40gb Machine, and a Fly Volume mounted at /root/.cache/whisper so model files download and persist outside the image; ASR_MODEL=large and ASR_ENGINE=faster_whisper configure the service. It shows flyctl commands for creating the app, GPU-hosted volume, Machine, public IPs, and HTTPS routes, then verifies GPU availability with nvidia-smi and exposes the web UI and OpenAPI specification. A second path automates volume and Machine creation through the Machines API, requiring cpu_kind plus valid cpus and memory_mb values. It also demonstrates a custom Ubuntu 22.04 image with NVIDIA CUDA libraries, FFmpeg, Python, and Whisper, concluding that GPU Machines can support composable AI workloads.
Building ChatGPT Plugins with Supabase Edge Runtime
A TypeScript template for ChatGPT Plugins runs on Supabase Edge Runtime and provides a path for exposing a TODO API to ChatGPT. The implementation serves the required ai-plugin.json manifest from an Edge Function because static file hosting is not currently supported, and generates an OpenAPI JSON document from endpoint JSDoc annotations with swagger-jsdoc. An Oak router defines TODO routes, while shared CORS headers allow requests from https://chat.openai.com and credentials. Docker configuration runs Edge Runtime locally with a bind-mounted functions directory, enabling changes without rebuilding and exposing requests through localhost:8000. The guide also covers local installation and testing through the ChatGPT UI, then deployment to Fly.io; it notes authentication as a possible next step.
Fly.io ❤️ JS
Fly.io proposes a general-purpose way to deploy JavaScript and Node.js applications despite the ecosystem’s many frameworks, package managers, runtimes, and TypeScript conventions. Its dockerfile-node project uses package.json, lockfiles, and dependency metadata to generate a baseline Dockerfile, .dockerignore, and optionally a docker-entrypoint script; users can invoke it with npx @flydotio/dockerfile. Conditional EJS templates accommodate framework-specific requirements, with initial templates for Express, Fastify, Gatsby, Nest, Next, Nuxt, and Remix, though current support may extend only to a splash screen. Future plans include replacing Fly.io’s existing flyctl scanners, integrating deployment-time secrets, volumes, databases, and health checks, and adding customization such as build caching, swap, Docker Compose generation, browser setup, and non-root execution.
Related topics
All topics →Weekly digest
The best engineering reads, once a week.