Serverpod: a Dart backend for Flutter apps, with code generation and a built-in ORM

What Serverpod solves for Flutter teams

A Flutter app needs a server, and the usual path is to pick a general purpose backend, then write the API contract twice: once on the server and once in Dart on the client. Serverpod's premise is that both sides are Dart, so the contract can be generated. The README states that it lets you write your server-side code in Dart, automatically generate your APIs, and hook up your database with minimal effort. The intended audience is the Flutter community specifically, not Dart developers in general and certainly not teams working in another language. The README also claims every design decision aims to minimize the amount of code you need to write, which is the kind of statement a framework makes about itself; the concrete version of that claim is code generation, covered below. Where Serverpod goes beyond a bare HTTP router is that it bundles the chores that usually pull in separate services: migrations, caching, file uploads, authentication, scheduling, health checks and deployment scripts. Whether that bundling is a benefit or a lock-in depends on how much of it you would otherwise assemble yourself.

How code generation and the ORM fit together

The mechanism the README describes is analysis of your server code to produce model and client-side code. Calling a remote endpoint is, in its words, as easy as making a local method call. That is the central design choice: the endpoint signature is the source of truth, and the Dart client is derived from it rather than maintained by hand. The ORM follows the same philosophy. Queries use native Dart types with null-safety, and the README describes a straight path from statically checked code to the database. Migrations are a separate, versioned system for applying schema changes as requirements evolve. Around that core sit several subsystems: a distributed cache that can run locally on the server or on Redis when the same cache must be shared across a cluster, file uploads to Google Cloud Storage or S3 or into the database, authenticated sockets for pushing serialized objects, and future calls that persist across a server restart and stand in for cron jobs. The built-in web server is the one piece the README flags as experimental and under active work, which is a meaningful caveat for anyone planning to serve traditional web pages or webhooks through it.

Installing Serverpod and calling a first endpoint

The README does not carry install steps; it points to docs.serverpod.dev for getting started, and the repository carries templates/ and examples/ directories plus a pubspec.yaml at the top level. Because the exact CLI flags are not in the README, the honest move is to treat the documentation as the place where the commands live, and to use the repository only to confirm what the toolchain expects. Two files at the root pin the required SDK versions, and checking them first avoids a class of confusing failures:

cat SERVERPOD_VERSION
cat DART_VERSION

Those two files tell you which Serverpod release and which Dart SDK the checkout targets. The repository also declares its Flutter requirement in FLUTTER_VERSION, which matters if you are generating a Flutter client alongside the server. From there, the documented workflow is the one the README describes: define your server-side code, let the generator produce the models and the client, then call the generated client from your app as though it were a local method. The README gives no example command for that generation step, and no sample endpoint, so anyone following this article should read docs.serverpod.dev before running anything. What you should expect to see after generation is Dart code on the client side that mirrors your server endpoints, which is the payoff the whole design is built around.

The licence split is the first thing to check

Serverpod's licences are not uniform, and the README says so plainly. All Serverpod packages are licensed under BSD-3 except the main serverpod package, which uses the SSPL. In practice, per the README, you can use any of the client packages in your app without limitation, and you can host your Serverpod server without limitation as long as you do not offer Serverpod as a cloud service to third parties. The README notes this is typically only relevant for cloud service providers. That is a narrow carve-out and most application teams will never touch it, but it is a real boundary: if your business model is hosting other people's Serverpod servers, the SSPL on the core package is the constraint you need to understand before you build on it. The repository also carries a CLA.md and a CONTRIBUTING.md, which is standard for a project that wants to keep relicensing options open. Nothing here is legal advice; if the cloud-service carve-out could apply to you, that is a question for a lawyer, not a README.

Where Serverpod is the wrong choice

The clearest limitation is the one the project states about itself: the built-in web server is experimental and actively being worked on. If your plan is to serve traditional web pages, webhooks or custom REST endpoints to third parties, you are building on the least settled part of the stack, and the README does not promise stability there. The second limitation is ecosystem reach. Serverpod generates Dart clients, so a native iOS or Android team, a web frontend in TypeScript, or a partner integrating over REST gets no benefit from the generation step and inherits the framework's conventions anyway. The third is that bundling is not free. Caching, authentication, scheduling and uploads all arrive with Serverpod's opinions attached, and swapping one of them for an external service means working against the framework rather than with it. Finally, the deployment story is partial by the project's own account: Terraform scripts exist for Google Cloud Platform and AWS, and the README says scripts for other platforms are still being worked on. If you run on neither, you are writing your own deployment.

Serverpod compared with Dart Frog and Firebase

Dart Frog is the closest comparison in language, since both are Dart server frameworks, and the difference is in what they assume. Dart Frog is a routing framework: you define routes and handlers, and the API contract is whatever you write. Serverpod inverts that by generating the client from your server code, so the contract is derived rather than authored. If you want a thin HTTP layer over Dart and you already know how you want to structure the API, Dart Frog's approach is less machinery. If the pain you are solving is keeping a Flutter client in sync with server changes, Serverpod's generation is the whole point. Firebase is a different category entirely: it is a hosted platform, so you trade operational control for managed services. Serverpod is open source and the README states you can host your server anywhere, which is the opposite trade. The cost is that you own the database, the cache, the deployment and the upgrades. The comparison with Supabase runs along similar lines: a hosted backend versus a framework you run yourself. Choosing between them is really choosing whether you want to operate the server.

Maintenance, releases and upgrade cost

The repository is not archived, and the last push was on 2026-09-23, so the project is being worked on now. The recent releases are both embedded PostgreSQL bundles: embedded-postgres-v16.13.0-r1 on 2026-07-22 and embedded-postgres-v16.13.0 on 2026-07-03. Those are supporting artifacts rather than the framework itself, which is worth noting if you are watching releases to judge when to upgrade your server. The root carries a CHANGELOG.md and a SERVERPOD_VERSION file, so version tracking is explicit rather than implied. Upgrade cost is where the bundling shows up again: because migrations are part of the framework, schema changes go through Serverpod's migration system, and the README documents that system but does not document rollback. That is the gap to plan around. A migration you cannot reverse is an operational risk, so test migrations against a copy before applying them to production. The pinned DART_VERSION and FLUTTER_VERSION files also mean SDK bumps are deliberate events in this repository, not incidental ones, and you should expect to move your toolchain when you move Serverpod.

Editorial conclusion

Adopt Serverpod when your team already writes Dart and you want the client and server to share generated types instead of hand-written REST contracts; the repository layout, with packages/, templates/, modules/ and examples/auth, shows the project is organised for that workflow. Skip it if you need a non-Dart client, if you depend on the experimental built-in web server for production traffic, or if you plan to resell the server as a hosted service, because the main serverpod package is SSPL rather than BSD-3. Before committing, check SERVERPOD_VERSION and DART_VERSION in the repository against your toolchain, and read the migration documentation for the version you install, since the README describes a migration system but does not document rollback.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-3-Clause
3. README
4. Releases
5. serverpod/serverpod on GitHub