Symphony (88250/symphony): a Java community platform you build from source

What Symphony is for, and who ends up running it

Symphony targets the operator who wants one system to cover a discussion forum, a knowledge Q&A area, and a social layer, instead of wiring a forum plugin, a separate Q&A tool and a profile system together. The README frames the motivation against older forum software: dated interfaces, few interactive features, thin administration, and a lack of long term upkeep. The feature list that follows is unusually wide. Post types include a city broadcast, a confidential post, a thought, a Q&A post and an ordinary post. Replies support thanking, accepting an answer, upvotes and downvotes, reporting, folding, and a Reddit style comment ranking. There is a points and currency system with recharge, withdrawal and an ETH wallet address field. The audience is therefore a team that already runs servers and expects to configure roles, audit logs and review queues, not an individual who wants a hosted board in five minutes.

The architecture visible in the repository

The repository is a Maven project with a Node build layered on top. pom.xml sits at the root, src/ holds the Java application and resources, and package.json declares gulp tasks named dev and build that compile Sass and bundle front end assets. The only runtime dependency listed in package.json is vditor, the Markdown editor, which matches the README's description of three editing modes: split Markdown preview, an instant rendering mode that keeps the Markdown markers visible, and a rich text style WYSIWYG mode. The Dockerfile shows the runtime shape: a Maven 3.9 image on Eclipse Temurin 17 builds the project with mvn package, copies src/main/resources/docker/ over the output, and the final image runs on eclipse-temurin:17-jre-alpine with java -cp "lib/*:." org.b3log.symphony.Server. The default timezone environment variable is Asia/Shanghai and the exposed port is 8080. That means the application is a single Java process started from a classpath, with the container image carrying the configuration files rather than generating them.

Building Symphony with the Dockerfile

The repository does not publish a runnable jar as its primary distribution path; the documented route in the code is the Dockerfile at the root. Build it from a clone of the master branch. The build stage runs Maven inside the image, so the first build downloads the full dependency tree and takes a while.

git clone https://github.com/88250/symphony.git
cd symphony
docker build -t symphony:local .

The Dockerfile runs mvn package -DskipTests -Pci -q, moves target/symphony/ into /opt/sym/, and copies src/main/resources/docker/ on top of it. Tests are skipped in that profile, which is worth knowing if you intend to change the code: your own build should not rely on the image to catch regressions.

The Dockerfile itself ends with the process it starts:

ENV TZ=Asia/Shanghai
EXPOSE 8080

ENTRYPOINT [ "java", "-cp", "lib/*:.", "org.b3log.symphony.Server" ]

Those three lines are the whole runtime contract: timezone Asia/Shanghai, port 8080, and org.b3log.symphony.Server as the entry point. The Dockerfile sets no database or cache environment variables, and the README does not document a first run wizard, so the service configuration has to come from the files copied out of src/main/resources/docker/ or from a volume you mount yourself. The README is silent on which database and cache the application expects; check pom.xml and that resources directory before you assume a default.

Where Symphony gets in your way

The release history is the first constraint. The newest release shown is v3.6.4, dated 2022-01-22, and the two before it are v3.6.3 from 2020-06-12 and v3.6.2 from 2020-03-25. Commits continue on master, with the last push on 2026-09-09, but the tagged release channel has not moved in years. If your upgrade process depends on versioned artifacts and changelogs, the version you can point at is old, and the code on master is ahead of it in ways the release notes do not describe. The second constraint is operational surface. The admin panel covers users, posts, replies, comments, chat rooms, files, domains, tags, reserved words, invite codes, ads, roles, reports, review queues, audit logs and browsing statistics. That breadth is the selling point and also the configuration burden. The third is the licence. AGPL-3.0 is a strong copyleft licence with a network clause, so a modified Symphony offered to users over a network carries source distribution obligations. The repository lists a THIRD_PARTY_LICENSE file, which you should read alongside LICENSE; nothing here is legal advice. Finally, the README does not document rollback, backup or migration between versions, so plan those yourself.

Symphony compared with forum software you assemble from parts

The obvious alternative category is a general purpose forum package with a plugin ecosystem, where the core handles threads and permissions and everything else, including Q&A, points or a social graph, is an add-on. Symphony takes the opposite position: the README lists Q&A posts, accepted answers, voting, points, wallet addresses, chat rooms and a review queue as built-in features rather than extensions. The difference shows up in two places. First, you configure behaviour through the admin panel and the shipped role definitions (administrator, honoured member, senior member, member, novice, visitor) instead of installing modules. Second, you inherit the maintainers' decisions about data model and UI, and you cannot swap the editor or the ranking algorithm for a third party one without forking. For a team that wants a single coherent product and is willing to run Java, that is a reasonable trade. For a team that wants to replace one subsystem at a time, a plugin based forum will be less friction.

Maintenance cost and what the licence means in practice

Two maintenance numbers matter. The last push to master was on 2026-09-09, so the codebase is being touched. The newest listed release is v3.6.4 from 2022-01-22, so the release channel is not. Those two facts point in different directions, and you should decide which one your deployment follows before you adopt the project. Building from master means tracking a moving target with no release notes; building from the v3.6.4 tag means running code that is several years behind the repository. On the licence side, AGPL-3.0 applies to the project, and the repository also carries a THIRD_PARTY_LICENSE file for bundled components such as the vditor editor. If you modify Symphony and let users reach it over a network, the AGPL's network clause is the part to read carefully with your own counsel. The README does not discuss commercial licensing or an exception, so do not assume one exists.

Editorial conclusion

Adopt Symphony if you are comfortable operating a Java stack built from source and you want forum, Q&A, tagging, moderation and admin tooling in one codebase rather than assembled from plugins. Do not adopt it if you need a one-command hosted install, a permissive licence for a closed product, or a project whose release cadence you can plan around, since the newest release listed is v3.6.4 from 2022-01-22. Before committing, read pom.xml and src/main/resources/docker/ to confirm the database, cache and port configuration your deployment needs, then build the Dockerfile once and watch the Maven step complete.

Frequently asked questions

Official sources

1. 88250/symphony on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases