autopush-rs

Push Server in Rust

Explore on GitHub Read Hacker News discussions

3Distinct people

4Mentions

0Explicit recommenders

364GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Push Server in Rust

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 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 year4 dated mentions

Observed mentions: 2019-10-11 13:11:57 UTC to 2025-04-03 21:11:10 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	1	1
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	0	0
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	0	0
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	1	1
2023	2023-01-01 00:00:00 UTC	2024-01-01 00:00:00 UTC	1	1
2024	2024-01-01 00:00:00 UTC	2025-01-01 00:00:00 UTC	0	0
2025	2025-01-01 00:00:00 UTC	2026-01-01 00:00:00 UTC	1	1

What Hacker News says

4 sources

callahad·Apr 3, 2025

> I don't know if that means an Apple server actually listens for the notification from the HTTP server or if the device itself maintains the connection to the server. In the case of Apple's ecosystem, the device maintains a connection to the Apple Push Notification service (APNs). The website POSTs notifications to APNs, which forwards them on to the user's device. The user's device then wakes up a local Service Worker for that website in order to process the incoming payload and display a notification. Declarative Web Push makes the very last step unnecessary. (It's the same on Android but using Firebase Cloud Messaging instead of APNs. Mozilla also runs a push service and its source is at https://github.com/mozilla-services/autopush-rs/)

In Declarative Web Push

awesomeMilou·Nov 27, 2023

Yes. Each browser vendor runs a push notification backend, where browsers automatically connect to. Each end user browser instance has a unique identifier with that push backend. As a matter of fact, Mozilla's backend is even open source and written in rust: https://github.com/mozilla-services/autopush-rs/ EDIT: And to send push notifications to an end user as a service provider, you (in simple terms) receive an encoded version of that URI from the push service, along with an authentication token that authorizes you to send notifications to the push service, which will be forwarded to the user that corresponds to the URI.

In Demystifying Web Push Notifications

sciurus·Feb 25, 2022

> Is it say possible to run a production quality server that can handle hundreds of thousands of concurrent users on digital ocean lets say? Absolutely. I used to work as an SRE on Mozilla's WebPush infrastructure. Every running Firefox in the world establishes a connection to it; that means it peaks at tens of millions of concurrent connections every day. We could easily handle hundreds of thousands of connections on a couple CPU cores and gigs of RAM. Although most connections were usually idle, we also regularly pushed messages to every connected client (e.g. when a collection in our remote settings service was updated). It's written in Rust using Actix. https://github.com/mozilla-services/autopush-rs

In Announcing Actix Web v4.0

sciurus·Oct 11, 2019

A few pieces of advice based on running https://github.com/mozilla-services/autopush-rs, which handles tens of millions of concurrent connections across a fleet of small EC2 instances. 1) Consider not running the largest instance you need to handle your workload, but instead distributing it across smaller instances. This allows for progressive rollout to test new versions, reduces the thundering herd when you restart or replace an instance, etc. 2) Don't set up security group rules that limit what addresses can connect to your websocket port. As soon as you do that connection tracking kicks in and you'll hit undocumented hard limits on the number of established connections to an instance. These limits vary based on the instance size and can easily become your bottleneck. 3) Beware of ELBs. Under the hood an ELB is made of multiple load ba

Read the rest

lancers and is supposed to scale out when those load balancers hit capacity. A single load balancer can only handle a certain number of concurrent connections. In my experience ELBs don't automatically scale our when that limit is reached. You need AWS support to manually do that for you. At a certain traffic level, expect support to tell you to create multiple ELBs and distribute traffic across them yourself. ALBs or NLBs may handle this better; I'm not sure. If possible design your system to distribute connections itself instead of requiring a load balancer. 2 and 3 are frustrating because they happen at a layer of EC2 that you have little visibility into. The best way to avoid problems is to test everything at the expected real user load. In our case, when we were planning a change that would dramatically increase the number of clients connecting and doing real work, we first used our experimentation system to have a set of clients establish a dummy connection, then gradually ramped up that number of clients in the experiment as we worked through issues.

In 600k concurrent websocket connections on AWS using Node.js (2015)