Self Hosted XMTP

Shane wrote about why we're changing course. I’m here to talk about what’s shipping, how to get started, and where the project goes from here.

tl;dr

Starting today, XMTP is a full messaging stack you can run yourself, and customize fully. It’s built for where messaging is heading: private conversations between people and agents, on infrastructure you control.

The hosted XMTP network (dev and production) shuts down on February 1, 2027.
SDK 8.0.0-rc4 is out for Swift, Kotlin, Node, and Browser, exclusively targeting self-hosted backends.
This new version of XMTP is a lot more “batteries included”, adding a bunch of long-requested protocol features that were hard to make work in a single shared network.
We’ve re-written the backend as a single Rust binary that handles what previously required 3 or 4 different services.
Migration guide: here
No token, now or ever. XMTP Labs is funding the project for the next two years as it moves to community ownership. More below.

Who is XMTP for?

Until today, XMTP was mostly used by crypto apps that needed two wallets to talk to each other. Even if you only wanted to use XMTP for its privacy and security features, for developers outside the crypto space there was enough complexity and mental overhead around our approach to decentralization that it never made sense to adopt.

Starting today, XMTP is for everyone. If you need private and secure 1:1 or group messaging in your app, you should take a look at the new XMTP.

Agent to agent

If you want two or more agents to talk to each other, no matter what platform they're on, XMTP lets agents join your backend in seconds. Our Node.js SDK and CLI are battle-tested, and an agent can be up and running in under a minute. Agents can generate identities and join a network autonomously, and they don't need an open port on the public internet to receive messages.

Human to agent

If you want your users to talk to their Muse, Grokbot, Claude Code instance, or any other agent in real time from inside your app, XMTP might be a fit. The user copies a short prompt to their agent, and the agent can set themselves up and start chatting. We have SDKs for the browser, iOS, Android, and Node.js, plus a CLI.

Human to human

If you've been thinking about implementing Signal Protocol or MLS to add secure messaging to your app, you should definitely give XMTP a try first.

Implementing a secure messaging protocol - with all the features users require - is no small undertaking. XMTP is built on top of the MLS standard, and our libraries have been through multiple independent security audits and years of production use by Fortune 500 companies, startups, and thousands of developers, on just about every platform. It’s a full featured messaging stack that includes content types (replies, reactions, attachments), private group metadata, permissions and roles, and dozens of other features that are very difficult to implement privately and efficiently.

You will burn billions of tokens trying to re-create XMTP on top of Signal or MLS from scratch.

What's new

Moving from one global network to self-hosting let us make XMTP much more batteries-included. Everything gets easier when a network only has to meet one application's requirements, instead of balancing the needs of many node operators * many applications. That lets us ship features developers have asked for for years, which were simply too thorny to build on a global distributed network.

Attachments. If you wanted to send messages over 1MB before, you had to run a separate server to handle the uploads. XMTP now has first-party support for attachments in our SDKs and backend, with encrypted and anonymous payloads stored on any S3-compatible object storage service. No separate upload service.
Custom metadata fields. Configure what data is stored in groups and DMs on your network. XMTP now allows user-scoped profile fields to live in the group! All end-to-end encrypted and hidden from server operators.
Push notifications, built in. Push used to be out of scope for the protocol, so you had to run your own push server. It was a pain. Notifications are now integrated to the SDKs, which removes most of the complexity around subscription management.
Webhooks. Let clients subscribe to signed webhooks when new messages arrive. Great for agents and backend services that don't need to be online 24/7. This lets you run an XMTP client on a Sprite or a Railway instance that goes to sleep when things are quiet.
Your network, your rules. Network operators can customize every limit and parameter: maximum group size, rate limits, allowed content types.
Flexible auth. Gate access to your backend with JWTs, API keys, or build a custom auth provider.
Handles. Users and agents can look each other up by name instead of by address. No ENS name or external registration required.
A brand new Rust backend. The entire network runs from one binary, built for easy deployment and high throughput.

We added all of this while deleting close to 500,000 lines of code. Clients are simpler to work with, streaming is faster and more reliable, and common operations like adding members to a large group are 3x faster.

What changes

Today you pick an environment and the SDK connects to our network:

Client.create({ env: 'production' })

After the change, you point the SDK at a backend URL. Run your own, or connect to one hosted by someone else:

Client.create({ backendUrl: 'https://myapp.com' })

If your mobile app receives push notifications, read the push changes here. As part of version 8.0, we’ve unified the API surface across all of our SDKs, so if you are upgrading from a previous version you should hand the migration guide for your SDK over to a coding agent to migrate.

Running a backend

We have hosting guides for AWS ECS, Fly.io, Railway, and Kubernetes. If you'd rather not run one, you can connect to a backend another app hosts.

Migrating

Upgrade to SDK 8.x on each platform.
Deploy a backend (or pick one to connect to).
Replace env with backendUrl in Client.create.
Follow the upgrade guide for your specific SDK.
If you run your own push server, switch to the built-in notifications and retire it
If you run a backend to handle attachments, update your client code to use the built-in methods.

Clients start with a fresh local database the first time they connect to a self-hosted backend; there is no live message migration from the hosted network. Apps that already have messages stored can do a one-time import to a new SDK version by following this guide.

The hosted network keeps running until February 1, 2027, but don't wait. Migrating early means you're on the stack that's getting all of our attention.

Where this goes

Agents need a private way to talk

People are bringing their agents into every product they use. Agents built by different companies need to coordinate with each other and with the humans responsible for them. Today that mostly runs over Slack, email, Telegram, shared databases, and one-off APIs. Platform operators are willing to subsidize all this messaging volume so they can harvest training data for their own AI projects. None of it is private.

XMTP gives every person and agent its own identity and keys. The operator of the network can’t read messages or group metadata.

Instead of one network that we run, the plan is lots of them, run by the people building on them, all on the same open protocol.

Who maintains it

We’ve always said XMTP should be able to exist without XMTP Labs. Self-hosting is how we finish that job: you can run the whole stack, change it, and keep it running without needing anything from us.

XMTP has been open source since day 1. But in reality, we were “source available”. Anyone could open a PR - and we are grateful to everyone who has contributed - but the amount of context required to make larger contributions was too much. Complicated distributed systems problems on the backend, complicated client coordination problems on the front-end. It was very easy to make a change and break things for everyone else.

The self-hosted version of XMTP is a much friendlier place to make contributions. You can fork the repo, make changes for yourself, and test new features end-to-end. Because everyone is talking to their own backend, it’s straightforward to gate new features without risks to everyone else using the network.

Here’s how the project runs from here:

Maintainers. XMTP Labs will keep funding the project for the next two years as it transitions to community ownership. Contributors who do the work of maintaining it will receive retroactive grants.
Discussion. Roadmap discussion and proposals stay on the community forum at improve.xmtp.org.
Funding. There’s no XMTP token, and there won’t be one. XMTP Labs is the first funder, and the project is open to contributions from other companies building on the protocol.

We have a long list of features that developers have been asking for, but were just too messy to release in a distributed and shared network. Here’s one example: we’ve long wanted a way for apps to be able to define custom fields on groups and users. That would let developers use the shared and permissioned group state in app-specific ways (linking outside accounts, maintaining scoreboards, customizing the look and feel of each group). Obviously useful feature.

We built support for this at the SDK level earlier this year but never opened it up for outside developers to contribute new fields to it. Why? Each field needs a globally unique Component ID, which means a registry where apps can claim one globally and other apps can read the definition. Doing that in a distributed and decentralized way gets complicated quickly, so we kept pushing the work off.

The feature wasn’t impossible before, but it is so much easier with the self-hosted network. I built it in a couple of days on the self-hosted foundation.

If you’ve been wanting to contribute to XMTP…this is the time.

We have release candidates for our 8.0 SDK publicly available for testing, and expect a stable and forwards-compatible release in the next few weeks.