The page for the person who has to sign off. The workloads XNS is built for, the pieces you operate yourself, what the rate actually covers — and the exit path, written down, because a storage decision you cannot reverse is not a decision you should have to make on faith.
The short version
Yes, for the workloads below, on the same terms as everybody else: $6.00 per TB of your data per month, protection included, $0 egress with no ratio cap, a 30-day minimum retention and no early-delete fee on top of it. There is no minimum commitment and no per-request pricing to model.
What makes that safe to sign is not the rate. It is that the storage is an S3 endpoint you run yourself, on a domain you control, that every tool speaking S3 already knows how to talk to — and that pulling all of your data back out again is free, at any size, at any time. The decision is reversible. Most storage decisions are not, which is why they take six weeks.
This page covers the four things a sign-off actually needs: what XNS is built to run, where its model differs from a big cloud, what you operate yourself, and how you would leave.
Built for
The common thread is data that is large, written once or seldom, read whenever you need it, and expensive to hold anywhere that charges you to read it back.
| Workload | Fit | Why this one |
|---|---|---|
| Backup and disaster recovery | Primary | Compliance-mode Object Lock means retention no credential can shorten. Free restores mean you can actually drill the plan monthly. Capability detail. |
| Video surveillance and VMS archives | Primary | Continuous write, long retention, occasional pull of a specific incident. Metered egress punishes exactly the moment you need the footage. Deployment case study. |
| AI and ML data lakes | Primary | Training corpora get read repeatedly by definition. On a metered platform each epoch bills again; here re-reading a dataset costs nothing. |
| Agent and pipeline storage | Primary | Bucket notifications fire on write, so event-driven pipelines work without polling. Scoped STS credentials keep an agent inside its own prefix. |
| Media, research and compliance archives | Strong | No maximum object size — no 5 TB per-object ceiling of the kind AWS, Ceph, MinIO and Wasabi apply. Legal hold and lifecycle expiration are both present. |
| Bulk offload from an expensive tier | Strong | One flat rate with no retrieval fee, so cold data does not get cheaper by becoming slow to read. How the egress models compare. |
| Application object storage over the S3 API | Strong | SigV4, multipart, range GET, conditional requests, presigned URLs, CORS, bucket policies, IAM and STS. Existing SDK code points at a new endpoint and runs. |
| Short-lived scratch and temp data | Check the terms | A 30-day minimum retention applies, so data written and deleted within days is billed for the 30. Storage that churns hourly belongs on a local disk. |
Integration fit check
None of these is a surprise once you know it, and all four take minutes to settle. They are here so you settle them during evaluation rather than during a migration window.
Every current S3 client signs with SigV4. The AWS CLI, boto3, restic, kopia and the MinIO mc client are each confirmed working against the gateway; rclone and other SigV4 tooling use the same signing path. Only genuinely old tooling that still signs the retired SigV2 way needs attention, and the fix is a configuration flag rather than a rewrite.
What to check: two small ones. If you generate presigned URLs from Python, pin the client to SigV4 explicitly — botocore still defaults some paths to the older scheme, and it surprises people in staging. And leave the region set to us-east-1; the gateway is single-region and reports itself that way.
The big clouds sell four or five classes and lifecycle rules to move data between them, because cold storage is how a large archive gets affordable there. XNS is one class at one rate with no retrieval fee — the cold-storage price without the cold-storage wait. There is nothing colder to move into.
What to check: point tools at STANDARD and drop storage-class transition rules. Expiration rules, including noncurrent-version expiration, work normally.
Replication exists because a big cloud puts your data in one region and needs a copy in another. XNS never puts it in one place: every object is erasure-coded into 80 data and 40 parity shards across up to 120 independent hosts, in a geography you compose. Losing a host, a facility or a whole operator is the case the repair process is built for.
What to check: nothing to configure. If policy requires a second copy at a different vendor — sound practice with any single provider, us included — drive two remotes from your backup tool. restic and kopia both do this natively, as does rclone.
XNS is an S3 API endpoint for applications and tools. Serving a public website straight out of a bucket is a separate job, and it is one a CDN or a reverse proxy in front of the endpoint does better anyway — with your certificate, your cache rules and your domain.
What to check: if a workload depends on bucket-hosted static websites or on server-side query pushdown, plan that layer separately. Presigned URLs and CORS are both present for direct browser access to individual objects.
Operational dependencies
XNS is not a console you log into with everyone else. The S3 endpoint is a gateway — the Relayer — that you run on your own Docker host, at a domain you control, with your own TLS certificate. That is what makes the endpoint private to you and the storage genuinely yours. It also means a real, if small, operational surface.
| Component | Owner | What it involves |
|---|---|---|
| The Relayer gateway | You | One Docker container on a host you choose. Keep it patched, reachable and backed by fast local disk. Setup guide. Not sure yet? See what you would run. |
| Endpoint DNS and TLS | You | A name you own, pointed at your gateway, with a certificate you control. No shared vendor domain in your data path. |
| Credentials and access policy | You | IAM users, groups, roles and STS run in your gateway. Issue a scoped key per job rather than reusing the owner credential. |
| Local disk for the gateway | You | High-throughput uploads are disk-sensitive; NVMe is the recommendation above roughly 5 Gbit/s. Published throughput evaluation. |
| The storage network itself | Us | Host contracting, shard placement, repair when a host or a facility goes away, and the settlement that pays for it. |
| Encryption at rest | Us, unconditionally | Every shard XChaCha20-encrypted before it leaves your gateway. No setting to enable, and no single host ever holds a reconstructable object. |
| Durability and repair | Us | 80 data plus 40 parity shards across up to 120 independent hosts, monitored and repaired continuously. The durability model. |
| Request audit trail | Both | Server access logging is on by default and lands in your own bucket — who did what to which object, allowed or denied, with status. |
If running a container is not something your team wants to own, say so before you evaluate rather than after — talk to us about it and we will tell you honestly whether the shape fits.
The exit path
Vendors do not usually publish this, which is exactly why it belongs here. If leaving is cheap and documented, staying is a choice you keep making rather than one you made once.
Nothing beyond the storage you have already used. Egress is $0 with no ratio cap and no overage price, so copying every byte out costs the same as leaving it in place. There is no exit fee, no data-transfer-out charge and no early-delete fee. The only floor is the 30-day minimum retention, so data written less than 30 days before you delete it is still billed for those 30 days.
Your data is in standard S3 objects with their original keys, so the destination is whatever speaks S3 — another provider, your own MinIO or Ceph cluster, or local disk.
Point the AWS CLI at your gateway and sync every object to wherever you are going:
aws s3 sync s3://my-bucket s3://my-bucket \ --endpoint-url https://s3.your-domain.example \ --source-region us-east-1
Or, if you prefer rclone for cross-provider work, a remote at each end and a checksum-verified copy between them:
rclone sync xns:my-bucket dest:my-bucket --checksum --fast-list --progress rclone check xns:my-bucket dest:my-bucket --checksum
The check pass compares checksums on both sides and exits non-zero on any mismatch, so the move is verified rather than assumed. The same commands work in the other direction to bring data in, which is a fair thing to notice.
Terms in this section are the ones current at xns.tech/pricing.json, which is the canonical, machine-readable copy and supersedes any figure quoted elsewhere.
Every API-level claim on this page is published operation by operation on the compatibility matrix, head to head with AWS S3, Ceph, MinIO, Wasabi, Backblaze B2 and Storj. If a framework or an auditor names something specific, ask us where we stand before you evaluate rather than after.
Explore the platform
Everything you need to go from evaluation to production.