Using Lambda MicroVMs as GitHub Actions Runners

For most of it's existence, AWS Lambda remained a true serverless platform, perhaps even the one that defined what serverless means. You pay as long as your functions are doing some work, with a stunning 1 millisecond granularity. If there is nothing for your functions to do, there is nothing to pay for. There are some nuances around picking the right amount of memory, as well as figuring our the concurrency settings, cold starts and such - it's not magic, after all, but even with these nuances in mind, nothing comes as close to serverless compute as Lambda.

End of 2025, something curious started happening with Lambda. First, we got a way to run Lambda on EC2 instances. You'd think it would help to run Lambdas with any possible hardware, and yet Lambda Managed Instances do not support some instance types, including GPU instances. It could also be a great way to save some money and just pay regular EC2 prices - if not for a 15% compute management fee and $0,20 charge per million invocations. So far it feels like Lambda Manage Instances cover just a few extremely specific use-cases, and I do believe that there was a better way to cover this use-cases without mixing the whole EC2 (server-full) world into the beautiful serverless Lambda world.

Lambda MicroVMs, released in June 2026, go even further. It's not Lambda running on top of EC2 anymore, now it's Lambda itself running MicroVMs for you, backed by Firecracker - same runtime that powers AWS Fargate.

What is a MicroVM? In case of Lambda, it's a Firecracker VM, booted from an image, that is kind of a snapshot of your own Dockerfile, layered on top of Lambda's base Amazon Linux 2023 image, bundled with some hooks, basic networking configuration and a couple of other nice features. Lambda MicroVMs are quite different from regular Lambda functions, and were built with a specific use-case in mind: AI.

AI Agents require a platform, where they can run their code in a safe, isolated way, isolated down to an individual end-user request. Kubernetes tries to solve it with Agent Sandbox (and it's own spin at MicroVMs, with gVisor and Kata containers), CloudFlare offers temporary accounts just for AI agents, and everyone else is also trying to build some kind of layer, which AI Agents can use. Does all of this look like essentially a further evolution of scaling and isolating our containerized workloads, but pushed primarily under an AI Agents agenda? Maybe, but not like there is anything wrong with that.

I wonder, if cloud environments behind Claude Code's cloud are powered by Lambda MicroVMs since a while - and whether this whole new service (and I would consider Lambda MicroVMs a new service and not just a new feature) grew internally out of some kind of collaboration between AWS and Antrophic. What I know for sure, is that we now have a whole new way to run our workloads - with per-second billing granularity (worse, than Lambda's per-millisecond granularity, better than Fargate's mandatory minimum 60 seconds charge), 8 hours maximum runtime (a huge jump from Lambda's 15 minutes) and a simple way to put anything you want inside MicroVMs Image. As one example, you could put GitHub Actions Runner inside it.

Running GitHub Actions self-hosted runners inside Lambda MicroVMs

Thanks to Microsoft, there is a whole business model of offering GitHub customers custom GitHub Runners - in most cases, they are cheaper and more reliable than whatever GitHub gives you. You can run your self-hosted GitHub Runners on EC2, inside EKS, on CodeBuild - or, of course, anywhere outside AWS as well. But can you run GitHub Runners as Lambda MicroVMs? As it turns out, you can, and it's not that complicated.

To make this happen, you need two components:

1. Something to listen to GitHub Webhooks

2. Something to actually run the job

The first component can be as simple as a Lambda function exposed over Function URL. The second component can be a Lambda MicroVM, one VM per job, triggered by the first Lambda as a single-use just-in-time runner. To achieve this, you need some custom code for the first component, as well as a ready to use Lambda MicroVM Image, with things like GitHub Actions runner, Docker and others baked in.

In return, you get:

1. Max job length of 8 hours (instead of 6 hours offered by hosted GitHub Runners);

2. Pay per job, no ongoing costs at all;

3. Access to your VPC and in general running completely inside your AWS environment;

4. Extremely strong isolation, as each job gets it's own MV;

5. 16% lower costs, when comparing 2 vCPU runners on GitHub vs 2 vCPU / 4 GB RAM on Lambda;

6. Docker with Docker compose - you can build container images and run containers inside Lambda MicroVMs;

7. Fantastic scaling-out capabilities. Default (and adjustable) quota for total memory used by your VMs is 1024 GB, burstable 4 times of that, by default you can start 4 MicroVMs per second (also adjustable);

It comes with one downside - Lambda MicroVMs are ARM-only as of now.

If this sounds attractive, we've built a new Terraform module, that deploys this complete setup to your GitHub Organization (or just some repos within your organization) - dispatcher Lambda, Lambda MicroVM image and everything else is included: here it is. You only need to create your own GitHub App and pass the private key and couple of other variables, and you are all set to go. If it doesn't work like this, please open a GitHub Issue (or a PR)!

Does it make sense to run GitHub Actions Runner inside Lambda MicroVMs?

This project started as a quick idea and PoC, but the whole architecture was simple enough to go an extra mile and wrap it in a ready to use open source component. But does it actually make sense to use it?

It depends what you compare this to.

If you are using GitHub-provided Runners, then Lambda MicroVM GHA Runners can be a much cheaper and secure way to run your CI/CD jobs - and getting them up and running won't take more than an hour.

If you already have an optimized fleet of EC2 (Spot or with Savings Plans) Instances, then MicroVMs will be much more expensive.

If you are looking for a more official and integrated solution, you'd be probably better off using CodeBuild GitHub Actions Runners.

Official GitHub Actions Runners are probably the worst way to run GitHub Actions jobs, meaning the amount of options to run these runners elsewhere is significant. Now there is one more option - admittedly, an option that uses something created for AI Agents to do a way less fancier job of running a CI/CD job. But do AI Agents really need something that different from what we all have been building for our job execution systems, ephemeral environments systems, or just any proper clusters full of containers? In the end, it's containers (and VMs) all the way down.