Password Pusher - Self-Hosted One-Time Secret Sharing AMI by cloudimg

This is a repackaged open source software product wherein additional charges apply for cloudimg support services.

Password Pusher is a popular open-source, self-hosted web application for securely sharing sensitive information. A sender pushes a password, a block of text, a file or a URL and receives a one-time link that 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, with a full audit trail. It is a private, self-hosted alternative to emailing credentials or using a public paste service, and this AMI delivers it fully installed and hardened so a working instance is operational within minutes of launch.

Password Pusher ships no prebuilt binary, so a manual install means compiling a matching Ruby, bundling gems, building front-end assets, preparing the database, authoring systemd units and configuring a TLS reverse proxy. This image completes every one of those steps at build time. It also closes the two security gaps a default deployment leaves open: the Rails session key and the database payload-encryption key both default to shared, insecure values upstream, and this image generates a unique random value for each on every instance's first boot.

The Rails application runs under puma as an unprivileged system user, bound to the loopback interface only, and is fronted by an nginx reverse proxy that terminates TLS on port 443 (with a plain-HTTP port 80 that redirects to HTTPS). Payloads are stored in a local SQLite database, encrypted at rest with the per-instance key. systemd starts the application and the web server on boot and restarts them on failure.

This image follows a defence-in-depth approach:

• Anonymous by design: the login and registration system is disabled, so there is no admin account, no API key and no shared credential baked into the image
• Per-instance encryption keys: both the Rails session-signing key and the Lockbox database-encryption key are generated uniquely and at random on each instance's first boot, so no two deployments share key material
• Network isolation: the application binds exclusively to the loopback interface; only the nginx reverse proxy is network-facing, and it serves over TLS
• TLS by default: a self-signed certificate is regenerated on first boot with the instance address in its subject alternative names; because secrets are encrypted server-side, transport encryption is enforced end to end
• Least privilege: the application runs as an unprivileged system user with NoNewPrivileges, PrivateTmp and ProtectSystem set
• Fully patched base: the operating system is brought to a fully patched baseline at build time

Buyers requiring formal compliance documentation should contact cloudimg to discuss specific requirements.

• Secure credential handoff: An IT team sharing a database password or API key with a contractor via a link that self-destructs after a single view, leaving no copy in email or chat
• Onboarding and offboarding: HR or IT sending initial account credentials to new hires over links that expire automatically, with an audit trail of what was retrieved and when
• Support and incident response: An on-call engineer passing a one-time recovery token or certificate to a colleague without it persisting in a ticketing system

Deploy on any EC2 instance type. Use the unauthenticated health endpoint with an Application Load Balancer for availability monitoring. Put your own domain and an ACM or CA-signed certificate on the reverse proxy or an ALB in front. Back up the SQLite database with EBS snapshots or AWS Backup if you need push history to survive an instance replacement.

Open the web interface in your browser, push a password, text, file or URL, and share the returned one-time link. The recipient views the secret once (or within the window you set) and the link then self-destructs. No login is required to push or retrieve a secret.

24/7 technical support by email and chat. Help with deployment, putting your own domain and TLS certificate in front, expiration and retrieval-step configuration, and backup planning for your push database.