Serverless Framework Alternatives in 2026

The Serverless Framework made AWS Lambda approachable by turning a short serverless.yml into a CloudFormation stack with functions, API Gateway routes and event sources. For years it was the default way to ship Lambda, and many teams still have dozens of services built on it.

Two things have changed since then. Serverless Framework V.4 requires a paid subscription for organizations over $2M in revenue, and apps that grew around it hit Lambda limits that a YAML file cannot fix, from 15-minute timeouts to connection limits on Postgres.

Reasons teams look for Serverless Framework alternatives:

• V.4, announced in late 2023, requires a paid subscription for organizations with more than $2M in annual revenue, and the CLI now requires a login or license key, a change that drew pushback from developers.
• Pricing is in credits per Service Instance, meaning each serverless.yml deployed to a stage, region and account, so many services across many stages add up, and V.3 is no longer maintained as of December 31, 2024.
• Everything is shaped as Lambda functions, which have a 15-minute maximum timeout and per-environment cold starts, so long-running work and steady traffic fit less well than in a container.
• Local development relies on plugins such as serverless-offline or on Dev Mode against deployed resources, and queues, buckets and databases are still raw CloudFormation in the resources section.

Serverless Framework alternatives at a glance

Encore: infrastructure from application code, deployed as containers

Encore combines the application code and the infrastructure that serverless.yml describes separately, so the endpoints, topics, cron jobs and databases are declared in TypeScript or Go where they are used. encore run starts them locally with your services, and a deploy provisions them in your own AWS or GCP account.

A common Serverless Framework service is an HTTP function that drops a message on SNS, with a second function subscribed through an SQS queue. In Encore the publishing side is an API endpoint and a Pub/Sub topic in one service:

import { api } from "encore.dev/api";
import { Topic } from "encore.dev/pubsub";

export interface InvoicePaid {
  invoiceId: string;
  customerId: string;
}

// SNS/SQS on AWS, Pub/Sub on GCP, a local broker under encore run.
export const invoicePaid = new Topic<InvoicePaid>("invoice-paid", {
  deliveryGuarantee: "at-least-once",
});

export const paid = api(
  { expose: true, method: "POST", path: "/billing/invoices/:invoiceId/paid" },
  async (req: InvoicePaid): Promise<{ queued: boolean }> => {
    await invoicePaid.publish(req);
    return { queued: true };
  },
);

The consumer is a subscription in a separate service, where concurrency and retries are set in code instead of in the event source mapping and the queue's redrive policy:

import { Subscription } from "encore.dev/pubsub";
import { invoicePaid } from "../billing/billing";

// A separate service that deploys and scales on its own. Retries back off,
// and messages that keep failing land in a dead-letter queue.
const _ = new Subscription(invoicePaid, "send-receipt", {
  handler: async ({ invoiceId, customerId }) => {
    // Keyed on invoiceId so a redelivery does not send a second receipt.
    console.log("sending receipt", invoiceId, "to", customerId);
  },
  maxConcurrency: 20,
  retryPolicy: { minBackoff: "1s", maxBackoff: "1m", maxRetries: 10 },
});

Under encore run, a request to POST /billing/invoices/inv_2/paid returns {"queued":true} and the subscriber in the other service logs the receipt, so the whole flow is tested on your machine rather than against a deployed stage. Scheduled functions become cron jobs that call an endpoint on a schedule, and they run in the cloud environments rather than locally, where you call the endpoint by hand. Since the topic and its consumer are ordinary code, an AI coding agent can add a new event and its handler in one change and run both locally.

Key features

• Services run as containers on ECS Fargate or EKS in AWS, as the AWS infrastructure docs describe, or on Cloud Run or GKE in GCP, so there is no 15-minute ceiling and no per-invocation cold start.
• Pub/Sub becomes SNS/SQS with dead-letter queues, Postgres databases become RDS, and buckets become S3.
• Encore provisions an IAM role for each service.
• Existing SNS topics, S3 buckets and RDS databases can be imported, so new services can work with resources a Serverless stack already created.

Good to know

Encore does not deploy Lambda functions, so it is a different runtime model rather than a new syntax for the same stack, and moving a service means porting the handlers to Encore endpoints and subscriptions. Teams usually start with one new service and leave existing Serverless Framework stacks running in the same account, and the migration guide for infrastructure-as-code users covers that path.

AWS SAM: the closest replacement for serverless.yml

AWS SAM

AWS SAM is AWS's open-source framework for serverless apps, a CloudFormation transform where a template.yaml describes functions, APIs and event sources in a format close to serverless.yml.

Transform: AWS::Serverless-2016-10-31
Resources:
  SendReceipt:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: .
      Runtime: nodejs24.x
      Handler: receipt.handler
      Events:
        InvoicePaid:
          Type: SQS
          Properties:
            Queue: !GetAtt InvoiceQueue.Arn
  InvoiceQueue:
    Type: AWS::SQS::Queue

Key features

• The SAM CLI is free, and sam local invoke and sam local start-api run functions in local containers.
• sam deploy --guided walks through the first deploy and saves the settings.
• Any CloudFormation resource can sit in the same template.

Good to know

SAM keeps the Lambda-first model and the CloudFormation deploys, so it solves the license question rather than the architecture one. Local runs cover the function code, while queues, databases and other resources are either mocked or reached in a deployed stack.

SST: TypeScript config with live Lambda development

SST defines resources in sst.config.ts through components for functions, APIs, queues, buckets, Postgres and frontend sites. Since v3 it deploys through Pulumi with Terraform providers instead of CloudFormation.

Key features

• sst dev deploys a stub function and proxies invocations to your machine, so code changes reload without a deploy.
• Components wrap common patterns, such as a queue with a subscriber or an API with routes.
• ECS containers are supported alongside Lambda, which helps with workloads that outgrow functions.

Good to know

SST is a common move for TypeScript teams on the Serverless Framework, but the infrastructure is still described separately from the application code, and the queues and databases used during sst dev are real resources in your account. The SST alternatives guide covers it in more depth.

AWS CDK: full control in a general-purpose language

AWS CDK

AWS CDK defines AWS resources as constructs in TypeScript, Python, Java, C# or Go and synthesizes them to CloudFormation, so a Serverless Framework stack can be rewritten as constructs for its functions, queues and API Gateway.

Key features

• Every AWS service is available, from low-level L1 constructs to higher-level patterns.
• Loops, functions and types from the host language replace YAML variables and plugins.
• cdk diff shows the changes before a deploy.

Good to know

CDK removes the license question and the plugin layer, but you take on writing and reviewing every resource, including IAM, and there is no local runtime for the stack. The AWS CDK alternatives and AWS CDK vs Terraform guides compare it further.

Terraform: one tool for Lambda and everything else

Terraform manages Lambda functions alongside the rest of a company's infrastructure in HCL, and community modules such as terraform-aws-modules/lambda/aws handle packaging the code and creating the function, role and log group.

Key features

• One workflow and state for Lambda, networking, databases and non-AWS providers.
• terraform plan shows changes before they are applied.
• A large registry of modules and providers.

Good to know

Terraform is a good fit when the platform team already runs it, but it was not built for application code, so packaging, versioning and local testing of functions are handled outside it, and Terraform has been under the Business Source License since 2023. The Terraform alternatives guide covers the options.

OpenTofu: Terraform under an open-source license

OpenTofu is the open-source fork of Terraform maintained under the Linux Foundation, and it works with the same HCL, providers and Lambda modules.

Key features

• MPL 2.0 license and community governance.
• Compatible with existing Terraform configurations and state.
• Additions such as client-side state encryption.

Good to know

OpenTofu answers the license concern on the Terraform side the way SAM does on the Serverless side, while the workflow stays the same, so Lambda packaging and local testing still sit outside the tool.

How to choose

• Encore if you are moving past Lambda-only services and want APIs, queues, cron jobs and databases defined in application code, running locally and deployed as containers in your own AWS or GCP account.
• AWS SAM for the closest replacement that keeps the same Lambda and CloudFormation model.
• SST for TypeScript teams that want to stay serverless with a faster dev loop.
• AWS CDK for full control over every AWS resource in a general-purpose language.
• Terraform or OpenTofu if the rest of your infrastructure already lives in HCL.

The license change only affects V.4 and later, so there is time to move service by service, starting with the ones that have outgrown Lambda's limits. The quickstart walks through a first Encore service.

Related guides

• SST alternatives
• AWS CDK alternatives
• Terraform alternatives
• What is serverless?
• Serverless functions explained
• AWS CDK vs Terraform