Play Framework: reading the 3.x and 2.x lines in one repository

One build file and eight module directories, no sample app

The top level of playframework/playframework reads like a dependency graph rather than a product. `web/`, `core/`, `transport/`, `cache/`, `cluster/`, `persistence/`, `dev-mode/` and `testkit/` sit next to `build.sbt`, `common.sbt` and a `project/` directory. Not one entry in that listing is a runnable example, so anyone cloning the repository to see how a Play application is wired finds framework sources instead. Count the directories before you estimate an upgrade, because all of them move with the same build.

The refresh loop lives in dev-mode, outside the request path

The project sells a "just hit refresh" workflow with built-in testing support, and the machinery behind both claims sits in two directories that are listed apart from `web/`: `dev-mode/` and `testkit/`. That split is the architectural fact worth noting. Reload behaviour and test helpers sit in directories apart from request handling. What the repository does not settle is how a change is detected, how long a recompile blocks, or what a compile error renders in the browser, because the README carries none of that and the top-level listing holds no configuration file that would answer it. The dev loop is the feature most people adopt Play for, and it is the one you will have to learn from the documentation site rather than from this tree.

3.0.12 and 2.9.12 both shipped on 2026-09-30

Two release lines move in lockstep here. Play 3.0.12 and Play 2.9.12 were both published on 2026-09-30, seven seconds apart, while the previous 3.x tag, 3.0.11, is dated 2026-05-21. Two live lines turn an upgrade into a line decision rather than a version bump: 3.x is where new work lands, 2.x is what existing deployments receive as patches. The last push to the default branch, `main`, was on 2026-10-29, so the tree is moving. A badge in the README points at the Maven artifact `org.playframework/play_2.13`. That coordinate carries a Scala 2.13 suffix, which means a different Scala version is a different artifact name and not a different build flag.

Stateless is a constraint: state has to live outside the process

The README's claim that applications scale predictably rests on an architecture it describes as stateless and non-blocking, and it pairs that with JSON and WebSocket support and asset compilers. Treat statelessness as a requirement rather than a feature. If nothing is preserved between requests inside the JVM, then session data and anything shared across nodes has to live outside the process; the `cache/` and `cluster/` directories are the places to look for that support. The consequence for a reader is blunt: wire a shared store behind those modules, or your horizontally scaled instances will quietly disagree with each other, and nothing in the framework stops you because a stateless design is precisely what permits that arrangement. The README names no cache backend and no cluster transport, so treat both directories as extension points and read the documentation for what you are meant to plug in.

The README stops before the first command

Look for a way to start a server in the README and you reach a row of links instead. There is no install block, no run command and no request example, only `www.playframework.com`, the download page, the Installing page, the New Application page, and separate Scala and Java home pages that split the documentation by language. The project points you at its own site instead of embedding the invocation here, and the artifact coordinate in the Maven badge is the only machine-readable string a Maven consumer can copy. For an evaluation this is the first thing to accept or reject. Working with Play means working with an external documentation site as part of your build instructions, so read the Installing page before you wrap any automation around this repository, because the flags you need are not in it.

Formatting config and a blame-ignore list set the cost of contributing

Two small files at the top level tell you what a patch will cost you. `.scalafmt.conf` means Scala sources are formatted by a tool with checked-in settings, so lines you reformatted on your own get normalised on the way in and your diff will not read the way you wrote it. `.git-blame-ignore-revs` lists revisions that `git blame` can skip. Both point the same direction as the licence header, which splits copyright between the Play Framework Contributors from 2022 and Lightbend from 2011 to 2021, a handover that has already happened. Contributions go to the Contributors side under Apache-2.0. Expect the formatter to run, and expect blame output that skips history.

Where a Play build diverges from a Spring-shaped stack

Play is routinely compared with Spring Boot, and the honest difference is structural rather than a matter of speed. Play keeps web, transport, cache, cluster, persistence, dev-mode and testkit inside one repository and one `build.sbt`, with shared settings in `common.sbt`, so one file tells you what the runtime contains. A Spring-centred application composes its web layer, its server and its tooling from separate projects, which is where the shape of the two stacks comes apart. Play's README makes no comparison and offers no benchmark, so treat this as a difference in how the artefacts are assembled. The practical test is dependency review: a team that already standardises on the Spring ecosystem inherits Play's server and reload machinery as well, and every one of those transitive dependencies needs its own pass through an existing policy.

Persistence and transport exist as directories with no named back end

`persistence/` and `transport/` are in the listing, and that is the extent of what this repository says about them. No ORM is named, no driver is named, and no top-level configuration file reveals a default. The README's own claim list is short and concrete: asset compilers, JSON and WebSocket support, built-in testing support, and RESTfulness by default. Nothing there covers how a query is written or which database a node connects to. For a data-driven service that gap is the schedule risk. You can finish the new application walkthrough from the documentation site and still have no answer to the question of what your second instance reads, so settle the persistence and transport choices from the docs before you commit to a delivery date.

Editorial conclusion

Adopt Play if you want a single artifact graph for a stateless Java or Scala service and you are willing to read a separate documentation site while you set up, because playframework/playframework builds web, transport, cache, cluster, persistence, dev-mode and testkit into one build.sbt with shared settings in common.sbt. Leave it if your organisation already standardises on the Spring ecosystem, since Play ships its own server and reload machinery and every transitive dependency then needs its own review. Verify the Installing page that the README links to before you write any automation, because this repository, last pushed on 2026-10-29 and licensed under Apache-2.0 by the Play Framework Contributors, contains no install command and no named cache or persistence layer to copy.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. playframework/playframework on GitHub
3. Project website
4. README
5. Releases