- Joined
- Aug 19, 2025
- Messages
- 180
- Reaction score
- 68
- Points
- 28
Infrastructure notice: We currently run servers in New York City and New Jersey. More regions are on the way — we're actively expanding our infrastructure footprint. Stay tuned for updates on the status page.
nabz/cloud -- File Sharing & a Real S3, Built on Our Own Hardware
cloud.nabzclan.vip - Newest NabzClan Project
So this has been in the works for a little while now and we're finally ready to talk about it properly. nabz/cloud is our take on cloud storage -- not a wrapper around AWS, not a reskin of some third-party bucket service, literally running on hardware we own and operate. It launched in public beta on May 15th 2026 and already shipped a full governance update (v0.1.0) less than 24 hours later. Development is moving fast.
The short version: it's two products in one. A proper web file manager for people who just want to upload and share stuff, and a fully S3-compatible API for developers who need object storage they can drop into existing tools and pipelines. Both run off the same backend, same auth, same storage nodes. You sign up once and you get both.
The File Manager -- nabz/cloud
This isn't just a basic upload page. The file browser has folders, grid and list views, drag-to-move between folders, inline previews for images, video, audio, PDFs, and code files, multi-select, bulk zip download, and rename. It feels like an actual file manager, not an afterthought.
Sharing is where it gets genuinely useful. You create a share link and can optionally lock it with a password, set it to expire after a certain date, and cap how many times it can be downloaded. Every link has a download counter. When the cap is hit or the expiry passes, the link stops working automatically. You can revoke any link at any time. Way more control than a Google Drive or Dropbox share link.
File versioning is built in. Every time you upload a new version of a file, the old one doesn't disappear -- it gets snapshotted. You can browse previous revisions from the preview panel and restore any of them with one click. If you've ever overwritten something you needed, you'll appreciate this immediately.
Trash works how you'd expect -- deleted files go there, you've got 30 days to restore them, and a cleanup sweeper handles automatic purging after that window. Bulk restore is supported so you're not clicking through things one by one.
The max file size is 5 GB per object. Storage quota is shown live in the header so you're never caught off guard.
The S3 API -- nabz/s3
This is the part that sets nabz/cloud apart from every other "file sharing" service. Underneath the web UI is a fully AWS SigV4-compatible S3 API running at
cloud-s3.nabzclan.vip. Region is us-nyc-a1-main. If you've used Amazon S3 before, you already know how to use this -- just change the endpoint URL and drop in your credentials.What's wired right now:
- ListBuckets, ListObjectsV2 (with prefix, max-keys, start-after)
- CreateBucket, HeadBucket, DeleteBucket
- GetObject, PutObject, HeadObject, DeleteObject
- CORS preflight (OPTIONS) -- answered without SigV4, matched against per-bucket CORS rules
- Query-string presigned URLs (GET and PUT) -- expiry from 1 minute up to 7 days
- Per-bucket config: CORS rules, bucket policy (AWS-style), lifecycle rules, object tags, SSE flag, static website index/error doc
Every single S3 request is audited. The metrics dashboard at
/s3/metrics shows activity by bucket, by operation, and by access key with sparklines and a last-50-requests drill-in per key. You can see exactly what's hitting your storage and where egress is going.Access keys can be scoped. Admin keys, read-only keys, or bucket-scoped keys that can only reach specific buckets. Read-only credentials can browse and download but not write. Bucket-scoped keys are locked to their buckets -- they literally can't reach anything else. Per-key IP and origin allow-lists let you restrict which IPs or origins a given key accepts requests from.
Bandwidth quotas work at two levels -- workspace-wide and per-key. Daily or monthly egress caps. The strictest of the two applies at any given time. When a quota is exhausted, GetObject returns
503 SlowDown with a Retry-After header before any storage I/O happens.
XML:
<Error>
<Code>SlowDown</Code>
<Message>this access key egress quota exhausted
(5368709120/5368709120 bytes this period).</Message>
</Error>
Coming soon on the S3 side: multipart upload (CreateMultipartUpload / UploadPart / CompleteMultipartUpload) and virtual-host-style addressing are on the roadmap. Right now large files go up as a single PutObject up to the 5 GB limit. We'd rather be upfront about what isn't wired yet than silently break your upload.
WebDAV -- Mount It as a Drive
This is one of the features most S3 services just don't bother with, and it's genuinely one of the most practical things about nabz/cloud.
Both the file manager and any individual S3 bucket support WebDAV -- you can mount your storage as a network drive directly in your OS. No dedicated client software. No sync daemon running in the background.
The WebDAV host is
webdav.cloud-s3.nabzclan.vip -- runs without Cloudflare's upload size cap in the way, so you're not hitting proxy limits on large files. Two paths:/webdav-- your full cloud workspace tree, folders and versions respected, quota enforced/webdav-s3/<bucket>-- a single S3 bucket's keyspace, with/-delimited prefixes showing up as folders
Auth is HTTP Basic -- either a dedicated WebDAV username + password you set at
/cloud/connect, or an existing access key (key ID as username, secret as password).macOS: Go -> Connect to Server (Cmd+K) -> paste
https://webdav.cloud-s3.nabzclan.vip/webdav -> done. Shows up in Finder sidebar like any other drive.Windows: Map a network drive, point it at the WebDAV URL, enter your credentials. Done.
Linux: Mount with
davfs2 or use rclone's WebDAV backend. Per-bucket mount snippets are pre-filled in the bucket connect page.
Bash:
# macOS Finder: Go -> Connect to Server (Cmd+K)
https://webdav.cloud-s3.nabzclan.vip/webdav
# rclone -- mount the whole cloud tree
rclone config create nabz webdav \
url=https://webdav.cloud-s3.nabzclan.vip/webdav vendor=other \
user=<ACCESS_KEY> pass=<SECRET_KEY>
# Linux -- mount a single S3 bucket
sudo mount -t davfs \
https://webdav.cloud-s3.nabzclan.vip/webdav-s3/my-bucket/ /mnt/my-bucket
This means you can open a file from your nabz/cloud storage in any app on your desktop, edit it, and save -- without ever going through a browser upload. It just works like a local folder.
Use Cases
Just want somewhere to put files and share them
Upload to the web UI, get a share link, optionally lock it with a password or expiry. The person you're sharing with doesn't need an account.
Client deliverables and handoffs
Drop final files in a folder, share a passworded link that expires after a week, set a download cap so the files aren't getting passed around. The download counter tells you if they've actually grabbed it.
Developer asset storage
Point boto3, aws-sdk-js, or the aws-cli at
cloud-s3.nabzclan.vip and use it as your object store. Works for anything currently using S3 -- static site assets, user uploads, build artifacts, whatever.Backups
rclone, restic, and Kopia all support S3. Set up nabz/s3 as a backup destination and your snapshots live on NabzClan-owned hardware. Bucket-scoped write-only keys mean your backup process can push data but a compromised key can't list or delete anything.
CI/CD artifact storage
Store build artifacts, release binaries, or test outputs in a bucket. Per-key bandwidth quotas and IP allow-lists let you lock a key down to your CI infrastructure specifically.
Mount as a drive for media workflows
Work with large video or audio files across machines -- mount the WebDAV endpoint and edit directly off remote storage without keeping a local copy.
Static website hosting
Set an index doc and error doc on any bucket and it'll serve them at the bucket root. Functional for static sites or documentation.
Temporary file distribution
Generate a presigned URL from any object with a short expiry. Hand it to someone, it works for the window you set, then it's gone. No account creation needed on their end.
Infrastructure & Reliability
We're currently running in two locations -- New York City and New Jersey -- with replica nodes across both. The platform runs on Next.js 16 with Postgres and Drizzle on the backend, fronted by nginx. We've been sitting at 100% uptime since launch.
[NOTICE]Expanding soon: More server regions are being planned. If you need a specific region for latency or data residency reasons, keep an eye on the status page and changelog for announcements. We want to hear where you are -- reply below if a specific region matters to you.[/NOTICE]
Storage nodes are managed through an admin panel with region assignments. The architecture is built to support multi-region from the ground up -- adding new locations isn't bolted on.
Why Not Just Use AWS / R2 / Backblaze?
Honest comparison, checked against public docs -- May 2026:
| Feature | nabz/cloud | AWS S3 | Cloudflare R2 | Backblaze B2 |
|---|---|---|---|---|
| S3-compatible API | Yes | Yes | Yes | Yes |
| Web file manager + previews | Yes | No | No | Limited |
| Share links w/ password + expiry | Yes | Presign only | Presign only | Presign only |
| WebDAV mount | Yes | No | No | No |
| Per-key bandwidth quotas | Yes | No | No | No |
| Live per-key metrics | Yes | CloudWatch ($$$) | Limited | Limited |
| Egress fee | Included | $0.09/GB | Free | 3x storage rate |
| Runs on own hardware | Yes | No | No | No |
AWS S3 -- No web file manager. No WebDAV. Metrics only through CloudWatch which costs extra. Egress is $0.09/GB which adds up fast at any real volume.
Cloudflare R2 -- Free egress is genuinely great, but there's no file manager, no WebDAV, and no useful per-key metrics. Presigned URLs only for sharing -- no password or download cap support.
Backblaze B2 -- Egress is charged at 3x the storage rate outside Cloudflare's free tier. Limited preview support. No WebDAV. Share link controls are minimal.
nabz/cloud does all the things none of them do together -- a real file manager, WebDAV mount, per-key live metrics, and egress included in the plan. Your data also lives on infrastructure a community you're already part of actually runs.
Compatible With Everything
If it speaks
s3://, it works. Just set the endpoint to cloud-s3.nabzclan.vip and drop in your credentials.
INI:
; ~/.aws/credentials
[nabz]
aws_access_key_id = NBZAK1ABCDEF...
aws_secret_access_key = ********************
region = us-nyc-a1-main
endpoint_url = https://cloud-s3.nabzclan.vip
INI:
; rclone.conf
[nabz]
type = s3
provider = Other
access_key_id = NBZAK1ABCDEF...
secret_access_key = ********************
endpoint = https://cloud-s3.nabzclan.vip
acl = private
Bash:
# aws-cli quickstart
aws --endpoint-url https://cloud-s3.nabzclan.vip s3 mb s3://my-bucket
aws --endpoint-url https://cloud-s3.nabzclan.vip s3 cp ./file.txt s3://my-bucket/
aws --endpoint-url https://cloud-s3.nabzclan.vip s3 presign s3://my-bucket/file.txt
CLIs: aws-cli, s3cmd, s5cmd, mc (MinIO client)
SDKs: boto3, aws-sdk-js v3, aws-sdk-go v2, aws-sdk-php, aws-sdk-java v2, aws-sdk-ruby
Desktop: Cyberduck, Mountain Duck, WinSCP (S3 mode), Transmit (macOS)
Backup & sync: rclone, restic, Kopia, s3fs (FUSE mount), Terraform (AWS provider)
WebDAV: macOS Finder, Windows Explorer, davfs2, Cyberduck
Suggestions We're Open To
This is still in beta and moving fast. Here's what we'd genuinely love feedback on -- reply in the thread:
- Multipart upload -- it's the most requested missing S3 feature. If your use case needs it, say so and it gets prioritized.
- Additional regions -- we're in NYC and NJ right now. If you're elsewhere and latency matters to you, reply with where you are. That data helps us decide where the next node goes.
- Custom domain support -- on the roadmap. If you have a specific use case (branded share links, custom bucket domains), let us know what you'd actually use it for.
- Larger file size limits -- the 5 GB cap is an nginx body limit right now. If you regularly work with files above that, worth knowing.
- UI rough edges -- the file browser and S3 console are both young. If something is confusing or doesn't behave as expected, that feedback is genuinely useful.
Plans & Pricing
Plans mirror your NabzClan VIP tier. Free account gets you started with no card needed -- signup takes about 8 seconds. Billing and upgrades go through the NabzClan subscription portal. New entitlements apply on your next page load after upgrading.
S3 storage and cloud storage quotas are tracked independently -- filling one never touches the other.
| Plan | Price | S3 Storage | S3 Egress | Cloud Storage | Requests/mo |
|---|---|---|---|---|---|
| Free | $0 | 5.4 GB | 15 GB | 5.6 GB | 30,000 |
| Tier 1 | $7/mo | 16 GB | 400 GB | 15.6 GB | 60,000 |
| Tier 2 | $15/mo | 30.4 GB | 800 GB | 45.6 GB | 180,000 |
| Tier 3 | $30/mo | 1.95 TB | Unlimited | 1.95 TB | Unlimited |
| Tier 4 | $80/mo | 9.53 TB | Unlimited | 2.70 TB | Unlimited |
API requests reset on the 1st of each month UTC. Full breakdown at cloud.nabzclan.vip/plans.
Getting Started
Signup takes about 8 seconds -- no card, just an account. Once you're in, head to
/s3/keys to generate your first access key, copy the endpoint config from /s3/connect, and you're talking to the API. For the file manager just go to /cloud and start uploading.- Sign up free -> cloud.nabzclan.vip/sign-up
- Docs -> cloud.nabzclan.vip/docs
- API Reference -> cloud.nabzclan.vip/docs/api
- Plans -> cloud.nabzclan.vip/plans
- Status -> cloud.nabzclan.vip/status
- Changelog -> cloud.nabzclan.vip/changelog
- Subscriptions -> subscriptions.nabzclan.vip
Part of the NabzClan project lineup -- nabzclan.vip/forums/projects.7/
Last edited: