Which plan includes this?

Team, for both the EU option and your own bucket. On Free and Pro, builds are stored in the United States.

Do builds I already uploaded move when I change the place?

No. Only new uploads go to the new place. Builds you already have stay where they are and keep working. Settings counts your live builds per place.

Which files go to the chosen place?

The .ipa, the .apk and a kept .aab of each build. Install pages, icons, tester feedback and analytics stay in AppForShare's own systems.

What if my bucket cannot be written?

The upload fails with a clear message. The file never lands somewhere else instead.

How do testers download from my bucket?

Through a signed link that works for 10 minutes, made when they press install or download. The bucket itself can stay private.

The Owner or an Admin. Everyone in the workspace can see where new builds go.

AppForShare Open Settings

Docs

Where build files are stored

On Team you choose where the build files of new uploads are kept: AppForShare storage in the United States or the European Union, or a bucket of your own. Settings, Where your files are. The Owner or an Admin changes it.

The three places

United States (default): AppForShare storage on Google Cloud us-east4. Every workspace starts here.
European Union: AppForShare storage on Google Cloud europe-west. Pick it in Settings, Where your files are.
Your own bucket: An Amazon S3 bucket, a bucket on any S3 compatible service, or a Google Cloud Storage bucket with an HMAC key. While a bucket is connected, it takes every new upload and the US or EU choice is not used.

Only the .ipa, .apk and kept .aab of each build live in the chosen place. Install pages, icons, feedback files and analytics do not.

Connect your own bucket

Service: Amazon S3 or S3 compatible, or Google Cloud Storage (HMAC key).
Endpoint: S3 only: the https address of the service, for example https://s3.eu-central-1.amazonaws.com. Google Cloud Storage always uses storage.googleapis.com.
Region: S3 only: the signing region, for example eu-central-1.
Bucket name in the host name: S3 only: tick it for Amazon S3 virtual hosted style addresses; leave it off for services that want path style.
Bucket: The name of the bucket.
Folder: appforshare/ by default; empty means the bucket root. Every build file goes under it.
Access key ID and Secret access key: A key that can write, read and delete objects in the bucket. For Google Cloud Storage, an HMAC key of a service account.

Press Test and save. Before saving, AppForShare writes one small file under the folder, reads it back and deletes it. If any step fails, nothing is saved and the message says why. The bucket's address must be public. The keys are encrypted with Google Cloud KMS, never shown again (only the last 4 characters of the key ID), never logged, and never returned by the API, CLI or MCP server. Test again checks a connected bucket at any time.

Folder layout

AppForShare writes only under <folder>builds/<build>/, one folder per build.

<bucket>/
  appforshare/            the Folder field
    builds/
      AbC123/             one folder per build (its link slug)
        package.ipa       the package testers download
      Xy9Kp2/
        package.apk
        bundle.aab        an uploaded .aab, when it is kept

What AppForShare does in your bucket, and never does

Writes the files of new builds under <folder>builds/<build>/ and reads them back for the checks on each new build, such as the malware check. Testers download through signed links.
Deletes only the files of a build that was deleted or expired, after the usual 7 day restore window.
Never lists the bucket, and never touches objects outside the build folders it wrote.
Deleting your AppForShare workspace deletes nothing in the bucket except our build files.

Lifecycle rules

AppForShare runs its own clean up: when a build is deleted or expires, it goes to the 7 day restore list, and after that window its files are deleted from the bucket. Live builds are never removed by this clean up. Because AppForShare never lists the bucket, it does not notice files that disappear on their own.

Do not set a bucket lifecycle rule that deletes objects under the AppForShare folder while builds are live. A tester would then get a broken download for a build the dashboard still shows.
If you want a rule as a safety net, make it longer than your longest live build, and limit it to the AppForShare folder.
With versioning on, a file AppForShare deletes stays as a noncurrent version until your own rules remove it, and it still counts in your provider's bill.

Disconnect

Disconnect sends new uploads back to AppForShare storage. Builds already in your bucket keep working until they are deleted or expire, and nothing in the bucket is deleted when you disconnect. Once no live build is left in it, AppForShare deletes the keys.

CLI

appforshare whoami prints where new builds are stored. appforshare info prints where one build's file is when it is in the EU or in your own bucket.

$ npx appforshare whoami
[email protected] in Acme (owner), plan team
New builds are stored in: United States (Google Cloud us-east4, Northern Virginia)

$ npx appforshare info AbC123
...
File stored in: your workspace's own bucket

Questions

Which plan includes this?: Team, for both the EU option and your own bucket. On Free and Pro, builds are stored in the United States.
Do builds I already uploaded move when I change the place?: No. Only new uploads go to the new place. Builds you already have stay where they are and keep working. Settings counts your live builds per place.
Which files go to the chosen place?: The .ipa, the .apk and a kept .aab of each build. Install pages, icons, tester feedback and analytics stay in AppForShare's own systems.
What if my bucket cannot be written?: The upload fails with a clear message. The file never lands somewhere else instead.
How do testers download from my bucket?: Through a signed link that works for 10 minutes, made when they press install or download. The bucket itself can stay private.
Who can change it?: The Owner or an Admin. Everyone in the workspace can see where new builds go.

Overview: where build files are stored. Related: where are my test builds stored, automatic clean up, privacy.