Security & privacy

Customer object data is not persistently stored by BucketPilot. What we keep is metadata — an index of object names, sizes, and storage classes.

Browser transfers use direct presigned URLs: uploads and downloads go straight between your browser and your own storage, and those bytes never pass through BucketPilot's servers.

During a migration or backup you have configured, BucketPilot may temporarily stream object data between the source and the destination you named, without persisting the object contents. That job is the only path on which our infrastructure handles object data at all.

BucketPilot Cloud is the deliberate exception. Files you put in a Cloud bucket are stored by us, in the region you chose and nowhere else (regions are not replicated to each other), for as long as the bucket exists; a deleted bucket stays restorable until its billing term ends and is then removed. Versioning, if on, keeps every copy of a file — and every copy is billed as storage. See BucketPilot Cloud for regions, billing and limits.

• •The recommended one-click CloudFormation role means no long-lived keys are stored at all: BucketPilot assumes a least-privilege IAM role in your account using a unique ExternalId, and you revoke access at any time by deleting the stack.
• •Where keys are used (access keys, R2 tokens, GCS interop keys, SSH private keys), they're encrypted at rest with AES-256-GCM and never returned by any API after saving.
• •Keys pasted with more permissions than needed are flagged at save time (an admin-level AWS key gets a warning and a suggestion to swap it for a least-privilege one).
• •SSH host keys are pinned on first connect; a changed key stops jobs with both fingerprints shown instead of silently trusting a possibly-impersonated server.

Every resource — credentials, buckets, jobs, activity — is scoped to exactly one workspace (your personal account, or one organization). Nothing is shared across workspaces, and organization roles (admin / member / read-only) gate what each person can change.

Every meaningful action lands in the activity feed — who did what, when, to which bucket or job — including denied permission attempts. On Business, the full feed exports as CSV for compliance reviews.

All traffic is TLS in transit; the app enforces HSTS. BucketPilot runs on AWS. API keys are stored as hashes and rate-limited per key.

An API key's scope decides what it can do, and it is worth being precise about. A read key is strictly GET-only. A read_write key can upload, copy and delete objects, create folders, change tags and storage classes, issue upload forms, and start, pause or cancel jobs — everything the app can do to your data over the API. Treat one like the storage credentials behind it, and issue read keys where reading is all that is needed.

Questions this page doesn't answer — data-processing terms, compliance attestations, or a security review for your procurement process — reach the team at any time via the in-app support assistant or the contact email; you'll get an engineer, not a form.

On the Business plan, the dashboard's activity feed exports as CSV — timestamp, actor, action, bucket, and job for every event in the workspace. Export CSV offers quick ranges (last 24 hours, 7 days, 30 days, all time) or a custom calendar range; the file is named with the dates it covers. Useful for compliance reviews and answering "who did what, when". A cell that begins with = + - or @ (a bucket, job or person named that way) is written with a leading apostrophe so a spreadsheet shows it as text instead of running it as a formula — drop the apostrophe if you need the original.