AIOZ Storage Developer Platform: SDKs, CLI, and Migrations

The AIOZ Storage developer platform is bigger than any single tutorial in this series lets on: two official SDKs plus a Python path through boto3, a CLI built on the standard AWS CLI, direct API access for anything else, two documented migration paths in, infrastructure-as-code support through Terraform, and two full application-building guides. Every one of those pieces has its own dedicated walkthrough elsewhere on this hub. This article is the map: what each piece is for, how they relate to each other, and the one underlying configuration pattern that every single one of them is built on top of.

TL;DR:

• AIOZ Storage's developer surface has nine pieces: three SDK/language paths (JavaScript, Go, Python), a CLI, direct API access via Postman, two rclone-based migration guides, Terraform for infrastructure-as-code, and two full application tutorials.
• Every single one is the same underlying pattern: a custom endpoint (https://s3.aiozstorage.network), path-style addressing, a placeholder region, and credentials from an access grant, adapted to whatever tool you're using.
• Pick your entry point by what you're actually doing: a language SDK for application code, the CLI for scripting and one-off operations, direct API calls for anything a client library doesn't cover, rclone for moving data in, Terraform for managing buckets as code.

The One Pattern Behind Every Tool Here

Before picking a specific guide, it's worth seeing the pattern that repeats across all nine of them, because once it clicks, every individual tutorial becomes a variation on the same theme rather than a new thing to learn from scratch. AIOZ Storage is S3-compatible, which means every existing S3 tool, AWS's own SDKs, the AWS CLI, Terraform's AWS provider, Postman, rclone, already knows how to talk to it. The adaptation each one needs is identical in shape: point it at AIOZ's endpoint instead of AWS's, tell it to use path-style addressing instead of virtual-hosted-style, give it a placeholder region since AIOZ Storage isn't region-partitioned, and hand it credentials from an AIOZ Storage access grant instead of an AWS IAM key. Every guide below is that same four-part swap, expressed in whatever configuration format the specific tool expects.

Picking Your Path In

Writing application code? Reach for one of the three language paths. JavaScript via @aws-sdk/client-s3, Go via aws-sdk-go-v2, or Python via boto3, all three are official AWS SDKs configured to point at AIOZ's endpoint instead, not a separate AIOZ-specific client library to learn.

Scripting, automation, or one-off operations? The CLI quickstart covers pointing the standard AWS CLI at AIOZ Storage's custom endpoint, useful for anything you'd normally reach for aws s3 to do, without writing a script around an SDK first.

Managing buckets as part of your infrastructure? Terraform brings AIOZ Storage into the same aws_s3_bucket resource type and state-file workflow already managing real AWS infrastructure, no separate provider required.

Need something the SDKs and CLI don't expose directly? Calling the API directly with Postman covers building AWS Signature Version 4 requests by hand, the fallback path for anything a client library abstracts away that you need to see or control directly.

Moving Existing Data In

Two migration guides cover the realistic starting points for data that already lives somewhere else, both built on rclone rather than a bespoke AIOZ tool. Migrating from Amazon S3 is the simpler of the two: both source and destination use rclone's s3 remote type, so the move is really just a config change, provider = AWS flips to provider = Other, plus a new endpoint and credentials. Migrating from Backblaze B2 is a meaningfully different story despite looking similar on the surface, since B2's native remote type in rclone (type = b2) predates its S3-compatible API, so that migration is really "B2-native to S3-compatible," not a same-protocol move the way the S3 migration is.

Building a Real Application

Two tutorials go beyond a single-operation quickstart into something closer to a real application pattern. The FastAPI file-management API wires boto3 into a working upload/download HTTP API, the shape most backend services actually need rather than a one-off script. Generating presigned URLs covers handing out temporary, scoped upload or download access without a standing credential, the pattern behind letting an untrusted client, a browser, a mobile app, upload directly to a bucket without ever holding real AIOZ Storage credentials itself.

Automating What Runs on a Schedule

Two more pieces cover recurring, unattended operations rather than one-time setup. Automating backups with GitHub Actions wires the same rclone remote config from the migration guides into a scheduled workflow, and multi-cloud disaster recovery with rclone bisync keeps AIOZ Storage and AWS S3 mirrored in both directions rather than one-way. Both build on the exact same rclone remote structure the migration guides establish, just run repeatedly instead of once.

Why One Underlying Pattern Instead of a Proprietary SDK

The practical payoff of AIOZ Storage leaning entirely on existing S3 tooling, rather than shipping its own client library, is that a team's existing AWS-adjacent skills and tools transfer directly. rclone's own documentation makes this explicit for its side of the equation: its S3 backend "can be used with a number of different providers," with "Other" as a standing provider option specifically for "any other S3 compatible provider" beyond the named list of AWS, Alibaba, Ceph, DigitalOcean, and others. Someone who already has rclone remotes configured for a different cloud isn't learning a new tool to work with AIOZ Storage, they're pointing a tool they already use at one more endpoint, exactly the same story the JavaScript, Go, and Python SDK guides on this hub tell for application code.

Frequently Asked Questions

What's the fastest way to start building on AIOZ Storage?
Depends on what you're building: a language SDK (JavaScript, Go, or Python) for application code, the CLI for scripting, or Terraform if you're managing buckets as infrastructure. All four use the same underlying endpoint-and-credentials pattern, just in different tool configurations.

Does AIOZ Storage have its own SDK?
No. It's S3-compatible, so it uses the official AWS SDKs (JavaScript, Go, and Python's boto3) configured to point at AIOZ's endpoint instead of AWS's, rather than a separate proprietary client library.

How do I move existing data from AWS S3 or Backblaze B2 to AIOZ Storage?
With rclone. The S3 migration is a same-remote-type config change (provider = AWS to provider = Other). The Backblaze B2 migration is a bigger jump, from B2's native remote type to an S3-compatible one, since B2's native API predates its S3-compatible one.

Can I manage AIOZ Storage buckets with Terraform?
Yes, through the standard Terraform AWS provider configured with a custom S3 endpoint, s3_use_path_style = true, and a few validation-skipping flags. No separate AIOZ Terraform provider is needed.

What if I need to do something the SDKs and CLI don't support directly?
Call the API directly. The Postman and AWS Signature Version 4 guide covers building and signing raw S3-compatible requests by hand, the fallback for anything a client library abstracts away.

Can I automate recurring backups or keep two clouds in sync?
Yes, both build on the same rclone remote configuration as the migration guides: a scheduled GitHub Actions workflow for one-directional backups, or rclone bisync for keeping AIOZ Storage and AWS S3 mirrored in both directions.

What's the one thing all of these guides have in common?
The same four-part adaptation: AIOZ Storage's custom endpoint (https://s3.aiozstorage.network), path-style addressing, a placeholder region, and credentials from an access grant, expressed differently depending on whether the tool is an SDK, a CLI, Terraform, or a raw HTTP request.

Related Reading

• AIOZ Storage Explained: S3-Compatible Decentralized Storage - the full product model every guide on this hub builds on top of.
• AIOZ Storage Access Control: Macaroons and Access Grants - generating the credentials every single tool on this hub needs.
• How to Use AIOZ Storage Effectively: A Practical Checklist - the setup mistakes to avoid before wiring any of these tools up.
• The 3-2-1 Backup Rule: A Practical Framework Explained - the framework behind the backup and disaster-recovery guides on this hub.
• How Automatic MIME Type Detection Works on AIOZ Storage - a real upload-time behavior that applies across every SDK, CLI, and API path on this hub.
• What Is CORS and Why It Matters for Object Storage? - a real requirement for any browser-based upload path built on top of the SDKs and APIs covered here.
• What Is an MCP Server? How AI Agents Access Storage - why an AI agent using AIOZ Storage today still goes through the SDKs and CLI covered on this hub, not a dedicated MCP tool.
• What Is Multipart Upload? Splitting Files Into Chunks - how the SDKs and CLI on this hub actually build large objects behind the scenes.

References

• rclone Documentation: Amazon S3 (and S3-compatible) Storage Providers
• AWS CLI Documentation: Using Endpoints