WeddingShare on Ubuntu 24.04 on Azure User Guide

Overview

WeddingShare is an open source, self hosted way to gather and share the photos and memories from your big day. You create one or more galleries, then share each gallery with a simple link or a printed QR code you can drop on the tables at your venue. Your guests open it on their phones and upload the photos and short video clips they took, and leave a message in the guestbook, all without creating an account. You keep control from a private admin area where you review and approve pending uploads, arrange galleries and change settings. It suits weddings, but works just as well for parties, reunions and any event where you want everyone's photos collected in one place you own.

This cloudimg image builds WeddingShare 1.8.2 from its official source (recorded in /opt/weddingshare/VERSION) and runs it under systemd as the unprivileged weddingshare system user. Because WeddingShare targets an end of life .NET release, this image runs it on the current .NET 10 LTS runtime, installed from Ubuntu's own package feed so it keeps receiving security updates. The application listens only on the local machine, and an nginx reverse proxy terminates TLS and is the single public entry point. A unique administrator password and encryption key are generated on the first boot of every VM, so no shared credential ships in the image. Backed by 24/7 cloudimg support.

Secure by default. WeddingShare ships with a built in administrator account and an encryption secret that both have well known default values (admin / admin, and the literal ChangeMe), which anyone could use against an unconfigured instance. This image never ships those defaults. On each virtual machine's first boot, before the site is exposed, a unique administrator password and a unique encryption key are generated and written to a root only file, and the well known defaults are rejected. The administration area is protected by that per machine password, while the guest upload flow stays open by design so your guests can contribute without signing in. The application itself is bound to 127.0.0.1 and only the nginx reverse proxy is exposed, serving the gallery over TLS out of the box with a certificate generated on first boot.

What is included:

• WeddingShare 1.8.2 built from the official source and published for the .NET 10 LTS runtime
• A dedicated weddingshare systemd service, hardened with NoNewPrivileges, PrivateTmp, ProtectSystem and a writable paths allowlist, plus automatic restarts
• An nginx reverse proxy that terminates TLS on port 443 and proxies to the loopback application, with a plain port 80 that serves a health endpoint and redirects everything else to HTTPS
• ffmpeg for generating thumbnails of uploaded video clips
• A unique administrator password and encryption key generated on first boot and written to /root/weddingshare-credentials.txt
• A fully patched Ubuntu 24.04 LTS base with unattended security upgrades enabled

Prerequisites

• An Azure subscription and either the Azure Portal or the Azure CLI
• A network security group that allows inbound TCP 22 (SSH) and 443 (the WeddingShare site and guest uploads over TLS). Port 80 is optional and only redirects to HTTPS plus serves a health probe
• Recommended VM size: Standard_B2s (2 vCPU, 4 GB). WeddingShare is light; for very large events with many high resolution photos and videos, choose a larger size and expand the OS disk so there is room for the uploads

Step 1 - Launch the VM

Azure Portal

1. Open the WeddingShare on Ubuntu 24.04 LTS offer from cloudimg on the Azure Marketplace and select Get It Now, then Create.
2. Choose your subscription, resource group and region, and a VM size. Standard_B2s is a good starting point.
3. Under Networking, allow inbound 22 and 443.
4. Review and create, then download or select your SSH key pair.

Azure CLI

az vm create \
  --resource-group my-weddingshare-rg \
  --name weddingshare \
  --image cloudimg:weddingshare:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

az vm open-port --resource-group my-weddingshare-rg --name weddingshare --port 22 --priority 1001
az vm open-port --resource-group my-weddingshare-rg --name weddingshare --port 443 --priority 1002

Accept the marketplace image terms once per subscription with az vm image terms accept --urn cloudimg:weddingshare:default:latest if prompted.

Step 2 - Confirm the services are running

SSH in as azureuser and confirm WeddingShare and nginx are active. WeddingShare listens on the loopback interface only (port 5000), and nginx is the single public entry point on ports 443 and 80:

systemctl is-active weddingshare nginx
sudo ss -tlnp | grep -E ':(80|443|5000) '

Both services report active. WeddingShare is bound to 127.0.0.1:5000 (not reachable off the machine), while nginx listens on 443 and 80.

Step 3 - Retrieve the per-VM administrator password

The administrator password and the encryption key are generated uniquely on this VM's first boot and written to a root only file. The installed WeddingShare version, the .NET runtime and the credentials file are:

cat /opt/weddingshare/VERSION
dotnet --list-runtimes | grep AspNetCore
sudo cat /root/weddingshare-credentials.txt

The file records the admin username (admin), the generated WEDDINGSHARE_ADMIN_PASSWORD and the URL to open in a browser. Keep this password somewhere safe; it is not stored anywhere in the cloudimg image.

Step 4 - Confirm the health endpoint

nginx serves an unauthenticated health endpoint on port 80 for load balancers and probes:

curl -s http://localhost/healthz

It returns ok. This endpoint never touches the application and never requires authentication, so it is safe for an Azure Load Balancer health probe.

Step 5 - Verify the authentication gate from the command line

The public gallery pages are open by design so guests can upload without an account, but the admin area at /Account requires the per VM administrator password. Confirm that an unauthenticated request to the admin area is redirected to the login page, then run the shipped self test, which proves that the upstream default admin / admin is rejected and the per VM password authenticates:

# The admin area is gated: an unauthenticated request is redirected to the login page (HTTP 302)
curl -sk -o /dev/null -w 'unauthenticated /Account -> HTTP %{http_code}\n' https://localhost/Account

# The self test proves: default admin/admin is REJECTED and the per-VM password authenticates
sudo /usr/local/bin/weddingshare-selftest

The unauthenticated admin request returns 302, and the self test prints OK, confirming the upstream default credential is rejected while the per VM password works.

Step 6 - Confirm the public guest surface

The public homepage and the guest gallery pages are served over TLS without a password, so your guests can open a shared link and upload their photos directly:

curl -sk -o /dev/null -w 'public homepage -> HTTP %{http_code}\n' https://localhost/
curl -sk -o /dev/null -w 'guest gallery   -> HTTP %{http_code}\n' 'https://localhost/Gallery?id=celebration'

Both return 200. The site uses a self signed certificate by default, so a browser will warn on first visit; see the production section below for adding a trusted certificate.

Step 7 - Open the site and sign in as the administrator

Open https://<your-vm-public-ip>/ in a browser. Because the certificate is self signed, accept the browser warning to continue (add a real certificate for production, below). The homepage is a Gallery Selector: guests type the name of a gallery (and its secret key, if you set one) to open it.

To manage the site, select the account icon in the top right and choose Login, then sign in with the username admin and the WEDDINGSHARE_ADMIN_PASSWORD from /root/weddingshare-credentials.txt.

Step 8 - Create a gallery and share it

In the admin area, open the Galleries tab and select Create to make a gallery. Give it a name your guests will recognise, for example the couple's names or the event. A secret key is generated for you; you can keep it as a light deterrent or clear it to make the gallery open to anyone with the link.

Each gallery has its own page with a Share Code (a QR code) and share controls. Print the QR code and place it on your tables, or send the link to your guests. When they open it, they see the gallery and an Upload Media area where they can add their photos and short video clips.

Guests can open any photo full size in the built in viewer, download it, or like it, without needing an account.

Step 9 - Moderate guest uploads

By default WeddingShare holds new guest uploads for review so nothing appears in a gallery until you approve it. In the admin area, the Review tab lists pending uploads with approve and reject actions; the Galleries tab manages your galleries and the Users, Resources, Settings, Audit and Data tabs cover accounts, custom branding, site settings, the audit log and import or export.

Security and networking notes

• Only ports 22 and 443 need to be open. Port 80 only redirects to HTTPS and serves the health probe; the application itself is bound to 127.0.0.1:5000 and is never reachable from the network. Never open port 5000 in your network security group.
• Guest uploads are open by design; the admin area is gated. Anyone with a gallery link (and its secret key, if set) can view and upload to that gallery, which is the point of the product. The admin area that creates galleries, moderates uploads and changes settings requires the per VM administrator password. If your VM is reachable from the public internet, restrict inbound access to the networks that need it using the network security group, and set a secret key on galleries you want to keep semi private.
• Change the administrator password from the admin area under Settings, or by setting ACCOUNT_OWNER_PASSWORD in /etc/weddingshare/weddingshare.env and restarting the service. The password is applied to the account on every start.
• Storage grows with uploads. Photos and videos are stored on the VM's own disk under /opt/weddingshare/wwwroot/uploads. For a large event, choose a larger VM size and expand the OS disk before you share the gallery.

Production: add a domain and a trusted certificate

The image serves HTTPS with a self signed certificate so guests see a browser warning. For a production deployment, point a DNS name at the VM and install a trusted certificate. Set your gallery base URL in the admin Settings to your domain so the QR codes and share links use it, then replace the self signed certificate with one from a certificate authority (for example using certbot with the nginx plugin against your-domain).

Troubleshooting

• Service status: systemctl status weddingshare and sudo journalctl -u weddingshare -n 100 --no-pager
• First boot log (password, encryption key and certificate generation): sudo cat /var/log/weddingshare-firstboot.log
• The site is briefly unavailable after a reboot: WeddingShare runs database migrations on start and the site is ready within a few seconds; the /healthz endpoint on port 80 comes up once nginx starts.
• .NET runtime: confirm the runtime with dotnet --list-runtimes | grep AspNetCore (it reports an ASP.NET Core 10 runtime).

Support

Every cloudimg image is backed by 24/7 support. If you have any questions about this WeddingShare image, contact the cloudimg team through the Azure Marketplace listing.

This is a repackaged open source software product with additional charges for cloudimg support services. WeddingShare is a trademark of its respective owner. All product and company names are trademarks or registered trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.