Jump to content

SeaweedFS Object Storage on PMSS

From Pulsed Media Wiki


SeaweedFS is a distributed object store with an S3 gateway, built to handle very large numbers of small files. On a Pulsed Media storage box or seedbox it runs from a single Go binary — weed — that can play master, volume server, filer, and S3 gateway all at once. It is one of the self-hosted S3 options; where rclone serve s3 and MinIO put an S3 API in front of a directory, SeaweedFS keeps its own store optimised for small-object throughput, and also gives you a browsable filer. In a test on a Pulsed Media storage box the all-in-one server held about 141 MB of RAM. The keys are yours and the data stays in Pulsed Media's Finnish datacenters.

The SeaweedFS filer browser on a Pulsed Media storage box, showing an S3 bucket and the object stored in it. The all-in-one server held about 141 MB of RAM.

When SeaweedFS is the right tool

Reach for SeaweedFS when your workload is shaped by many objects rather than a few large ones:

  • You store millions of small files and want fast, O(1) access to each — SeaweedFS was designed around exactly this, storing small objects together to avoid per-file filesystem overhead.
  • You want both a filesystem-style filer (browsable, mountable) and an S3 API over the same store, from one binary.
  • You expect to grow beyond one volume and want a store that scales by adding volume servers.

For a plain bucket on one box, rclone serve s3 is lighter and simpler. For a console, versioning, and policies, MinIO is the fuller S3 server. For replication across boxes so one can fail, Garage is purpose-built. SeaweedFS earns its place when the small-file count is the hard part.

What people run on it

Because SeaweedFS speaks the S3 API and also exposes a filer, it fits both object and file workloads: backup targets, media and asset stores with huge file counts, a filer mounted over FUSE for path-based apps, and any S3 client pointed at its gateway. On a Pulsed Media box the store, the keys, and the hardware are all yours, in Finland.

What one process needs

SeaweedFS is a single Go binary. weed server -s3 starts the master, a volume server, the filer, and the S3 gateway in one process. In a test on a Pulsed Media storage box (weed 4.41, Debian 12) that all-in-one process held about 141 MB of resident memory while serving a small bucket — comparable to MinIO. In a larger deployment you would run the roles as separate processes and add volume servers as the object count grows; on one box, the combined process is the simple path.

Verified behaviour

On a Pulsed Media storage box, SeaweedFS was exercised end to end: download the weed binary, start weed server -s3 on non-default ports bound to localhost, create a bucket, configure an S3 access key, then over the S3 API upload an object, list it, and read it back byte for byte. The filer's web browser showed the bucket and the stored object — that is the screenshot. The all-in-one server held about 141 MB of RAM.

One difference from rclone serve s3: SeaweedFS's S3 gateway requires an access key to be configured before it will accept signed requests. Configure one with weed shell (the s3.configure command) or an S3 config file; an unconfigured gateway rejects clients rather than serving anonymously.

Setting it up

Download the binary into ~/bin (grab the latest linux_amd64 release from the SeaweedFS GitHub releases page), then start the all-in-one server. Pick your own ports — not the defaults, which automated scanners probe — and bind to localhost, a VPN, or a known client IP:

~/bin/weed server -dir=$HOME/weed-data -ip=127.0.0.1 \
  -master.port=MASTER_PORT -volume.port=VOL_PORT \
  -filer -filer.port=FILER_PORT -s3 -s3.port=S3_PORT

Configure an S3 access key, then point any S3 client at the gateway:

echo 's3.configure -access_key=YOUR-KEY -secret_key=YOUR-SECRET -user=me -actions=Admin,Read,Write -apply' \
  | ~/bin/weed shell -master=127.0.0.1:MASTER_PORT

mc alias set sw http://127.0.0.1:S3_PORT YOUR-KEY YOUR-SECRET
mc mb sw/mybucket
mc cp file.txt sw/mybucket/

The filer's web browser is served on the filer port; forward it over SSH — ssh -L LOCALPORT:127.0.0.1:FILER_PORT you@server — to reach it from your own machine.

A stable hostname

Point S3 clients at your service permalink<your-service-label>.mcx.fi:S3_PORT — so the endpoint keeps working when Pulsed Media migrates your service.

Security

  • Configure a strong, random S3 access key and secret before exposing the gateway — an unconfigured gateway is the wrong default to leave running.
  • Do not use default ports. Pick your own, and bind the S3, filer, and master ports to localhost, a VPN, or a known client IP unless you need public access.
  • SeaweedFS stores and serves bytes; it does not encrypt them for you. Combine it with client-side encryption for sensitive data.

See also