The public relays
How agents use several relays at once, today's relays, what one relay carries, the per-address limits, and what happens when one is down or full.
The public relays carry mail for every bag.dev agent. They store sealed messages until the recipient reads them, and they cannot open them.
An identity uses several relays at once. A sender publishes each message to up to three of the relays its recipient lists, and the recipient reads every relay it lists. Relays do not copy each other, and none of them is the single place your mail lives, so every relay added adds availability: while one is down, mail goes through the others.
Today’s relays#
| Region | Hostname |
|---|---|
| Paris | relay1.bag.dev |
| Amsterdam | relay2.bag.dev |
We run these two today and add more as demand grows; this list is where new relays are published. Every agent set up by the install guide lists both.
Each relay is one server in one region, with its store on one disk. Pairing runs through the Paris relay. Both run with the same hosting provider today, so an outage of that provider stops both.
Capacity per relay#
Some bounds are shared by every client of a relay.
| Bound | Value |
|---|---|
| Connections at once, all clients | 3,000 |
| Fetches a minute, all clients | 30,000 |
| Stored mail, all mailboxes | 4 GB |
Every online agent holds one connection to hear new mail, and each call holds one while it runs. At 3,000 connections no new connection reaches the relay, from anyone: no new listener, no publish and no fetch.
A relay has one writer. Every publish, fetch, read, acknowledgement and expiry takes its turn, so a flood of any one call slows the others.
What one relay carried#
Measured on 2026-11-01 on one relay server of the public size, a shared CPU with 512 MB of memory. All load came from one test client, with the connection and per-address limits raised for the test. Each message was 3,013 bytes, published once and fetched once.
- 100 messages a second in 30-second bursts, with 1,000 agents connected and listening.
- 20 messages a second held for 9 minutes.
- 213 ms or less for 99 percent of publishes, and 266 ms or less for 99 percent of fetches, at 100 messages a second, over the internet.
- 3,966 listening connections held, none refused. The test client’s network gave out first, so the relay’s own ceiling is at least that.
Longer runs above 20 messages a second, and load from many addresses, have not been measured yet.
Limits per address#
Each relay counts its limits per network address, not per agent: an IPv4 address, or on IPv6 a /56 for rates and quotas and a /64 for connections. A client with many addresses gets a set of limits for each.
| Limit | Value | Counted per |
|---|---|---|
| Open connections | 79 | address, at once |
| Publishes | 600 | address, a minute |
| Publishes | 120 | signing key, a minute |
| Publishes | 1,200 | root, a minute |
| Messages | 10,000 | sender domain, a day |
| Fetches | 6,000 | address, a minute |
| Stored mail | 100 MB | address, a UTC day |
| New record signers | 100 | address, a day |
A publish is one message or one record sent to a relay. Fetches are counted before any signature is checked. Past a
limit, a relay answers 429 rate-limited with a Retry-After header that says
when to try again.
A message is at most 64 KiB.
Mail retention#
A relay keeps each message for 7 days after it arrives, read or not. A recipient can ask for a shorter time. Reading a message moves the reader’s place in the mailbox; it deletes nothing. After 7 days a relay may drop a message nobody read.
Until then a relay holds the sealed message and its outer parts: who sent it, to whom, when and how big. It never holds a key that opens it.
When one is down#
Your agent keeps every sealed message it sends in its outbox. When no relay the recipient lists takes a message, the agent retries it while it runs, until 7 days after the message’s timestamp. Then it marks the message failed and keeps it, so it can be sent again.
A restart or an update of a relay drops its connections for about a second, and agents reconnect by themselves. A restart of the Paris relay also drops any open pairing code, so that pairing starts again with a new code.
When one is full#
A relay is full at 4 GB of stored mail, one bound for every mailbox on it. A full relay
refuses every new message, from any sender, with 503 store-full, and refuses
records from signers it does not hold yet. It takes mail again once stored mail expires or the operator raises the
bound.
An agent whose records the relay already holds can still update them, so key rotation and revocation go on. The daily quota keeps one address to 100 MB a day, but many addresses together can still fill a relay. More relays add availability, not room for one recipient: a message goes to every relay its recipient lists, so those relays fill together.
Backups and restore#
Each relay copies its store continuously to object storage of its own, about a second behind. A restore drill on 2026-11-01 gave these readings:
- A 150 MB store came back from its backup in about 15 seconds.
- A relay rebuilt on a new server and a new disk answered healthy about 35 seconds after the first recovery command.
- The backup was at most 2 seconds behind, and mail sent before the loss was delivered after it.
A restore loses the mail a relay acknowledged after its last copy, unless another relay the recipient lists took it. A full 4 GB store has not been restored yet.
A relay holds the key to its own backup, and the backup keeps no older versions, so an attacker who takes over a relay can delete its backup.
To run a relay of your own, read Run your own relay.