Working with objects

Use Copy to… or Move to… from a file's ⋯ menu, or select several files and use the Copy / Move buttons.

Both let you choose a destination bucket. By default the object stays in the bucket you're in; pick another and it lands there instead. The copy happens inside your storage provider — the bytes never travel through BucketPilot.

Only buckets on the same storage connection can be chosen, because a single copy is performed with a single set of credentials. To move data between two different connections — or into an SFTP server — create a migration job instead, which is built for that: it resumes, retries, and shows progress.

Where it lands. Type a full key to name the copy yourself. End the destination with a slash to drop the file into that folder under its own name, or enter a single / to put it at the bucket root. Selecting several files asks for a prefix instead, and each file keeps its own name beneath it.

Whole folders can be copied or moved too, including into another bucket — everything inside comes with them. Very large folders are better handled by a migration job, which resumes and retries; the file browser refuses a folder past its size cap and says so.

Drag files onto a bucket (or click Upload) and they go directly from your browser to your own storage over presigned URLs — BucketPilot never proxies the bytes. Uploading several files at once is a Pro feature; uploads are indexed the moment they finish, so they're searchable immediately.

Large files. A single upload request tops out at 5 GB — that is S3's limit, not ours. Past it the browser splits the file into parts and uploads them one after another, which is handled for you: there is nothing to switch on and no different button. The part size grows with the file, so a very large object never runs out of part numbers. If an upload fails part way, the parts already sent are discarded rather than left behind billing (you can see any that ever do accumulate on the bucket's Lifecycle tab). The largest object S3 can store is 5 TB.

Browser uploads need the bucket's CORS to allow them, and BucketPilot handles this for you: buckets created in BucketPilot get it on creation, and connected buckets get it automatically when you import them (with a fallback on the first upload). A bucket that already carries its own CORS rules is never touched — BucketPilot only adds the rule when there's none of its own.

From a bucket you can copy, move, rename, change storage class, edit tags, and download — including whole folders, recursively. Folder operations are capped at 5,000 objects; for anything larger, use a migration job.

Share a link… on a file's ⋯ menu makes a direct download link for someone who has no BucketPilot account. Pick how long it should work; the link goes straight to your storage, so the download never passes through BucketPilot.

Anyone holding the link can download the file until it expires. There is no sign-in behind it and no way to withdraw one once it has been sent — forwarded, archived or pasted somewhere public, it keeps working until the clock runs out. Treat the link as you would the file.

How long a link can last depends on how the bucket is connected. A bucket connected with access keys can have links of up to seven days, which is the protocol's own limit. A bucket connected through a role — what the one-click setup creates — is signed with a temporary session, and a link cannot outlive the session that signed it: in practice that is about an hour. BucketPilot only offers the durations that will actually work and says which limit applies, rather than handing you a seven-day link that stops working after sixty minutes.

Archived files can't be shared until they're restored — the link would be refused by your storage provider, so BucketPilot says so instead of producing one.

CORS decides which websites may read from or write to a bucket directly from a visitor's browser. When a request isn't allowed, the browser refuses the response before your code runs — the bucket logs a successful request and your app sees an unexplained "Failed to fetch", naming no rule and no reason.

A bucket's Security tab has the rules and, more usefully, a test:

• •Editing. Origins one per line (scheme, host and port — never a path, because a browser never sends one), methods as checkboxes, request headers, exposed headers and the preflight cache. Rules are checked here before they're saved: S3's own answer to a bad rule is MalformedXML, which names neither the rule nor the field.
• •Testing. Give an origin, a method and any request headers, and BucketPilot tells you whether the bucket's live rules would allow it — and if not, which of the three things was wrong and what to change. This is the question a real browser test can't answer: a browser only ever sends the origin it's on, so a test fired from BucketPilot could only ask whether BucketPilot may reach the bucket, never whether your own site may.

Two things worth knowing. Saving replaces the whole configuration — there is no per-rule write in S3, so every rule you see is exactly what the bucket will have. And BucketPilot needs a rule of its own: uploads and downloads in the file browser go straight from your browser to your storage, so if you remove every rule, BucketPilot re-adds its upload rule on the next transfer rather than leaving the app broken. A bucket that should truly be closed to browsers has to be closed in your provider's console.

A bucket's Security tab shows how it is protected at rest and against deletion — the questions an audit asks, without a trip to your provider's console:

• •Default encryption — whether a key was chosen for this bucket, and which. A bucket with no encryption configuration is not an unencrypted bucket: on AWS every object has been encrypted with S3-managed keys since 2023 regardless, so BucketPilot reports that as Provider default rather than as a problem. When a KMS key is used, BucketPilot also shows whether S3 Bucket Keys are on — leaving them off can multiply KMS request charges on a busy bucket.
• •Object Lock — whether objects can be deleted before their retention expires, and in which mode. COMPLIANCE means nobody can, including the account root; GOVERNANCE means a user holding the bypass permission can.
• •Versioning and MFA Delete.

On Amazon S3 these are controls, not just readouts.

• •Default encryption — the Change button on that row: S3-managed keys, your own KMS key, or dual-layer KMS. It applies to new objects only — nothing already in the bucket is re-encrypted. S3 itself doesn't check a KMS key when you set it — a typo is saved and every later upload then fails — so BucketPilot first tests the key with a one-byte write (removed straight away; it needs s3:PutObject and s3:DeleteObject, and the connection must be allowed to use the key: kms:GenerateDataKey and kms:Decrypt). If the test fails you are told why and can still save anyway; on a bucket with an Object Lock default retention the test is skipped, because its test object couldn't be removed, and you are told that too.
• •Turn on Object Lock — when you create a bucket (the New bucket dialog), or for an existing bucket that has versioning on (the Security tab). It can never be turned off, and versioning stays on for good. Admins only.
• •Default retention — lock every new object for a number of days or years, in Governance mode (a lock only someone holding a special bypass permission could shorten — and BucketPilot never asks for it) or Compliance mode (nobody can delete or overwrite the object until it expires, not even the account root). Or remove the default. Admins only, and you confirm Compliance by typing it.
• •One file — the file's menu, Retention & legal hold…: lock it until a date, and place or lift a legal hold (a hold has no end date and does not expire; it blocks deletion until someone lifts it). A lock can be extended and never shortened from here, and its mode isn't changed. A Compliance lock needs an admin and the same typed confirmation.

MFA Delete stays display-only: it can only be changed by the account root user with the AWS CLI and a hardware token, so there is no console or API path for it anywhere. Changing a bucket's default encryption does not re-encrypt anything already in it, and a default retention applies to objects written after it is set. These controls need the Put permissions in the connection's policy — see Connecting your AWS account — and the Credentials page tells you if a connection doesn't have them yet.

"Not reported" is its own answer. If your provider doesn't implement one of these calls, or the connected credential isn't allowed to read it, BucketPilot says so instead of showing it as off — and when it's a permission that's missing, it points you at the connection that grants it.

MFA Delete is the one case where nothing reported means off. S3 mentions MFA Delete only once it has actually been set up, so a bucket that has never had it says nothing at all — which BucketPilot shows as Off, not as unknown. (A bucket created with Object Lock reports it as disabled outright.)

The Whole bucket menu at the top of a bucket's page does three things to every object in it:

• •Download everything builds one .zip. An archive can hold 2,000 objects and 4 GiB, so for a bigger bucket the dialog says so and points you at a copy instead, rather than offering a button that can't work. Objects archived to Glacier can't go in a zip; you are told which.
• •Copy everything to another bucket copies every object into a bucket you pick, optionally under a folder, keeping their paths. Nothing changes in the original. It runs as a tracked job you can leave and come back to.
• •Move everything to another bucket does the same, then removes each object from this bucket once its copy has landed. The bucket stays, empty. You confirm by typing its name, and only people who may delete see it.

A copy always goes into a different bucket — copying a bucket into itself has no useful meaning — and the destination must be on the same kind of storage; use a copy job for anything else, or for a server. Moving is refused while a backup or migration job reads from or writes to the bucket, and names those jobs, because emptying it would leave them with nothing; copy instead, or change those jobs first. All of it needs access to the whole bucket, not one folder of it.

When a transfer dies half way — a closed laptop, a dropped connection, a process killed mid-copy — the parts it already uploaded stay in the bucket and keep billing. They aren't objects: they appear in no file listing, and they aren't counted in this bucket's cost estimate either, because that's built from the object index.

BucketPilot finds them. Open a bucket's Lifecycle tab and, under the rules, you'll see how many unfinished uploads it holds, how old they are, how much they take up, and roughly what they cost per month. You can abort selected ones, or sweep everything older than seven days.

Aborting discards the parts and cannot be undone — whoever started the upload would have to start it again. Uploads younger than 24 hours are never swept, because an upload still running looks exactly like an abandoned one. Individual uploads can still be aborted by hand, which is a person looking at one row and deciding.

To stop them accumulating at all, add a lifecycle rule that aborts incomplete uploads after a few days — the rule editor has a switch for it, and it costs nothing to leave on.

Objects in GLACIER or DEEP_ARCHIVE keep no readable copy. They still appear in the file browser, marked Archived beside their storage class, but they can't be downloaded or copied until a restore has thawed them — that's a storage-provider rule, not a BucketPilot limit. GLACIER_IR is different: it's cold but instant, and needs no restore.

Restoring. Use Restore from archive… from a file's ⋯ menu, or select several files (or whole folders) and press Restore from archive. You choose:

• •How fast. Expedited (1–5 minutes), Standard (3–5 hours), or Bulk (5–12 hours). Deep Archive has no Expedited option — it offers Standard (up to 12 hours) and Bulk (up to 48 hours). Faster tiers cost more per GB, and retrieval is billed separately from storage.
• •How long it stays readable. 1–90 days, 7 by default. When that window ends the temporary copy disappears and the object is archived again.

A restore does not change the storage class — a restored GLACIER object is still GLACIER, with a readable copy alongside it. The badge follows the state: Archived, then Restoring…, then Readable with the expiry date.

Anything in the selection that isn't archived is skipped rather than failed, so restoring a mixed folder does the right thing. If you try to download an archived object, BucketPilot says so and offers to restore it instead of handing you a link that would fail.