शुरुआत#

लोकल में upload, presigned URL, public bucket, CDN cache और thumbnail flow को बार-बार test करते-करते, सिर्फ testing के लिए बाहरी S3 को लगातार जोड़े रखना सोच से ज्यादा अस्वाभाविक लगने लगा। बात सिर्फ cost की नहीं थी; हर experiment के समय बाहरी account और resource से होकर गुजरना मुझे बार-बार खटक रहा था।

इसलिए इस बार मैंने दिशा बदल दी। Test में बार-बार इस्तेमाल होने वाले storage को on-premise पर ही ले आया, और application जिस interface को देखती है उसे जितना हो सके S3 그대로 बनाए रखने का फैसला किया। मुझे लगा कि local, dev environment में on-premise S3 compatible storage लगाकर, और production में उसी interface के साथ AWS S3 या Cloudflare R2 को सीधे बदल सकना कहीं बेहतर संरचना होगी।

नतीजे में SeaweedFS + Nginx CDN + TLS + TTL संयोजन के साथ single-node आधार वाला S3 compatible storage तैयार किया। और यह काम research draft, infrastructure config draft, manifest तैयार करने, deployment procedure को व्यवस्थित करने तक AI द्वारा end-to-end automation का एक उदाहरण भी था। इस लेख में वास्तविक key, Secret, internal path, internal IP जैसी संवेदनशील जानकारियों को पूरी तरह mask करके ही पेश किया गया है।

मैंने इसे खुद क्यों बनाया#

AWS S3 खुद समस्या नहीं था। लेकिन test के मकसद से देखते-देखते यह धीरे-धीरे असहज लगने लगा।

• local और development environment में file upload flow को बार-बार verify करना था।
• public bucket और private bucket को अलग रखकर CDN, presigned URL, thumbnail layer को साथ में जांचना था।
• अस्थायी files को छोटे cycle में बनाना और मिटाना बार-बार हो रहा था।
• हर बार बाहरी storage को आधार बनाकर experiment करना, एक साधारण test के हिसाब से जरूरत से ज्यादा भारी लग रहा था।

मुझे किसी विशाल storage platform की जरूरत नहीं थी, बल्कि 테스트와 검증에 충분한 S3 호환성 और 간단한 온프레미스 운영성 चाहिए थी। और अधिक सटीक रूप में कहूं तो, developer जिस storage contract को देखता है उसे S3 호환 인터페이스 पर स्थिर रखना था, ताकि environment के अनुसार सिर्फ backend implementation को बदला जा सके।

SeaweedFS ही क्यों#

शुरुआत में मैंने सबसे परिचित विकल्पों को पहले देखा, लेकिन 2025 के अंत तक MinIO को default choice मानना मुश्किल लगा। License बदलाव और community operation की दिशा में आए परिवर्तन की वजह से, इसे लंबे समय तक हल्के समाधान की तरह लेकर चलना अस्पष्ट लगा।

इसके उलट Ceph RGW कहीं अधिक पूर्ण विकल्प था, लेकिन इस लक्ष्य के लिए बहुत भारी था। मुझे single-node आधार वाले test storage और सरल media operation की जरूरत थी, कोई बड़े पैमाने का storage cluster चलाना लक्ष्य नहीं था।

इसलिए अंतिम चुनाव SeaweedFS पर आया।

• Apache 2.0 license होने से commercial constraint हल्का है।
• यह S3 Gateway देता है, इसलिए मौजूदा SDK flow को बहुत बदलना नहीं पड़ता।
• upload, download, bucket separation, presigned URL जैसे मुख्य उपयोग क्षेत्र में S3 interface लगभग वैसा ही बना रहता है।
• Helm आधारित Kubernetes deployment आसान है।
• image, audio, short video जैसे छोटे media files के लिए इसका स्वभाव अच्छी तरह मेल खाता है।

मैंने कोई पूरी तरह perfect S3 replacement नहीं चुना, बल्कि इस उपयोग-परिसर में S3와 거의 같은 계약으로 움직이는 저장소 को सबसे संक्षिप्त रूप में चुनने के करीब गया।

मैंने इसे वास्तव में इस तरह तैयार किया#

मैंने architecture को अनावश्यक रूप से जटिल नहीं बनाया। SeaweedFS को केंद्र में रखकर S3 compatible layer बनाई, और उसके सामने Nginx cache layer जोड़ी। उसके ऊपर TLS, public bucket के लिए thumbnail layer, और temporary file TTL policy भी जोड़ी।

Operational unit लगभग इस तरह बंटी:

• S3 endpoint: वह मूल storage जिससे application सीधे जुड़ती है
• CDN endpoint: public resource cache delivery
• thumbnail endpoint: public bucket के लिए image transformation layer
• bucket separation: static, public public हैं, images, videos, bgm, files private हैं
• TTL: _tmp/ prefix वाली files 2 हफ्ते बाद अपने-आप expire होती हैं

इस setup के बाद test में जरूरी मुख्य flow एक ही बार में verify हो गया। Upload, public access, private presigned URL, CDN cache, thumbnail generation, temporary file cleanup, सब कुछ एक ही storage पर संभालना संभव हो गया।

Spring Boot की तरफ भी मौजूदा S3 integration approach को बहुत नहीं बदला। local और test profile में सिर्फ endpoint को on-premise S3 compatible address से बदला, और path-style access तथा public/private bucket rule को उसी हिसाब से align किया। यानी storage नया बनाने के बाद भी application code का बड़ा ढांचा जस का तस रखा जा सका।

मुझे यह हिस्सा खास तौर पर पसंद आया। local, dev environment में SeaweedFS जैसे on-premise storage को जोड़ें, और production में AWS S3 या R2 पर जाएं, तब भी application जिस interface से जुड़ती है वह लगभग वैसी ही रह सकती है। यानी storage product बदलना सीधे application storage abstraction को उलट देने वाली बात नहीं बनती।

दूसरे शब्दों में, इस setup का असली मूल्य सिर्फ एक storage node खड़ा कर देना नहीं था, बल्कि 환경마다 저장소 구현체는 달라도, 코드가 바라보는 인터페이스는 S3 호환으로 고정했다 यही इसकी मुख्य बात थी। ऐसा interface testing के लिए भी अच्छा है, और बाद में production storage बदलते समय भी काफी लचीलापन देता है।

इस बार AI ने कितना काम संभाला#

इस काम में SeaweedFS से भी दिलचस्प बात यह थी कि इस पूरी प्रक्रिया में AI को कितना आगे तक धकेला जा सकता है।

व्यवहार में नीचे के काम AI ने end-to-end automate कर दिए, और इंसान की भूमिका सिर्फ sensitive information भरने और final review तक सीमित रही।

• S3 compatible storage candidates पर research और comparison draft
• MinIO, SeaweedFS, Ceph, RustFS की तुलना करके विकल्पों को संक्षिप्त करना
• Helm values, Nginx cache manifest, TLS configuration draft तैयार करना
• bucket structure, TTL policy, test procedure, operations checklist व्यवस्थित करना
• deployment guide और troubleshooting document लिखना

इस अनुभव से मैंने फिर महसूस किया कि infrastructure work में भी, अगर requirement और security boundary पहले से स्पष्ट हो, तो AI काफी गहराई तक automation कर सकता है। खासकर इस तरह के काम में, जहाँ draft 작성 -> 설정 파일 생성 -> 배포 절차 문서화 -> 실제 반영 जैसा flow बार-बार दोहराया जाता है, वहाँ इसकी उपयोगिता काफी स्पष्ट लगी।

समापन#

यह कोई भव्य storage platform adoption story नहीं है। यह उस S3 को थोड़ा और अपने नियंत्रण में ले आने का रिकॉर्ड है, जिसे test की वजह से मुझे बार-बार इस्तेमाल करना पड़ता था।

लेकिन सिर्फ इतना भी काफी अर्थपूर्ण रहा। Public/private resource, CDN, presigned URL, thumbnail, TTL जैसे असली operational flow को अब बाहरी dependency के बिना ज्यादा बार verify किया जा सकता है। और उससे भी अधिक महत्वपूर्ण यह है कि local और dev में on-premise, जबकि production में S3 या R2, इन सबको एक ही S3 compatible interface के नीचे चुनने वाली संरचना मिल गई।

और एक बात और भी साफ हो गई। AI सिर्फ code generation तक सीमित नहीं है; यह infrastructure draft, config और deployment document को भी काफी ऊँचे स्तर तक automate कर सकता है। इंसान का काम अभी भी बचता है, लेकिन कम से कम अब यह कहीं ज्यादा स्पष्ट है कि किस हद तक क्या सौंपा जा सकता है।

परिशिष्ट#

नीचे documents/workspace/infrastructure/S3_COMPATIBLE_STORAGE_RESEARCH.md का पूरा पाठ दिया गया है।

S3 compatible object storage solution research#

तिथि: 2025-12-30 उद्देश्य: AWS S3 के विकल्प के लिए self-hosted infrastructure solution चुनना

पृष्ठभूमि#

MinIO की स्थिति (दिसंबर 2025)#

MinIO अब अनुशंसित नहीं है। मुख्य कारण:

1. लाइसेंस समस्या: Apache 2.0 → AGPL-3.0 में बदलाव

   • network service के रूप में देने पर source code को सार्वजनिक करना अनिवार्य
   • commercial use के लिए annual license $96,000 से शुरू

2. maintenance mode में बदलाव (दिसंबर 2025)

   • नए feature, improvement, PR acceptance बंद
   • security patch सिर्फ case-by-case evaluation के बाद
   • community version binary distribution बंद, सिर्फ source code उपलब्ध

3. management UI हटाया गया

   • community edition से management console feature हटा दिया गया
   • full feature केवल paid version में

संदर्भ: InfoQ - MinIO in Maintenance Mode

आवश्यकताएँ#

solution comparison#

1. SeaweedFS ⭐ (अनुशंसित)#

फायदे#

• अरबों files तक handle कर सकता है, media storage के लिए उपयुक्त
• O(1) seek की वजह से छोटे files तक तेज पहुंच
• Erasure Coding support से storage efficiency
• cloud tiering, यानी cold data का automatic migration
• FUSE mount, WebDAV, Hadoop integration support

सीमाएँ#

• कुछ advanced S3 features unsupported हैं, जैसे lifecycle policy
• metadata backup अनिवार्य है; Filer metadata खोने पर file orphan हो सकती है

Helm install#

helm repo add seaweedfs https://seaweedfs.github.io/seaweedfs/helm
helm upgrade --install seaweedfs seaweedfs/seaweedfs -n storage --create-namespace

संदर्भ: SeaweedFS GitHub

2. RustFS#

फायदे#

• MinIO migration और coexistence support
• small object पर अच्छा performance
• Apache 2.0 license

सीमाएँ#

• अभी भी beta phase में, production use में सावधानी
• documentation और community अपेक्षाकृत कम

Helm install#

helm repo add rustfs https://charts.rustfs.com
helm install rustfs rustfs/rustfs -n rustfs --create-namespace \
  --set ingress.className="nginx"

संदर्भ: RustFS GitHub

3. Ceph RGW (via Rook)#

फायदे#

• S3 compatibility में सबसे मजबूत, सबसे ज्यादा S3 API support
• block, file, object storage को एक साथ संभालता है
• multi-tenancy, namespace isolation
• Erasure Coding के advanced settings
• exabyte-scale तक expand हो सकता है

सीमाएँ#

• install और operation जटिल
• resource requirement ऊँची, कम से कम 3 node और तेज network चाहिए
• learning curve बड़ा

Helm install (Rook)#

helm repo add rook-release https://charts.rook.io/release
helm install rook-ceph rook-release/rook-ceph -n rook-ceph --create-namespace
# CephCluster CRD लागू करना जरूरी है

संदर्भ: Rook Documentation

4. Garage#

फायदे#

• हल्का और resource efficient
• multi-zone/site replication का built-in support
• Rust आधारित memory safety

सीमाएँ#

• AGPL-3.0 license, इसलिए commercial use constraint
• Erasure Coding support नहीं, सिर्फ 3x replication
• advanced S3 feature कम

संदर्भ: Garage

S3 compatibility comparison#

SeaweedFS मुख्य S3 operations, जैसे PUT, GET, DELETE, LIST, को अच्छी तरह support करता है, लेकिन advanced feature, जैसे Object Lock और Lifecycle, सीमित हैं

अंतिम अनुशंसा#

🥇 SeaweedFS (मजबूत अनुशंसा)#

अनुशंसा के कारण:

1. Apache 2.0 license - commercial use के लिए पूरी स्वतंत्रता
2. media storage के लिए optimized - image, audio, video storage में मजबूत
3. production validated - कई वर्षों के बड़े deployment case
4. Kubernetes friendly - official Helm chart और Operator
5. उचित मूल्य - 25TB तक free, उसके बाद $1/TB प्रति माह

🥈 दूसरा विकल्प#

Nginx CDN configuration guide#

SeaweedFS + Nginx संयोजन से CDN configuration का उदाहरण:

Nginx cache settings#

# /etc/nginx/nginx.conf

http {
    # cache storage configuration
    proxy_cache_path /var/cache/nginx/s3
        levels=1:2
        keys_zone=s3_cache:100m
        max_size=50g
        inactive=7d
        use_temp_path=off;

    upstream seaweedfs_s3 {
        server seaweedfs-s3.storage.svc.cluster.local:8333;
        keepalive 64;
    }

    server {
        listen 80;
        server_name cdn.example.com;

        # image caching (7 days)
        location ~* \.(jpg|jpeg|png|gif|webp|ico|svg)$ {
            proxy_pass http://seaweedfs_s3;
            proxy_cache s3_cache;
            proxy_cache_valid 200 7d;
            proxy_cache_valid 404 1m;
            proxy_cache_use_stale error timeout updating;
            proxy_cache_lock on;

            add_header X-Cache-Status $upstream_cache_status;
            add_header Cache-Control "public, max-age=604800";

            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
        }

        # audio/video caching (30 days)
        location ~* \.(mp3|wav|ogg|mp4|webm|m4a)$ {
            proxy_pass http://seaweedfs_s3;
            proxy_cache s3_cache;
            proxy_cache_valid 200 30d;
            proxy_cache_valid 404 1m;
            proxy_cache_use_stale error timeout updating;
            proxy_cache_lock on;

            add_header X-Cache-Status $upstream_cache_status;
            add_header Cache-Control "public, max-age=2592000";

            # Range request support (video streaming)
            proxy_set_header Range $http_range;
            proxy_set_header If-Range $http_if_range;

            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
        }

        # other files
        location / {
            proxy_pass http://seaweedfs_s3;
            proxy_cache s3_cache;
            proxy_cache_valid 200 1d;

            add_header X-Cache-Status $upstream_cache_status;

            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
        }
    }
}

cache status headers#

• HIT: cache से परोसा गया
• MISS: origin से लाया गया
• STALE: expired cache दिया गया, जब origin में error हो
• UPDATING: background refresh चल रहा है

संदर्भ: NGINX Caching Guide

Kubernetes deployment architecture#

┌─────────────────────────────────────────────────────────────────┐
│                        Kubernetes Cluster                        │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  ┌──────────────────────────────────────────────────────────┐   │
│  │                    Ingress (Nginx)                        │   │
│  │                   cdn.example.com                         │   │
│  └──────────────────────┬───────────────────────────────────┘   │
│                         │                                        │
│  ┌──────────────────────▼───────────────────────────────────┐   │
│  │              Nginx Cache Layer (CDN)                      │   │
│  │          /var/cache/nginx (PVC: 50Gi+)                   │   │
│  └──────────────────────┬───────────────────────────────────┘   │
│                         │                                        │
│  ┌──────────────────────▼───────────────────────────────────┐   │
│  │                   SeaweedFS                               │   │
│  │  ┌─────────┐  ┌─────────┐  ┌─────────┐  ┌─────────┐      │   │
│  │  │ Master  │  │ Volume  │  │ Volume  │  │ Volume  │      │   │
│  │  │  (x3)   │  │   #1    │  │   #2    │  │   #3    │      │   │
│  │  └────┬────┘  └────┬────┘  └────┬────┘  └────┬────┘      │   │
│  │       │            │            │            │            │   │
│  │  ┌────▼────────────▼────────────▼────────────▼────┐      │   │
│  │  │              Filer (S3 Gateway)                 │      │   │
│  │  │           seaweedfs-s3:8333                     │      │   │
│  │  └─────────────────────────────────────────────────┘      │   │
│  └──────────────────────────────────────────────────────────┘   │
│                                                                  │
│  ┌──────────────────────────────────────────────────────────┐   │
│  │                  Persistent Volumes                       │   │
│  │     Volume #1      Volume #2      Volume #3               │   │
│  │     (100Gi+)       (100Gi+)       (100Gi+)                │   │
│  └──────────────────────────────────────────────────────────┘   │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

अगले चरण#

1. SeaweedFS Helm chart से test environment बनाना
2. S3 SDK integration test, यानी मौजूदा code compatibility की जांच
3. Nginx cache layer configure करना
4. performance benchmark, image, audio, video के लिए
5. production deployment plan बनाना

संदर्भ सामग्री#

• SeaweedFS GitHub
• SeaweedFS Use Cases
• RustFS GitHub
• Rook Ceph Documentation
• InfoQ - MinIO Alternatives
• DEV.to - MinIO Alternatives Comparison
• Onidel - MinIO vs Ceph vs SeaweedFS vs Garage
• NGINX Caching Guide
• NGINX as Object Storage Gateway