Manage bucket access and keys

A private bucket has three separate access paths: Fortly account roles for console administration, bucket-scoped S3 credentials for applications, and temporary signed requests for recipients. Choose the narrowest path that does the job.

Separate people, apps and recipients

A management API token is not an S3 key. An S3 key cannot create buckets, administer other keys, change account settings or authorize console routes. Never give a browser a management token to make a file upload work.

Remove a teammate's access

Removing or demoting an admin stops their private-file and bucket-management access. Fortly checks current membership again inside protected write transactions, including bucket creation and retries. A file upload admitted before an access change must still pass authorization before it is published.

S3 credentials are delegated application access, independent of the human who created them. Removing that person does not automatically revoke those keys or disconnect a running app. During offboarding, review Access keys and Connect in each affected bucket. Revoke external keys that the person could use, rotate app credentials, verify the replacement, then revoke the previous keys. An owner or another current admin must perform these actions.

Choose a permission

Read only supports scoped bucket discovery, object listings, metadata and downloads. It cannot upload, replace, delete or copy objects into the bucket. Use it for consumers that serve existing files.

Read and write includes deletion. Use a separate credential for an uploader, background job or administrative integration, and protect it accordingly. A write key still cannot change bucket policies or administer the bucket.

Keys have one bucket's scope. A CDN folder restriction does not reduce the key's S3 access to that folder. Use separate buckets and credentials for separate integration boundaries. Sharing an account or project does not grant a key access to another bucket. Object names are identifiers, not access rules: a users/alex/ prefix does not implement end-user authorization. Your app checks who may request each file before it signs or sends an S3 request.

Connect a Fortly app

In the bucket's Connect section, choose the permission and connect the project app. Fortly creates a dedicated credential and adds encrypted runtime variables together. A configurable prefix lets the same app connect to more than one bucket without reusing variable names.

Existing variables are not overwritten. If a name conflicts, select another prefix or deliberately resolve the conflicting configuration. The configured connection shows its permission and provides a code example using its saved prefix. Read-only connections show a download example. Follow the result's configuration-refresh and redeployment guidance.

Disconnecting revokes the connection credential and removes variables that still belong to that connection. Values you edited later are preserved; review them before connecting again. Disconnecting a bucket does not delete its objects. After disconnection, deleting the old bucket will not remove configuration belonging to a replacement connection.

Create an external access key

Open Access keys → Create access key, enter a name and choose its permission. Set an expiry when the tool has a limited lifetime. Creation returns the secret once. Copy it into a secret manager or the external application's server configuration, then acknowledge the result before leaving.

Ordinary key lists never return the secret. If it is lost, create a replacement; there is no recover-secret action. Do not paste it into chat, screenshots, source control or browser storage. The list shows the key's state, permission and last-used time; last use is updated periodically rather than for every request.

Use a different key for each integration so that retiring one does not disrupt the others. Revocation affects subsequent requests; a response that was already streaming may finish.

Rotate without an unexplained outage

For an app connection, choose its rotation action. Fortly creates a replacement key and updates its owned runtime variables. The previous key remains active until you explicitly revoke it. Verify that the app can read or write with the new configuration, apply any required restart or deployment, then revoke the previous key under Access keys.

For an external tool, create a replacement credential, update the tool's secret configuration, test the required operation, and revoke the old key. If a credential is compromised, revoke it immediately rather than keeping a cutover window.

Rotation is not revocation. Retaining an old key deliberately keeps its access until the final step. Audit each remaining integration before retiring a shared credential.

Understand temporary links

A signed URL is a transferable credential for a particular request. The console defaults to 15 minutes and enforces a maximum of 24 hours. Use shorter expiry for sensitive documents. It is not a one-time link, and changing the object at the same key can change what an unexpired link downloads.

Console S3 links and console-generated signed CDN links share a hidden read-only signer. Settings → Revoke download links revokes the console signer and invalidates its existing links. It also invalidates console-generated signed CDN links. It does not revoke ordinary app keys or public folder URLs. App-generated URLs follow the key your app used to sign them; revoke that key to block subsequent requests through those links. Individual console-link revocation is not offered.

Bucket deletion revokes its access before cleanup starts. Platform account deletion also revokes access. Your app's end-user sign-out does not, by itself, revoke an already-issued signed URL.

Allow a browser origin

Use Settings → Browser access (CORS) only when a browser needs to call S3 directly. Add the exact origin, allowed methods and actual request headers. An origin includes scheme and port where applicable; https://app.example.com is different from a localhost origin.

Each rule is checked as a complete rule. An origin allowed to GET in one rule does not gain PUT merely because another rule permits PUT for another origin. Saving or removing CORS rules never substitutes for a valid key or signature. Server-to-server S3 requests do not need CORS.

Keep access separate from capacity

A valid key does not bypass plan limits. Private writes share capacity with Project files, multipart data and pending cleanup. Over-quota accounts retain authorized reads, deletion and multipart aborts. Review usage and capacity for admission and plan changes, or the control API for automation.

Deliver with edge caching

The bucket's Delivery section offers signed CDN links using existing bucket-scoped read credentials, or explicitly confirmed public folders. Every cache hit checks current key/scope/account access and delivery budget. Signed delivery tokens are not S3 SigV4 URLs. Pause blocks new requests; revocation retires a signing key's links. Public delivery never grants S3 upload, listing or administration.