serverless/examples: clone one folder, run serverless deploy, and own the resources it creates

Every folder is a service, and the root of the repo holds no code

serverless/examples is a catalogue, not a library. The root is mostly a long run of directories named after what they do, including aws-node-express-api/, aws-node-scheduled-cron/, aws-node-puppeteer/, aws-golang-auth-examples/, aws-java-simple-http-endpoint/ and aws-dotnet-rest-api-with-dynamodb/. Each directory is a self-contained Serverless Framework service, and each ships its own README.md with an explanation of the service and its use cases.

That layout is what makes the repository cheap to read and awkward to consume. You can skim dozens of service designs in an afternoon, since each folder has one job. None of it is something you install. The root package.json is named serverless-examples, sits at version 0.0.0 and is marked private, and the repository publishes no GitHub releases, so there is no version to depend on. Copying a folder out of the clone is the whole adoption path, and you inherit whatever the example assumes about your account.

serverless deploy is the first command and it targets a real account

Installation is one global package:

npm install -g serverless

After that, take an example and deploy it:

git clone https://github.com/serverless/examples
cd examples/folder-name
serverless deploy

Look at what the sequence leaves out. There is no step that starts a local stand-in for API Gateway, Lambda or DynamoDB. serverless deploy creates real resources in whichever cloud account your credentials point at, so even a first run leaves infrastructure behind for you to delete. If you need to stay offline, the root listing has folders whose names say so, such as aws-node-rest-api-with-dynamodb-and-offline/, and its README is the place to find out what that example expects.

npm run docs rewrites the README table you are reading

The README you browse is generated, and the file says so twice. Auto-generated markers bracket the table of contents and the example table, both annotated as generated with npm run docs, which runs a script called generate-readme.js:

"docs": "node generate-readme.js",
"check-docs": "node generate-readme.js && git diff --exit-code README.md examples.json"

Two consequences for anyone opening a pull request. Hand-editing the table of contents or the example rows is wasted work, because the next generator run overwrites the region between the markers. check-docs exists to catch exactly that mistake: it regenerates the files and then asks git whether README.md and examples.json differ from what is committed. Prose written outside the markers survives. A pull request that edits a row in the table does not, and it fails check-docs.

Node 24 is a floor for the tooling, not for the services

The root manifest ends with an engines block:

"engines": { "node": ">=24" }

That floor belongs to the repository tooling, generate-readme.js and validate.js, and not to anything you deploy. The examples name their own runtimes row by row in the generated table, where dotnet, golang, java, python and nodeJS all appear. One row describes a REST API with DynamoDB on .NET 10, another deploys a Node.js function as a container image with SnapStart enabled, and another bundles TypeScript handlers as ES modules with the built-in esbuild support. A reader on an older Node can copy any of them, but cannot run npm run docs or npm run validate, which means the README regeneration their own contribution would need is out of reach.

v4 is the default branch and every table link ends in /tree/v4/

Every link in the example table points at /tree/v4/, and v4 is the default branch. The clone command in the instructions passes no branch argument, so a fresh clone lands on v4 and every folder you open is the v4 version.

The folder names follow a convention worth copying instead of fighting. Cloud provider and runtime come first, aws-node-, aws-golang-, aws-java-, aws-dotnet-, and the service follows. Sorting the root by name therefore groups every Node.js service together, which is also how the Getting Started section points readers at four different starting points for a first HTTP endpoint: aws-node-simple-http-endpoint, aws-python-simple-http-endpoint, aws-java-simple-http-endpoint and aws-golang-simple-http-endpoint.

MIT in the manifest, no terms per example, and services you have to pay for

Licensing is stated once and loosely. package.json carries "license": "MIT", LICENSE.txt sits at the root, and no licence assertion appears in the repository metadata at all, so the file is the only place a grant is written down. Read LICENSE.txt before you copy an example into a product.

What the repository does not do is assign terms per example. Nothing in the root listing or the manifest says that one folder is under different terms than the rest. The example descriptions also mention Auth0 and AWS Cognito in the authorizer examples, and S3 and DynamoDB in several others. The code you copy carries the manifest's MIT, and the services it calls carry their own pricing and their own credentials. That split is the part to read before you paste a folder into something you have to operate.

The CLI template menu and a clone hand you different things

The Getting Started section offers two routes, and they are not equivalent. One is the Framework's own interactive template menu: run the serverless command and pick a starter from the list. The other is the clone, which hands you the maintainers' version of the same kind of service, with its README, its history, and whatever state that example is currently in.

Pick the menu when you want a clean service with no example-specific baggage attached. Pick the clone when you want to see how the people who maintain this repository structured the same problem, down to the folder naming convention and the runtime they chose.

Adding an example means a pull request judged on structure

The answer to new contributors is one sentence: submit a PR or open an issue. The table of contents also lists Adding example code and Adding a community example, and a Community Examples section sits above Contributing, so the repository expects both curated and community submissions in the same tree.

The repository's own scripts are npm run validate and npm run check-docs.

Editorial conclusion

Read this repository when you want a working Serverless Framework service to copy instead of writing one from an empty directory, and skip it when you need a package to depend on or a local stack that runs without an account. Before your first deploy, run npm run check-docs so your pull request does not carry a hand-edited table, and read LICENSE.txt, since package.json states MIT while the repository records no license assertion.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. serverless/examples on GitHub