Object storage on hardware we own.

Buckets, uploads, and shareable links on the same infrastructure your instances run on, billed on the same invoice. Public access is set object by object, so one bucket can hold the logo your site serves to the world and the export nobody outside your organization should ever see. A presigned link hands a file to someone who has no account and never needs one.

Create a Bucket See Storage Rates

carpathian.ai / dashboard / object-storage

client-deliverables

brand/logo-dark.svgPublic. A browser fetches it straight from the bucket at a stable address.

handoff/site-export.zipShare link active. It works for whoever holds it and closes when the window ends.

exports/quarterly-ledger.csvPrivate. Only accounts in your organization with view access can open it.

builds/api-server.tar.gzPrivate. Uploaded by a key the deployment pipeline holds, which can write and nothing else.

public to anyone with the addressshare link activeprivate to your organization

Buckets you own

Created, renamed, and deleted from the same dashboard as your instances

Public per object

Visibility is set on the object, so one bucket holds both kinds of file

Links that expire

The recipient needs the link, not an account, and it closes on schedule

One invoice

Storage sits beside infrastructure and bandwidth on the monthly bill

What it does

Five things you can do with a bucket, each of them granted on its own. The list below is everything object storage does today, with no higher tier holding anything back.

Buckets you create and name

A bucket is the container files go into, and you make as many as the work needs. One for a client, another for the assets a website serves. Inside a bucket, each object carries a path of its own, so images/avatars/face.png lands where the name says it should instead of in one flat pile. Creating, renaming, and deleting buckets is a single permission, held apart from everything that happens to the files inside, and renaming one later does not move what it holds.

Uploads into a bucket

Files arrive from the dashboard or from an application running on one of your instances, and either way they land in the same bucket and appear in the same listing. Upload is its own permission, so an account can be allowed to add files without being allowed to touch anything that is already stored.

Browsing what is stored

Viewing is separate from everything else. An account with view access opens the bucket list, walks the objects inside, and downloads what it needs. Nothing it does can add a file, remove one, or expose one, which makes it the right grant for the person who needs to look something up now and then.

Share links and public objects

Two ways to put a file in front of someone. A presigned share link works for whoever holds it, without an account, and expires at the end of the window you set on it. Marking an object public gives it an address a browser can fetch directly, which is what static assets want. Both take the share permission, and it is not bundled with upload.

Deletes, held separately

Removing an object is a grant of its own. An account can be given the ability to clear out last year's exports without gaining the ability to create buckets or publish anything, and an account that uploads all day can be kept away from delete entirely. The two are different jobs and they are handed out as different jobs.

Scoped to your organization

Every query against object storage is filtered by the organization that owns the bucket. Buckets, objects, and the names of both stay inside the tenant that created them, and nothing crosses between tenants. What reaches the outside world is what someone with the share permission decides to publish or link.

Where it fits

Object storage is the place for files that should outlive a single instance, or that need an address of their own. These are the placements it gets used for most.

Application uploadsAn application on a Spark instance writes what its users upload into a bucket instead of onto the instance disk, so rebuilding or replacing that instance is no longer a question of what happens to the files.

Static assetsLogos, images, and downloads a browser fetches directly. Mark the object public and it has an address you can point a page at, without a second host to keep in sync.

Archives and exportsReport dumps, ledger exports, and anything a system produces on a schedule and needs to keep somewhere other than the machine that produced it.

Client handoffA presigned link sent to someone who does not have an account and does not need one. They download the file, the window closes, and there is no shared login to remember to take back.

Build artifactsImages, binaries, and packages a deployment pipeline produces, in a bucket where the pipeline account holds upload access and nothing more.

Backup destinationA target for backup tooling you run yourself, alongside the nightly archives and on-demand snapshots your instances already get.

Five separate permissions

Viewing, managing buckets, uploading, deleting, and sharing are granted separately. An account holds any combination of the five, and holding one gives it no claim on the others.

carpathian.ai / dashboard / object storage access

View buckets and objects
Read access. The account opens the bucket list, looks through what is inside, and downloads what it needs. That is the whole extent of it.
Create, rename, and delete buckets
Control over the containers rather than their contents. Renaming a bucket later does not move the files inside it.
Upload files into buckets
Write access on its own. An account with this and nothing else adds files without touching what is already there.
Delete objects from buckets
Removal, held apart from upload, so emptying a bucket is something a person was deliberately trusted with rather than a side effect of being able to fill it.
Share objects
Mint a presigned link, or mark an object public so anyone with the address can fetch it. This is the grant that lets a file leave your organization.

The shape this is built for is the contractor who needs to put files somewhere. Give that account upload access and it can add files to the bucket for as long as the engagement runs, with no ability to delete what is already there, rename the bucket, or publish anything to the open internet. When the work ends you remove one grant and the account goes quiet.

The same split covers the read-only case. Someone who needs to pull an export gets view access and nothing else, so the worst outcome of a session going missing is a download rather than an empty bucket.

Sharing is kept apart from uploading on purpose, because minting a link or marking an object public is the point where a file leaves your organization. That is a different decision from putting the file in a bucket, and in most teams it belongs to different people. Underneath all five grants, every query is scoped to the organization that owns the bucket, so permissions decide what your own people can do and tenancy decides the rest.

Three ways in

A signed-in session in the dashboard is one of them. The second is an API key issued to your own code, and the third is a share URL held by someone who has neither. A key carries separate read, write, and delete scopes, so the separation of duties you set up for people is the separation of duties you get for machine credentials.

carpathian.ai / api / object storage keys

Read
List buckets, list what is in them, and download the contents. A key carrying this and nothing else can copy data out and change none of it.
Write
Upload objects, including large files sent in parts. A key carrying this adds data and cannot remove any.
Delete
Remove objects, and abort a large upload that is still in flight. Held on its own, the same way it is for people.
Object storage template
A ready-made scope set that grants all three at once, for the key that genuinely has to do everything.

A key is issued with the scopes the job needs and nothing beyond them, which is the argument above applied to machine credentials. The key a deployment pipeline uses can be given write and stopped there, so a build runner that gets compromised can add an artifact and cannot empty the bucket behind it. A key that serves a public site gets read. The routes sit under /api/v1/cos/, and a key only ever holds the scopes it was issued with.

Large files are sent in parts instead of one long request, and an upload interrupted partway resumes from the parts the server already holds rather than starting from the beginning. It matters for the files large enough that a dropped connection would otherwise cost you the whole transfer, and it works the same way from the dashboard and from your own code.

The third way in carries no credential at all. A share URL works for whoever holds it, with no account behind it, which is why minting one is a permission of its own and why it reaches a single object rather than the bucket around it.

On the same invoice

Storage is a line on the monthly invoice you already receive, next to your instances and your bandwidth. There is no separate storage subscription to sign up for, no second billing portal to keep credentials for, and no minimum spend to commit to before a bucket will hold a file.

Rates are published on the pricing page, and they are the rates the dashboard charges against. Create a bucket, upload to it, and what you store appears on the next invoice beside everything else you run with us.

See Storage Rates

In our buildings

Objects sit on hardware in Carpathian facilities in Des Moines, Iowa. US Central 001 is the production site and US Central 002 is the disaster recovery site, and both are buildings we operate, which makes this site redundancy inside our own footprint.

Nothing is relayed to a third-party storage provider. When a customer or an auditor asks where a file physically lives, the answer is a building with an address, staffed by people we employ, so data residency is a question we can answer without drawing a supply chain.

US Central 001 in Des Moines, the production site
US Central 002 in Des Moines, the disaster recovery site
No third-party storage provider anywhere in the path
Every query scoped to the organization that owns the bucket

Common questions

What teams ask before they move files onto it.

Is public access set on the bucket or on the object?

On the object. Each object carries its own visibility, so one bucket can hold a logo any browser is allowed to fetch and an export nobody outside your organization can open. Changing that setting takes the share permission, which is granted separately from the permission to upload.

Does someone need a Carpathian account to open a share link?

No. A presigned share link works for whoever holds it, with no account and no sign-in, and it stops working when the window you set on it closes. That is what makes it the right way to hand a file to a client who will never log in to anything of yours.

Can I let a contractor upload without letting them delete?

Yes. Uploading and deleting are separate permissions, as are viewing, managing buckets, and sharing. Grant upload on its own and the account can add files for as long as the engagement lasts without the ability to remove what is already there or publish any of it.

Can I reach object storage from my own code?

Yes. Alongside the dashboard session and share URLs, there is an API under /api/v1/cos/ that authenticates with an API key. A key carries separate read, write, and delete scopes, so a pipeline that only pushes build artifacts can be issued write and nothing else, and there is a ready-made object storage scope set for a key that needs all three. Large files upload in parts and resume from what the server already holds if the transfer is interrupted.

How does storage get billed?

On the same monthly invoice as your instances and your bandwidth. There is no separate storage subscription, no second billing portal, and no minimum spend to commit to before a bucket will hold a file. Rates are published on the pricing page.

Where do the objects physically live?

In two Carpathian facilities in Des Moines, Iowa. US Central 001 is the production site and US Central 002 is the disaster recovery site, and both are buildings we operate. Nothing is relayed to a third-party storage provider, so the answer to where a file sits is a building with an address.

Is this the same as the nightly backups on my instance?

No. Instances get nightly backup archives and on-demand snapshots, which is a separate product surface with its own page. Object storage is a bucket you fill yourself. Plenty of teams use both, and a bucket is a sensible destination for backup tooling you run inside your own instance.

Can another organization see my buckets?

No. Every query is scoped to the organization that owns the bucket, so buckets, objects, and the names of both stay inside the tenant that created them. What leaves is what someone with the share permission decides to publish or link.

The rest of what runs on this hardware

Buckets usually sit beside the instances that fill them and the nightly archives that protect those instances. Storage, infrastructure, and bandwidth land on one monthly invoice.

Cloud Instances Instance Backups Pricing

Create a bucket on hardware we own.

Object storage is part of Carpathian Cloud, so an account that reaches your instances reaches your buckets. Make one, upload a file, and decide object by object who gets to see it.

Create a Bucket See Storage Rates