# functions-framework-dart: one Dart function, four places to run it

> The Functions Framework for Dart lets you write a function as a single annotated shelf handler and run the same code on your laptop, on Cloud Run, on App Engine and on Knative based platforms. It is a community supported project with no service level agreement, its own framework package was last published in 2023, and the newer google_cloud package is where the recent work has landed.

**GoogleCloudPlatform/functions-framework-dart** — FaaS (Function as a service) framework for writing portable Dart functions

- Repository: https://github.com/GoogleCloudPlatform/functions-framework-dart
- Website: https://pub.dev/packages/functions_framework
- Stars: 549 · Forks: 49
- Language: Dart
- License: Apache-2.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/googlecloudplatform-functions-framework-dart

## A community supported framework, stated plainly at the top

The Functions Framework for Dart is an open source FaaS framework for writing portable Dart functions, brought to you by the Google Dart and Cloud Functions teams. The status note at the top of the project documentation is unusually clear: this is a community supported project, there is no official level of support, and the code is not covered by any SLA or deprecation policy. The invitation is to start a discussion or open issues for bugs and feature requests.

That framing matters more than usual for a framework, because frameworks break in ways that applications do not. A function you deploy stays deployed even if the framework stops moving, but a framework upgrade can change the shape of every function in your codebase, and a project with no deprecation policy gives you no warning that a change is coming. The licensing, by contrast, is the simplest possible position: Apache 2.0, with the text in the LICENSE file and the licence link pointing at the copy inside the framework package.

The distribution is the ordinary Dart one. The package is published on pub.dev as functions_framework, and the repository is a mono-repo with a mono_repo.yaml at the top, holding the pubspec.yaml, the functions_framework/ package, the functions_framework_builder/ package, a google_cloud/ package, an integration_test/ directory, an examples/ tree, a docs/ directory with the quickstarts, a tool/ directory and an analysis_options.yaml. There is also an AUTHORS file and an .agent/ directory.

## The programming model: an annotated shelf handler

The whole programming model fits in one function. You write a Dart function that takes a shelf Request and returns a shelf Response, and you mark it with the CloudFunction annotation:

```dart
import 'package:functions_framework/functions_framework.dart';
import 'package:shelf/shelf.dart';

@CloudFunction()
Response function(Request request) => Response.ok('Hello, World!');
```

That is the example in the documentation, taken from examples/hello/lib/functions.dart, and the point of the framework is what comes after it: a request to the deployed URL returns Hello, World!, and you never write an HTTP server or any request handling logic. The annotation is what tells the framework's builder which function to wire up, and the handler signature is a plain shelf handler, so it is the same shape you would test with a shelf request in a unit test.

The feature list is short, which is a sign that the design is doing the work elsewhere. The framework invokes a function in response to a request, it automatically unmarshals events that conform to the CloudEvents specification, and it is portable between serverless platforms. The CloudEvents support is the part that is not obvious from the example: a function that receives an event rather than a plain HTTP request gets the event decoded for it, which matters for the platform event modes where a request arrives wrapped in an event envelope.

The examples directory shows the range of shapes the model covers, with directories for fullstack, hello, json, protobuf_firestore and raw_cloudevent. The last of those is the one to look at if you are dealing with CloudEvents, since it shows what happens when you want the raw event rather than the unmarshalled one.

## Four runtimes, and the gap at Google Cloud Functions

The portability claim is the reason the framework exists. The documentation lists the environments where the same function runs: your local development machine, Google Cloud Run, Google App Engine, and Knative based environments. The Functions Framework concept is the same across the family, so a function written against it is not tied to one hosting product.

The exception is stated with equal clarity. Google Cloud Functions does not currently provide an officially supported Dart language runtime, and the team says it is working to make running on Cloud Run as smooth and symmetric an experience as possible for Dart Functions Framework projects. The wording is careful, and it is worth reading carefully too: the target is Cloud Run, and Cloud Run is where the deployment story is being made smooth, while Cloud Functions, despite the name, is the one place where the language is not officially hosted.

For Knative based platforms, the appeal is the same one that attracts people to Knative generally. Your function is a container that answers HTTP requests, and a platform that speaks Knative can run it. The local development machine is the fourth target, and it is the one that determines how quickly you can iterate, because the same function runs unchanged in a container on your own hardware.

App Engine is on the list as well, so the framework covers the older generation of Google hosting alongside the newer serverless products. A project that has to run the same logic in more than one of these places is exactly the case the framework was written for.

## The quickstart: a Docker container that listens on 8080

The local quickstart is the Dart quickstart, and it runs the example in a container. You build the image from the example directory and run it:

```shell
$ cd examples/hello
$ docker build -t app .
...

$ docker run -it -p 8080:8080 --name demo --rm app
Listening on :8080
```

The port mapping publishes 8080 on the host, the container is named demo, and --rm means the container is removed when it stops, which is convenient for a throwaway local run. The listening message is the check that the framework started and bound the port.

From a second terminal, the request goes to the local port:

```shell
$ curl localhost:8080
Hello, World!
```

The same Hello, World! the deployed version returns, which is the point of the exercise: the output is identical, and the only difference between the local run and the deployed run is where the container lives. More quickstarts live in the docs/quickstarts directory, including the Cloud Run one, and the documentation page for the Dart quickstart is the one referenced from the repository.

The container path also explains the function_framework_builder package in the mono-repo. Building a function into a container that the platform can run, and wiring the annotated function into the request handler, is a build step rather than something you write by hand in each project.

## A mono-repo where the framework package froze and google_cloud kept moving

The release history is the most informative thing in the repository, and it shows a split.

The functions_framework package was published at v0.4.3+1 on 2023-08-13. The google_cloud package has two recent releases, v0.2.1-beta.1 on 2026-02-11 and v0.3.0 on 2026-02-15. So the framework package itself has not had a new published version in more than three years, while the google_cloud package, which provides the Cloud Functions compatible types and helpers, has seen two releases in the same week in February 2026.

The repository was last pushed on 2026-09-01 and is not archived, so the code is still being worked on even where the published artifacts lag. The practical reading is that most of the ongoing work is going into the google_cloud package and the integration story rather than into the framework's own API surface, which is at least consistent with a mature, stable API that does not need frequent releases.

The test badges in the project documentation show what is being checked: a Dart Unit CI workflow, a Dart Lint CI workflow and a Dart Conformance CI workflow. The conformance one is the interesting badge, because a conformance suite is the shared Functions Framework test suite used across language implementations, and passing it is the strongest available evidence that this Dart implementation behaves like the others rather than inventing its own semantics.

The contributors' guide, CONTRIBUTING.md, covers how to build and test changes and how to format the code, and analysis_options.yaml holds the lint configuration that the lint CI job enforces.

## Where this is the wrong tool, and what to check first

The failure cases follow from the same two facts the documentation puts first. If you deploy to Google Cloud Functions, there is no officially supported Dart runtime, so the framework cannot give you a supported deployment on that product. If your organisation requires a service level agreement, a defined support window, or a deprecation policy for the runtime layer, a project that states it has none of those is not a dependency you can put in that path.

There is a subtler failure case in the package split. The functions_framework package is the piece that gives you the annotation and the portable runtime, and it has not been republished since 2023. If you start a new project, pub will give you that version, and the recent work sits in a different package. Deciding which package your service should depend on is a decision you have to make explicitly rather than one that resolves itself.

For teams that do not use Dart at all, the honest comparison is with the other language implementations of the Functions Framework. The value here is not that Dart is special, it is that a Dart codebase gets a backend written in the same language with the same handler shape it can already unit test. If your service language is fixed by other reasons, or if your platform already standardises on one Functions Framework language, this argument does not apply.

Before you commit, three checks are worth making. Read the quickstart for the platform you will actually deploy to, since the local Docker path and the Cloud Run path are not identical documents. Look at the conformance CI badge to see whether the framework still passes the shared test suite. And look at the google_cloud package releases, because that is where the recent work is and it is likely to be where the API you need has been evolving.

## Conclusion

functions-framework-dart fits a Dart team that wants a backend written the same way as the rest of its Dart code, deployable to Cloud Run or a Knative platform without a rewrite, and the shelf based model keeps a function testable without a cloud in the loop. It is the wrong tool if you need a supported runtime, because Google Cloud Functions has no officially supported Dart runtime and the project itself is explicitly community supported with no SLA and no deprecation policy, and it is the wrong tool if you need an actively published framework package, since functions_framework was last published at v0.4.3+1 on 2023-08-13. Before you adopt it, read the quickstarts for the platform you deploy to, decide whether the google_cloud package or the framework package is the dependency you actually want, and check the conformance CI badge, since that tells you whether the framework still passes the shared Functions Framework test suite.

## FAQ

### What is the Functions Framework for Dart and who maintains it?

It is an open source FaaS framework for writing portable Dart functions, brought to you by the Google Dart and Cloud Functions teams. The project is explicitly community supported, with no official level of support, no SLA and no deprecation policy, and it is licensed under Apache 2.0 and published on pub.dev.

### How do I write a Dart function with the Functions Framework?

You write a handler that takes a shelf Request and returns a shelf Response and mark it with the CloudFunction annotation, for example a function returning Response.ok('Hello, World!'). The framework then invokes it in response to a request, so you do not write an HTTP server or request handling logic yourself.

### Where can I run a Dart function built with this framework?

The documentation lists your local development machine, Google Cloud Run, Google App Engine and Knative based environments, and it states that Google Cloud Functions does not currently provide an officially supported Dart language runtime, with the work aimed at making Cloud Run deployment smoother.

### How do I run the Dart functions framework example locally?

From the examples/hello directory, build the container with docker build -t app . and run it with docker run -it -p 8080:8080 --name demo --rm app, which prints Listening on :8080. A request to localhost:8080 from a second terminal then returns Hello, World!.

## Sources

- [GoogleCloudPlatform/functions-framework-dart on GitHub](https://github.com/GoogleCloudPlatform/functions-framework-dart)
- [License: Apache-2.0](https://github.com/GoogleCloudPlatform/functions-framework-dart/blob/main/LICENSE)
- [Project website](https://pub.dev/packages/functions_framework)
- [README](https://github.com/GoogleCloudPlatform/functions-framework-dart/blob/main/README.md)
- [Releases](https://github.com/GoogleCloudPlatform/functions-framework-dart/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/googlecloudplatform-functions-framework-dart