Object storage on your own server

When it is the right shape

Object storage suits data that is written once and read many times, addressed by name rather than by path, and accessed over HTTP: uploads, images, video segments, backups, build artefacts.

It is the wrong shape for anything that wants to be a filesystem — a database directory, a home directory, anything with partial writes or locking.

MinIO or Garage

MinIO

Mature, fast, very complete S3 compatibility, good console. Check the licence terms against your use before you commit to it commercially.

Garage

Lighter, designed for a handful of nodes across locations, modest hardware requirements. Less complete API coverage; check the calls you actually use.

Disks: give it whole drives

Object storage wants direct access to disks, not a RAID array underneath it. With four or more drives, erasure coding gives you redundancy with far less waste than mirroring, and it heals itself when a disk is replaced.

Use XFS, one filesystem per drive, mounted at predictable paths, addressed by id rather than by /dev/sdX — device names move between boots. Bulk SAS drives are the right hardware here; see SAS, SATA and NVMe. Tell us what you are building and we will specify a chassis with the bays for it.

Put it behind nginx

Terminate TLS at nginx, proxy to the storage service on localhost. Raise client_max_body_size for large uploads and turn proxy_request_buffering off so a multi-gigabyte upload is streamed instead of landing on the proxy's disk first. See nginx pitfalls.

Keys and buckets

• One access key per application, with a policy scoped to its own bucket. Never hand out the root credentials.
• Buckets private by default. Public buckets are how data ends up indexed by search engines.
• Use presigned URLs for temporary public access rather than opening a bucket.
• Turn on versioning for anything you would regret overwriting, and object locking for backups — that is what makes a copy ransomware cannot delete.

See managing secrets for where those keys should live.

As a backup target

This is the most common reason to run it. restic, borg, Duplicati, Veeam and most database tools all speak S3, so your own object store becomes a backup destination for every machine you have — on your network, at your port speed, with no egress charges.

Two conditions: put it on a different machine from the things it backs up, and enable object locking so a compromised server cannot delete its own history. See backups and testing a restore.

Watch the capacity

Object stores fill silently because nothing ever deletes itself. Set lifecycle rules to expire old versions and incomplete multipart uploads — abandoned multiparts are invisible in listings and can quietly consume terabytes. Alert on free space, as in logs and a disk that fills up.

---

Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base