Signal-Server: the build command is documented, the start command is not

The build begins with FoundationDB, not with Java

The only prerequisite the project states is FoundationDB. Signal-Server uses FoundationDB as its data store and requires the FoundationDB client library to be installed on the host system before anything else works, which means the build environment needs a database client present, not just a JDK. The command given for building and testing is a single Maven wrapper invocation: ```shell script $ ./mvnw clean test ``` The wrapper is committed as mvnw alongside mvnw.cmd, so no globally installed Maven is required, and .java-version pins the JDK the project expects while .mvn/ holds the Maven configuration.

Building is documented, starting the service is not

The documentation covers exactly one operational step, and it is a build-and-test step. Nothing in it explains how to bring the server up, which configuration it reads, which ports it binds, or what a healthy process looks like once it is running. TESTING.md sits in the repository root alongside the README, so test setup is the one part of the workflow with a document attached to it. For a reader, the gap is the whole operational half of running a server: you can build and test with one command and then discover that the path to a running instance is yours to work out. Anyone evaluating this project should plan to spend the discovery time that the README does not save them.

No releases means you pin a commit, not a version

The repository has no GitHub releases at all, which is the single most consequential fact for anyone planning an upgrade path. There is no v-tagged artifact to point a deployment at, no release notes to read before rolling forward, and no published changelog attached to a version. What is available is the main branch, and that branch is being worked on: the repository is not archived and its last push is dated 2026-10-28. The consequence is that reproducibility is your job. A build taken today and a build taken next month are different by definition, and comparing them means comparing commits rather than reading a set of notes. If your process requires an identifiable server version for incident review or audit, you need to record the commit identifier yourself at build time.

The module layout is the only map of the system

The top-level tree is short enough to read as an outline. There is a single pom.xml at the root, a service/ directory holding the server itself, websocket-resources/ for the websocket side, spam-filter as its own top-level entry, api-doc/ for the API description, and integration-tests/ separated from the rest. Supporting files sit alongside them: .editorconfig, .java-version, .mvn/, and a .gitmodules file.

The export classification makes the legal check yours

The distribution carries a cryptography notice rather than a support promise, and it is specific. This distribution includes cryptographic software, and the country you reside in may restrict the import, possession, use, or re-export of encryption software. Before using any of it, you are asked to check your own country's laws, regulations, and policies, with the Wassenaar arrangement linked for background. The U.S. Department of Commerce Bureau of Industry and Security has classified the software as Export Commodity Control Number 5D002.C.1, covering information security software using or performing cryptographic functions with asymmetric algorithms. The distribution form makes it eligible for export under the ENC Technology Software Unrestricted exception, Section 740.13 of the BIS Export Administration Regulations, for both object code and source code. That is a statement about the exporter's position, not legal advice, so the check stays with whoever deploys it.

Support is redirected to an unofficial forum

The help section states the position plainly: direct technical support cannot be provided, and help running the software in your own environment is expected to come from an unofficial community forum hosted at community.signalusers.org. There is exactly one official address in the project documentation, and it is [email protected], reserved for reporting security issues rather than for troubleshooting a deployment. For a reader, that splits the audience. Someone evaluating Signal's own service has documentation and a security contact; someone self-hosting has neither direct support nor a documented runbook, and the repository offers neither. Combined with the absence of releases and of a start command, the practical picture is a codebase meant to be read rather than a product meant to be installed.

Protocol documentation lives on signal.org, not in the tree

If you arrive looking for the wire format, the project redirects you immediately to https://signal.org/docs/ and calls that the place for protocol documentation. The README points to signal.org/docs for protocol documentation. The repository also has an api-doc/ directory next to service/, whose contents the README does not describe.

Editorial conclusion

Signal-Server suits organizations prepared to build from source, run their own infrastructure, and accept that no direct support exists. It does not suit anyone wanting a packaged install or a tagged release to pin. Before starting, confirm FoundationDB is installed on the host, read TESTING.md, and settle the export and licensing questions the cryptography notice raises in your jurisdiction.

Frequently asked questions

Official sources

1. Issues
2. License: AGPL-3.0
3. Project website
4. README
5. signalapp/Signal-Server on GitHub