S3-compatible gateway for Kubernetes
Keep your object store. Lose its limits.
Arcois Exera sits in front of the S3-compatible storage you already run. Small objects stop hurting, moving between stores stops being an outage, and every tenant gets quotas and billing. Nothing in your applications changes.
You already run S3. You know these.
Five problems that come from the store owning your metadata
Every one of them has the same cause: your storage system is also your clients' endpoint, so it has to carry every name, version and listing as well as the bytes. Exera takes the metadata. The store keeps the bytes.
1 · Object count
Listing a big bucket takes hours. Resharding blocks writes. The index pool is busier than the data.
An object store pays about the same price for every object it holds, whatever its size. Billions of small objects spend that price on index entries, placement decisions and rebuild work, and the bill arrives as slow listings and long recoveries.
Exera packs small objects into sealed volumes
Your store receives a few large objects instead of millions of small ones. Listing runs over Exera's own ordered index and never asks the store to enumerate anything. A read fetches one byte range for exactly that object, so nothing is unpacked and nothing is staged.
64 KB objects sealed into 100 MB volumes give a ratio near 800 to one. Work out your own number.
2 · Mobility
Changing provider means an outage, so you never change provider.
Moving petabytes with copy tools means dual writes in every application, a write freeze, or both. Tools that list a billion keys run out of memory, and ETags and timestamps do not survive the copy. So the price rise gets paid.
One DNS switch. The old store keeps serving while data moves.
Point your clients at Exera. Keys it has not seen yet are read from the old store on demand and imported as they go. The cutover never deletes the old copy, so the way back is pointing clients at the old endpoint. Near-zero downtime, measured in one DNS or load-balancer change.
3 · Redundancy
Your second copy has to be the same vendor, the same version, in the same product family.
Built-in replication is same-vendor only. It is opaque when it falls behind, and a full resync of a large bucket is something nobody wants to run twice. Regulators increasingly ask for a copy that fails independently.
One write, two S3-compatible stores from different vendors
A placement policy can name two stores from two vendors. Every write goes to both. Backend health tracking, an owed-copy index and a background healer close any gap a store opens while it is down. For a second site, active-passive geo-replication keeps a whole cluster ready to promote.
4 · Tenancy
You want to offer S3 to tenants, and the store has no quotas, no metering and no self-service identity.
Usage counters drift, limits apply per instance rather than per tenant, and the answer to "a second tenant" is often a second cluster. Chargeback becomes a spreadsheet.
Realms: isolated tenants with quotas, usage snapshots and standard IAM
Each realm holds its own buckets, users, credentials and policies, administered by that tenant. Quotas warn softly and then refuse. Daily usage snapshots feed billing. Tenants manage their own users and keys with the standard IAM and STS tooling, behind one endpoint and one console.
5 · Cold data
Tape is the cheapest and most ransomware-resistant storage there is, and your S3 cannot use it.
A tape drive wants long sequential writes. Small files make it stop and reposition, and that shoe-shining wears the drive and the media. Appliances that solve it lock the catalogue inside the appliance.
Arcois tape archive: sealed volumes, sent to tape on a schedule
Arcois ships an LTFS-based tape service for TS4300 and TS4500 libraries. It runs outside the cluster, so no node needs privileged access, and it writes two copies across cartridges. Because Exera already packs small objects into large sealed volumes and sends them on a schedule, the drive streams instead of shoe-shining. How the archive works.
How it works
One rule, four consequences
Clients address Exera and never a store. A store receives opaque blobs that are written once and never modified. Every piece of S3 metadata lives in Exera, in a transactional metadata plane.
Numbers
Arithmetic you can check yourself
Who this is for
Three places Exera pays for itself
Small-object workloads on a store you already own
Backups, logs, traces, images, machine data. The store stays; the object count it sees drops by orders of magnitude.
Read the use caseRegional or sovereign S3 as a service
Sell S3 with per-tenant quotas, usage snapshots for billing and self-service identity, on hardware in your own jurisdiction.
Read the use caseA provider exit with a way back
Move between S3-compatible providers while clients keep writing. The old copy stays until you remove it yourself.
Read the use caseRuns where you run
Your cluster, your stores, your data
Bring your object count.
We will do the arithmetic with you before you install anything.