Where test build services store your files, and why EU buyers ask

Sooner or later a security questionnaire asks where your build distribution tool stores files. For European companies, and for agencies whose clients are European, it is often one of the first questions. A test build is not personal data in itself, but it is unreleased software, it can contain keys and endpoints, and the service around it holds tester emails, device identifiers and install records. This guide explains why buyers ask, what to ask any vendor, and where AppForShare keeps build files.

This is practical guidance, not legal advice. Your own data protection team decides what your company needs.

Why buyers ask

• Company policy. Many companies keep a list of approved regions for any service that holds their data or code.
• Client contracts. Agencies often sign contracts that say where a client's material may be stored.
• Transfers. European buyers review transfers of personal data outside the EU, and the tester side of a build tool does hold personal data.
• Leaks. An unreleased build can reveal features, endpoints and sometimes secrets. Knowing where it sits and who can reach it is part of the risk review.

A build service stores more than the build

"Where are the files" has several answers inside one service. Ask about each:

• the build files themselves (.ipa, .apk, .aab, desktop packages);
• details read from the build: app name, version, bundle ID, icon;
• tester data: emails, device identifiers such as UDIDs, install records and IP addresses;
• feedback: screenshots, recordings and comments;
• logs, backups and caches in a content delivery network;
• mail, sent through an email provider that may be in another country.

What to ask any vendor

1. In which region are build files stored, and can I choose it? Does the choice apply to existing builds or only new ones?
2. Which of the items above follow that choice, and where are the others?
3. Can I use my own storage bucket? What does the vendor write there, what does it delete, and what happens when I disconnect it?
4. How are the keys to my bucket stored, and who can see them?
5. How do testers download: directly from the bucket, through signed links, through a CDN? How long is a download link valid?
6. When I delete a build, when are the files really gone, including backups?
7. Which sub processors handle my data, and where? This is usually on the privacy page.
8. If the chosen storage cannot be written, does the upload fail, or does it land somewhere else?

How Updraft describes its hosting

As listed on November 9, 2026, Updraft (Apps with love AG, Bern) hosts files in Switzerland with the provider Exoscale, and its Enterprise plan lets a customer use their own S3 bucket (for example on AWS or Exoscale) or Google Cloud Storage with a service account key. It is a good answer for buyers who want data in Switzerland. Ask them the same questions about the items that are not build files.

Where AppForShare stores build files

By default, build files are stored on Google Cloud Storage in the United States (us-east4). On the Team plan, an Owner or Admin can choose in Settings, Where your files are, where new uploads go:

• Our storage in the United States (Google Cloud us-east4), the default;
• Our storage in the European Union (Google Cloud europe-west);
• Your own bucket: Amazon S3, any S3 compatible service, or Google Cloud Storage with an HMAC key.

What the setting covers, plainly:

• It covers the build files: the .ipa, the .apk and the kept .aab. Install page details, icons, feedback files and analytics are not part of this setting; the privacy page lists who processes what.
• It applies to new uploads. Builds already uploaded stay where they are, and Settings counts how many builds are in each place. appforshare whoami and appforshare info show where new uploads go and where a given build is.
• If the chosen place cannot be written, the upload fails with a clear message. Files never land somewhere else instead.

For your own bucket, you give the endpoint, region, bucket, a folder (appforshare/ by default) and an access key. Before saving, AppForShare writes, reads and deletes one small test file there. The keys are encrypted with Google Cloud KMS and never shown again; only the last 4 characters of the key ID are displayed. AppForShare writes only build files under its folder, never lists the bucket, and deletes only the files of a build that was deleted or expired, after the usual 7 day restore window. Testers download through a signed link that is valid for 10 minutes. If you disconnect the bucket, new uploads go back to our storage, and builds already in your bucket keep working until they are deleted.

Choosing a location is a technical setting, not a certification. It answers the "where" question for build files; your own review covers the rest.

Common questions

Can I move my existing builds to the EU?

Not with this setting: it applies to new uploads. Upload a build again if you need that one in the new place.

Which plan lets me choose?

Team. Free and Pro store build files in the United States.

Does AppForShare delete anything else in my bucket?

No. It only touches its own build files under the folder you set, even when the workspace is deleted.

More: storage location and the storage location docs.