TMKeep private files private
Create a private bucket and choose which apps or keys can read and write it. Uploads stay private until you explicitly share a link or publish an asset folder.
APP STORAGE
Private files.Connected to your app.
Create a bucket, connect your app and work with the same objects in the console and your S3 client. Keep access clear and capacity visible.
Available on hosted Fortly. Private S3 buckets and deliberately public Project files share the account storage pool.
DEFAULT ENVIRONMENT
App uploads Private
3 objects · Same files in your console and S3 client
ALL FILES
SELECTED OBJECTreports/export.csvtext/csv
Activity this monthIllustrative totals · traffic is separate from stored capacity
- Read requests
- 125
- Write requests
- 18
- Data received
- 21 MB
- Data sent
- 1.6 GB
Connect launchboard.
Choose the access your app needs. Fortly saves a dedicated key and runtime variables together.
Includes uploading, replacing and deleting objects.
App connection configured
Read and write
Encrypted runtime variables saved. Redeploy if your app reads them at startup.
S3_ENDPOINT · S3_REGION · S3_BUCKET
AWS_ACCESS_KEY_ID · AWS_SECRET_ACCESS_KEYUse it in your app ↗Connecting storage does not grant your app's users access. Your app authorizes each document request.
One key. One bucket.
Use a dedicated credential for each integration. A secret is shown once when created; key lists cannot retrieve it.
- App connection
- Not connected in this example
- Permission
- Choose it in Connect
- Secret storage
- Encrypted · server-side
Rotation creates a replacement. Verify the new connection, then explicitly revoke the previous key.
Read the key lifecycle guide ↗Private stays private.
Display names can change. The S3 identity stays stable so app connections keep working.
- S3 name
app-uploads-example- Access
- Scoped key or temporary signed request
- Browser access
- Explicit origins, methods and headers
- Shared capacity
- Project files + private objects + pending work
Public bucket URLs and built-in bucket CDN delivery are not enabled. Database restores do not restore objects.
Understand capacity and cleanup ↗Local example · No uploads, keys or account changes · Private buckets require an enabled installation
THE ACCESS MODEL COMES FIRST
Your files. Clear boundaries.
Connect without copying secrets
Add a dedicated key and runtime variables to your Fortly app together. Existing values are never overwritten.
See capacity and activity
One shared allowance counts stored and pending bytes. Request and transfer totals explain how each bucket is used.
UPLOAD. CONNECT. USE.
One storage workspace.
Access you can understand.
Private buckets have their own keys and temporary links. Public files keep their public URLs. The console makes the distinction explicit.
Read the private bucket guide ↗01A private bucket for your app.
Open Storage, create a bucket with a display name, then upload a file or connect your app. Files, Connect, Delivery, Access keys and Settings stay inside Fortly’s existing project workspace. Renaming a bucket does not move its objects or change the stable S3 name.
A connection adds a dedicated bucket key and five encrypted runtime variables in one transaction. Choose Read only or Read and write, including deletion. Use a prefix for a second bucket, and review conflicts before changing an existing variable. Disconnect revokes the key and preserves values you edited yourself.
Private buckets are available on hosted Fortly within the same account storage pool. New buckets keep delivery off until you choose signed links or explicitly publish an asset folder. Fortly currently uses the Default environment for these resources; this feature does not introduce automatic preview-environment cloning.
02The same files through your tools.
Console uploads and S3 clients use the same private objects. Connect an external app with the endpoint, region, stable bucket name and a scoped key. Path-style SDK and CLI examples are available beside the connection controls. Secrets are shown once, and ordinary key lists cannot retrieve them.
The supported S3 subset includes scoped discovery, object reads, byte ranges, listings, writes, deletion, same-bucket copy and multipart uploads. Single uploads are limited to 64 MiB; multipart objects can reach 5 GiB with documented part limits. Unsupported operations fail explicitly. Check the compatibility guide, including checksum and client configuration limits, before production migration.
Temporary download links expire and remain subject to the signing key’s access. Console links can be revoked together without disrupting app keys. CDN delivery is a separate opt-in: require signed links or explicitly confirm one public asset folder, while the S3 origin stays private. Open Delivery for cache lifetime, URLs, purge, pause and delivery-budget visibility. Cache activity adds time-range charts, observed reasons, measured timing and a request inspector without retaining signed URLs or object paths. Explore the delivery workflow.
03Capacity that includes work in progress.
Private buckets and public Project files, including Worker R2 folders, draw from the existing account object-storage pool. Uploads reserve capacity atomically. Incomplete multipart uploads and uncertain writes remain counted until cleanup settles them. A replacement temporarily needs room for both copies.
In each bucket, Activity this month shows read and write requests plus data sent and received. These durable totals include supported S3 and console file operations. Traffic is measured separately from stored capacity. Plan reductions must still cover stored files and pending uploads; keep enough storage capacity or free space before moving down.
Deleting a file removes it from listings immediately; space becomes available when the backing bytes are removed. Accounts at their limit can still read and delete authorized files. PostgreSQL, key-value data, deployment artifacts and platform backups are separate from this meter. No additional bucket charge is introduced.
Permanent bucket deletion first revokes access, then removes objects and incomplete uploads in retryable background work. The stable identity is never reused. There is no recovery window: keep separate copies when your retention policy requires them.
04Public files and Worker compatibility stay explicit.
Existing Project files stay available at /_files/ on the project and connected custom domains. Anyone who knows the URL can download them. Use them for public images and downloadable assets; an unguessable name is not authorization. Creating a private bucket does not migrate or change these files.
Worker R2 bindings remain project-file folders, with the documented get, head, put, delete and list subset and retained binding metadata. They do not automatically become private S3 buckets. Open Deployments → Bindings to reach their matching folder, or Storage → Project files to browse it directly.
Public files and Worker bindings · Private bucket control API
05Storage context for your AI agent.
The remote MCP tool list_storage_buckets discovers resources within the agent’s approved projects. It reports bucket identity, state, aggregate usage and redacted app connection status, then rechecks current project membership on every call.
Object names, contents, access-key secrets and temporary links are excluded. An agent can help diagnose capacity or write an SDK integration without receiving private files or credentials. Storage administration stays in the console and authenticated control API.
A file workflow you can follow.
Keep resource setup, app configuration and day-to-day file work together. The bucket has one header and five sections: Files, Connect, Delivery, Access keys and Settings. Its identity stays stable when the display name changes. You can work with an SDK and return to the console to inspect the same object, without exporting it into a second file manager.
Make the first object visible.
Name the bucket, upload a small file and inspect its size. Folder navigation follows S3 prefixes; a folder appears when an object exists under it. Refresh files reloads objects written by SDKs as well as the console.
Give the app the right access.
Choose read only or read and write. Save a dedicated key and encrypted runtime variables together, then follow the connection's deployment guidance. Your application decides which user can act on which object.
Understand the next change.
Review request and transfer totals, plan account capacity, rotate keys with an explicit cutover and watch cleanup settle after deletion. Keep metadata visible to project members without granting private object access.
Share a document. Keep the bucket private.
A temporary URL is useful when your app has already checked the person asking. The recipient downloads directly through the S3 endpoint, while an ordinary public file URL would skip that authorization boundary. Choose a short expiry, protect the signing key and keep the URL out of logs. The console can revoke its temporary links together without disrupting separately scoped app keys.
Browser access has another boundary: explicit CORS origins, methods and headers. CORS does not grant object permissions. Server-to-server clients use scoped credentials, and app-user authorization belongs in the application. The access model is documented alongside the SDK examples, rather than left to trial and error after an upload succeeds.
Follow a private upload from user to download or go directly to keys, rotation and browser access.
Stored capacity and traffic, explained separately.
The bucket header reports its committed objects. The account meter includes all participating project files, private objects and pending work. A replacement needs temporary headroom; deleting a file releases capacity only once the backing bytes are removed. Reads and deletion remain available when the account reaches its allowance.
Monthly activity follows requests started in the current UTC calendar month. It records supported authorized S3 and console file operations, including retries, with processed HTTP body bytes. HEAD does not count a full-file download, and a byte range counts its transferred body. These measurements persist across node restarts and are available to approved metadata-only agents.
Moving to a smaller plan cannot strand a larger data set in an undersized allowance: retain enough Storage Packs or free space before the reduction takes effect. No data is automatically deleted, no pack is silently purchased, and usage metrics do not turn into automatic per-request charges. Read the capacity examples and refusal guide before a larger import.
A delivery path with an access boundary.
Use the bucket's Delivery section to keep documents behind short-lived signed CDN links or deliberately publish an asset folder. Preview files before confirming public access. Existing bucket credentials sign private links in server-side application code; no extra secret needs to enter a browser.
The edge caches eligible bodies after checking current access and the shared delivery budget. Overwrite and deletion change what can be served, revoking a key blocks its signed links on hits too, and purge selects a fresh cache generation across edge locations. Original objects count once toward stored capacity; delivery requests and processed bytes are tracked separately. See CDN delivery or follow the setup, signing and usage guide.
Before you build
A few useful answers.
Are stored files private?
Private buckets require scoped keys or temporary signed links. Project files and existing Worker R2 folders remain public at their /_files/ URLs. Private buckets are available on hosted Fortly and open first in Storage.
Can I connect an S3 client?
Private buckets support a documented S3 subset with path-style addressing, scoped keys, byte ranges and multipart operations. Read the compatibility guide before moving a production client. Worker R2 bindings have their own separate subset.
How is capacity counted?
Private bucket objects, incomplete uploads and Project files share the account’s existing object-storage pool. Reserved uploads and cleanup are counted conservatively. No separate bucket charge is introduced.
Does a database restore restore files?
No. PostgreSQL point-in-time recovery leaves object storage unchanged. Permanent bucket deletion has no promised recovery window.
What happens when storage is full?
New writes that cannot reserve capacity are refused. Authorized reads and deletions remain available. Replacements need space for both copies until cleanup removes the previous one.
Can I move to a smaller plan with files still stored?
Only if the new capacity covers stored plus reserved bytes. Otherwise the request is rejected and the current tier and packs remain unchanged. You can explicitly retain enough Storage Packs on the smaller base plan.
Do traffic figures mean I am being charged per request?
No. The current request and transfer totals are usage measurements. Payment collection, a prepaid wallet and automatic usage invoicing are not connected.
Does a private bucket include a CDN?
CDN delivery is separately enabled. Configure signed links or explicitly publish a folder in Delivery. The S3 origin stays private, and cache hits still check current access and delivery budgets. The CDN guide explains access, caching and current delivery limits.