Password Pusher on AWS User Guide

Overview

This guide covers deploying and operating Password Pusher on AWS using the cloudimg AWS Marketplace AMI. Password Pusher is a popular open-source, self-hosted web application for sharing sensitive information securely and temporarily. A sender pushes a password, block of text, a file or a URL and receives a one-time link; the link stops working automatically once it has been viewed a set number of times (default 5) or a set number of days have passed (default 7), whichever comes first, and every push is tracked with an audit trail. It is a simpler, private alternative to emailing credentials or using a public paste service.

The image builds the Password Pusher application reproducibly from source at build time (the exact version and source commit are recorded in /opt/passwordpusher/VERSION). It is a Ruby on Rails app that runs under systemd on the puma web server as the unprivileged passwordpusher system user, bound to loopback only (127.0.0.1:5100). nginx is the sole network-facing surface and terminates TLS on port 443, reverse-proxying to Password Pusher. Data is held in a local SQLite database, and push payloads are encrypted at rest.

This appliance is anonymous by design. It ships with the login and signup system disabled, so there is no admin account and no credential of any kind is ever baked into the image. Pushing a secret needs no login. The only per-instance secrets are generated on first boot for this specific instance and are never shared between instances: the Rails session-signing key (SECRET_KEY_BASE), the database payload-encryption key (PWPUSH_MASTER_KEY), and the self-signed TLS private key (whose Subject Alternative Names include the instance public IP, hostname and 127.0.0.1).

What is included:

• Password Pusher built from source and run under systemd on puma as the unprivileged passwordpusher system user

• The application bound to loopback only (127.0.0.1:5100) — it is never network-exposed directly

• nginx terminating TLS on :443 and reverse-proxying to Password Pusher, with HSTS and sensible security headers

• Port :80 returns a 301 redirect to HTTPS for every path except an unauthenticated /healthz endpoint (HTTP 200) for load balancer probes

• A self-signed TLS certificate regenerated per instance on first boot (SAN includes the instance public IP + hostname) — replace it with your own CA-signed certificate for production

• A local SQLite database with push payloads encrypted at rest using a per-instance key generated on first boot

• A built-in one-time self-test at /opt/passwordpusher/passwordpusher-selftest.sh that proves the self-destruct semantics end to end over TLS

• Ubuntu 24.04 LTS base with latest security patches applied at build time

• 24/7 cloudimg support with a guaranteed 24-hour response SLA

Prerequisites

• An AWS account with permission to launch EC2 instances

• An EC2 key pair for administrative SSH access to the instance

• A security group allowing inbound TCP 443 (HTTPS) and 80 (redirect) from the networks that should reach the service, and 22 (SSH) from your management network only

• A recommended instance type of m5.large or larger

Connecting to your instance

Connect over SSH as the default login user for the OS variant you launched. Use your EC2 key pair and the instance's public IP or DNS name.

Password Pusher is anonymous by design: there is no admin login, no API key and no database password to read.

Step 1: Launch from the AWS Marketplace

1. Locate the Password Pusher listing in the AWS Marketplace and choose Continue to Subscribe, then Continue to Configuration and Continue to Launch.

2. Select the Ubuntu 24.04 delivery option, an instance type (m5.large or larger), your VPC and subnet, and your EC2 key pair.

3. For the security group, allow inbound 443 and 80 from your users, and restrict 22 to your management network.

4. Launch the instance. When it is running, browse to https://<instance-public-ip>/.

Step 2: Verify the Password Pusher and nginx services

SSH in as ubuntu and confirm the services are active, and that Password Pusher is bound to loopback only with nginx the only public listener:

sudo systemctl is-active passwordpusher nginx

sudo ss -tln | grep -E ':5100 |:80 |:443 '

You should see puma on 127.0.0.1:5100 (loopback only), while nginx listens on 0.0.0.0:80 and 0.0.0.0:443.

Step 3: Open the Password Pusher web interface

Browse to https://<instance-public-ip>/. Because the certificate is self-signed and generated per instance, your browser will warn about the certificate the first time. Accept it (or install your own certificate, see Step 9). You are presented with the push form: type or paste your secret, and choose how long it should live using the Expire secret link and delete after day and view sliders.

Step 4: Push a secret and get a one-time link

Select Push It!. Password Pusher stores the secret encrypted and shows a secret link you can share with the recipient, along with a QR code and a ready-to-send message. The message notes that the link will expire after the configured number of views or days, so you should send it to the recipient rather than opening it yourself.

Step 5: Retrieve the secret

When the recipient opens the link, Password Pusher reveals the secret (blurred until they click to reveal it, so it is not exposed to shoulder-surfers or link previews), with a clear note of how many views remain before the link and its content are permanently deleted.

Step 6: Confirm the secret expires

Once the view limit is reached, opening the same link again proves the expiry guarantee: the secret has been consumed and Password Pusher reports that it has expired and is no longer available.

Step 7: Verify the one-time semantics from the command line

The image ships a self-test that proves the self-destruct behaviour end to end over TLS. It pushes a one-time secret through the JSON API, reads it once (returning the secret), then reads it again (returning expired with no payload):

sudo /opt/passwordpusher/passwordpusher-selftest.sh

The expected output confirms the round trip: the first read returns the secret and the second read reports the push expired.

Step 8: Confirm TLS and check the baked version

Confirm that plain HTTP redirects to HTTPS, that the web UI answers over TLS, and inspect the per-instance self-signed certificate and the baked application version:

curl -s -o /dev/null -w '%{http_code} -> %{redirect_url}\n' http://127.0.0.1/

curl -sk -o /dev/null -w '%{http_code}\n' https://127.0.0.1/

sudo openssl x509 -in /etc/nginx/tls/passwordpusher.crt -noout -subject -ext subjectAltName

cat /opt/passwordpusher/VERSION

Step 9: Use your own domain and a trusted certificate (production)

The image ships a self-signed certificate so it is secure out of the box, but browsers will warn on it. For production, point a DNS name at the instance and install a CA-signed certificate. With your own domain you can obtain a free certificate from Let's Encrypt:

sudo apt-get update && sudo apt-get install -y certbot python3-certbot-nginx
sudo certbot --nginx -d your-domain.example.com

Certbot installs the certificate into nginx and sets up automatic renewal. Password Pusher builds share links from the host the browser used, so no application configuration change is needed when you move to your own domain. Alternatively, terminate TLS on an Application Load Balancer with an AWS Certificate Manager certificate in front of the instance.

Step 10: How the appliance is wired

• Password Pusher — a Ruby on Rails application at /opt/passwordpusher/app, run by passwordpusher.service on the puma web server as the unprivileged passwordpusher user, bound to 127.0.0.1:5100, serving both the web UI and the JSON API.

• SQLite — a local database at /opt/passwordpusher/app/storage/db/production.sqlite3. Push payloads are encrypted at rest with a per-instance key. No external database is required.

• nginx — nginx.service, terminating TLS on :443 and reverse-proxying to Password Pusher, redirecting :80 to HTTPS, and serving an unauthenticated /healthz for load balancer probes.

• First boot — password-pusher-firstboot.service runs once on first boot: it resolves the instance public IP via EC2 IMDSv2, generates the per-instance session and payload-encryption keys, regenerates the per-instance self-signed TLS certificate, ensures the database schema is current, starts the services, proves the one-time round trip, and writes /root/passwordpusher-info.txt.

Step 11: Managing the Password Pusher service

sudo systemctl restart passwordpusher

sudo journalctl -u passwordpusher.service --no-pager | tail -20

Adjust application behaviour (for example the default expiry, or enabling accounts) by editing the environment file /etc/passwordpusher/passwordpusher.env, then run sudo systemctl restart passwordpusher. See the Password Pusher documentation for the full list of PWP__ configuration variables.

Step 12: Security recommendations

• Restrict SSH. Allow inbound 22 only from your management network; keep 443 (and 80 for the redirect) open to your users.

• Install a trusted certificate. Replace the self-signed certificate with a CA-signed one (Step 9) so recipients are not trained to click through warnings.

• Keep pushes short lived. The shortest expiry that still works for your recipients gives the smallest window of exposure. Both a day limit and a view limit apply by default.

• Keep the image updated. Unattended security upgrades remain enabled so the OS keeps receiving patches.

• Consider enabling accounts. The appliance ships anonymous by design. If you want per-user audit logs and dashboards, you can enable the login system in /etc/passwordpusher/passwordpusher.env; choose a strong password when you create the first account.

Step 13: Support and Licensing

Password Pusher is open source software distributed under the Apache License 2.0. This image bundles the upstream Password Pusher release unmodified; the licence file is retained on the image under /opt/passwordpusher/LICENSE. cloudimg packaging, hardening and support are provided by cloudimg.

Deploy on AWS

Find this image on the AWS Marketplace and deploy it in minutes. See www.cloudimg.co.uk for the full catalogue.

Need Help?

cloudimg provides 24/7 support with a guaranteed 24-hour response SLA. Contact us through www.cloudimg.co.uk for deployment assistance, configuration help or any questions about this image.