Home / Privacy / Server code

Signal publishes its server code, but can you verify what's actually running?

Published: October 7, 2026 · Updated: October 8, 2026

Yes, Signal publishes its server code publicly. Anyone can read it, copy it, and even run their own copy. That is genuinely unusual among major messaging apps. But there is an honest limit: nobody outside Signal can verify that the servers currently handling your messages were built from that published code. This guide gives the balanced picture: what is actually open, what the publication proves, where verification stops, and why the limit is not a reason to panic.

What Signal actually publishes

Signal's server software is published in its public code repositories, under an open-source license, where anyone can read it. This is not a partial dump or a marketing gesture: the publication includes the code that routes messages, manages accounts, and handles the parts of the system users never see. You can clone it, study it, and run your own instance of it on your own hardware.

For context on how unusual this is: most major messaging apps publish no server code at all. Their servers are pure black boxes. Signal sits at the opposite end of the industry spectrum. Our open-source explainer walks through the client-side code, which is even more transparent thanks to reproducible builds; this page is about the server side specifically.

Publishing the server code does two concrete things:

• It lets experts check the design. Security researchers can read how the server handles messages, what it stores, and what it forgets. If the server code were secretly copying your messages to a database, anyone reading the code would see it.
• It lets you run your own. Because the code is public and licensed openly, nothing stops you from running a Signal-compatible server for your own study. You cannot plug it into Signal's network, but you can verify how it behaves.

What publishing the server code proves

The published code answers a specific question: what is this software designed to do? And the answer, readable by anyone, is reassuring on the points that matter most:

• Messages are not stored. The server code shows the design: messages wait briefly in a queue until delivered, then are deleted. There is no message archive to leak, subpoena, or hack. This matches what law enforcement actually receives when it comes knocking.
• The server cannot read message content. Encryption happens on your device before anything touches the network. The server handles sealed envelopes, and the code confirms it has no key to open them.
• Stored account data is minimal. What the server keeps about you is a tiny record, which is exactly why subpoena responses contain so little.

These are not promises. They are inspectable facts about published code. That distinction is the whole point of publishing it.

The honest limit: verifying the deployment

Here is the caveat, stated plainly: reading the code tells you what the software does. It does not tell you which software is running on Signal's servers right now. There is no technical mechanism that lets an outsider confirm that the servers currently handling your messages were built from the published code, unmodified.

This is not a Signal-specific failure. It is a property of all centralized services:

• Clients can be verified; servers cannot. Your phone downloads an app file you can inspect, checksum, and even rebuild from source (reproducible builds). A server is a remote machine you never touch. You send it traffic; it sends traffic back. What happens in between is, by the architecture of the internet, unobservable.
• No major messaging app solves this. The competitors do not even publish server code, so there is nothing to compare against. Signal's position is: here is the code, read it, run it yourself, and judge the design. That is the maximum transparency the architecture allows.
• A malicious server is constrained by the cryptography anyway. This is the key point people miss. Even a hypothetical rogue server cannot read your message content, because it never holds the keys. The cryptography was designed so that the server is untrusted by default. A dishonest server could misbehave in metadata ways (logging who talks to whom and when), but it cannot open the envelopes.

Frequently asked questions

Client code vs server code: the transparency gap

The table's bottom line: the client side is where verification is strongest and where the keys live, so that is where scrutiny matters most. The server side is less verifiable but also less powerful, because the encryption was built on the assumption that the server might be hostile.

Why the limit exists (and why it is not a scandal)

It helps to understand why nobody has solved deployment verification, so the caveat reads as engineering reality rather than suspicion:

• Remote attestation exists but is not deployed here. In theory, hardware features can let a server prove what software it runs. In practice, no major messaging service offers this, and the schemes have their own trust problems (you end up trusting the chipmaker instead).
• Publishing code is already the expensive, unusual choice. Maintaining public server code that outsiders can scrutinize costs real engineering effort and gives competitors a free look at your infrastructure. Companies do it for credibility, not convenience.
• The design assumes an untrusted server. This is the part that turns the caveat from a hole into a footnote. End-to-end encryption means the server is outside the trust boundary by design. You do not need to trust the server, because the cryptography does not require you to.

Be skeptical of anyone who presents the deployment gap as a Signal scandal while recommending an app that publishes nothing at all. That is not analysis; it is marketing wearing a trench coat.

What you can still check for yourself

The verification story is not "trust us." There are concrete things you, or experts you trust, can actually do:

• Read the code. It is public. You do not need permission, an account, or a relationship with Signal.
• Run your own instance. Spin up the published server code and watch how it handles messages: queue, deliver, delete. Confirm the design claims with your own eyes.
• Verify your client build. Reproducible builds mean the app on your phone can be checked against the published source. This is the verification that matters most, because the client holds your keys.
• Read the audit reports. Commissioned independent audits covered the protocol and apps; their published scopes and findings are checkable.
• Watch the subpoena responses. Signal publishes redacted responses to law-enforcement requests. They show, in the real world, how little data the servers actually hold.

The bottom line

Signal's server transparency is the best in the industry and still incomplete, and both halves of that sentence are true at once. The code is public, the design is inspectable, the cryptography distrusts the server by default, and the deployment cannot be independently verified, which is true of every centralized service ever built. If someone tells you the published code means the servers are proven safe, they are overselling. If someone tells you the verification gap means Signal is untrustworthy, ask them what their preferred app publishes. Then watch the conversation end.

Keep reading

• is Signal open source?: the client-side transparency story
• Signal's independent security audits: who reviewed the code
• can police read Signal messages?: what the servers actually hand over
• what metadata Signal collects: the tiny account record explained