Pingvin Share on Ubuntu 24.04 on Azure User Guide
Overview
Pingvin Share is an open source, self hosted file sharing platform and a privacy friendly alternative to public file transfer services. Upload files, generate secure share links with optional passwords, expiration dates and view limits, and let recipients download without creating an account. Reverse shares let you invite others to upload files directly to you. The cloudimg image delivers Pingvin Share fully installed and configured on Ubuntu 24.04 as a Next.js frontend and a NestJS backend on Node.js behind an nginx reverse proxy, so a complete file sharing platform is running within minutes of launch. Backed by 24/7 cloudimg support.
Pingvin Share is licensed under the BSD 2-Clause License. All product and company names are trademarks or registered trademarks of their respective holders. This image repackages the upstream open source release (version 1.13.0) with cloudimg's provisioning and support.
What is included:
- Pingvin Share 1.13.0, built from source on Node.js 22 LTS
- nginx as a reverse proxy on port 80, forwarding
/api/*to the backend and everything else to the frontend, tuned for large uploads - All persistent data (the
pingvin-share.dbSQLite database and every uploaded share file) on a dedicated, independently resizable Azure data disk mounted at/data/pingvin - A per-VM administrator account created on first boot, with a random password written to a root-only file, so no default or shared login ships in the image
pingvin-share-backend.service,pingvin-share-frontend.serviceandnginx.serviceas systemd units, enabled and active- 24/7 cloudimg support

Prerequisites
An active Azure subscription, an SSH key pair, and a VNet plus subnet in the target region. Standard_D2s_v3 (2 vCPU / 8 GiB RAM) is a good starting point; scale up for heavier upload activity or more users. NSG inbound: allow 22/tcp from your management network and 80/tcp (HTTP) from your users. Add 443/tcp if you enable HTTPS. The backend API on 8080 and the frontend on 3333 are internal and never exposed by the NSG.
Step 1 — Deploy from the Azure Marketplace
Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Pingvin Share by cloudimg, and select Create. On Basics pick your subscription, resource group, region and size; under Administrator account choose SSH public key and paste your key; under Inbound port rules allow SSH (22) and HTTP (80). Then Review + create and Create.
Step 2 — Deploy from the Azure CLI
az vm create \
--resource-group <your-rg> \
--name pingvin-share \
--image <marketplace-image-urn> \
--size Standard_D2s_v3 \
--admin-username azureuser \
--generate-ssh-keys \
--public-ip-sku Standard
Open HTTP to reach the web UI:
az vm open-port --resource-group <your-rg> --name pingvin-share --port 80 --priority 900
Step 3 — Connect to your VM
ssh azureuser@<vm-public-ip>
Step 4 — Confirm the services are running
The three services that back Pingvin Share should all report active, and the unauthenticated /api/health health endpoint answers through nginx on port 80:
systemctl is-active pingvin-share-backend pingvin-share-frontend nginx
curl -s http://127.0.0.1/api/health; echo
Expected: three lines of active, then OK. The frontend listens only on the loopback address 127.0.0.1:3333 and the backend on :8080; nginx on port 80 is the only exposed application port, so the app servers are never reachable directly from the network.

Step 5 — Retrieve your administrator password
On the first boot of every VM, a one-shot service (pingvin-share-firstboot.service) starts the backend, which creates the database and generates a fresh application secret unique to that VM, then registers an administrator account with a random password. No shared or default password ships in the image.
sudo cat /root/pingvin-share-credentials.txt
The file (mode 0600, root only) contains the sign-in URL, the administrator username (admin) and the generated password.
You can prove the sign-in round-trip from the VM's own shell. This reads the per-VM password and posts a real sign-in; a wrong password is rejected with HTTP 401 and the correct password answers HTTP 200:
PASS=$(sudo grep '^pingvin.admin.pass=' /root/pingvin-share-credentials.txt | cut -d= -f2-)
echo -n 'health -> HTTP '; curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1/api/health
echo -n 'bad pass -> HTTP '; curl -s -o /dev/null -w '%{http_code}\n' -X POST -H 'Content-Type: application/json' -d '{"username":"admin","password":"wrong"}' http://127.0.0.1/api/auth/signIn
echo -n 'admin -> HTTP '; curl -s -o /dev/null -w '%{http_code}\n' -X POST -H 'Content-Type: application/json' -d "{\"username\":\"admin\",\"password\":\"$PASS\"}" http://127.0.0.1/api/auth/signIn
Expected: health -> HTTP 200, bad pass -> HTTP 401, and admin -> HTTP 200, confirming the password in the file signs in.

Step 6 — Sign in and create a share
Browse to http://<vm-public-ip>/, choose Sign in, and enter admin with the password from the credentials file. To create a share, open Upload, drag your files into the drop zone, then set an optional password, expiration date and visitor limit and generate a secure link to send to recipients.

Step 7 — Manage your shares and administer the platform
Open My shares to see every share you have created, copy or revoke its link, and track downloads. Reverse shares let you generate an upload link so external parties can send files to you without an account.

As the administrator you also get an Administration area. From User management you can create additional users, grant or revoke admin rights, and remove accounts; the configuration section controls registration, SMTP email, OAuth providers and storage back ends.

Step 8 — Confirm the version, the stack and the data disk
node --version
curl -s http://127.0.0.1/api/health; echo
findmnt -no SOURCE,TARGET,FSTYPE /data/pingvin
Expected: Node.js v22, OK from the health endpoint, and /data/pingvin mounted from the dedicated data disk (/dev/sdc, ext4). The SQLite database and all uploaded files live on that disk, which is independently resizable and survives instance replacement — resize it from the Azure portal if you need more room.

First-boot service and security model
A one-shot pingvin-share-firstboot.service runs after the network is up. It starts the backend (which creates the SQLite database and seeds a fresh per-VM application secret), registers an administrator with a random password through the application's own sign-up endpoint, resolves the instance address from the Azure instance metadata service, writes the credentials file at mode 0600 (root only) and drops a sentinel so it runs exactly once. The image ships with an empty database and no usable login; the per-VM administrator is created on first boot.
systemctl is-active pingvin-share-firstboot.service
sudo stat -c '%a %U:%G %n' /root/pingvin-share-credentials.txt
Expected: active, then 600 root:root /root/pingvin-share-credentials.txt.

Enabling HTTPS with your own domain
The image serves the web UI over plain HTTP on port 80. For a browser-trusted certificate, point a DNS record at the VM, open port 443 in the NSG, and install a certificate from your CA (for example 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 updates the nginx site to serve your domain certificate. Pingvin Share is served behind the proxy on loopback, so no application configuration change is needed; your file sharing platform is then reachable over HTTPS at your domain.
Backup and maintenance
Pingvin Share stores everything, including the pingvin-share.db database and every uploaded file, under /data/pingvin on the dedicated data disk, so a backup is a single directory. Snapshot the data disk and OS disk from the Azure portal for a full point-in-time copy, or archive the tree:
sudo tar -C /data -czf /var/backups/pingvin-$(date +%F).tar.gz pingvin
Keep the OS current with sudo apt-get update && sudo apt-get upgrade; the image ships with unattended security updates enabled. Review the Pingvin Share documentation before moving between releases, and always back up before an upgrade.
Support
This image is backed by 24/7 cloudimg support for deployment and initial configuration, retrieving the first-boot administrator password, reverse proxy and TLS termination, SMTP email and OAuth provider configuration, S3-compatible storage back ends, SQLite database administration and backups, performance tuning and storage administration. Email support@cloudimg.co.uk or use the live chat in the support portal; critical issues receive a one-hour average response.