RunR vs AWS Lambda
RunR is an open-source (MIT) serverless platform: functions, multi-file projects and containers on Knative, on Kubernetes clusters you operate. AWS Lambda is the serverless compute service of Amazon Web Services: functions deployed as .zip archives or container images run in an AWS Region and are invoked by requests and events.
Both run functions that scale to zero and react to events. Lambda is a managed service in AWS Regions; RunR is software you install on your own clusters.
Differences at a glance#
| RunR | AWS Lambda | |
|---|---|---|
| Where it runs | Your Kubernetes clusters (1.30 or newer), each connected as a region (Regions) | One AWS Region per function, across several Availability Zones there (resilience) |
| Who operates it | You: the control plane installs with Helm or Docker Compose (Production install) | AWS; Lambda Managed Instances run functions on EC2 instances in your account that Lambda manages (Managed Instances) |
| What you deploy | A single-file function, a multi-file project built in the cluster, any OCI image, or WebAssembly (Architecture, WebAssembly) | .zip archives for managed runtimes, or container images up to 10 GB uncompressed (deployment packages) |
| Isolation | runc, gVisor or Kata Containers per project type, set up per region (Kata Containers hypervisors) | Firecracker microVMs; Managed Instances use containers on EC2 Nitro instances (how Lambda works, Managed Instances) |
| Events | HTTP, schedules, queues, webhooks, topics, Kafka, NATS, RabbitMQ, MQTT, Postgres CDC, S3 and IMAP, with retries and dead letters (Triggers) | Event source mappings for DocumentDB, DynamoDB, Kinesis, Amazon MQ, Amazon MSK, self-managed Kafka and SQS (event source mappings) |
| Rollouts | Blue-green with a test URL; canary in steps that rolls back by itself on error rate or p95 latency (Deploy strategies) | An alias splits traffic between two versions; AWS SAM with CodeDeploy runs canary or linear deployments that roll back on CloudWatch alarms (alias routing, gradual deployments) |
| Workflows | Durable workflows built in: steps, retries, sleeps, events, child workflows; Python and TypeScript SDKs (Durable workflows) | Lambda durable functions run multi-step workflows for up to one year; Step Functions is a separate orchestration service (durable functions, Step Functions) |
| Several regions | Global projects: one host name, HA or proximity mode, failover between regions (Global projects) | Deployed per Region; AWS describes cross-Region failover with Route 53 (cross-Region failover); Web Functions have multi-Region endpoints with latency routing and no health-based failover (Web Functions endpoints) |
| Untrusted code | The Sandbox API: sandboxes under gVisor or Kata on your cluster, with exec, files, processes and warm pools (Sandbox API) | Lambda MicroVMs: Firecracker sandboxes that can be suspended and resumed (MicroVMs) |
| Trusted code | SBOMs, scans, cosign signatures, a policy gate and signed-image admission (Supply chain) | Code signing with AWS Signer (code signing) |
| Infrastructure as code | Terraform / OpenTofu provider brf-tech/runr, the runr CLI, a GitHub Action (Terraform provider) |
AWS SAM, AWS CDK, CloudFormation AWS::Lambda::Function, Terraform aws_lambda_function (SAM, Terraform) |
Lambda limits an invocation to 900 seconds and a function to 128 MB – 10,240 MB of memory (quotas). On RunR the longest request of a project is its region's request_timeout, 300 seconds by default and up to 3,600 (Regions), and the GPU nodes of your clusters serve GPU functions and containers (GPU workers).
When to choose which#
AWS Lambda fits when your data and events are already in AWS services, you want AWS to run the compute, and the event source mappings, IAM and the rest of AWS are what your functions work with.
RunR fits when code, data and logs must stay on infrastructure you operate (on premises, a private cloud, air-gapped regions), when you want the same platform on clusters at several providers, or when functions, long-running containers, GPU workloads and agent sandboxes should share one console, one API and one set of roles (Roles and permissions).
RunR documentation to read next#
- Production install and single-host install
- Triggers and Scaling
- Durable workflows and Sandbox API
- Global projects
- All comparisons
The statements about AWS Lambda come from the AWS documentation, read on 2026-11-03 and linked next to each one. AWS and AWS Lambda are trademarks of Amazon.com, Inc. or its affiliates. RunR is not affiliated with or endorsed by Amazon Web Services.