Serverpod is built by the community for the community. Pull requests are very much welcome. If you are making something more significant than just a tiny bug fix, please get in touch with Serverpod's lead developer Viktor Lidholt before you get started. This makes sure that your contribution aligns with Serverpod's overall vision and roadmap and that multiple persons don't do the same work.
If you want to contribute, please view our roadmap and pick issues from there. This will make it much more likely that we can include the new features you are building.
For us to be able to accept your code, you must follow the guidelines below. We cannot accept contributions unless there are tests written for it. We also cannot accept features that are not complete for all use cases. In very rare circumstances, we may still be able to use code that doesn't comply with the guidelines, but it may take a long time for us to free up a resource that can clean up the code or write missing tests.
Working on Serverpod
The main Serverpod repository contains all Serverpod code and code for tests and official modules and integrations. Send any pull requests to the
We are very conscious about keeping the Serverpod code base clean. When you write your code, make sure to use
dart format and that you don't get any errors or lints from
Running all tests
Continuous integration tests are automatically run when sending a pull request to the
main branch. You can run the tests locally by changing your working directory into the root serverpod directory and running:
Tests may not yet work if running on a Windows machine. Mac or Linux is recommended for Serverpod development.
Running individual tests
Running single individual tests is useful when you are working on a specific feature. To do it, you will need to manually start the test server, then run the integration tests from the
- Add an entry for the test server at the end of your
- Start the Docker container for the test server.
$ cd tests/serverpod_test_server/docker-local
$ docker-compose up --build --detach
- Start the test server.
$ cd tests/serverpod_test_server
$ dart bin/main.dart
- Run an individual test
$ cd tests/serverpod_test_server
$ dart test test/connection_test.dart
Command line tools
To run the
serverpod command from your cloned repository, you will need to:
$ cd tools/serverpod_cli
$ dart pub get
$ dart pub global activate --source path .
Depending on your Dart version you may need to run the
dart pub global command above every time you've made changes in the Serverpod tooling.
If you run the local version of the
serverpod command line interface, you will need to set the
SERVERPOD_HOME environment variable. It should point to the root your cloned
serverpod monorepo. (E.g.
If you use
serverpod create to set up a new project with a local version of the tooling, you may need to edit the pubspec files in the created packages to point to your local serverpod packages.
Editing the pubspec.yaml files
First off, we are restrictive about which new packages we include in the Serverpod project. So before starting to add new dependencies, you should probably get in touch with the maintainers of Serverpod to clear it.
Secondly, you shouldn't edit the
pubspec.yaml files directly. Instead, make changes to the files in the
templates/ directory. When you've made changes, run the
update_pubspecs command to generate the
Submitting your pull request
To keep commits clean, Serverpod squashes them when merging pull requests. Therefore, it is essential that each pull request only contains a single feature or bug fix. Keeping the pull requests smaller also makes it faster and easier to review the code.
If you are contributing new code, you will also need to provide tests for your code. The tests should be placed in the
Feel free to post on Serverpod's discussion board if you have any questions. We check the board daily.