Password Pusher 2.17.1 on AWS User Guide

Overview

This guide covers launching and using the Password Pusher 2.17.1 on Ubuntu 24.04 AMI from cloudimg on Amazon EC2. It is one version of the cloudimg identity, secrets and PKI listing on AWS Marketplace; you pick it as the software version when you subscribe and launch.

Password Pusher is an open source application for sending a password or other secret through a link that expires. Paste the secret, choose how many days and how many views it may last, and send the link. When either limit is reached, the secret is deleted from the database and the link only says that it has expired. A passphrase can be added so the link alone is not enough, and the recipient can delete the secret as soon as they have read it.

The cloudimg image is a hardened, ready-to-use Password Pusher server:

• nginx in front, Password Pusher behind it. nginx is the only public listener (ports 80 and 443). Password Pusher (Rails on Puma) listens on 127.0.0.1:5100, the loopback address only, and systemd stops it and its background worker from talking to any other address at all.
• HTTPS from the first boot. The image serves HTTPS from the first boot with a certificate generated on your instance (an end-entity certificate, not a certificate authority). Port 80 redirects to HTTPS. The instance's name is set from its own public address at first boot; you can change it to your own domain.
• Encrypted with your instance's own key. Password Pusher encrypts every secret in the database with Lockbox. First boot generates this instance's own Lockbox key, its own Rails secret_key_base and its own Rails credentials key, so no two instances share a key, and the key upstream ships as a default cannot read anything on this instance. The key is read from a file that only the service account can read, never from an environment variable or a command line.
• Expired means deleted. When a secret expires (by views, by days, or by the recipient's delete button), the encrypted payload is removed from its database row, and SQLite's secure_delete overwrites the freed space. A background worker expires secrets on time even if nobody opens the link again.
• Anonymous, with nothing to sign in to. The image runs Password Pusher with logins and sign-ups switched off: there are no accounts, no administrator password and no first-run wizard. Anyone who can reach the address can push a text secret, which is how this mode is designed; the security group decides who that is (Step 8).
• Abuse limits. nginx allows 12 state-changing requests (creating, deleting or unlocking a secret) per minute per client address, with a burst of 20, and 20 requests per second overall. A secret is at most 1 MB. URL pushes (an anonymous open redirect) and file pushes (whose files upstream stores unencrypted) are switched off. A page on another website cannot create or unlock secrets here.
• Real client addresses, fixed host name. The rate limit and the audit log use the real TCP peer address; Rails trusts no proxy but the local nginx, so a forged X-Forwarded-For header changes nothing. Requests for any host name other than the instance's configured names are dropped.
• Browser hardening. Password Pusher's own Content-Security-Policy, and an nginx policy that refuses framing. Share links never leave the site in a Referer header. The nginx access log records /p/<token> instead of secret links, nginx's error log is limited to critical errors, and Password Pusher logs at warn.
• Security fixes, applied cleanly. Password Pusher 2.17.1 is the newest release. cloudimg raises the Rails family to 8.1.4.1 and loofah, rails-html-sanitizer and nokogiri to their fixed releases inside 2.17.1's own version constraints (a lock-file update; no application source is changed), and a vulnerability scan of the shipped lock file finds nothing. See Step 12.
• Locked down. TLS 1.2 and 1.3 only; Password Pusher, its worker, nginx and the first-boot service are blocked from the instance metadata service, and the AMI requires IMDSv2.
• Built from source, verified, on a fully patched Ubuntu 24.04 LTS at build time, with unattended security upgrades switched on. See Step 13 for exactly what is installed.

What is on the image: Password Pusher 2.17.1 (from the upstream v2.17.1 tag, in /opt/pwpush/app), Ruby 4.0.9 compiled from the ruby-lang.org release (in /opt/pwpush/ruby), SQLite, nginx from Ubuntu 24.04, cloud-init and the AWS Systems Manager agent. Node.js and Yarn are used at build time only, to build the web assets, and are not on the image.

Default user: ubuntu · Architecture: x86_64 · Recommended instance type: m5.large

Prerequisites

• An AWS account subscribed to the listing, an EC2 key pair and a VPC subnet.
• A security group that allows TCP 22 (SSH) from your own networks only, and TCP 443 (the web app) and TCP 80 (redirects to HTTPS) only from the networks whose people should use this service: your office, your VPN, or your VPC CIDR. Anyone who can reach port 443 can create secret links, so do not open it to 0.0.0.0/0 unless you want a public service. Do not open 5100: Password Pusher listens on the loopback address only.
• For production, a DNS name you control (for example pwpush.example.com) and, ideally, a certificate from a certificate authority. Until then the instance uses its public IP address with its own self-signed certificate.

Step 1: Launch the instance

In the AWS Marketplace listing choose Continue to Subscribe, then Continue to Configuration, pick Password Pusher 2.17.1 on Ubuntu 24.04 as the software version and your Region, then Launch through EC2. Choose m5.large, your key pair, and a security group as above.

With the AWS CLI (replace the values in angle brackets):

aws ec2 run-instances --image-id <ami-id-from-the-listing> --instance-type m5.large \
  --key-name <your-key-pair> --security-group-ids <your-security-group> --subnet-id <your-subnet> \
  --metadata-options HttpTokens=required,HttpEndpoint=enabled \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=password-pusher}]'

First boot takes about half a minute after the instance is running: it generates the keys and the certificate and prepares the database. If you want the instance to use your own name from the start, put it in /etc/cloudimg/pwpush-domain.preset with user data (for example a cloud-init write_files entry); otherwise first boot uses the instance's public IP address (or its private address if it has no public one), and also serves its EC2 public DNS name.

Step 2: Connect to your instance

Operating system	SSH user
Ubuntu 24.04	ubuntu

ssh -i <your-key.pem> ubuntu@<public-ip>

The login message shows the address of the web app.

Step 3: Check the services

systemctl is-active pwpush pwpush-worker nginx

active
active
active

(pwpush-firstboot runs once, on the first boot, and shows inactive on every later boot.)

Only SSH, HTTP and HTTPS are public. Password Pusher listens on the loopback address:

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

LISTEN 0      511          0.0.0.0:80        0.0.0.0:*          
LISTEN 0      4096         0.0.0.0:22        0.0.0.0:*          
LISTEN 0      511          0.0.0.0:443       0.0.0.0:*          
LISTEN 0      1024       127.0.0.1:5100      0.0.0.0:*          
LISTEN 0      511             [::]:80           [::]:*          
LISTEN 0      4096            [::]:22           [::]:*          
LISTEN 0      511             [::]:443          [::]:*

A built-in self-test pushes a secret through nginx that may be viewed once, reads it, checks that a second read finds it expired with no payload, and that its database row no longer holds the encrypted payload:

sudo pwpush-selftest

pwpush-selftest: created (1 view), first read 200 + identical payload, second read expired with no payload, database row emptied
PWPUSH_SELFTEST_OK

Step 4: Read the address and the certificate fingerprint

sudo cat /root/pwpush-info.txt

The file (root only, mode 0600) gives this instance's address, the SHA-256 fingerprint of its certificate and where the settings, the encryption key and the database are. There is no administrator password to collect: this Password Pusher has no accounts.

# Password Pusher 2.17.1 on this instance. Open the URL in a browser; there is no account or password (anonymous).
# The certificate is self-signed for this instance: compare its SHA-256 fingerprint with PWPUSH_TLS_SHA256 below.
# Pushes are encrypted with this instance's own key (/etc/pwpush/master.key): back it up with the database.
PWPUSH_URL=https://198.51.100.24/
PWPUSH_HOST=198.51.100.24
PWPUSH_TLS_SHA256=CC:31:61:86:...:(64 hex digits in pairs)
PWPUSH_ADDRESS_SOURCE=imdsv2-public-ipv4
PWPUSH_SETTINGS=/etc/pwpush/pwpush.env
PWPUSH_MASTER_KEY_FILE=/etc/pwpush/master.key
PWPUSH_DATABASE=/var/lib/pwpush/storage/db/production.sqlite3
GUIDE=https://www.cloudimg.co.uk/guides/password-pusher-2-17-1-on-ubuntu-24-04-aws/

The certificate is self-signed and unique to your instance, so your browser warns about it. Open the certificate details in the browser, check that its SHA-256 fingerprint matches PWPUSH_TLS_SHA256, and only then continue. Do not add the certificate to your operating system's trust store; for production, replace it with a certificate from a certificate authority (Step 11). The certificate is an end-entity certificate for this instance's names only. Copy it to your home directory so that the commands in this guide can use it as their trust anchor:

sudo cat /etc/ssl/pwpush/pwpush.crt > ~/pwpush-instance.crt
openssl x509 -in ~/pwpush-instance.crt -noout -subject -ext basicConstraints,keyUsage,extendedKeyUsage,subjectAltName

subject=CN = 198.51.100.24, O = cloudimg
X509v3 Subject Alternative Name: 
    IP Address:198.51.100.24, DNS:ec2-198-51-100-24.compute-1.amazonaws.com, IP Address:172.31.16.20, IP Address:127.0.0.1
X509v3 Basic Constraints: critical
    CA:FALSE
X509v3 Key Usage: critical
    Digital Signature, Key Encipherment
X509v3 Extended Key Usage: 
    TLS Web Server Authentication

Step 5: Push a secret

Browse to the PWPUSH_URL address. Type or paste the secret (or use Generate Password), and use the sliders to choose how many days and how many views the link may last, whichever comes first (here 1 day and 1 view). The Qr Codes tab pushes text as a QR code instead. The screenshots in this guide were taken on an instance set to the name pwpush.example.com (Step 11); yours shows its own address until you set a name:

Choose Push It!. The secret is encrypted with this instance's key and stored. The page shows the secret link with a copy button, a QR code of the link, a ready-to-send message that includes the link and its expiry, and the limits. Send the link to the recipient over any channel, and do not open it yourself:

The link ends in /r: it opens a retrieval step first, so a chat or email program that previews links does not use up a view. The recipient opens it and confirms:

They choose Click Here to Proceed and see the secret, blurred until they click it, with Copy to Clipboard buttons and how long the link has left:

The one allowed view is now used up and the secret is deleted. Opening the same link again shows that it has expired; if the recipient sees this the first time they open a link, someone else has opened it:

Step 6: Passphrases and deleting a secret

Put a passphrase in the Passphrase field when you push a secret, and send it to the recipient by a different channel from the link. The link then asks for the passphrase before anything is shown:

A wrong passphrase is refused with That passphrase is incorrect; the right one shows the secret. While views are left (this push allowed 2), the recipient can delete it at once instead of waiting for it to expire:

Password Pusher asks them to confirm. Delete removes the secret from the database, even though a view and a day were left, and the link shows that it has expired from then on:

Step 7: Use the JSON API from scripts

Password Pusher has a JSON API. On the instance, connect to nginx on the loopback address (--connect-to; the security group normally does not let an instance reach its own public address) with the instance certificate as the trust anchor. Create a secret that lasts 1 day or 2 views, read it twice, and read it a third time:

U=$(sudo sed -n 's/^PWPUSH_URL=//p' /root/pwpush-info.txt)
jq -n --arg p 'api-test secret' '{password: {payload: $p, expire_after_days: 1, expire_after_views: 2}}' > ~/push.json
R=$(curl -s --cacert ~/pwpush-instance.crt --connect-to ::127.0.0.1:443 -H 'Content-Type: application/json' --data-binary @"$HOME/push.json" "${U}p.json")
echo "${R}" | jq -c '{html_url, expire_after_days, expire_after_views, expired}'
T=$(echo "${R}" | jq -r .url_token)
for n in 1 2 3; do curl -s --cacert ~/pwpush-instance.crt --connect-to ::127.0.0.1:443 "${U}p/${T}.json" | jq -c '{payload, expired, views_remaining}'; done
rm -f ~/push.json

{"html_url":"https://198.51.100.24/p/_buo1vuuuava6h0/r","expire_after_days":1,"expire_after_views":2,"expired":false}
{"payload":"api-test secret","expired":false,"views_remaining":1}
{"payload":"api-test secret","expired":false,"views_remaining":0}
{"payload":null,"expired":true,"views_remaining":0}

html_url is the link to send. The response also carries url_token, the secret part of the link; give the link to the recipient instead of reading the secret yourself, because every read through the API uses up a view just as the page does.

Requests a page on another website makes are refused before they reach Password Pusher (their Origin is not this instance, so nginx answers 403), and a request for a host name the instance does not serve gets no answer at all (curl reports 000):

U=$(sudo sed -n 's/^PWPUSH_URL=//p' /root/pwpush-info.txt)
curl -s --cacert ~/pwpush-instance.crt --connect-to ::127.0.0.1:443 -o /dev/null -w '%{http_code}\n' -H 'Content-Type: application/json' \
  -H 'Origin: https://evil.example' --data '{"password":{"payload":"x"}}' "${U}p.json"
curl -s -k --connect-to ::127.0.0.1:443 -o /dev/null -w '%{http_code}\n' https://unknown.example/ || echo "(no answer: nginx closed the connection)"

403
000
(no answer: nginx closed the connection)

Step 8: Limits and who can create pushes

The appliance settings are in /etc/pwpush/pwpush.env (root and the pwpush group, mode 0640). It holds no secret:

sudo grep -E '^PWP__' /etc/pwpush/pwpush.env

PWP__DISABLE_LOGINS=true
PWP__DISABLE_SIGNUPS=true
PWP__ALLOW_ANONYMOUS=true
PWP__ENABLE_URL_PUSHES=false
PWP__ENABLE_FILE_PUSHES=false
PWP__ENABLE_QR_PUSHES=true
PWP__NOTIFY_BY_EMAIL__ENABLED=false
PWP__PROMETHEUS__ENABLED=false
PWP__CLOUDFLARE_PROXY=false
PWP__HOST_PROTOCOL=https
PWP__LOG_LEVEL=warn

nginx limits how fast one client address can create, unlock or delete secrets, and how many requests it can make in all. The address is the real TCP peer; a forged X-Forwarded-For header neither changes it nor appears in the log:

grep -E 'limit_req_zone' /etc/nginx/conf.d/cloudimg-pwpush.conf
grep -E 'client_max_body_size|limit_req ' /etc/nginx/sites-available/pwpush

limit_req_zone $cloudimg_pwpush_write_key zone=pwpush_write:10m rate=12r/m;
limit_req_zone $binary_remote_addr zone=pwpush_all:10m rate=20r/s;
    client_max_body_size 2m;
        limit_req zone=pwpush_write burst=20 nodelay;
        limit_req zone=pwpush_all burst=100 nodelay;

A client over the limit gets HTTP 429 until its allowance refills; other clients are not affected. The access log records secret links without their tokens:

sudo tail -3 /var/log/nginx/access.log | sed -E 's/^[0-9a-f.:]+ /<client-ip> /'

<client-ip> - [08/Nov/2026:08:37:21 +0000] "GET /p/<token>.json HTTP/2.0" 200 474 "curl/8.5.0"
<client-ip> - [08/Nov/2026:08:37:23 +0000] "POST /p.json HTTP/2.0" 403 146 "curl/8.5.0"
<client-ip> - [08/Nov/2026:08:37:23 +0000] "GET / HTTP/2.0" 444 0 "curl/8.5.0"

Who can create secret links is decided by your security group. Keep the 443 and 80 rules limited to the networks that should use the service. To put the service on a private address only, launch it in a private subnet (or remove the public IP) and allow 443 from your VPC CIDR or VPN range.

Step 9: Expiry defaults and other settings

New pushes default to 7 days and 5 views, with the retrieval step on and the recipient allowed to delete the secret; a sender can choose up to 90 days and 100 views. Password Pusher reads its settings from its own settings.yml, and any of them can be overridden with a PWP__ line in /etc/pwpush/pwpush.env (the name is the setting's path in capitals, joined with __). The settings Password Pusher is running with:

sudo pwpush-rails runner 'pw = Settings.pw; puts({days_default: pw.expire_after_days_default, days_max: pw.expire_after_days_max, views_default: pw.expire_after_views_default, views_max: pw.expire_after_views_max, retrieval_step: pw.retrieval_step_default, deletable_by_viewer: pw.deletable_pushes_default}.inspect)'

Password Pusher Version: 2.17.1
{days_default: 7, days_max: 90, views_default: 5, views_max: 100, retrieval_step: true, deletable_by_viewer: true}

For example, to make new pushes default to 1 day and 1 view (the sender can still choose more):

printf '%s\n' 'PWP__PW__EXPIRE_AFTER_DAYS_DEFAULT=1' 'PWP__PW__EXPIRE_AFTER_VIEWS_DEFAULT=1' | sudo tee -a /etc/pwpush/pwpush.env >/dev/null
sudo systemctl restart pwpush pwpush-worker

Every setting is described in /opt/pwpush/app/config/settings.yml. Keep PWP__DISABLE_LOGINS, PWP__DISABLE_SIGNUPS and PWP__ALLOW_ANONYMOUS as they are: this image has no mail server for account sign-ups, and with logins on Password Pusher starts a first-run administrator wizard that anyone who reaches the page first could complete.

URL pushes are off because an anonymous URL push lets anyone create a redirect from your domain to any site. If only trusted networks can reach the instance and you want them:

sudo sed -i 's/^PWP__ENABLE_URL_PUSHES=false$/PWP__ENABLE_URL_PUSHES=true/' /etc/pwpush/pwpush.env
sudo systemctl restart pwpush pwpush-worker

sudo pwpush-rails ARGS runs bin/rails ARGS as the pwpush user with these settings, for example sudo pwpush-rails runner 'puts Push.count'.

Step 10: The encryption key, the database and backups

Secrets are stored in the SQLite database /var/lib/pwpush/storage/db/production.sqlite3, encrypted with the Lockbox key in /etc/pwpush/master.key. The Rails credentials (with this instance's secret_key_base) are in /opt/pwpush/app/config/credentials/. Only the pwpush user can read the key files:

sudo stat -c '%a %U:%G %n' /etc/pwpush/master.key /etc/pwpush/pwpush.env /opt/pwpush/app/config/credentials/production.key \
  /opt/pwpush/app/config/credentials/production.yml.enc /var/lib/pwpush/storage/db/production.sqlite3

400 pwpush:pwpush /etc/pwpush/master.key
640 root:pwpush /etc/pwpush/pwpush.env
400 pwpush:pwpush /opt/pwpush/app/config/credentials/production.key
440 root:pwpush /opt/pwpush/app/config/credentials/production.yml.enc
600 pwpush:pwpush /var/lib/pwpush/storage/db/production.sqlite3

The database never holds a secret in plain text, so a copy of the database alone reveals nothing; a copy together with master.key reveals every secret that has not expired yet. Keep master.key with your backups of the database, and protect both: without the key, the stored secrets cannot be read. To back up, stop the service briefly and copy both (replace <backup-dir> with a directory only root can read):

sudo systemctl stop pwpush pwpush-worker
sudo install -d -m 0700 <backup-dir>
sudo cp -p /etc/pwpush/master.key /var/lib/pwpush/storage/db/production.sqlite3 <backup-dir>/
sudo systemctl start pwpush pwpush-worker

Secret links are short-lived by design, so many teams do not back up this service at all: if the instance is lost, senders push the secret again.

Step 11: Use your own domain and certificate

Point a DNS record (for example pwpush.example.com) at the instance, then give the new name first and any other names or addresses that should keep working after it:

sudo pwpush-set-domain pwpush.example.com "$(sudo sed -n 's/^PWPUSH_HOST=//p' /root/pwpush-info.txt)"

nginx then serves only those names and a new self-signed certificate is issued for them; /root/pwpush-info.txt shows the new address and fingerprint. Secret links use the name the sender browsed to, so open Password Pusher at https://pwpush.example.com/. Run pwpush-set-domain again if a stop and start changes the instance's public IP address and you use the address rather than a DNS name.

To use a certificate from a certificate authority, run pwpush-set-domain with your name first, then replace /etc/ssl/pwpush/pwpush.crt (full chain) and /etc/ssl/pwpush/pwpush.key (mode 0600, root) and run sudo systemctl reload nginx. Running pwpush-set-domain again issues a new self-signed certificate, so put your certificate back after any later run.

Step 12: Security notes

• Metadata service. The AMI requires IMDSv2. Password Pusher and its worker may talk to the loopback address only, and nginx and the first-boot service are denied the instance metadata addresses by systemd. Password Pusher sends no mail and makes no outbound requests.

systemctl show -p IPAddressAllow -p IPAddressDeny pwpush pwpush-worker
systemctl show -p IPAddressDeny nginx pwpush-firstboot

IPAddressAllow=127.0.0.0/8 ::1/128
IPAddressDeny=0.0.0.0/0 ::/0

IPAddressAllow=127.0.0.0/8 ::1/128
IPAddressDeny=0.0.0.0/0 ::/0
IPAddressDeny=2001::/32 64:ff9b::/96 2002::/16 169.254.169.254/32 168.63.129.16/32 64:ff9b:1::/48 ::ffff:0.0.0.0/96 fd00:ec2::254/128

IPAddressDeny=64:ff9b:1::/48 64:ff9b::/96 2002::/16 168.63.129.16/32 2001::/32 169.254.169.254/32 ::ffff:0.0.0.0/96 fd00:ec2::254/128

• Where the keys live. Password Pusher reads its Lockbox key from /etc/pwpush/master.key (mode 0400, pwpush); the environment only names the file (PWPUSH_MASTER_KEY_FILE), so the key is in no process environment, command line, journal or log. The Rails credentials key is production.key (mode 0400, pwpush). All three keys are generated on your instance at first boot. Core dumps are off for Password Pusher and nginx, and the instance has no swap.
• Response headers. Every page is served with Password Pusher's own Content-Security-Policy, nginx's frame-ancestors 'none' policy, X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy: same-origin (a secret link is never sent to another site; the page's own forms keep their Origin), Cross-Origin-Opener-Policy: same-origin and Strict-Transport-Security.
• Ruby gem security fixes. Password Pusher 2.17.1's own lock file pins Rails 8.1.4, which has published advisories, including a critical one in Active Storage. cloudimg updates the lock file inside 2.17.1's own version constraints (bundle lock --update --conservative): Rails 8.1.4.1, loofah 2.25.3, rails-html-sanitizer 1.7.2 and nokogiri 1.19.7. A scan of 2.17.1's original lock file finds 32 advisories; a scan of the shipped lock file finds none. The exact change is in /usr/share/doc/cloudimg-pwpush/gemfile-lock.diff. One advisory remains in the JavaScript build tools (minimatch, a denial of service through a crafted pattern): those tools run only at build time, on the build's own files, and are not on the image.
• Upgrades. Ubuntu security updates (including nginx) install automatically. Password Pusher and its Ruby are built for this image, so cloudimg publishes new versions of this AMI for new Password Pusher releases and gem security fixes.

Step 13: Licences and source

Password Pusher is licensed under the Apache License 2.0. The image ships its licence and records exactly what it was built from:

cat /usr/share/doc/cloudimg-pwpush/SOURCE.txt
/opt/pwpush/ruby/bin/ruby -v

Password Pusher 2.17.1 (Apache-2.0)
source: https://github.com/pglombardo/PasswordPusher.git tag v2.17.1 = commit 6219d332864f4baecde7742e732231063b9a990a (pinned by tag and sha)
license sha256: aa870dca9a9c4c65e745d961d15c01e53a0846db155995ad23fdcf5c698802a4
Gemfile.lock: the tag lock (sha256 18de9972a09779a8651d0b6ad3d96fa5cabeec6d4c74aaaef0b37124238ec1a5) + the cloudimg in-range security raises (recipe file password-pusher-aws-gemfile-lock.diff, sha256 bdec351e9c54f163d4205ff558918fab5e3c15dc768185f4859a11478b6ec478) = sha256 f0d4288a3030b8cb363c458d9a3b47205793fd7ddc9b85d20d5c6f44020625e8
ruby: https://cache.ruby-lang.org/pub/ruby/4.0/ruby-4.0.9.tar.gz (sha256 c35350682ff050b79702d57ade4516e7336063f510155d19fb2fb5b3f3909511), compiled from source
assets built with node v24.22.2 (sha256 48cc0e21e048790e54c0cf5749c2725005313d652651c40b7a21feb9697aaf75) + yarn 1.22.22 (sha256 c17d3797fb9a9115bf375e31bfd30058cac6bc9c3b8807a3d8cb2094794b51ca); neither ships
ruby 4.0.9 (2026-10-23 revision 3e93b23afc) +PRISM [x86_64-linux]

cloudimg builds Password Pusher from the upstream v2.17.1 tag, pinned to its commit; every download is checked against a fixed SHA-256, and Node.js is also checked against its signed checksum list. A different file stops the build. The licence text is in /usr/share/doc/cloudimg-pwpush/LICENSE-PasswordPusher-Apache-2.0.txt; Ruby (Ruby licence or BSD-2-Clause) and the gems keep their own licences, and nginx is the Ubuntu package (/usr/share/doc/nginx/copyright). Password Pusher is a trademark of its respective owner. All product and company names are trademarks or registered trademarks of their respective holders; cloudimg is not affiliated with or endorsed by them.

Support

cloudimg supports this image: email support@cloudimg.co.uk. See the identity, secrets and PKI listing guide for the other versions in this listing.