Dart Backend in 2026: What Flutter Teams Should Actually Use

Introduction

In 2024, I wrote about the state of Dart on the backend.

At the time, the conclusion was not great. There were interesting projects and a few serious attempts, but overall it felt early. A lot of things looked promising, but not many felt stable enough to actually build on long term.

If you look at the ecosystem today, it doesn’t look dramatically different. Most of the same tools are still around, and the general landscape feels familiar.

But under the surface, quite a bit changed.

Some projects died. Some improved quietly. And for the first time, it feels like parts of the ecosystem are starting to converge instead of everyone trying to build their own thing in isolation.

At the same time, one thing hasn’t changed.

A lot of Dart backend projects still don’t survive. They show up, get some traction, and disappear once the author moves on. Which is why I’m not even going to try to list everything that exists. That list is long and not very useful.

This is not that kind of article.

This is what actually matters if you’re building something today.

What stayed the same (and what didn’t)

I still stand by what I said in 2024.

Serverpod is the best choice for Flutter projects. DartFrog is an opinionated Shelf wrapper. Shelf is 10 years old and still killing it.

That hasn’t really changed.

Serverpod is still the only thing that feels like a real backend framework in Dart. You get structure, code generation, and a clear way to build things. More importantly, it’s not a one-person project, which in this ecosystem is a big deal. If you’re building a Flutter product and want something cohesive, this is still the default choice.

Shelf is the opposite end of the spectrum. Minimal, boring, and basically unchanged for a decade. It has boilerplate and lacks type safety, but it’s extremely predictable and well understood. That predictability matters more now than it used to, mostly because AI tools handle Shelf very well. You don’t get invented abstractions or broken suggestions. You get exactly what you expect, which makes it surprisingly practical.

DartFrog sits somewhere in between. It adds structure on top of Shelf without turning into a full framework. That positioning still makes sense. The interesting shift is that it’s now community-driven. In Dart-backend-land, that’s actually a positive signal. It means it didn’t disappear once things got hard.

The only real new piece here is Relic.

Relic comes out of the Serverpod ecosystem and addresses a lot of long-standing issues with Shelf. The structure is cleaner, request handling is more modern, and overall it feels like a more thought-out foundation.

Technically, I think it’s a LOT better than Shelf, but that doesn’t automatically make a difference. We are in the age of AI-enabled engineering, and Shelf has been around for long enough that AI pick up how to write code for it properly. It’s battle-tested and you get exactly what you write.

Serverless

This is where most of the actual movement happened, and also where most of the failures are.

Over the last couple of years, there were multiple attempts to make serverless Dart a real thing.

1. Celest was one of the more ambitious ones. Got accepted to YC (W24). It tried to create a proper platform around serverless Dart.
2. Globe went into a similar direction, but with more of a focus on automating deployments and an accompaying suite of services like cron jobs, AI and KV stores.
3. Dart edge tried interfacing edge functions from Supabase, Vercel and Cloudflare workers, but it was too hard to maintain and DX was really far off Flutter standards.
4. Dartblaze, my own project, was just an attempt to really bring serverless Dart on Firebase.

All of these projects were trying to solve the same problem: make serverless Dart possible, powerful, and painless.

And all of them ran into the same issues: sub-par developer experienced, lack of ecosystem support and most importantly: lack of willingness to pay for something like this. Yes, developers are not used to paying for infra’s development. They expect it to work and have a generous free tier.

This year, the Firebase team decided to answer our prayers → they started to work Dart Cloud Functions for Firebase.

Inveritase (company behind Globe, dart_edge and dart_firebase_admin package), are also a part of this effort.

They have made quite a bit of effort, as you can see in the official repo:

This is the first time serverless Dart feels like it might actually stick, not as a workaround, but as something officially supported.

Also, AWS Lambdas are still a valid option (as seen in my article). You can compile Dart, deploy it, and run it just fine. That hasn’t changed.

But there’s a difference between something being possible and something being natural.

Firebase will win this battle.

BaaS

If you’re building Flutter apps, this part ends up being more important than it seems at first. In practice, you’re often choosing an ecosystem before you choose a backend.

Right now, that choice is fairly clear.

Firebase is still the default. With Dart Cloud Functions coming in, it becomes even more compelling.

Supabase is a strong alternative. The developer experience is good and Flutter support is solid. But once you go beyond the basics, you’re relying on JavaScript or edge functions, which breaks the full Dart story (although you could just spin a Shelf server and it would work).

AWS Amplify is different. The Flutter support is strong, and the fact that it uses a pure Dart SDK actually matters. It’s not just a wrapper. And you get access to the full AWS ecosystem, which is a big advantage depending on your preferences.

Options like Appwrite or Pocketbase are still good, especially for smaller or self-hosted setups, but in most real-world scenarios the decision usually comes down to Firebase, Supabase, or Amplify.

How it all fits together

If you want a full-stack Dart setup, you will likely run a combination of framework and tools.

For predictable workloads, running Serverpod, Shelf, or Relic on GCP or AWS makes sense. You get control, stability, and a system you understand.

For bursty or unpredictable workloads, serverless fits better.

That’s where Dart Cloud Functions or Lambdas come in. Not instead of your backend, but alongside it.

A structured backend for core logic, and serverless for the parts that benefit from scaling independently.

In practice, that usually looks like this:

• GCP: Serverpod, Shelf, or Relic for the core, with Dart Cloud Functions handling spikes.
• AWS: the same backend choices, with Lambdas handling the unpredictable parts.

In cases where you don’t need serverless or the cloud, you can deploy to a VPS. Serverpod a community developed serverpod_vps package to help you get started, and for Shelf/DartFrog, you can read my article around deploying dockerized Dart containers.

The main reason to choose Dart as backend tool is because you use Flutter for the frontend, but this comes at a great disadvantage: lack of ecosystem support.

Dart as backend ecosystem is still very young compared to Node, Python, Java, Go or Rails. In those ecosystems, a lot of common problems are already solved. You plug things in and move on. With Dart, you still end up building more of that yourself.

Inveritase did make a great deal of effort with dart_edge and Globe’s runtime, but in the end, it was still not enough. All things considered, I think the Dart Cloud Functions support will bridge the gap and give you access to a wide array of GCP services, which should propel the ecosystem a lot further.

Conclusion

Dart on the backend is in a much better place than it was a couple of years ago, mostly because the pieces finally fit together.

You have a clear server-side story with Serverpod, Shelf, and Relic, and now a real serverless path with Firebase. That combination actually works.

The tradeoff is still the same.

The ecosystem is young. Compared to Node, Python, or Go, you will build more things yourself.

It makes sense if you’re already using Flutter and want one language across the stack. In that setup, it’s fast, simple, and now finally practical.

If you have found this useful, make sure to like and follow for more content like this. To know when the new articles are coming out, follow me on Twitter and LinkedIn.