Website • Documentation • X / Twitter • Community Slack • Forum The Serverless Framework – Makes it easy to use AWS Lambda and other managed cloud services to build applications that auto-scale, cost nothing when idle, and result in radically low maintenance. The Serverless Framework is a command-line tool with approachable YAML syntax to deploy both your code and cloud infrastructure needed to ma
Tools
Tools
No tool list yet. Remote servers get one after the first health check.
⚡ Serverless Framework – Effortlessly build apps that auto-scale, incur zero costs when idle, and require minimal maintenance using AWS Lambda and other managed cloud services.
Copy the stdio config for Cursor, Claude Desktop, Claude Code, or VS Code on this page. It uses the publisher's install, not a PlugMCP proxy.
Does Serverless need an API key?
No required environment variable is listed on this record.
What transport does Serverless use?
Serverless runs locally over stdio.
When was Serverless last checked?
Last checked 2026-11-10. Website • Documentation • X / Twitter • Community Slack • Forum The Serverless Framework – Makes it easy to use AWS Lambda and other managed cloud services to build applications that auto-scale, cost nothing when idle, and result in radically low maintenance. The Serverless Framework is a command-line tool with approachable YAML syntax to deploy both your code and cloud infrastructure needed to ma
From the publisher
Documentation
The Serverless Framework – Makes it easy to use AWS Lambda and other managed cloud services to build applications that auto-scale, cost nothing when idle, and result in radically low maintenance.
The Serverless Framework is a command-line tool with approachable YAML syntax to deploy both your code and cloud infrastructure needed to make tons of serverless application use-cases, like APIs, front-ends, data pipelines and scheduled tasks. It's a multi-language framework that supports Node.js, Typescript, Python, Go, Java, and more. It's also completely extensible via over 1,000 plugins which add more serverless use-cases and workflows to the Framework.
October 2026 – V.4 continues to feature significant updates. Review them all below. Recent releases added Web Apps on AWS Lambda Web Functions, MCP server hosting on AWS Lambda, a rebuilt Dev Mode, built-in support for AI coding agents, Sandboxes (isolated, ephemeral compute on AWS Lambda), native Amazon Bedrock AgentCore support, Managed Instances, Durable Functions, and built-in AWS Login & SSO. As always, we are more excited about the serverless future than ever.
Key features
01. Sandboxes – Deploy isolated, ephemeral compute environments on AWS Lambda — ideal for untrusted or per-session workloads such as AI agents and code execution. .
02. AWS Login & SSO – Set up AWS credentials via browser-based flows with and .
03. Deployment Diffs – Preview how a deployment will change your live AWS CloudFormation stack before deploying with .
04. Reconcile Command – Keep usage records in sync with your AWS accounts when stacks are removed outside the CLI, via .
05. Managed instances – Native support for EC2-backed Lambda execution to enable higher throughput, predictable capacity, and long-running workloads.
06. Durable functions – Built-in support for durable, stateful workflows and long-running orchestrations.
Here's a list of everything that's new in V.4, so far:
Web Apps – Run Express, Fastify, Hono, Next.js and other Node.js HTTP servers on AWS Lambda Web Functions. Define a server under the top-level webApps block and serverless deploy packages it, creates the web function and its HTTPS endpoint, and prints the URL. Your code listens on process.env.PORT as it does locally — no handler to export and no adapter to install. Custom domains are served through Amazon CloudFront. More info here.
MCP Server Hosting – Deploy MCP servers written with the official MCP TypeScript SDK to AWS Lambda behind API Gateway with response streaming, via the mcp section in serverless.yml. More info here.
AI Coding Agent Support – serverless agent setup installs the bundled Agent Skills that teach Claude Code, Codex, Cursor and other agents to work with the Framework, and the serverless agent commands give agents structured access to your service. When a command runs under a detected AI coding agent, the CLI never opens a prompt and shows progress as plain lines.
Sandboxes – Deploy isolated, ephemeral compute environments on AWS Lambda — ideal for untrusted or per-session workloads such as AI agents and code execution. More info here.
Amazon Bedrock AgentCore Support – Define AI agents, memory, tools, gateways, browsers, and code interpreters directly in serverless.yml via the ai property, and manage them with the serverless agent commands. More info here.
Deployment Diffs – Preview how a deployment will change your live AWS CloudFormation stack before deploying with serverless diff.
Reconcile Command – Keep usage records in sync with your AWS accounts when stacks are removed outside the CLI, via serverless reconcile.
Managed instances – Native support for EC2-backed Lambda execution to enable higher throughput, predictable capacity, and long-running workloads.
Durable functions – Built-in support for durable, stateful workflows and long-running orchestrations.
Lambda tenant isolation mode: Use tenant isolation mode to create distinct Lambda compute environments per tenant to help reduce noisy neighbor effects and isolate high-traffic customers more cleanly.
HTTP response streaming: Stream logs, long-running reports, partial responses, or AI LLM responses from Lambda with API Gateway HTTP APIs.
Per-function IAM roles: Add per-function IAM policies or switch the entire service to use per-function policies.
Built-in plugins: Popular community plugins are now first-class, built-in features of the framework, including Python requirements, AppSync, Prune, API Gateway Service Proxy, and more.
Improved Custom Domain Support: You no longer need an external plugin to automatically configure custom domains and SSL certificates for your APIs and more. It's now built into the Serverless Framework CLI.
Introducing Serverless MCP: Built for Cursor, Windsurf, and other AI-powered IDEs, it auto-detects cloud resources from your code, fetching logs, state, and config from AWS, enabling you to debug serverless apps directly in your IDE — no AWS console visit needed! Supports Serverless Framework, Cloudformation, and more.
Support for AWS SAM, AWS CloudFormation, & Traditional Serverless Framework Projects: Now, you can use one tool to deploy all three of these IaC project files. More info here
Native TypeScript Support: You can now use .ts handlers in your AWS Lambda functions in serverless.yml and have them build automatically upon deploy. ESBuild is now included in the Framework which makes this possible. More info here.
The AWS AI Stack: V.4 is optimized for the AWS AI Stack. Deploy a full-stack, serverless, boilerplate for AI applications on AWS, featuring LLMs via Amazon Bedrock and much more.
New Dev Mode: Run serverless dev and your deployed stage's real traffic — API requests, queue messages, direct invokes — runs the code in your working copy, with the function's own environment and IAM role, without a deployment. serverless dev --detach runs the session in the background for scripts and AI coding agents, controlled with dev status, dev wait, dev stop, dev requests and dev replay. More info here.
Lambda Self-Managed Code Storage: Set provider.deploymentBucket.codeStorageMode: reference to have Lambda run function and layer code directly from your deployment bucket. More info here.
Provisioned Mode for Event Sources: The provisionedPollers property enables AWS Lambda's provisioned mode for sqs, kafka and msk events.
Runtime Deprecation Warnings:package and deploy warn when a function uses a runtime past its AWS deprecation date, and say when Lambda stops allowing new functions and updates on it.
Latest Runtime Support: Support for Node.js 24 (nodejs24.x), Python 3.14 (python3.14), Java 25 (java25), Ruby 4.0 (ruby4.0), .NET 10 (dotnet10) and the Amazon Linux 2023 Java runtimes (java8.al2023, java11.al2023, java17.al2023) on AWS Lambda, plus the public-preview nodejs26.x and python3.15.
Latest Region Support: Support for all major regions, including the newly announced ap-southeast-6 in New Zealand.
New Stages Property: Easily organize stage-specific config via stages and set default config to fallback to.
Improved Compose Experience: Serverless Compose now has a beautiful new CLI experience that better demonstrates what is being deployed. Services reference each other's outputs with the ${service:<service>.<Output>} resolver, including services deployed to a different stage, and --service accepts a comma-separated list to run a command on a subset of services. More info here.
AWS Partition Variable:${aws:partition} resolves to the AWS partition for the deployment region, such as aws, aws-cn or aws-us-gov, making ARNs portable across partitions. More info here.
New Terraform & Vault Integrations: Pull state outputs from several Terraform state storage solutions, and secrets from Vault. Terraform DocsVault Docs
Advanced Logging Controls for AWS Lambda: Capture Logs in JSON, increased log granularity, and setting a custom Log Group. Here is the AWS article. Here is the YAML implementation
Axiom Integration: Integrate with Axiom's observability solution for a powerful logging, metrics and traces experience, at 3X less than AWS cloudwatch.
AWS SSO: Environment variables, especially ones set by AWS SSO, are prioritized. The Framework and Dashboard no longer interfere with these.
Automatic Updates: These happen by default now. Though, you will be able to control the level of updates you're open to.
Improved Onboarding & Set-Up: The serverless command has been re-written to be more helpful when setting up a new or existing project.
Updated Custom Resource Handlers: All custom resource handlers now use a current Node.js runtime (nodejs24.x).
Deprecation Of Non-AWS Providers: Other cloud providers have been deprecated. V.4 focuses on delivering the best experience on AWS.
Breaking Changes
We're seeking to avoid breaking changes for the "aws" Provider. However, there are a few large things that are changing to be aware of:
The V.4 License is changing. See the section below for more information on this.
Authentication is required within the CLI.
Non-AWS Providers have been deprecated. We will be introducing new ways in V.4 to use other cloud infrastructure vendors.
If you stumble upon additional breaking changes, please create an issue. To learn more about what's different and potential breaking changes, please see our Upgrading to Serverless Framework V4 Documentation.
License Changes in V.4
Please note, the structure and licensing of the V.4 repository differ from the V.4 npm module. The npm module contains some proprietary licensed software, as V.4 transitions to a common SaaS product, as previously announced. The original Serverless Framework source code and more will continue to remain MIT license software, and the repository is structured to clearly distinguish between proprietary and open-source components — the MIT-licensed code carries its own LICENSE file in packages/serverless, while the repository root LICENSE covers the proprietary components.
Build More, Manage Less: Innovate faster by spending less time on infrastructure management.
Maximum Versatility: Tackle diverse serverless use cases, from APIs and scheduled tasks to web sockets and data pipelines.
Automated Deployment: Streamline development with code and infrastructure deployment handled together.
Local Development: Route events from AWS to your local AWS Lambda code to develop faster without having to deploy every change.
Ease of Use: Deploy complex applications without deep cloud infrastructure expertise, thanks to simple YAML configuration.
Language Agnostic: Build in your preferred language – Node.js, Python, Java, Go, C#, Ruby, Swift, Kotlin, PHP, Scala, or F#.
Complete Lifecycle Management: Develop, deploy, monitor, update, and troubleshoot serverless applications with ease.
Scalable Organization: Structure large projects and teams efficiently by breaking down large apps into Services to work on individually or together via Serverless Compose.
Effortless Environments: Seamlessly manage development, staging, and production environments.
Customization Ready: Extend and modify the Framework's functionality with a rich plugin ecosystem.
Vibrant Community: Get support and connect with a passionate community of Serverless developers.
Quick Start
Here's how to install the Serverless Framework, set up a project and deploy it to Amazon Web Services on serverless infrastructure like AWS Lambda, AWS DynamoDB, AWS S3 and more.
Install the Serverless Framework via NPM
First, you must have the Node.js runtime installed, version 18.17.0 or greater, then you can install the Serverless Framework via NPM.
Open your CLI and run the command below to install the Serverless Framework globally.
npm i serverless -g
Run serverless to verify your installation is working, and show the current version.
Update Serverless Framework
As of version 4, the Serverless Framework automatically updates itself and performs a check to do so every 24 hours.
You can force an update by running this command:
serverless update
Or, you can set this environment variable:
SERVERLESS_FRAMEWORK_FORCE_UPDATE=true
The serverless Command
The Serverless Framework ships with a serverless command that walks you through getting a project created and deployed onto AWS. It helps with downloading a Template, setting up AWS Credentials, setting up the Serverless Framework Dashboard, and more, while explaining each concept along the way.
This guide will also walk you through getting started with the Serverless Framework, but please note, simply typing the serverless command may be the superior experience.
serverless
Create A Service
The primary concept for a project in the Serverless Framework is known as a "Service", and its declared by a serverless.yml file, which contains simplified syntax for deploying cloud infrastructure, such as AWS Lambda functions, infrastructure that triggers those functions with events, and additional infrastructure your AWS Lambda functions may need for various use-cases (e.g. AWS DynamoDB database tables, AWS S3 storage buckets, AWS API Gateways for recieving HTTP requests and forwarding them to AWS Lambda).
A Service can either be an entire application, logic for a specific domain (e.g. "blog", "users", "products"), or a microservice handling one task. You decide how to organize your project. Generally, we recommend starting with a monolithic approach to everything to reduce complexity, until breaking up logic is absolutely necessary.
To create and fully set up a Serverless Framework Service, use the serverless command, which offers an interactive set-up workflow.
serverless
This will show you several Templates. Choose one that fits the language and use-case you want.
Serverless ϟ Framework
Welcome to Serverless Framework V.4
Create a new project by selecting a Template to generate scaffolding for a specific use-case.
? Select A Template: …
❯ AWS / Node.js / HTTP API
AWS / Node.js / Express API
AWS / Node.js / Express API with DynamoDB
AWS / Node.js / Scheduled Task
AWS / Node.js / Simple Function
AWS / Python / HTTP API
AWS / Python / Flask API
AWS / Python / Flask API with DynamoDB
AWS / Python / Scheduled Task
AWS / Python / Simple Function
(Scroll for more)
After selecting a Service Template, its files will be downloaded and you will have the opportunity to give your Service a name.
? Name Your Service: ›
Please use only lowercase letters, numbers and hyphens. Also, keep Service names short, since they are added into the name of each cloud resource the Serverless Framework creates, and some cloud resources have character length restrictions in their names.
As of Serverless Framework V.4, if you are using the serverless command to set up a Service, it will eventually ask you to log in.
If you need to log in outside of that, run serverless login.
Logging in will redirect you to the Serverless Framework Dashboard within your browser. After registering or logging in, go back to your CLI and you will be signed in.
Please note, you can get up and running with the Serverless Framework CLI and Dashboard for free, and the CLI will always be free for small orgs and indiehackers. For more information on pricing, check out our pricing page.
Creating An App
The "App" concept is a parent container for one or many "Services" which you can optionally set via the app property in your serverless.yml. Setting an app also enables Serverless Framework Dashboard features for that Service, like tracking your Services and their deployments in Serverless Framework Dashboard, enabling sharing outputs between them, sharing secrets between them, and enabling metrics, traces and logs.
If you are using the serverless onboarding command, it will help you set up an app and add it to your Service. You can use the serverless command to create an App on an existing Service as well, or create an App in the Dashboard.
❯ Create A New App
ecommerce
blog
acmeinc
Skip Adding An App
The app can also be set manually in serverless.yml via the app property:
service: my-service
app: my-app
If you don't want to use the Serverless Framework Dashboard's features, simply don't add an app property. Apps are not required.
Setting Up AWS Credentials
To deploy cloud infrastructure to AWS, you must give the Serverless Framework access to your AWS credentials.
Running the Serverless Framework's serverless command in a new or existing Service will help identify if AWS credentials have been set correctly or if they are expired, or help you set them up from scratch.
No valid AWS Credentials were found in your environment variables or on your machine. Serverless Framework needs these to access your AWS account and deploy resources to it. Choose an option below to set up AWS Credentials.
❯ Sign in with AWS Console (Recommended)
Save AWS Credentials in a Local Profile
Skip & Set Later (AWS SSO, ENV Vars)
We recommend signing in with the AWS Console: it opens your browser, and once you sign in, the Framework saves short-term credentials to an AWS profile on your machine, so no long-term access keys are stored. You can run the same flow at any time with serverless login aws.
If you signed in to the Serverless Framework Dashboard, the list also offers Create AWS IAM Role, which stores an AWS IAM Role in the Dashboard so credentials stay centralized across your team instead of on each teammate's machine.
If you are using AWS SSO, you can run serverless login aws sso to sign in via your browser, or simply paste your temporary SSO credentials within the terminal as environment variables.
To learn more about setting up your AWS Credentials, read this guide.
Deploy A Service
After you've used the serverless command to set up everything, it's time to deploy your Service to AWS.
Make sure your terminal session is within the directory that contains your serverless.yml file. If you just created a Service, don't forget to cd into it.
cd [your-new-service-name]
Deploying will create/update cloud infrastructure and code on AWS, all at the same time.
Many Serverless Framework and serverless developers generally choose to develop on the cloud, since it matches reality (i.e. your production environment), and emulating Lambda and other infrastructure dependencies locally can be complex.
In Serverless Framework V.4, we've created a hybrid approach to development, to help developers develop rapidly with the accuracy of the real cloud environment. This is the new dev command:
serverless dev
When you run this command, Dev Mode attaches the Node.js and Python functions of your deployed stage to your machine in seconds, with no deployment.
From then on, real invocations of those functions — API requests, queue messages, direct invokes — run the code on your machine, with the function's own environment and IAM role, and the result goes back to the caller. Your edits apply on the next invocation.
Logs and errors from your code show in your terminal dev session.
Press Ctrl+C to end the session: Dev Mode restores your functions to their deployed configuration.
Please note, dev is only designed for development or personal stages/environments and should not be run in production or any stage where a high volume of events are being processed. Dev Mode refuses the prod and production stages.
To invoke your AWS Lambda function on the cloud, you can find URLs for your functions w/ API endpoints in the serverless deploy output, or retrieve them via serverless info. If your functions do not have API endpoints, you can use the invoke command, like this:
More details on the invoke command can be found here.
Deploy Functions
To deploy code changes quickly, you can skip the serverless deploy command which is much slower since it triggers a full AWS CloudFormation update, and deploy only code and configuration changes to a specific AWS Lambda function.
To deploy code and configuration changes to individual AWS Lambda functions in seconds, use the deploy function command, with -f [function name in serverless.yml] set to the function you want to deploy.
serverless deploy function -f my-api
More details on the deploy function command can be found here.
Streaming Logs
You can use Serverless Framework to stream logs from AWS Cloudwatch directly to your terminal. Use the sls logs command in a separate terminal window:
sls logs -f [Function name in serverless.yml] -t
Target a specific function via the -f option and enable tailing (i.e. streaming) via the -t option.
Full Local Development
Many Serverless Framework users choose to emulate their entire serverless architecture locally. Please note, emulating AWS Lambda and other cloud services is never accurate and the process can be complex, especially as your project and teammates grow. As of V.4, we highly recommend using the new dev mode with personal stages.
If you do choose to develop locally, we recommend the following workflow...
Use the invoke local command to invoke your function locally:
sls invoke local -f my-api
You can also pass data to this local invocation via a variety of ways. Here's one of them:
sls invoke local --function functionName --data '{"a":"bar"}'
More details on the invoke local command can be found here
Serverless Framework also has a great plugin that allows you to run a server locally and emulate AWS API Gateway. This is the serverless-offline plugin.
A big benefit of Serverless Framework is within its Plugin ecosystem.
Plugins extend or overwrite the Serverless Framework, giving it new use-cases or capabilites, and there are hundreds of them.
Note that some formerly popular plugins are no longer needed — their functionality is now built into the framework, including Python requirements, custom domains, AppSync, Prune, and API Gateway Service Proxy.
Some of the most common Plugins are:
Serverless Offline - Emulate AWS Lambda and API Gateway locally when developing your Serverless project.
Using Serverless Framework Compose requires a serverless-compose.yml file. In it, you specify which Services you wish to deploy. You can also share data from one Service to another, which also creates a deployment order.
The value will be passed to service-bas a parameter named queueUrl. Parameters can be referenced in Serverless Framework configuration via the ${param:xxx} syntax:
# service-b/serverless.yml
provider:
...
environment:
# Here we inject the queue URL as a Lambda environment variable
SERVICE_A_QUEUE_URL: ${param:queueUrl}
More details on Serverless Framework Compose can be found here.
Remove Your Service
If you want to delete your service, run remove. This will delete all the AWS resources created by your project and ensure that you don't incur any unexpected charges. It will also remove the service from Serverless Dashboard.
sls remove
More details on the remove command can be found here.
What's Next
Here are some helpful resources for continuing with the Serverless Framework:
We take security seriously. If you discover a security issue, please responsibly disclose it by contacting us at [email protected]. Please do not publicly disclose vulnerabilities until we have addressed them.
