A Single German IP

For over a year, a single IP from Germany has been generating 8,000–10,000 anonymous pushes daily on pwpush.com, far exceeding the activity of any other single IP. Initially, I wondered if this was spam or abuse, but it could also have been a legitimate automated use case—who’s to say? With no complaints or harm reported, I let it slide.

Then, a few weeks ago, this IP ramped up to 90,000–100,000 pushes per day, dwarfing all other activity.

More recently, it spiked to a staggering ~200,000 pushes daily, pushing our system to its limits. This surge began to impact the experience for other users, so I had to take action.

Here’s the story, along with some context about how Password Pusher handles push expiration and what we’ve done to keep the service running smoothly.

How Push Expiration Works

In Password Pusher, pushes (and their associated requests) are designed to expire automatically based on either a view limit or a duration limit. Once a limit is reached, the secret URL self-destructs, ensuring sensitive data doesn’t linger.

  • View-Based Expiration: This is straightforward. When a push reaches its final allowed view, the application displays the payload and immediately deletes the push.
  • Duration-Based Expiration: This requires periodic scans. Background jobs run at intervals to identify pushes that have exceeded their duration and trigger their deletion.

To ensure no expired pushes slip through, we re-verify expiration limits whenever a viewer requests a push. If the limits are exceeded, the push is deleted on the spot, and the viewer sees an expiration message. This approach guarantees that expiration rules are always enforced, even if a background job hasn’t yet processed a push.

The Impact of the Anonymous IP

As the IP’s activity surged to ~200,000 pushes per day, our background expiration jobs took longer to complete. This increased system load and began affecting other users’ experience. While I’d like to believe there was a valid use case behind this activity, the strain it placed on Password Pusher’s infrastructure was undeniable.

Of course I can scale out more workers and increase resources but this all has a financial cost. For the single anonymous source with unknown motives, this wasn’t an option.

So to address this, I made the tough decision to block the IP—a step I’ve rarely taken. I also optimized the performance of the background expiration job and tightened API throttling to better manage high-volume usage. These changes have helped stabilize the system and ensure a smoother experience for all users.

Looking Ahead

Password Pusher is an open-source project at its core, built by the team at Apnotic to serve the community.

We’re committed to providing anonymous access and supporting diverse use cases, but we also have to prioritize the availability and performance of the service for everyone.

A Message to the Owner of that IP

If you’re the user behind this IP and have a legitimate use case, please reach out! I’d be happy to discuss how we can support your needs without compromising the experience for others.

You can contact me directly, and we’ll work to find a solution.

Alternatively, if your use case involves high-volume pushes, you might consider self-hosting your own instance of Password Pusher to better suit your needs. Here’s how you can get started:

Run Your Own Ephemeral Instance

Set up a DNS record to point to your server (e.g., pwpush.example.com).

Run the following command:

docker run -d -p "80:80" -p "443:433" --env TLS_DOMAIN=pwpush.example.com pglombardo/pwpush:latest

Browse to https://pwpush.example.com.

Or Alternatively

Use one of our production-ready Docker Compose files with persistent databases for a more robust setup.

Thank you to our amazing community for your continued support. Password Pusher thrives because of you.