SeaweedFS

In the Azure Portal, open Marketplace, search for SeaweedFS, select the SecureAnyCloud publisher entry, and click Create.

On the Networking tab, attach a network security group that allows inbound TCP 22 from your management IP range, TCP 443 (the filer web UI) from your admin networks, and TCP 8333 (the S3 API) from your application networks. The internal master, volume and filer ports are bound to loopback and are never exposed.

Click Review + create and wait for validation, then click Create. Deployment takes around two minutes.

Create the resource group, network, security rules and VM:

RG="seaweedfs-prod" LOCATION="eastus" VM_NAME="seaweedfs-01" ADMIN_USER="azureuser" GALLERY_IMAGE_ID="/subscriptions/<sub-id>/resourceGroups/azure-sac/providers/Microsoft.Compute/galleries/sacGallery/images/seaweedfs-ubuntu-24-04/versions/<version>" SSH_KEY="$(cat ~/.ssh/id_rsa.pub)" az group create --name "$RG" --location "$LOCATION" az network vnet create \
  --resource-group "$RG" \
  --name seaweedfs-vnet --address-prefix 10.95.0.0/16 \
  --subnet-name seaweedfs-subnet --subnet-prefix 10.95.1.0/24 az network nsg create --resource-group "$RG" --name seaweedfs-nsg az network nsg rule create \
  --resource-group "$RG" --nsg-name seaweedfs-nsg \
  --name allow-ssh --priority 100 \
  --source-address-prefixes "<your-mgmt-cidr>" \
  --destination-port-ranges 22 --access Allow --protocol Tcp az network nsg rule create \
  --resource-group "$RG" --nsg-name seaweedfs-nsg \
  --name allow-filer-ui --priority 110 \
  --source-address-prefixes "<your-mgmt-cidr>" \
  --destination-port-ranges 443 --access Allow --protocol Tcp az network nsg rule create \
  --resource-group "$RG" --nsg-name seaweedfs-nsg \
  --name allow-s3-api --priority 120 \
  --source-address-prefixes 10.95.0.0/16 \
  --destination-port-ranges 8333 --access Allow --protocol Tcp az vm create \
  --resource-group "$RG" --name "$VM_NAME" \
  --image "$GALLERY_IMAGE_ID" \
  --size Standard_B2s --storage-sku StandardSSD_LRS \
  --admin-username "$ADMIN_USER" --ssh-key-values "$SSH_KEY" \
  --vnet-name seaweedfs-vnet --subnet seaweedfs-subnet --nsg seaweedfs-nsg \
  --public-ip-sku Standard

Connect as azureuser:

ssh azureuser@<vm-ip>

By the time you connect, seaweedfs.service and nginx.service are running, and seaweedfs-firstboot.service has generated the per-VM credentials and TLS certificate.

Check that both services are active:

sudo systemctl is-active seaweedfs.service nginx.service

The output shows active twice. Confirm the first-boot sentinel:

sudo test -f /var/lib/sac/data/seaweedfs-firstboot.done && echo FIRSTBOOT_DONE

Confirm the public TLS listeners, and check that the internal ports are bound to loopback only:

sudo ss -tln | grep -E ':(443|8333|8888|8334|9333) '

The output shows 0.0.0.0:443 and 0.0.0.0:8333 (public, TLS). The filer 8888, S3 backend 8334 and master 9333 are bound to 127.0.0.1.

Read the credentials file with sudo:

sudo cat /root/seaweedfs-credentials.txt

The file contains the per-VM S3 access key and secret key, the filer UI user and password, and the two endpoint URLs:

S3_ACCESS_KEY=<S3_ACCESS_KEY> S3_SECRET_KEY=<S3_SECRET_KEY> FILER_UI_USER=<FILER_UI_USER> FILER_UI_PASSWORD=<FILER_UI_PASSWORD> S3_ENDPOINT_URL=https://<vm-ip>:8333 FILER_UI_URL=https://<vm-ip>/

Store these values in your secret store. The file is mode 0600 (root-only). To confirm the installed version, run:

sudo /usr/local/bin/weed version

Open https://<vm-ip>/ in your browser. The endpoint uses a per-VM self-signed certificate, so your browser prompts you to proceed on the first visit.

When the browser asks for HTTP Basic Auth, sign in with the FILER_UI_USER and FILER_UI_PASSWORD from Step 5. The filer landing page lists the storage root.

Each S3 bucket appears as a directory under /buckets/. Open /buckets/ to browse your buckets and their objects directly in the browser.

The filer UI can also create folders and upload files. Navigate into any directory and use the upload control to add objects. They are immediately readable through the S3 API.

The AWS CLI is preinstalled. The commands below read the per-VM S3 keys straight from the credentials file. They then run a full create-bucket, put, get, verify and delete round trip through the TLS S3 endpoint:

export AWS_ACCESS_KEY_ID="$(sudo awk -F= '/^S3_ACCESS_KEY=/{print $2}' /root/seaweedfs-credentials.txt)"
export AWS_SECRET_ACCESS_KEY="$(sudo awk -F= '/^S3_SECRET_KEY=/{print $2}' /root/seaweedfs-credentials.txt)"
export AWS_DEFAULT_REGION="us-east-1" EP="--no-verify-ssl --endpoint-url https://127.0.0.1:8333" aws $EP s3 mb s3://sac-demo echo "sac-roundtrip-ok" > /tmp/probe.txt aws $EP s3 cp /tmp/probe.txt s3://sac-demo/probe.txt aws $EP s3 cp s3://sac-demo/probe.txt /tmp/probe-back.txt cat /tmp/probe-back.txt aws $EP s3 rm s3://sac-demo/probe.txt aws $EP s3 rb s3://sac-demo

The output includes make_bucket, the upload and download lines, sac-roundtrip-ok, and then the removals. The --no-verify-ssl flag is needed only for the self-signed certificate on a first local connection.

List all buckets:

export AWS_ACCESS_KEY_ID="$(sudo awk -F= '/^S3_ACCESS_KEY=/{print $2}' /root/seaweedfs-credentials.txt)"
export AWS_SECRET_ACCESS_KEY="$(sudo awk -F= '/^S3_SECRET_KEY=/{print $2}' /root/seaweedfs-credentials.txt)"
export AWS_DEFAULT_REGION="us-east-1" aws --no-verify-ssl --endpoint-url https://127.0.0.1:8333 s3 ls

To list the objects in a bucket, add the bucket name:

export AWS_ACCESS_KEY_ID="$(sudo awk -F= '/^S3_ACCESS_KEY=/{print $2}' /root/seaweedfs-credentials.txt)"
export AWS_SECRET_ACCESS_KEY="$(sudo awk -F= '/^S3_SECRET_KEY=/{print $2}' /root/seaweedfs-credentials.txt)"
export AWS_DEFAULT_REGION="us-east-1" aws --no-verify-ssl --endpoint-url https://127.0.0.1:8333 s3 ls s3://sac-demo --recursive || true

Any aws-sdk works. This Python boto3 example points at the public S3 endpoint with the per-VM keys:

python3 -c " import boto3, urllib3 urllib3.disable_warnings() s3 = boto3.client( 's3', endpoint_url='https://<vm-ip>:8333', aws_access_key_id='<S3_ACCESS_KEY>', aws_secret_access_key='<S3_SECRET_KEY>', region_name='us-east-1', verify=False, ) print(s3.list_buckets()) "

For production, install the per-VM certificate (/etc/seaweedfs/tls/seaweedfs.crt) into your client's trust store instead of disabling verification. Alternatively, front SeaweedFS with a certificate from a public CA.

• weed binary: /usr/local/bin/weed
• AWS CLI v2: /usr/local/bin/aws
• Data directory: /var/lib/seaweedfs
• S3 identities config: /etc/seaweedfs/s3.json
• TLS certificate and key: /etc/seaweedfs/tls/seaweedfs.crt and seaweedfs.key
• Filer Basic Auth file: /etc/seaweedfs/filer.htpasswd
• nginx site: /etc/nginx/sites-available/seaweedfs
• systemd unit: /etc/systemd/system/seaweedfs.service
• First-boot script: /usr/local/sbin/seaweedfs-firstboot.sh
• First-boot service: /etc/systemd/system/seaweedfs-firstboot.service
• Credentials file: /root/seaweedfs-credentials.txt
• First-boot sentinel: /var/lib/sac/data/seaweedfs-firstboot.done

Check the status:

sudo systemctl status seaweedfs.service --no-pager | head -n 8

Restart the server and the TLS front:

sudo systemctl restart seaweedfs.service
sudo systemctl restart nginx.service

View recent activity from the systemd journal, filtered to the component and cluster lines:

sudo journalctl -u seaweedfs.service --no-pager -n 40 | grep -iE 'start seaweed|s3 api|filer|volume server|master' | grep -viE 'error|refused|fail' | tail -8

To see the full log, including any warnings, drop the filters: sudo journalctl -u seaweedfs.service --no-pager -n 40

The shipped image is single-node, which suits development, staging, and small to medium workloads. For production, make these changes:

• Attach a dedicated data disk. Add a Premium SSD, format it as xfs, mount it at /var/lib/seaweedfs, and set ownership to seaweedfs:seaweedfs. Storage then scales independently of the OS disk.
• Use a CA-signed certificate. Replace /etc/seaweedfs/tls/seaweedfs.crt and seaweedfs.key with a certificate for your DNS name. The SecureAnyCloud nginx-ssl-certbot-ubuntu-24-04 image automates Let's Encrypt. Clients then no longer need --no-verify-ssl.
• Restrict the filer UI (443). Allow admin networks only, through the NSG.
• Restrict the S3 API (8333). Allow your application server subnets only, through the NSG.
• Add scoped S3 identities. Edit /etc/seaweedfs/s3.json to add per-application access keys with least-privilege actions (for example Read, Write and List on specific buckets) instead of sharing the admin key. Then restart seaweedfs.service.

Cannot reach the filer UI on port 443

• Confirm that the services are running: sudo systemctl is-active seaweedfs.service nginx.service
• Confirm that the listeners are bound: sudo ss -tln | grep -E ':443|:8333'
• Check the journal: sudo journalctl -u seaweedfs.service --no-pager -n 50
• Confirm that the NSG allows TCP 443 from your client source IP.

S3 client errors with "InvalidAccessKeyId" or "SignatureDoesNotMatch"

• Confirm that the access key is exactly the value of S3_ACCESS_KEY from the credentials file.
• Confirm that the secret is exactly S3_SECRET_KEY, with no whitespace.
• Confirm that region_name is set to us-east-1.
• Confirm that the endpoint is https://<vm-ip>:8333 (S3 API), not 443 (the filer UI).

PutObject fails with an internal error

• Confirm that the data volume has free disk: df -h /var/lib/seaweedfs
• Check that the master can grow volumes: curl -s http://127.0.0.1:9333/vol/status

Filer UI prompts for a password that is not accepted

• Read the credentials again: sudo cat /root/seaweedfs-credentials.txt
• Confirm that the first-boot sentinel exists: ls -la /var/lib/sac/data/seaweedfs-firstboot.done

• Restrict both public ports. Limit 443 (filer UI) and 8333 (S3 API) to trusted networks through the NSG. Never expose them to the open internet without additional controls.
• Replace the self-signed certificate with a CA-signed one before you serve anything beyond a private VNet.
• Create scoped S3 identities in /etc/seaweedfs/s3.json. Never share the admin access key with applications.
• Rotate the filer UI password by regenerating the /etc/seaweedfs/filer.htpasswd entry and reloading nginx.
• Keep SeaweedFS updated by replacing /usr/local/bin/weed with a newer release binary. Data under /var/lib/seaweedfs is preserved across upgrades.
• Store the credentials in your secret store and keep the 0600 file readable by root only.

SeaweedFS is open source under the Apache License 2.0, which permits commercial use, modification and redistribution. SecureAnyCloud ships the upstream Apache-2.0 build unmodified and retains the upstream license and notices.

SecureAnyCloud provides commercial support for the SecureAnyCloud image, separately from the SeaweedFS project itself. Support covers deployment, configuration and integration with other SecureAnyCloud products.

• Email: sales@secureanycloud.com
• Website: secureanycloud.com
• Support hours: 24/7 with guaranteed 24 hour response SLA

Deploy on Azure

Launch SeaweedFS on Ubuntu 24.04 with 24/7 support from SecureAnyCloud.

View on Marketplace

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Deploy on Azure

Launch SeaweedFS on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com