How Apache DataFusion Runs SQL In-Process
Apache DataFusion is an embeddable query engine: SQL goes in, runs as columnar Arrow batches inside your own process, and results come out without a separate service.
Loading visual explainer…
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.
Explanation
Caddy is a web server that reads a configuration of site blocks to serve files or proxy requests. In a typical static-site deployment, a client request hits DNS, resolves to a platform edge, gets routed to a Caddy container, and is matched against a site block. Caddy then applies redirects and serves the file with file_server. In the Hugo-on-Fly example, automatic HTTPS is disabled because the platform handles certificates. Understanding this flow helps you debug where a request is actually handled and decide which layer should own TLS, DNS, and file serving.
FAQ
Why would you disable Caddy's automatic HTTPS?
In the Hugo on Fly example, auto_https is disabled because Fly handles certificate management. Fly's edge terminates TLS and requests Let's Encrypt certificates via DNS validation using flyctl certs. Disabling Caddy's auto_https avoids duplicate certificate management and lets the platform own TLS.
How does Caddy know which site to serve when multiple domains point to the same container?
Caddy uses site blocks in its configuration. Each block matches a hostname, such as makeroni.cc or the old fly.dev hostname. When a request arrives, Caddy matches the Host header to the appropriate block and applies its directives, like file_server or a redirect.
What is the role of the multi-stage Docker build in this Caddy deployment?
The Hugo post uses a multi-stage Docker build to first generate the static site with Hugo and then copy the output into a Caddy image. This keeps the final image small because it only contains Caddy and the static files, not the Hugo build toolchain. The resulting image is deployed to Fly.
The posts behind it
Related reading
Red Hat · · TutorialBuild a multi-tenant platform with OpenShift Dev Spaces
Local developer workstations introduce three concrete operational risks: production-parity risk from environment drift, slow time-to-first-commit for new engineers, and unmanaged security exposure from misconfigured tools. Red Hat OpenShift Dev Spaces addresses these by moving compute and tooling into containerized workspaces running directly on the cluster, with environments declared as code in a devfile. A production deployment requires four-zone namespace isolation separating control (openshift-devspaces), core server (devspaces-checluster), secure asset (devspaces-openvsx), and sandbox (username-devspaces) zones to prevent operator reconciliation from overriding custom configurations. Resource governance uses a two-tier model with defaultContainerResources fallback limits and containerResourceCaps absolute per-container ceilings, while automated cleanup cron jobs (monthly on the 1st) and inactivity idling (after 4 hours) protect etcd health by removing stopped workspaces after 30 days. The guide concludes with next steps for authentication and private extension registries.
Cloudflare · · AnnouncementIntroducing on-demand CPU and memory profiling with flamegraphs for Workers and Durable Objects
Cloudflare introduced on-demand CPU and memory profiling for Workers and Durable Objects, accessible via the CLI or the Dashboard’s Observability page. Users can generate interactive flamegraphs and download pprof files, with each rectangle’s width representing CPU time or memory usage over a chosen duration. Profiling the R2 binding Worker revealed that genericR2JsonReplacer, called by JSON.stringify, processed nested values multiple times; fixing it made the function 2.7x faster. A different Worker with P999 memory at 133 MB (above the 128 MB limit) was found to have a partially enabled Prometheus code path accounting for 66.7% of allocations; disabling it reduced P999 memory to 118 MB and eliminated out-of-memory errors. The profiling system locates the correct data center and isolate for the Worker or Durable Object, and continuous profiling is being developed to automatically capture samples without manual initiation.
- Cloudflare · · Announcement
Deno is joining Cloudflare
The Deno team is joining Cloudflare to merge workerd and celld, aiming to make self-hosting Workers and Durable Objects radically simpler for developers. Ryan Dahl, creator of Node.js and Deno, explains that Durable Objects provide a powerful abstraction: a distributed singleton with a SQLite database that scales by sharding state and WebSocket connections across machines. He started celld to run this model outside Cloudflare with a single Rust binary and object storage as its only external dependency. Kenton Varda counters the theory that Workers’ unique design creates lock-in, noting that workerd is open source and that celld provides an escape hatch for migration. The merged effort, led by Ryan and Bert Belder, will make self-hosting a first-class supported way to build and run apps using the Workers programming model.
Intercom · · Tutorial3 Tips on Using Ngrok to Maximize Messenger Apps
Ngrok is a tool that creates public URLs to expose a web server on a development machine, enabling developers to set webhook URLs while building Messenger Apps for Intercom without external infrastructure. To start, run ‘ngrok http 3000’ to tunnel a local server; the free version limits sessions to eight hours and generates a new address each run. The ngrok web interface at http://localhost:4040 allows inspection of HTTP traffic, showing request and response details. Developers can replay requests with the Replay button to avoid manually re-triggering endpoints during testing. The interface also validates JSON formatting in request and response bodies, highlighting errors like missing quotes for debugging.
Fly.io · · TutorialHugo's There - Flying with Hugo and Caddy
A new community venture’s website is built with Hugo, served by Caddy, and deployed on Fly, with a custom makeroni.cc domain added after the initial deployment. The process initializes a Fly app on port 80, uses Hugo’s Quickstart and Ananke theme, and employs a multi-stage Docker build based on klakegg/hugo:0.74.0-onbuild, copying generated files into caddy:2.1.1. Caddy serves the static files with file_server while auto_https is disabled because Fly handles certificate management; separate rules serve makeroni.cc and redirect the old fly.dev hostname. DNS A and AAAA records connect the domain to Fly, and flyctl certs create requests a Let’s Encrypt certificate through DNS validation, leaving the site ready to serve securely after redeployment.
More like this
More how it works explainers
How MaaS Governance Wraps a Model Endpoint on AKS
A model deployed on AKS is open by default. See how MaaS policies insert Authorino authentication and Limitador rate limits in front of vLLM, so bad keys and over-quota requests stop at the gate.
How BYOK Works: Your Key and Knowledge at Request Time
BYOK lets a system run on assets you supply — your model credential or your private knowledge — instead of the vendor's defaults. This walkthrough traces six steps from registration to an audited response.
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.
The best engineering reads, once a week
One useful email. Unsubscribe anytime.