The Matrix server is open source. https://github.com/matrix-org/synapse
The Element client is also open source. https://github.com/element-hq/element-web
It does not actually need to be configured in a federated state and frankly scales better when it's not. The login can be tied to anything or use it's own. From a modern SAML SSO to an old school forum.
You can run one for a few friends and it scales just as well as a private discord for a few friends. Just need persistent storage for media uploads if people are sharing video a lot.
In Welcoming Discord users amidst the challenge of Age Verificationmatrix-org
synapse
Python2015–2026
matrix-org / synapse · Archived
synapse
Synapse: Matrix homeserver written in Python/Twisted.
68Distinct people
116Mentions
1Explicit recommenders
12.1KGitHub stars
What to know before exploring
What it is
Synapse: Matrix homeserver written in Python/Twisted.
GitHub
Where it is used
The source check is incomplete. Verified examples will appear here.
What people are saying
I use AVENTER-UG's docker-matrix container for Synapse, and a separate VM for PostgreSQL. Element-web I currently upgrade straight from the tarballs. Upgrades are fairly…
snerbles used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- matrix-org/matrix-spec-proposals · linked in 10 of the same discussions
- element-hq/element-web · linked in 7 of the same discussions
- awesome-technologies/synapse-admin · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year116 dated mentions
Observed mentions: 2015-02-05 16:06:38 UTC to 2026-02-13 02:28:43 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 14 | 1 | 13 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 23 | 3 | 20 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 17 | 0 | 17 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 30 | 2 | 28 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 9 | 1 | 8 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 0 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Synapse
Synapse is now actively maintained at element-hq/synapse
Synapse is an open-source Matrix homeserver developed
from 2019 through 2023 as part of the Matrix.org Foundation. The Matrix.org
Foundation is not able to resource maintenance of Synapse and it
continues to be developed by Element;
additionally you have the choice of other Matrix homeservers.
See The future of Synapse and Dendrite
blog post for more information.
Briefly, Matrix is an open standard for communications on the internet, supporting
federation, encryption and VoIP. Matrix.org has more to say about the goals of the
Matrix project, and the formal specification describes the technical details.
Contents
Synapse is now actively maintained at element-hq/synapse
Installing and configuration
Using a reverse proxy with Synapse
Upgrading an existing Synapse
Platform dependencies
Security note
Testing a new installation
Registering a new user from a client
Troubleshooting and support
Identity Servers
Development
Installing and configuration
The Synapse documentation describes how to install Synapse. We recommend using
Docker images or Debian packages from Matrix.org.
Synapse has a variety of config options
which can be used to customise its behaviour after installation.
There are additional details on how to configure Synapse for federation here.
Using a reverse proxy with Synapse
It is recommended to put a reverse proxy such as
nginx,
Apache,
Caddy,
HAProxy or
relayd in front of Synapse. One advantage of
doing so is that it means that you can expose the default https port (443) to
Matrix clients without needing to run Synapse with root privileges.
For information on configuring one, see the reverse proxy docs.
Upgrading an existing Synapse
The instructions for upgrading Synapse are in the upgrade notes.
Please check these instructions as upgrading may require extra steps for some
versions of Synapse.
Platform dependencies
Synapse uses a number of platform dependencies such as Python and PostgreSQL,
and aims to follow supported upstream versions. See the
deprecation policy
for more details.
Security note
Matrix serves raw, user-supplied data in some APIs -- specifically the content
repository endpoints.
Whilst we make a reasonable effort to mitigate against XSS attacks (for
instance, by using CSP), a Matrix homeserver should not be hosted on a
domain hosting other web applications. This especially applies to sharing
the domain with Matrix web clients and other sensitive applications like
webmail. See
https://developer.github.com/changes/2014-04-25-user-content-security for more
information.
Ideally, the homeserver should not simply be on a different subdomain, but on
a completely different registered domain (also known as top-level site or
eTLD+1). This is because some attacks are still possible as long as the two
applications share the same registered domain.
To illustrate this with an example, if your Element Web or other sensitive web
application is hosted on A.example1.com, you should ideally host Synapse on
example2.com. Some amount of protection is offered by hosting on
B.example1.com instead, so this is also acceptable in some scenarios.
However, you should not host your Synapse on A.example1.com.
Note that all of the above refers exclusively to the domain used in Synapse's
public_baseurl setting. In particular, it has no bearing on the domain
mentioned in MXIDs hosted on that server.
Following this advice ensures that even if an XSS is found in Synapse, the
impact to other applications will be minimal.
Testing a new installation
The easiest way to try out your new Synapse installation is by connecting to it
from a web client.
Unless you are running a test instance of Synapse on your local machine, in
general, you will need to enable TLS support before you can successfully
connect from a client: see
TLS certificates.
An easy way to get started is to login or register via Element at
https://app.element.io/#/login or https://app.element.io/#/register respectively.
You will need to change the server you are logging into from matrix.org
and instead specify a Homeserver URL of https://<server_name>:8448
(or just https://<server_name> if you are using a reverse proxy).
If you prefer to use another client, refer to our
client breakdown.
If all goes well you should at least be able to log in, create a room, and
start sending messages.
Registering a new user from a client
By default, registration of new users via Matrix clients is disabled. To enable
it:
In the
registration config section
set enable_registration: true in homeserver.yaml.
Then either:
set up a CAPTCHA, or
set enable_registration_without_verification: true in homeserver.yaml.
We strongly recommend using a CAPTCHA, particularly if your homeserver is exposed to
the public internet. Without it, anyone can freely register accounts on your homeserver.
This can be exploited by attackers to create spambots targetting the rest of the Matrix
federation.
Your new user name will be formed partly from the server_name, and partly
from a localpart you specify when you create the account. Your name will take
the form of:
@localpart:my.domain.name
(pronounced "at localpart on my dot domain dot name").
As when logging in, you will need to specify a "Custom server". Specify your
desired localpart in the 'User name' box.
Troubleshooting and support
The Admin FAQ
includes tips on dealing with some common problems. For more details, see
Synapse's wider documentation.
For additional support installing or managing Synapse, please ask in the community
support room #synapse:matrix.org (from a matrix.org account if necessary). We do not use GitHub
issues for support requests, only for bug reports and feature requests.
Identity Servers
Identity servers have the job of mapping email addresses and other 3rd Party
IDs (3PIDs) to Matrix user IDs, as well as verifying the ownership of 3PIDs
before creating that mapping.
They are not where accounts or credenti
Read the full README on GitHubWhat Hacker News says
116 sourcesi ran a synapse instance for a couple years for private purposes, but at this point the ecosystem seems kinda captured by element. self hosting is a pain. in some places it's really hard to tell that mistakes in good faith were made or it's just intentionally complicated to keep "normal" people from running their own instance. Especially the whole worker setup was subject to change multiple times and broke my instance every. single. time. couple that with sparse, out of date documentation and the "pro edition" they now announced suddenly makes a lot of sense (from their perspective at least)
- They own Element, the by far most used client
- They own Synapse, the by far most used server
- They own dendrite, the only matrix server so far that even comes close to spec adherance with synapse, which has been strangled (as evidenced by the last
Read the rest
release almost half a year ago [3])
Because everyone is running synapse, everyone needs to keep running synapse or risk losing compatibility with the federation.
This is not what the sales brochure for matrix read like. Like, at all.
Do y'all believe it's random chance that the official synapse docker-compose does not come with async workers? [1]
And now check out the terrible setup process for setting up the whole "workers magic" (which, mind you, is unavoidable the moment you have some bigger rooms joined) [2] - Like who on this godforsaken planet considers this valid even for 2022? Pair that with how easy to handle the base documentation is and things start to smell. They have the stench of trying to artificially create a moot by making it "too hard for non-pros".
I understand synapse and dendrite development need funding, but this is not the way to go. All good will towards Element as a steward of matrix I had is completely eroded by now and I assume that will be the case for many others too. Forks are bound to happen at this point and I'm looking forward to the ecosystem become more diverse again.
Oh, and did you know the Matrix Foundation is infact a UK based Inc. controlled by 5 people in 5 companies, of which 4 companies are residing at the same address [4] and the fifth has an odd interest in NFTs and other BS?
[1] https://github.com/matrix-org/synapse/blob/develop/contrib/d...
[2] https://matrix-org.github.io/synapse/latest/workers.html - note how this page is already marked as deprecated. Prepare for it to vanish altogether soon. You are not supposed to set up workers, you are supposed to beg element to run a decent matrix server
[3] https://github.com/matrix-org/dendrite
[4] https://find-and-update.company-information.service.gov.uk/c...
> It's well known that a non-profit sitting close to a for-profit just is often just a structural maneuver at this point. A case in point is the recent WordPress controversy.
I agree there. Which is why we have been separating Matrix and Element more and more - eg by setting up the Governing Board https://matrix.org/blog/2023/12/electing-our-first-governing... and removing as much of the historical interdependencies as possible. Just as Mozilla severed itself from Rust, or W3C is independent of browser vendors.
> So it has an ecosystem with a subset of its former participants. Some of those who are gone see it as closed. Probably not just me.
Probably, hence my enthusiasm in trying to set the record straight :|
> the repo was literally transferred, though?
No… it’s still there at https://github.com/matrix-org/synapse. The Fdn archived it
Read the rest
given they have no resources to maintain it.
> With all its issues?
The name & description of each issue (not comments) was copied over to avoid breaking the numbering system and relative links, with a link back to the issue on the old repo.
> As well as the trademark?
There is no Synapse trademark and never has been… The Matrix trademark continues to live with the Foundation, as you’d expect.
> I'm representing my perspective, and you're representing yours.
As is your right. My point is that yours is littered with factual bugs, but you have been presenting it on HN as accurate, which is frustratingly misleading.
> So the ideal FLOSS messaging platform is yet to come.
If you don’t like CLAs and/or you don’t like AGPL, there are full Matrix stacks which have nothing to do with Element which are pretty fantastic, imo. Or keep going with Zulip - kudos to Tim & co for improving their financial viability by ratelimiting push (https://blog.zulip.com/2023/12/15/new-plans-for-self-hosted-... - something we’ve never done) rather than selling copyleft exceptions.
when we did a comparison of package managers that lock dependencies, we wrote up some interesting notes at https://github.com/matrix-org/synapse/issues/11537#issuecomm...
Notable omission in pip-tools which many are suggesting here as being simpler: it can't write requirements files for multiple environments/platforms without running it once for each of those environments and having one file for all of them.
We settled on Poetry at the time but it has been quite unstable overall. Not so bad recently but there were a lot of issues/regressions with it over time.
For this reason I am happy to see new takes on package management, hopefully some of these will have clearer wins over the others, where you have to spend ages trying to figure out which one will do what you need.
In Python Has Too Many Package ManagersWhat are you thinking of here? Synapse has supported purging room history since 2016: https://github.com/matrix-org/synapse/pull/911, and configurable data retention since 2019: https://github.com/matrix-org/synapse/pull/5815.
Meanwhile, Matrix has never needed the full room history to be synchronised - when a server joins a room, it typically only grabs the last 20 messages (with other history pulled in demand when the client scrolls up). (It does needs to grab all the key-value state about the room, although these days that happens gradually in the background).
If you're wondering why Matrix implementations are often greedy on disk space, it's because they typically cache the key-value state aggressively (storing a snapshot of it for the room on a regular basis). However, that's just an implementation quirk; folks could absolutely come
Read the rest
up with fancier datastructures to store it more efficiently; it's just not got to the top of anyone's todo list yet - things like performance and UX are considered much more important than disk usage right now.
some context re the Matrix isses, long history apparently: https://github.com/matrix-org/synapse/issues/14481#issuecomm...
In GrapheneOS is moving off Matrix> wow, the pile-on is real tonight.
My intent isn't to "pile-on"; it's to provide insight into the issues people have with Matrix. I understand that it's your creation, but judging by this and the GitHub thread, it seems like you get quite defensive in these situations. Ultimately, these are valid criticisms of the platform; people aren't personally attacking you or the project. Personally I commend what you've created.
> I suggested that GrapheneOS stopped enumerating potential ways to attack Matrix rooms on Twitter if they actually wanted to discourage attacks.
Well, the issue was posted above. The Graphene guy posted it on Twitter, and by doing so you claimed he "slagged [you] off"[0].
> Meanwhile, that issue has not remotely been abandoned, and has continued to be worked on in private (given the risk it might have security impact)
Read the rest
- although as it's a rare edge case without a known security impact, it's competing with a lot of the other work we do to support Matrix, hence slow progress; especially with highly constrained funding.
This is the part I don't understand. If you're working on it in private, you acknowledge it may be a security risk (plus your use of the word "attack"), but you've also de-prioritized it because it's not a security risk?
[0]: "what the hell is this? We have burnt a bunch of time investigating this and trying to help you on this today, and in return we get slagged off on twitter?!" https://github.com/matrix-org/synapse/issues/14481#issuecomm...
Why not Matrix? Here's one reason: it has incredibly hard-to-debug edge cases, and plenty of bugs. One of my favourites is the one where people are kicked out of your room at random, which was reported a year ago[0]. It wasn't fixed, however, because the head of the Matrix foundation (Matthew) didn't seem to like the issue being posted on Twitter.
The reporter took down the tweet, and it's still now effectively abandoned (despite it still being an issue; I've spoken to quite a few mods about it). This is honestly really disappointing behaviour from a platform owner.
[0]: https://github.com/matrix-org/synapse/issues/14481
In Financial situation of the Matrix.org Foundation> That doesn't make this situation any less bad to the rest of the community.
How is the community suffering here? Let's say Element adds a bunch of baller stuff to their versions over the next few months and then closes the source. Can't the community just fork the last AGPL version? You might say, "well then no one can take the AGPL fork and make their own closed-source business", but do you want them to? Even if you do, they still can with the existing Apache-licensed version, just like Element is doing right now.
You're arguing that Element will lose a lot of contributions, but TFA points out that despite being super open, the vast majority of contributions are still made by Element employees (which seems to be true [0]). It's not the case that Element is looking to monetize the (small) contributions of others, it is the case that oth
Read the rest
ers are looking to monetize the (huge) contributions of Element.
And besides, aren't the MSCs the core of Matrix? It's already super possible to build your own compliant client and server.
The situation is that Element needs money to keep developing the ecosystem. It would be cool if there were a big network of donors and contributions, but there isn't. You're essentially saying, "that's fine, go out of business then, and the community will keep developing the ecosystem", but that's not happening now, and it can still happen anyway with the Apache-licensed versions, which again people can still contribute to.
[0]: https://github.com/matrix-org/synapse/graphs/contributors
Really good write up. Been using gevent in pyinfra[1] for years and swear by it. Had some pains with setup, and am usually very wary of such magic, but it’s just really solid. Mostly write go these days though which has taken the shine off for sure!
Twisted, however, is a different beast. Have spent s decent chunk of time working on Matrix synapse homeserver[2], written in twisted, and oh my it just sucks.
[1] https://github.com/Fizzadar/pyinfra
[2] https://github.com/matrix-org/synapse
In Asyncio, twisted, tornado, gevent walk into a barYou can self-host with https://github.com/mautrix/imessage and https://github.com/matrix-org/synapse/
In I built an iMessage bot using BeeperLibera.ems.host stopped accepting incoming events from matrix.org in many rooms
1 points · Open discussionI use AVENTER-UG's docker-matrix container for Synapse, and a separate VM for PostgreSQL. Element-web I currently upgrade straight from the tarballs. Upgrades are fairly seamless, and it's been well behaved for the past 24 months or so - the teams behind the Matrix ecosystem have been phenomenal.
But you want sysadmin pain points, here are some random pointers in no particular order:
- Familiarity with reverse proxies helps a lot. I recommend terminating both client (443) and federation (8448) traffic through nginx or similar.
- The Synapse Github (https://github.com/matrix-org/synapse/issues) is one of the first places I start trawling if something gets weird.
- Federation is the second-hardest part, and if something goes wrong and you're not watching the Synapse logs it can fail silently - here it helps to have friends on other instance
Read the rest
s there to check connectivity (and blame you when THEIR instance breaks federation, that's fun). https://federationtester.matrix.org and similar help a lot too, and it's good to at least have a couple of bots from matrix.org to poke at if you suspect something's amiss.
- Fuck everything about troubleshooting STUN/TURN. Newer playbooks may make coturn deployment easier.
- It's easy to test migrations/deployments with an update to your hosts file - you can verify that your clients connect to the new server and that data has been restored without doing anything to the original server.
EDIT - Keep in mind that a lot of the above went on from 2018-2019 (except the server migration, but that was easy) and the documentation/automation has improved quite a lot since then.
Oh! Well, a couple things:
- Matrix is the protocol, Element is confusingly both the hosting service and the mobile app, and Synapse is the server -- just to get terminology right
- Matrix actually does the "multiple clients" thing really right [0]
- I think a lot of people self-host; I did and there are a few others in this thread. It's easy if you've any experience hosting web API servers. A core Matrix goal is to be decentralized, so self-hosting is thus also a core goal. You can see docs here [1], or docs for Docker here [2] if that's your thing.
[0]: https://matrix.org/clients/
[1]: https://matrix-org.github.io/synapse/latest/
[2]: https://github.com/matrix-org/synapse/tree/master/docker
In Matrix 2.0: How we’re making Matrix go voomJust one example: https://github.com/matrix-org/synapse/issues/5677
Another would be the user agent of the clients (windows, linux, …) on Element Web…
In MinesTRIX, A privacy focused social media based on matrixShowing the 15 most recent of 116 sources. Enable JavaScript to search and browse every indexed mention.