osls: a Serverless Framework v3 fork that stayed on AWS

A fork with the same configuration format and no hosted services

osls, short for Open Serverless, is an open-source command-line tool for deploying serverless applications on AWS. It uses familiar YAML in serverless.yml to define Lambda functions, event sources, IAM permissions and supporting CloudFormation resources. The point of the project is not a new format. osls v4 continues a project that began as a maintained fork of Serverless Framework v3, it is independent from upstream Serverless Framework v4, and it does not use the Serverless Dashboard, Console or licensing services. It remains compatible with most Serverless Framework v3 service configurations. For a team that already has a serverless.yml, the migration cost is therefore mostly about the CLI and the removed features rather than about rewriting the service definition, which is the single most important practical fact about this fork.

Installing it, and getting the command to resolve to osls

The requirement is a recent Node.js, and the project is explicit about which versions count. If you are replacing a global Serverless Framework installation, the documentation says to remove it first so that the serverless command resolves to osls, and then shows three commands.

npm uninstall -g serverless
npm install -g osls@4

osls --version

The uninstall step is not optional advice, it is a functional requirement. The package installs three command names, osls, sls and serverless, all pointing at the same bin/serverless.js entry, so a leftover global serverless install would win the name resolution and you would end up running the tool you meant to replace. The same bin file is also what makes the fork a drop-in for scripts and CI pipelines that already call serverless deploy, which is the most common way this kind of tool gets adopted in practice.

The v3 line still exists, and that is deliberate

The project keeps two supported lines. osls v4 is the current stable release, and the v3 line lives on a separate branch and continues to receive bug and security fixes. If you are coming from osls v3 or from Serverless Framework v3, the documentation points you at an upgrade guide, and it also says that v4 has breaking changes, which are documented in that same guide. This arrangement is the interesting part of the project's strategy. A fork that only shipped the new major version would leave existing users to discover the breakages themselves, whereas keeping the old branch patched means the upgrade is a decision you take on your own schedule rather than one forced on you by a dropped branch. The stated goal of the project is continuity for existing serverless projects, including Bref projects, so that they keep working over the long term.

What was removed, in the project's own list

The difference section is a list of removals, and reading it tells you who this fork is for. The documentation is focused on the current osls release and AWS usage, and documentation for non-AWS providers has been removed. Serverless Dashboard, Enterprise and Console features have been removed, and if you rely on those hosted upstream services you should use upstream Serverless Framework instead. Serverless Components support has been removed, because those projects are old and unmaintained. The Tencent Cloud integration from the upstream serverless CLI has been removed. Unused dependencies, broken auto-updating, post-install messages and the automatic use of a local serverless installation from node_modules have all been removed. The pattern is consistent: anything that required a server at a vendor, or that pointed at an abandoned ecosystem, is gone, and so are the rough edges in the command line behaviour.

What was kept, and what was fixed

The other side of the list is what makes the fork worth running. New AWS Lambda runtimes are kept up to date, which is the maintenance burden that matters for a tool whose whole job is deploying to AWS. Internal AWS calls use AWS SDK for JavaScript v3 in osls v4, including support for IAM Identity Center credentials, which is the credential path that organisations on the newer identity systems need. Known inherited dependency vulnerabilities have been fixed, which is the sort of thing a fork of a large project can do that the upstream project has no particular reason to prioritise. The package is published as an npm package only, with no standalone binary distribution, and the dependency list in the manifest shows the AWS SDK v3 clients for API Gateway in both versions, CloudFormation, CloudWatch and its logs, Cognito identity provider, ECR, EventBridge, IAM, Lambda, S3, SSM and SSO OIDC, plus STS and the credential providers.

The documentation is organised around AWS and around the migration

The documentation directory has its own index, and the entry points tell you what the project considers important. There is a setup page for installing osls and deploying a first service, a concepts page covering the core ideas behind services, functions and events, an upgrading to v4 page, and a full serverless.yml configuration reference. The reference sections each have their own index: guides for concepts, build and test, deploy and operate, and reference topics; a function events section for every supported AWS Lambda event source; a CLI reference for every osls command and its options; and a section on authoring plugins, where you can write your own commands, variables and configuration extensions. The plugin documentation is the one to notice. Serverless Framework plugins are a large existing ecosystem, and keeping them working is a substantial part of what compatibility with v3 configurations actually means in practice.

Who maintains it, and what it is for

The project status section is short and unusually clear about the intent. The repository was created and is maintained by the Bref maintainers and contributors, and the main goal is continuity for existing serverless projects, including Bref projects, so they keep working over the long term. No major new feature areas are planned, but community contributions are welcome for maintenance work such as supporting new AWS Lambda runtimes, adapting to AWS changes, fixing bugs and making small improvements. That is a project with a deliberately narrow scope, and the reasons are structural rather than a shortage of ambition. The hosted components of the upstream tool were a licensing and account dependency, the multi-provider support was a maintenance surface that AWS alone already fills, and the fork exists to keep a working tool for the projects that depend on it. The licence is MIT, the default branch is 4.x, and the releases are v4.4.0 on 2026-09-25, v4.3.1 on 2026-09-07 and v4.3.0 on 2026-09-06, with the last push to the repository on 2026-10-06.

Editorial conclusion

osls fits a team that already deploys with Serverless Framework v3, including Bref users, and wants the tool to keep working without an account on a hosted service, since the fork keeps the same serverless.yml format and the same three command names. It does not fit a team that uses Serverless Components, the Tencent Cloud integration, or the Dashboard and Enterprise features, because all of those have been removed, and it does not fit a team deploying to a non-AWS provider, since the documentation for other providers has been deleted. Before you switch, read the upgrade guide, because v4 has breaking changes relative to v3, and check the Node.js requirement, since osls needs a recent runtime and a global serverless install has to be removed first so the command resolves to the fork.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. oss-serverless/osls on GitHub
4. README
5. Releases