Serverless

Apache OpenWhisk6.8k★

Apache OpenWhisk is the elder statesman of open source serverless platforms. It powered IBM Cloud Functions for years, runs at Apache governance, and supports a wide range of runtimes: Node, Python, Go, Swift, PHP, Ruby, dotnet, Rust, Scala, Java, and Docker images. Version 2.0.0 shipped last spring, and the project recently migrated to Apache Pekko after Akka changed licenses. Still alive, still active. Deployment is the real question. You can run a Java standalone for local dev, or stand up a Kubernetes-native cluster for production. Most platform teams pick OpenFaaS or Knative for simpler operational stories; OpenWhisk is heavier, with more components (controller, invoker, Kafka, CouchDB) to manage. The reward is a mature, battle-tested platform. Solo developers: probably skip. The setup overhead doesn't pay off until you're running real production workloads. Small teams: evaluate OpenFaaS or Knative first; come here if those don't fit. Large teams running enterprise workloads who want the Apache Software Foundation backing and broad runtime support: OpenWhisk is worth the ops investment. The catch: more moving parts than the alternatives. Operating a production OpenWhisk cluster requires managing Kafka, CouchDB, and the controller/invoker split. The platform is excellent; the day-two operations are not trivial.

Nuclio5.7k★

Nuclio is the serverless platform built for data-heavy workloads. Where OpenFaaS and Knative target generic HTTP functions, Nuclio is tuned for real-time event processing: streaming ingest, ML inference, image and video pipelines, and anything that needs to push hundreds of thousands of records per second. Iguazio created it, and they claim 10-100x throughput over competing serverless engines for those workloads. Apache 2.0, runs on Docker, Kubernetes, or edge devices, with first-class GPU support and scale-to-zero. Triggers cover HTTP, Kafka, Kinesis, NATS, S3 events, and the data integrations the ML world cares about. The Jupyter and Kubeflow integrations are first-class; data scientists deploy functions from notebooks without writing Kubernetes manifests. Solo data scientists and small ML teams: this is genuinely useful. It's the closest open source thing to a managed Modal or Replicate for serverless inference. Large teams with serious data science operations: pair it with MLRun and Kubeflow for a complete MLOps stack. Teams that just want HTTP functions: use OpenFaaS or Knative, you don't need Nuclio's complexity. The catch: this is open core. Nuclio is the open source layer; the production-grade enterprise experience lives inside Iguazio's commercial Data Science Platform. The OSS version is real and complete enough to run in production, but the most polished operations are upsold.

serverless-step-functions1.0k★

This plugin lets you define AWS Step Functions directly in your serverless.yml. Instead of going to the AWS console and clicking through the Step Functions designer, you write the state machine definition alongside your Lambda code and deploy it all together. The plugin is free and open source. It doesn't have its own license file clearly posted, but it's a community plugin for the Serverless Framework ecosystem. There's nothing to host. It's a Serverless Framework plugin: `npm install` it, add it to your config, and it deploys Step Functions state machines to AWS when you run `serverless deploy`. The ops burden is trivial because AWS manages the actual Step Functions infrastructure. Solo developers: if you're already on Serverless Framework and need Step Functions, this saves you from writing CloudFormation by hand. Small teams: same story: it keeps your workflow definitions in version control next to your functions. Beyond that: at scale, you might prefer CDK or Terraform for more control. The catch: this is tightly coupled to the Serverless Framework. If you move to CDK, SAM, or SST for your infrastructure, this plugin doesn't come with you. Also, development has slowed; the last meaningful updates were a while back. It works, but don't expect rapid feature additions.

edge-runtime943★

Supabase Edge Runtime is the engine that powers Supabase Edge Functions. It lets you run TypeScript/JavaScript functions at the edge using Deno. If you're building on Supabase and need serverless functions that respond fast from locations close to your users, this is what runs them under the hood. Free and open source under MIT. You can self-host it to run Deno-based edge functions on your own infrastructure. It handles request routing, worker isolation, and memory management for function execution. As part of the Supabase platform, you get 500K function invocations/month free on their hosted service. Beyond that, it's $2 per million invocations on the Pro plan ($25/mo base). Supabase users: use Edge Functions through the platform, the free tier is generous. Non-Supabase users: look at Deno Deploy or Cloudflare Workers instead. The catch: this is a specialized runtime, not a general-purpose serverless platform. It's tightly coupled to the Supabase ecosystem. If you're not using Supabase, you'd be better off with Deno Deploy directly, Cloudflare Workers, or Vercel Edge Functions. Self-hosting it standalone is possible but there's limited documentation for that use case.

functions-framework-dart547★

This is the framework that makes it work. It gives you a local development server and the scaffolding to write HTTP and CloudEvent handlers that deploy directly to Cloud Functions or Cloud Run. Apache 2.0, Google-maintained. It's a thin layer. You write a Dart function, annotate it, and the framework handles the HTTP server, request parsing, and function routing. Works with the Dart package ecosystem via pub.dev. Fully free. No paid tier exists. It's a framework, not a service. You pay Google Cloud for compute when you deploy, but the framework itself costs nothing. Solo Dart developers experimenting with serverless: useful if you're committed to Dart on the backend. Small teams: only makes sense if your whole stack is Dart (Flutter front + Dart backend). Larger teams: almost certainly using Node, Python, or Go for Cloud Functions already. The catch: the Dart serverless ecosystem is tiny, and zero velocity tells you adoption is niche. If your function needs packages that don't exist in Dart, you're stuck. Node.js or Python Cloud Functions have 100x the community support.