Solidus Relay vs running your own mediator

Sometimes you should run your own, and this page is written to help you decide that, not to talk you out of it.

Weigh that honestly against the alternative before choosing either.

Run your own when any of these is true

A third party may not sit in your message path. This is the decisive one. A hosted mediator, ours or anyone's, sees who connects, when, how often and how large the envelopes are. That is structural, not a policy we could change: what a mediator can and cannot see. If your threat model excludes an external observer of routing metadata, stop reading and self-host.
The operator is in your threat model. Ours names itself as an adversary we do not defend you against, threat model. Self-hosting does not eliminate that role; it moves it to you, which is often exactly the point.
Data residency or regulatory constraints dictate where infrastructure runs.
You need it in production now with a support contract. We are beta with no SLA. A mediator you operate, or a commercially supported one, both beat us on that.
Your volume makes per-use pricing worse than a server. Run the arithmetic; it is not always close.

Do not run your own when

Nobody owns it. A mediator is not fire-and-forget. Queues fill, certificates expire, disks fill, versions drift. An unowned mediator fails silently and the symptom is messages that never arrive, which surfaces as a bug in someone else's agent, days later.
It would be your only reason to run infrastructure. If everything else you build is serverless or managed, one stateful service with a queue is a disproportionate operational burden.
You would build it from scratch. Do not. Use the OpenWallet Foundation mediator (Apache 2.0) or build on Credo-TS, see vs the OWF mediator and vs Credo-TS. Hand-rolling DIDComm envelope handling is where this goes wrong quietly.

What self-hosting does not buy you

It does not make traffic analysis go away, it relocates the vantage point. Your correspondents' mediators still see their side, and a network observer still sees yours. See traffic analysis.

It does not improve herd privacy: it usually makes it worse. A mediator serving one organisation has an anonymity set of one organisation. Every message through it is yours by definition. See herd privacy.

That second point is genuinely counterintuitive and it cuts against the instinct that self-hosting is always the more private choice. For confidentiality and control, self-hosting wins. For blending into a crowd, it loses, and our crowd is small too, so on that axis nobody here is offering you much.

What you would be taking on

Availability and on-call. Storage and queue growth (ours caps envelopes at 1 MiB and retains queued messages 14 days by default, see queue depth and backpressure). Key management for the mediator's own identity. Upgrades as DIDComm evolves. Monitoring that distinguishes "quiet" from "broken".

None of it is exotic. All of it is real, and it is the same work whether you host for one agent or a thousand.

The honest summary

Hosted is a convenience trade, not a capability trade. You are exchanging operational burden for an observer in your routing path. Whether that is a good trade depends entirely on your threat model, and we would rather you make it deliberately than by default.