# Firecracker Published articles for Firecracker. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Security evaluations find traditional virtual machines inadequate for containing cyber-capable autonomous agents DevFeed: [Security evaluations find traditional virtual machines inadequate for containing cyber-capable autonomous agents]() Original publisher: [Read original article]() Author: Olimpiu Pop Published: 2026-09-17T07:07:00Z Content type: news Language: en Sources: [InfoQ]() Topics: [virtual machines](), [Security](), [Vulnerabilities](), [Linux Kernel](), [qemu](), [Firecracker](), [systems]() Tags: [agent-escape-vm](), [ai-security](), [development](), [devops](), [firecracker](), [linux](), [linux-kernel](), [news](), [qemu](), [security](), [security-breach](), [virtual-machines](), [virtualization](), [vm](), [vulnerabilities]() ### AI overview Security evaluations found that a cyber-capable autonomous agent escaped standard QEMU and KVM virtual machine configurations by exploiting kernel and library vulnerabilities. Firecracker contained the agent in testing, but the agent still hardlocked the host through Linux kernel flaws. ### Source excerpt Traditional virtual machines are inadequate for isolating cyber-capable autonomous agents. Tests using GPT-5.6-Cyber indicated multiple escape attempts due to kernel flaws. While Firecracker provided some containment, vulnerabilities remained. The study underscores the need for minimal attack surface virtualisation technologies and rapid, proactive patching strategies to safeguard host systems. By Olimpiu Pop ## How AWS Lambda logs every flow across thousands of microVMs per host with eBPF and Rust DevFeed: [How AWS Lambda logs every flow across thousands of microVMs per host with eBPF and Rust]() Original publisher: [Read original article]() Author: Prashant Kumar Singh Published: 2026-09-11T12:00:00Z Content type: article Language: en Sources: [The New Stack]() Topics: [AWS Lambda](), [Architecture & Design](), [SIEM, Security, Observability](), [telemetry](), [Amazon EC2](), [Amazon S3](), [VPC]() Tags: [architecture](), [aws](), [aws-lambda](), [aws-marketplace](), [compliance](), [ebpf](), [firecracker](), [incident](), [incident-response](), [logs](), [monitoring](), [observability](), [post-contributed](), [rust](), [s3](), [scale](), [security](), [server](), [serverless](), [sponsor-aws-marketplace](), [sponsored-post-contributed](), [vpc]() ### AI overview AWS Lambda describes replacing an aging network-capture system with an eBPF and Rust pipeline that records network flows across short-lived, tenant-isolated microVMs. The system prioritizes complete, correctly attributed records with minimal overhead for security investigation, metering, audit, observability, and monitoring. ### Source excerpt On any compute platform, when a security alert fires, the question is always the same. Which workload talked to that The post How AWS Lambda logs every flow across thousands of microVMs per host with eBPF and Rust appeared first on The New Stack. ## Cursor Cloud Agents can now run in Vercel Sandbox DevFeed: [Cursor Cloud Agents can now run in Vercel Sandbox]() Original publisher: [Read original article]() Author: Allen Zhou Published: 2026-09-03T15:00:00Z Content type: release Language: en Sources: [Vercel News]() Topics: [cursor](), [Vercel](), [Agent Harness](), [Firecracker]() Tags: [agents](), [apis](), [architecture](), [cursor](), [enterprise](), [firecracker](), [guide](), [sandbox](), [scale](), [vercel](), [virtual-machines](), [workflows]() ### AI overview Cursor Cloud Agents can run in Vercel Sandbox, using isolated Firecracker microVMs as their execution environment. The architecture combines Cursor's agent harness and inference loop with Vercel Functions and Workflows for durable request handling, worker provisioning, monitoring, retries, cleanup, and short-lived user-scoped credentials. ### Source excerpt Cursor Cloud Agents can now run in Vercel Sandbox instead of Cursor's hosted machines. Cursor manages the agent harness and inference loop. Its Self-Hosted Machines APIs let you supply the execution environment where agents clone repositories, edit files, and run commands and tests. Self-Hosted Machines requires a Cursor Enterprise plan. Vercel Sandbox provides that execution environment as an isolated Firecracker microVM for each agent request. Vercel Functions and Vercel Workflows form a durable control plane that claims queued agent requests, provisions workers, monitors sessions, and cleans up automatically. With this architecture, you get: A scale-to-zero worker pool without long-lived virtual machines A dedicated, isolated Sandbox for every agent request Durable retries when a worker or session fails Short-lived, user-scoped credentials inside each Sandbox Follow the step-by-step guide to deploy the reference implementation to your own Vercel account, or learn more in the Vercel Sandbox documentation. Read more ## Developing provably correct Rust code with Verus DevFeed: [Developing provably correct Rust code with Verus]() Original publisher: [Read original article]() Author: Bryan Parno Published: 2026-08-31T15:35:33Z Content type: article Language: en Sources: [Amazon Science homepage]() Topics: [Rust formal verification](), [Vulnerabilities]() Tags: [amazon-elastic-compute](), [automated-reasoning](), [aws-lambda](), [code](), [firecracker](), [formal-methods](), [formal-verification](), [open-source](), [rust](), [security](), [testing]() ### AI overview The article explains how Verus formally verifies Rust code against mathematical specifications, helping establish correctness beyond what Rust safety checks and conventional tests provide. ### Source excerpt How the Verus "program verifier", which automatically checks code against a mathematical specification of its functionality, helps increase security assurance in software projects. ## $1 million hacker challenge for Vercel Sandbox DevFeed: [$1 million hacker challenge for Vercel Sandbox]() Original publisher: [Read original article]() Author: Andy Riancho Published: 2026-08-18T13:00:00Z Content type: article Language: en Sources: [Vercel News]() Topics: [Vercel](), [Firecracker](), [Security](), [vulnerability](), [Network](), [Amazon EC2](), [Linux](), [Open Source]() Tags: [agents](), [bounty](), [firecracker](), [linux](), [network](), [open-source](), [sandbox](), [security](), [vercel](), [vulnerability]() ### AI overview Vercel announces a two-week public HackerOne challenge offering up to $1 million in total payouts for researchers who can escape Vercel Sandbox isolation. The article explains that Sandbox uses Firecracker microVMs on bare-metal Amazon EC2 hosts, with host-side network controls forming part of the security boundary. Individual reports can receive up to $50,000 for vulnerabilities allowing access to another Vercel tenant's data. ### Source excerpt Agents need to run untrusted code, and the microVM has become the standard way to do it: a dedicated guest kernel per workload, isolated from the host and from every other workload on the same machine. But recent security research and real-world incidents have revealed that agents running untrusted code do not need to cross a VM boundary to escape containment; they only need one network path the security model failed to account for, which we explained in our post A sandbox without a network boundary is only half a sandbox. Isolation only holds if both sides of it hold: the Firecracker microVM and the host-side network controls. Recently our CTO pointed an open-weight model with no safeguards at Vercel Sandbox. It did not escape, but it mapped the guest kernel, built a VM to reproduce its ideas, and wrote a fuzzer. Defenders have first-mover advantage, but it won't last forever, and the choice is when to test the boundaries (we strongly encourage building a scanning program, which you can do on any budget with an open-source tool like deepsec and AI Gateway). We are proactively choosing to test Vercel Sandbox on our own schedule, not an attacker's, and we are doing it in the open, with the best researchers in the world. So for two weeks, we are paying up to $1,000,000 USD to the researchers who can escape a Vercel Sandbox. The challenge Starting today, Vercel is running a two-week public HackerOne program focused on Vercel Sandbox isolation. Program: Public HackerOne program, open to all eligible researchers Window: Tuesday, August 18 to Tuesday, September 1, 2026, or earlier if the reward pool is exhausted Max per report: $50,000 USD, for a vulnerability that lets a threat actor read or modify another Vercel tenant's data Total pool: Up to $1,000,000 USD in total payouts Bounties are paid per report, scoped to a single root cause, and assigned by Vercel triage based on the maximum demonstrable impact. The full bounty table, detailed scope, and the list of known-dupl ## We rebuilt the Linux microVM stack on Apple Silicon DevFeed: [We rebuilt the Linux microVM stack on Apple Silicon]() Original publisher: [Read original article]() Author: Ivan Cernja Published: 2026-08-18T00:00:00Z Content type: article Language: en Sources: [Encore Updates]() Topics: [Firecracker](), [virtualization](), [macOS](), [Linux](), [Dockerfile](), [Go Language]() Tags: [docker](), [firecracker](), [go](), [linux](), [macos](), [virtualization]() ### AI overview Encore rebuilt its Linux microVM development stack to work on Apple Silicon. The article describes crackling, an API that uses Firecracker on Linux and Apple's hypervisor on macOS, along with the tooling needed to run the same build system on developer laptops and in production. ### Source excerpt Maybe we should have just moved everyone to Linux. ## AWS Lambda MicroVM Sandboxes with the Serverless Framework DevFeed: [AWS Lambda MicroVM Sandboxes with the Serverless Framework]() Original publisher: [Read original article]() Author: Serverless Team Published: 2026-07-21T00:00:00Z Content type: release Language: en Sources: [Serverless Blog]() Topics: [AWS Lambda](), [serverless framework](), [Firecracker](), [Emulator]() Tags: [aws](), [aws-lambda](), [cloud-computing](), [emulator](), [faas](), [firecracker](), [function-as-a-service](), [infrastructure-as-code](), [news](), [serverless](), [serverless-architecture](), [serverless-framework]() ### AI overview AWS Lambda MicroVMs run untrusted and agent-generated code in isolated Firecracker virtual machines. The Serverless Framework supports them as Sandboxes in serverless.yml, with deployment and a local MicroVM emulator for development and testing. ### Source excerpt AWS Lambda MicroVMs are a new compute primitive for running untrusted and agent-generated code in fully isolated Firecracker virtual machines. The Serverless Framework brings them into serverless.yml as Sandboxes, with one-command deploys and a full local MicroVMs emulator so you can build and test before you ship. ## Serverless ICYMI Q2 2026 DevFeed: [Serverless ICYMI Q2 2026]() Original publisher: [Read original article]() Author: Julian Wood Published: 2026-07-20T16:40:00Z Content type: article Language: en Sources: [AWS Compute Blog]() Topics: [Serverless](), [Amazon Web Services](), [AWS Lambda](), [Firecracker](), [Amazon S3](), [Filesystems](), [Linux](), [virtualization](), [mount](), [Latency]() Tags: [2026](), [amazon-eventbridge](), [amazon-s3](), [amazon-simple-storage-service-s3](), [aws](), [aws-lambda](), [aws-step-functions](), [ci-cd](), [firecracker](), [latency](), [linux](), [mount](), [serverless](), [virtualization]() ### AI overview A Q2 2026 recap of AWS serverless launches and resources, focusing on AWS Lambda MicroVMs and Amazon S3 Files integration with Lambda. ### Source excerpt In this 33rd quarterly recap post, discover the most impactful AWS serverless launches, features, and resources from Q2 2026 that you might have missed. Stay current with the latest serverless innovations that can improve your applications. In case you missed our last ICYMI, read about what happened in Q1 2026. AWS Lambda MicroVMs AWS Lambda [...] ## Run Claude Managed Agents with Vercel Sandbox DevFeed: [Run Claude Managed Agents with Vercel Sandbox]() Original publisher: [Read original article]() Author: Allen Zhou Published: 2026-05-18T23:01:00Z Content type: release Language: en Sources: [Vercel News]() Topics: [Claude](), [Vercel](), [Firecracker](), [Security](), [Cloud]() Tags: [agents](), [claude](), [cloud](), [firecracker](), [firewall](), [low-latency](), [sandbox](), [security](), [vercel]() ### AI overview Vercel Sandbox now supports Claude Managed Agents, combining Anthropic's managed agent loop with self-hosted execution on Vercel infrastructure. Each session runs in an isolated Firecracker microVM with firewall-based credential brokering, deny-by-default egress, and low-latency access to private networks and cloud workloads. ### Source excerpt You can now run Claude Managed Agents with Vercel Sandbox. Claude Managed Agents handles the model, harness, tools, and session state. Self-hosting lets you bring the execution environment, so an agent's tool calls run on your existing Vercel infrastructure with your private APIs, internal services, and customer data. Each agent session runs in its own isolated Firecracker microVM, using the same infrastructure that powers 1B+ Vercel deployments with enterprise-grade security, availability, and performance. What you get: A managed agent loop from Anthropic, including the model, harness, tools, and session state A Vercel function control plane that spawns a sandbox per session Firecracker microVM isolation per session, with millisecond startup Credential brokering at the firewall, so secrets never enter the sandbox Deny-by-default egress with a domain allowlist Low-latency connectivity to your private network and cloud workloads Follow the step-by-step guide for a reference implementation and learn more in the Vercel Sandbox docs. Read more ## Optimizing Vercel Sandbox snapshots DevFeed: [Optimizing Vercel Sandbox snapshots]() Original publisher: [Read original article]() Author: Guðmundur Bjarni Ólafsson Published: 2026-04-02T04:00:00Z Content type: article Language: en Sources: [Vercel News]() Topics: [Amazon S3](), [Go Language]() Tags: [aws](), [benchmarking](), [cache](), [compression](), [concurrency](), [firecracker](), [go](), [http](), [infrastructure](), [performance](), [s3](), [sandbox](), [streams](), [vercel]() ### AI overview Vercel describes optimizing Sandbox filesystem snapshot restores from over 40 seconds at p75 to under one second through parallel S3 range downloads, parallel decompression, streamed decompression, and local caching. ### Source excerpt When we recently shipped filesystem snapshots in Vercel Sandbox to let teams capture and restore a sandbox's entire filesystem state, our initial engineering focus was entirely on reliability, making sure the system would never fail to snapshot or lose data. Once that foundation was stable, our attention turned to performance. p75 snapshot restores were taking over 40 seconds, and through parallelization and local caching, we brought that under one second. What a snapshot looks like on disk Vercel Sandbox runs on the same infrastructure as our internal builds product, Hive. Each sandbox is an isolated container inside a Firecracker microVM. A snapshot is a compressed copy of the sandbox's disk. We're working with two different files: The raw disk image (.img), which can be several GBs A compressed version in our custom VHS format (Vercel Hive Snapshot), which is what gets uploaded to and downloaded from S3 When you call sandbox.snapshot(), we compress the .img into a .vhs and upload it to S3. When you call Sandbox.create() with a snapshot, we download the .vhs and decompress it back. Without compression, every snapshot operation transfers hundreds of MBs to low GBs over the network, adding seconds to tens of seconds to every restore. Parallelize you shall With reliability in place, we turned to the restore path, which was painfully sequential. We'd download the entire .vhs file from S3 in a single request, wait for it to finish, then decompress it in a single thread. Snapshots range from 200MB to a few GBs, so that single S3 download alone could take several seconds to tens of seconds. We used the Range HTTP header to download chunks in parallel instead, with the AWS Go SDK's transfermanager API handling the orchestration. After benchmarking different concurrency levels and chunk sizes, we ended up with 2-5x faster downloads. We applied the same thinking to decompression. Our .vhs format stores a header and a frame for each allocated region of the disk image, so ins ## I wrote a replacement for GitHub's code review bot DevFeed: [I wrote a replacement for GitHub's code review bot]() Original publisher: [Read original article]() Author: Alex Ellis Published: 2025-11-18T00:00:00Z Content type: opinion Language: en Sources: [Alex Ellis' Blog]() Topics: [GitHub](), [Code review](), [GitHub Copilot code review](), [Pull Request]() Tags: [agent](), [code-review](), [firecracker](), [github](), [github-copilot](), [large-language-models-llms](), [linux](), [llm](), [opencode](), [review](), [self-hosted](), [self-hosting](), [slicer](), [source]() ### AI overview The author describes building a replacement for GitHub's code review bot. They explain code review bots and compare GitHub Copilot's feedback with the opencode CLI, reporting that Copilot's feedback was superficial while opencode produced more useful review feedback for an OpenFaaS product change. ### Source excerpt If GitHub themselves have a native code review bot, why not just use it? ## Seven Years of Firecracker DevFeed: [Seven Years of Firecracker]() Original publisher: [Read original article]() Author: Marc Brooker Published: 2025-09-18T00:00:00Z Content type: article Language: en Sources: [Marc Brooker's Blog](), [Marc Brooker's Blog]() Topics: [Firecracker](), [virtualization](), [Amazon Web Services](), [Security](), [Open Source](), [Amazon Bedrock AgentCore](), [Serverless](), [Artificial Intelligence](), [Multitenancy](), [Large Language Model](), [Python]() Tags: [ai](), [amazon-bedrock-agentcore](), [aws](), [aws-lambda](), [firecracker](), [llm](), [multitenancy](), [open-source](), [python](), [security](), [virtualization]() ### AI overview This article reflects on seven years of Firecracker, an open source technology for creating and managing small virtual machines. It describes Firecracker's role in AWS Lambda, its security and compatibility benefits compared with container and language-level isolation, its use across AWS, and its role in Amazon Bedrock AgentCore for running AI agents. ### Source excerpt Seven Years of Firecracker Time flies like an arrow. Fruit flies like a banana. Back at re:Invent 2018, we shared Firecracker with the world. Firecracker is open source software that makes it easy to create and manage small virtual machines. At the time, we talked about Firecracker as one of the key technologies behind AWS Lambda, including how it'd allowed us to make Lambda faster, more efficient, and more secure. A couple years later, we published Firecracker: Lightweight Virtualization for Serverless Applications (at NSDI'20). Here's me talking through the paper back then: The paper went into more detail into how we're using Firecracker in Lambda, how we think about the economics of multitenancy (more about that here), and how we chose virtualization over kernel-level isolation (containers) or language-level isolation for Lambda. Despite these challenges, virtualization provides many compelling benefits. From an isolation perspective, the most compelling benefit is that it moves the security-critical interface from the OS boundary to a boundary supported in hardware and comparatively simpler software. It removes the need to trade off between kernel features and security: the guest kernel can supply its full feature set with no change to the threat model. VMMs are much smaller than general-purpose OS kernels, exposing a small number of well-understood abstractions without compromising on software compatibility or requiring software to be modified. Firecracker has really taken off, in all three ways we hoped it would. First, we use it in many more places inside AWS, backing the infrastructure we offer to customers across multiple services. Second, folks use the open source version directly, building their own cool products and businesses on it. Third, it was the motivation for a wave of innovation in the VM space. In this post, I wanted to write a bit about two of the ways we're using Firecracker at AWS that weren't covered in the paper. Bedrock AgentCore Back in J ## Preview: Slice Up Bare-Metal with Slicer DevFeed: [Preview: Slice Up Bare-Metal with Slicer]() Original publisher: [Read original article]() Author: Alex Ellis Published: 2025-08-30T08:09:48Z Content type: release Language: en Sources: [Alex Ellis' Blog]() Topics: [Firecracker](), [Kubernetes](), [OpenFaaS](), [systemd](), [Arch Linux](), [Arm](), [migration](), [Ollama]() Tags: [arm](), [bare-metal](), [boot](), [deploy](), [firecracker](), [k3s](), [kubernetes](), [linux](), [network](), [preview](), [self-hosting](), [slicer](), [storage](), [systemd](), [testing](), [work](), [x86-64]() ### AI overview OpenFaaS Ltd is previewing Slicer, an internal tool that partitions bare-metal hosts into Firecracker microVMs. The article describes use cases including Kubernetes cluster scaling, customer simulations, chaos testing, production troubleshooting, Arm and x86_64 testing, persistent workloads, multi-host deployments, and GPU access for Ollama. ### Source excerpt The easiest and best supported way to learn and deploy Firecracker and microVMs. ## Intel N100 Mini PC for R&D and Self-Hosting Compared with Raspberry Pi 5 DevFeed: [Intel N100 Mini PC for R&D and Self-Hosting Compared with Raspberry Pi 5]() Original publisher: [Read original article]() Author: Alex Ellis Published: 2025-08-18T08:09:48Z Content type: opinion Language: en Sources: [Alex Ellis' Blog]() Topics: [pc](), [intel](), [cpu](), [Self-hosted](), [Raspberry Pi](), [NVMe](), [Firecracker](), [Kubernetes](), [Linux](), [k3s](), [OpenFaaS](), [ddr5]() Tags: [ddr5](), [firecracker](), [github-actions](), [intel](), [k3s](), [kubernetes](), [linux](), [m-2-nvme](), [mini-pc](), [pc](), [processor](), [self-hosting](), [storage](), [threads](), [work]() ### AI overview The article evaluates the low-power Intel N100 Mini PC for R&D and self-hosting, comparing it with the Raspberry Pi 5. It discusses CPU, RAM, NVMe storage, Ethernet, virtualization, Kubernetes, Firecracker, and cost considerations. ### Source excerpt Exploring the capabilities of the Intel N100 Mini PC for work and self-hosting as an alternative to public cloud. ## Decomposing Aurora DSQL DevFeed: [Decomposing Aurora DSQL]() Original publisher: [Read original article]() Author: Marc Brooker Published: 2025-04-17T00:00:00Z Content type: article Language: en Sources: [Marc Brooker's Blog](), [Marc Brooker's Blog]() Topics: [DSQL](), [Transactions](), [Concurrency](), [Firecracker](), [PostgreSQL](), [Replication](), [Availability](), [systems]() Tags: [architecture](), [availability](), [blog-post](), [concurrency](), [dsql](), [firecracker](), [postgresql](), [replication](), [systems](), [transactions]() ### AI overview The article explains Aurora DSQL by decomposing transaction processing into execution, ordering, validation, and persistence. It describes PostgreSQL-powered query processors isolated with Firecracker, parallel ordering and validation by adjudicators, and durable replication across availability zones or regions before changes are applied for read visibility. ### Source excerpt Decomposing Aurora DSQL Riffing, I guess. Earlier today, Alex Miller wrote an excellent blog post titled Decomposing Transaction Systems. It's one of the best things I've read about transactions this year, maybe the best. You should read it now. In the post, Alex breaks transactions down like this: Every transactional system does four things: It executes transactions. It orders transactions. It validates transactions. It persists transactions. then describes how these steps map to traditional OCC and PCC systems, research designs like Calvin, and real-world systems like FoundationDB. How do these steps map to Aurora DSQL? An overview of DSQL's architecture may be useful if you haven't been following along so far: Now, an hour of video and 20 minutes of reading another post later, we're back. Let's dive in. Executing a transaction means evaluating the body of the transaction to produce the intended reads and writes. Aurora DSQL executes transactions on a horizontally scalable fleet of Firecracker-isolated, PostgreSQL-powered, query processors. At this stage there's no coordination at all. MVCC is used for reads during execution, and no writes escape the query processor running that particular transaction. See this post for more on this step. Ordering a transaction means assigning the transaction some notion of a time at which it occurred. Validating a transaction means enforcing concurrency control, or more rarely, domain-specific semantics. In DSQL, ordering and validating happen in parallel, done by the adjudicators involved in the transaction. Each adjudicator provides a range of possible orderings (not after, not before), and one final adjudicator makes the final ordering decision. Similarly, each involved adjudicator weighs in on validation, with one final adjudicator checking that everybody says yes. Strictly, the final-final order is chosen only after validation completes, but the ordering and validation protocols run in parallel. See this post for more. Persi ## How to run Firecracker without KVM on cloud VMs DevFeed: [How to run Firecracker without KVM on cloud VMs]() Original publisher: [Read original article]() Author: Alex Ellis Published: 2025-02-12T09:05:21Z Content type: tutorial Language: en Sources: [Alex Ellis' Blog]() Topics: [Firecracker](), [virtualization](), [virtual machines](), [Cloud](), [Amazon Web Services](), [Amazon EC2]() Tags: [aws](), [bare-metal](), [cloud](), [ec2](), [firecracker](), [github-actions](), [kvm](), [qemu](), [virtual-machines](), [virtualization]() ### AI overview This tutorial introduces a way to run microVMs on cloud virtual machines without KVM, using the PVM virtualization framework. It explains the limitations of nested virtualization and compares the cost of AWS bare-metal EC2 with alternatives. ### Source excerpt MicroVMs need bare-metal or nested virtualisation with /dev/kvm. But what if that's not available? The PVM virtualisation framework may be the answer. ## DSQL Vignette: Reads and Compute DevFeed: [DSQL Vignette: Reads and Compute]() Original publisher: [Read original article]() Author: Marc Brooker Published: 2024-12-04T00:00:00Z Content type: article Language: en Sources: [Marc Brooker's Blog](), [Marc Brooker's Blog]() Topics: [DSQL](), [Databases](), [Scalability](), [Architecture & Design](), [SQL](), [Amazon Web Services](), [Amazon Aurora](), [AWS Lambda](), [Firecracker]() Tags: [architecture](), [aws](), [aws-lambda](), [cloud-native](), [database](), [dsql](), [firecracker](), [scalability](), [sql]() ### AI overview This article examines the architecture behind Aurora DSQL, focusing on SQL execution and transactional reads. It explains how DSQL independently scales compute, read throughput, write throughput, and storage by disaggregating storage from compute, and describes its dynamically scalable SQL execution layer. The article also discusses lessons from AWS Lambda and the use of Firecracker MicroVMs running customized Postgres engines for transactions. ### Source excerpt DSQL Vignette: Reads and Compute The easy half of a database system? In today's post, I'm going to look at half of what's under the covers of Aurora DSQL, our new scalable, active-active, SQL database. If you'd like to learn more about the product first, check out the official documentation, which is always a great place to go for the latest information on Aurora DSQL, and how to fit it into your architecture. Today, we're going to focus on running SQL and doing transactional reads. But first, let's talk scalability. One of the most interesting things in DSQL's architecture is that we can scale compute (SQL execution), read throughput, write throughput, and storage space independently. At a fundamental level, scaling compute in a database system requires disaggregation of storage and compute. If you stick storage and compute together, you end up needing to scale one to scale the other, which is either impossible or uneconomical. That's why, when we launched Aurora 10 years ago (nearly to the day!) we chose an architecture which separated compute and storage (from Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases, SIGMOD'17): As the paper says: We use a novel service-oriented architecture (see Figure 1) with a multi-tenant scale-out storage service that abstracts a virtualized segmented redo log and is loosely coupled to a fleet of database instances. In DSQL, we took this pattern one step further: we changed the interface between the SQL executor and storage to remove the need for a large local cache1 right next to the SQL engine. With that out of the way, we could build a new scalable SQL execution layer which can dynamically scale to meet the needs of nearly any workload. Compute Scale: Lessons from Lambda Aurora wasn't the only big launch at re:Invent 2014. Another big one was AWS Lambda2. AWS Lambda brought a new compute scalability model: the ability to scale up efficiently in small units, each with a single well-defined ## JIT WireGuard DevFeed: [JIT WireGuard]() Original publisher: [Read original article]() Published: 2024-03-12T00:00:00Z Content type: article Language: en Sources: [The Fly Blog]() Topics: [fly.io](), [API](), [Command-line interface](), [Firecracker](), [GraphQL](), [Networks](), [Remote Procedure Call (RPC)](), [Messaging](), [Server](), [Kernel](), [SQLite](), [Containers]() Tags: [api](), [cdn](), [cli](), [close-to-users](), [containers](), [deploy-app-servers](), [docker](), [elixir](), [firecracker](), [fly](), [fly-io](), [graphql](), [heroku-alternative](), [heroku-competitor](), [hosting](), [i](), [kernel](), [messaging](), [networking](), [networks](), [postgresql-clusters](), [rpc](), [servers](), [sqlite]() ### AI overview Fly.io describes improvements to its WireGuard gateway architecture for greater speed and scalability. The article explains how flyctl creates a networking stack, obtains peer configurations through a GraphQL API, distributes them to regional gateways through RPC over NATS, and installs them using SQLite and WireGuard libraries. ### Source excerpt We're Fly.io and we transmute containers into VMs, running them on our hardware around the world with the power of Firecracker alchemy. We do a lot of stuff with WireGuard, which has become a part of our customer API. This is a quick story about some tricks we played to make WireGuard faster and more scalable for the hundreds of thousands of people who now use it here. One of many odd decisions we've made at Fly.io is how we use WireGuard. It's not just that we use it in many places where other shops would use HTTPS and REST APIs. We've gone a step beyond that: every time you run flyctl, our lovable, sprawling CLI, it conjures a TCP/IP stack out of thin air, with its own IPv6 address, and speaks directly to Fly Machines running on our networks. There are plusses and minuses to this approach, which we talked about in a blog post a couple years back. Some things, like remote-operated Docker builders, get easier to express (a Fly Machine, as far as flyctl is concerned, might as well be on the same LAN). But everything generally gets trickier to keep running reliably. It was a decision. We own it. Anyways, we've made some improvements recently, and I'd like to talk about them. Where we left off Until a few weeks ago, our gateways ran on a pretty simple system. We operate dozens of "gateway" servers around the world, whose sole purpose is to accept incoming WireGuard connections and connect them to the appropriate private networks. Any time you run flyctl and it needs to talk to a Fly Machine (to build a container, pop an SSH console, copy files, or proxy to a service you're running), it spawns or connects to a background agent process. The first time it runs, the agent generates a new WireGuard peer configuration from our GraphQL API. WireGuard peer configurations are very simple: just a public key and an address to connect to. Our API in turn takes that peer configuration and sends it to the appropriate gateway (say, ord, if you're near Chicago) via an RPC we send over ## Fly Kubernetes does more now DevFeed: [Fly Kubernetes does more now]() Original publisher: [Read original article]() Published: 2024-03-07T00:00:00Z Content type: article Language: en Sources: [The Fly Blog]() Topics: [Kubernetes](), [fly.io](), [Firecracker](), [k3s](), [Containers](), [networking](), [API](), [Prometheus]() Tags: [2](), [api](), [cdn](), [close-to-users](), [complexity](), [containers](), [deploy-app-servers](), [docker](), [elixir](), [firecracker](), [fly](), [fly-io](), [heroku-alternative](), [heroku-competitor](), [hosting](), [i](), [k3s](), [kubernetes](), [networking](), [postgresql-clusters](), [prometheus](), [servers]() ### AI overview Fly Kubernetes has moved from early access toward a closed beta as a managed Kubernetes service backed by Fly.io infrastructure. It handles Kubernetes control-plane operations while users deploy workloads. The article explains that Fly's design uses K3s and Virtual Kubelet, transforms containers into Firecracker microVMs, and connects pods through an internal WireGuard mesh. ### Source excerpt Eons ago, we announced we were working on Fly Kubernetes. It drummed up enough excitement to prove we were heading in the right direction. So, we got hard to work to get from barebones "early access" to a beta release. We'll be onboarding customers to the closed beta over the next few weeks. Email us at sales@fly.io and we'll hook you up. Fly Kubernetes is the "blessed path"™ to using Kubernetes backed by Fly.io infrastructure. Or, in simpler terms, it is our managed Kubernetes service. We take care of the complexity of operating the Kubernetes control plane, leaving you with the unfettered joy of deploying your Kubernetes workloads. If you love Fly.io and K8s, this product is for you. What even is a Kubernete? So how did this all come to be--and what even is a Kubernete? You can see more fun details in Introducing Fly Kubernetes. If you wade through all the YAML and CNCF projects, what's left is an API for declaring workloads and how it should be accessed. But that's not what people usually talk / groan about. It's everything else that comes along with adopting Kubernetes: a container runtime (CRI), networking between workloads (CNI) which leads to DNS (CoreDNS). Then you layer on Prometheus for metrics and whatever the logging daemon du jour is at the time. Now you get to debate which Ingress--strike that--Gateway API to deploy and if the next thing is anything to do with a Service Mess, then as they like to say where I live, "bless your heart". Finally, there's capacity planning. You've got to pick and choose where, how and what the Nodes will look like in order to configure and run the workloads. When we began thinking about what a Fly Kubernetes Service could look like, we started from first principles, as we do with most everything here. The best way we can describe it is the scene from Iron Man 2 when Tony Stark discovers a new element. As he's looking at the knowledge left behind by those that came before, he starts to imagine something entirely different and ## Fly Postgres, managed by Supabase DevFeed: [Fly Postgres, managed by Supabase]() Original publisher: [Read original article]() Author: Inian Parameshwaran; Paul Copplestone Published: 2023-12-15T07:00:00Z Content type: release Language: en Sources: [Supabase Blog]() Topics: [Databases](), [fly](), [fly.io](), [Supabase](), [Latency](), [Firecracker](), [API](), [GraphQL](), [observability](), [Replication]() Tags: [api](), [edge-computing](), [firecracker](), [fly](), [fly-io](), [graphql](), [latency](), [observability](), [postgres](), [recovery](), [release](), [replication](), [testing]() ### AI overview Supabase and Fly.io are launching Fly Postgres, a managed Postgres service deployed across Fly.io's edge locations. It includes extensions, pgvector support, connection pooling, backups, point-in-time recovery, branching, observability, migrations, a dashboard, and automatically generated REST and GraphQL APIs. The service is being progressively rolled out to testers. ### Source excerpt A managed Postgres offering developed by Supabase and Fly.io ## My Favorite Bits of OSDI/ATC'23 DevFeed: [My Favorite Bits of OSDI/ATC'23]() Original publisher: [Read original article]() Author: Marc Brooker Published: 2023-07-13T00:00:00Z Content type: opinion Language: en Sources: [Marc Brooker's Blog](), [Marc Brooker's Blog]() Topics: [Rust](), [systems](), [Firecracker](), [Memory Safety](), [Security](), [distributed-systems](), [Serverless]() Tags: [distributed-systems](), [firecracker](), [memory-safety](), [rust](), [security](), [serverless](), [systems]() ### AI overview An opinion piece about OSDI'23 and USENIX ATC'23 discusses the growing use of Rust in systems research, memory safety becoming standard practice, metastability in distributed systems, increased attention to security issues such as timing side-channels, and research on cloning and snapshot safety for serverless workloads. ### Source excerpt My Favorite Bits of OSDI/ATC'23 Talking to 3D people is cool again. This week brought USENIX ATC'23 and OSDI'23 together in Boston. While I've followed OSDI and ATC papers for years, it's the first time I've been to either of them (I've have been to NSDI a couple times). It was a really good time. In this post I'll cover a couple of my favorite papers1, and trends I noticed. Overall, it was great to meet a bunch of folks in person who I've only interacted with online, and nice to be back to in-person conferences. Thoughts and Trends When we presented the Firecracker paper at NSDI'20, several people said to me that they were worried about the fact we had chosen Rust, because it raised the risk that Firecracker wouldn't be useful once Rust was no longer in vogue. This year at OSDI, pretty much everybody I talked to was building in Rust. Obvious exceptions are folks doing AI/ML work (Python still seems big there), and folks looking to get into the mainline Linux kernel. I couldn't be more happy to see memory safety start to become the default practice in systems. Loads of folks were talking about emergent system properties like metastability. Unfortunately, not a lot of folks seem to be writing papers about it, or getting grants to work on it. I did talk to a couple folks with upcoming papers, and I really hope the hallway interest turns into more publications. Metastable failures in distributed systems and Metastable Failures in the Wild are some of the most important systems work of the last few years, in my opinion. There's a lot more to do here. I got a rough feeling that more papers were paying more attention to security issues than in years past. Subtle issues like timing side-channels especially. Another trend I like to see. Security and systems have always been linked, so this isn't new, but there does seem to be a reduction in completely security-naive work. Some of the Papers I Enjoyed The Most Take Out the Trache by Audrey Cheng et al2. This paper makes an a ## How to use multiple Docker registry mirrors DevFeed: [How to use multiple Docker registry mirrors]() Original publisher: [Read original article]() Author: Alex Ellis Published: 2023-06-08T13:27:06Z Content type: tutorial Language: en Sources: [Alex Ellis' Blog]() Topics: [Docker](), [docker registry](), [pull through cache](), [Self-hosted](), [GitHub Actions](), [Firecracker]() Tags: [buildx](), [cache](), [container](), [container-registry](), [docker](), [docker-registry](), [firecracker](), [github-actions](), [how-to](), [kubernetes](), [linux](), [mirror](), [registries](), [registry](), [self-hosted]() ### AI overview This tutorial explains why self-hosted GitHub Actions runners can hit Docker Hub's anonymous image pull limits and how a Docker registry configured as a pull-through cache can help. It covers configuring Docker and buildx to use multiple registry mirrors, including considerations for local HTTP and Internet-facing HTTPS setups. ### Source excerpt Why would you need to use a mirror for a container registry? And is there a way to use two or more? Find out from the actuated team. ## Firecracker: Lightweight Virtualization for Serverless Applications DevFeed: [Firecracker: Lightweight Virtualization for Serverless Applications]() Original publisher: [Read original article]() Author: Marc Brooker Published: 2020-02-19T00:00:00Z Content type: article Language: en Sources: [Marc Brooker's Blog](), [Marc Brooker's Blog]() Topics: [Firecracker](), [Serverless](), [virtualization](), [Amazon Web Services](), [AWS Lambda](), [Containers](), [Security](), [amazon]() Tags: [aws](), [aws-lambda](), [containers](), [deployment](), [firecracker](), [hardware](), [open-source](), [performance](), [production](), [scale](), [security](), [serverless](), [virtualization]() ### AI overview The article introduces Firecracker, an open source Virtual Machine Monitor optimized for multi-tenant serverless and container workloads. It explains how Firecracker addresses the tradeoff between virtualization security and container efficiency, and describes its deployment in AWS Lambda and Fargate at large production scale. ### Source excerpt Firecracker: Lightweight Virtualization for Serverless Applications Our second paper for NSDI'20. In 2018, we announced Firecracker, an open source VMM optimized for multi-tenant serverless and container workloads. We heard some interest from the research community, and in response wrote up our reasoning behind building Firecracker, and how its used inside AWS Lambda. That paper was accepted to NSDI'20, and is available here. Here's the abstract: Serverless containers and functions are widely used for deploying and managing software in the cloud. Their popularity is due to reduced cost of operations, improved utilization of hardware, and faster scaling than traditional deployment methods. The economics and scale of serverless applications demand that workloads from multiple customers run on the same hardware with minimal overhead, while preserving strong security and performance isolation. The traditional view is that there is a choice between virtualization with strong security and high overhead, and container technologies with weaker security and minimal overhead. This tradeoff is unacceptable to public infrastructure providers, who need both strong security and minimal overhead. To meet this need, we developed Fire-cracker, a new open source Virtual Machine Monitor (VMM)specialized for serverless workloads, but generally useful for containers, functions and other compute workloads within a reasonable set of constraints. We have deployed Firecracker in two publically available serverless compute services at Amazon Web Services (Lambda and Fargate), where it supports millions of production workloads, and trillions of requests per month. We describe how specializing for serverless in-formed the design of Firecracker, and what we learned from seamlessly migrating Lambda customers to Firecracker. Like any project the size of Firecracker, it was developed by a team of people from vision to execution. I played only a small role in that, but it's been great to work with ## What Firecracker open-source means for the serverless community DevFeed: [What Firecracker open-source means for the serverless community]() Original publisher: [Read original article]() Author: Jared Short Published: 2018-11-28T00:00:00Z Content type: opinion Language: en Sources: [Serverless Blog]() Topics: [Firecracker](), [Serverless](), [Amazon Web Services]() Tags: [aws](), [aws-lambda](), [cloud-computing](), [faas](), [firecracker](), [function-as-a-service](), [infrastructure-as-code](), [insights](), [open-source](), [serverless](), [serverless-architecture](), [serverless-framework]() ### AI overview The article discusses AWS open-sourcing Firecracker, the core technology behind Lambda and Fargate, and considers what this means for the serverless community. ### Source excerpt AWS open-sourced Firecracker, the Lambda and Fargate core. Here's what it means for the serverless community.