Password Pusher Logo
Password Pusher
Go Ahead. Email Another Password.

Frequently Asked Questions

Trust and Security

Password Pusher exists as a better alternative to emailing passwords.

Emailing passwords is inherently insecure. The greatest risks include:

  • Emailed passwords are usually sent with context to what they go to or can potentially be derived from email username, domain etc…
  • Email is inherently insecure and can be intercepted at multiple points by malicious entities.
  • Emailed passwords live in perpetuity (read: forever) in email archives.
  • Passwords in email can be retrieved and used later on if an email account is stolen, cracked etc..

The same risks persist when sending passwords via SMS, WhatsApp, Telegram, Chat etc… The data can and is often perpetual and out of your control.

By using Password Pusher, you bypass all of this.

For each password posted to Password Pusher, a unique URL is generated that only you will know. Additionally, passwords expire after a predefined set of views are hit or time passed. Once expired, passwords are unequivocally deleted.

If that sounds interesting to you, try it out or see the other frequently asked questions below.

And rightfully so. All good security begins with healthy skepticism of all involved components.

Password Pusher exists as a better alternative to emailing passwords. It avoids having passwords exist in email archives in perpetuity. It does not exist as a end-all security solution.

Password Pusher is open-source so the source can be publicly reviewed and can alternatively be run internally in your organization.

Passwords are unequivocally deleted from the database once they expire. Additionally, random URL tokens are generated on the fly and passwords are posted without context for their use.

A note for those with an interest in extreme security: there is no way I can reliably prove that the opensource code is the same that runs on (this is true for all sites in reality). The only thing I can provide in this respect is my public reputation on Github, LinkedIn, Twitter and my blog. If this is a concern for you, feel free to review the code, post any questions that you may have and consider running it internally at your organization instead.

Tools, Utilities and Applications

Absolutely. Password Pusher has a number of applications and command line utilities (CLI) that interface with or privately run instances. Push passwords from the CLI, Slack, Alfred App and more.

See our Tools and Applications page for more details.

Yes. Using the previously mentioned tools, many users and organizations integrate Password Pusher into their security policies and processes.

The Tools page outlines the resources available to automate the secure distribution of passwords.

There are no limits currently and I have no intention of adding any. To minimally assure site stability, Password Pusher is configured with a rate limiter by default.

Running Your Own Private Instance

Yes. We provide Docker containers and installation instructions for a wide variety of platforms and services.

tldr; docker run -p 5100:5100 pglombardo/pwpush:latest

Password Pusher supports re-branding "out of the box" allowing you to add a custom logo, text and even change images in the application.

The source code is released under the Apache 2.0 License and that pretty much defines any and all limitations. There are quite a few rebranded and redesigned clone sites of Password Pusher and I welcome them all.

Some organizations are bound by security policies that prohibit the use of public services for sensitive information such as passwords. There are even organizations that require all tools to be on private intranets without access to the outside world.

It's for these reasons that we provide the ability (and encourage) users and organizations to run private instances when needed.

Running an private instance of Password Pusher for your company or organization gives you the peace of mind that you know exactly what code is running. You can configure and run it as you like.

On the other hand, if your instance gets hacked and the encryption broken, malicious entities now have a targeted dictionary of passwords to brute force accounts in your organization. Note that this would be limited to pushes which haven't yet hit their expiration limits.

In this respect, the public instance at may be superior in that it contains only passwords without identifying information mixed among users from around the globe.

The user should carefully weigh the pros and cons and decide which route is best for them. We happily support both strategies.


Absolutely. If you need any resources such as statistics, graphics or anything else, don't hesitate to contact me: pglombardo at

Very likely. I love to hear all ideas and feedback. If you have any, please submit them to the Github repository and I will respond as soon as possible.

This is an opensource project made out of love for technology and a desire to improve the security (and daily lives) of the tech community.

It doesn't make any money but it does incur hosting that are about $50/month for These are happily paid out of pocket by myself for more than 10 years.

If you feel inclined to support Password Pusher, you can sign up to Digital Ocean using the badge below. Password Pusher will get a hosting credit for the first $25 you spend.

DigitalOcean Referral Badge

For other ways to support Password Pusher, see also the "Want to help out?" section on the about page. Thank you! ❤️