Where your files are stored

Every organisation gets storage on the platform by default, and can instead connect its own S3 bucket or WebDAV server. The choice is made once, for the organisation, by an administrator with the storage permission — it is not a per-project or per-file setting.

The default: platform storage

Files are held in the platform’s own storage in Frankfurt. Nothing needs connecting and nothing needs paying for separately — the space available is the one your plan includes.

That answers most data-residency questions on its own. The honest limit: the hosting provider is US-headquartered, so a European region does not by itself answer an objection about US legal reach. If that is the question being asked, connect your own storage.

Connecting your own storage

Where an organisation chooses platform storage or connects its ownOpen /a/settings/organization in the app

×

Two kinds are supported:

S3, or anything that speaks the S3 API — AWS, and the many providers that implement it. You give the connection a Name, then supply an Endpoint, a Region, a Bucket and an access key pair.

WebDAV — Nextcloud, ownCloud and similar. You supply a Server URL, a username and password, and a Base path under the server root (for example /remote.php/dav/files/anw). Leave the path empty to use the root itself. WebDAV has no region, so that field does not appear.

A few things that surprise people:

• The region is stored exactly as you type it and is never guessed from the endpoint. It is frequently a compatibility value rather than a real place — Infomaniak, for instance, documents us-east-1 for data physically held in Switzerland. Copy whatever your provider’s documentation says, even when it looks wrong.
• Connecting does not move anything. Files already stored keep living where they were written. The backend you choose applies to new uploads.
• A connected backend cannot be disconnected while it still holds files. The attempt is refused rather than orphaning them.
• Credentials are write-only to you. They are stored encrypted and never shown again, and the activity log records which bucket was connected — never the secret.

Setting up an S3 bucket

The bucket is created in your provider’s console, not here. The platform needs a private bucket and a key pair scoped to it — never your account’s root credentials.

1. Create a private bucket. Public access must stay off: every file is served through the platform, which mints a short-lived link per download, so nothing needs to be world-readable.

2. Create an access key limited to that bucket, and grant it these actions — reading, writing, deleting, and the four that large uploads are split into:

   GetObject · HeadObject · PutObject · DeleteObject · CreateMultipartUpload · UploadPart · CompleteMultipartUpload · AbortMultipartUpload

   Without the multipart four, small files upload and large ones fail.

3. Add a CORS rule — only if you want Direct uploads. Skip this and the connection still works on the proxied lane. The rule must allow PUT, GET and HEAD from https://actionnetwork.world, and — the part that is easy to miss — it must expose the ETag response header:

   [
     {
       "AllowedOrigins": ["https://actionnetwork.world"],
       "AllowedMethods": ["PUT", "GET", "HEAD"],
       "AllowedHeaders": ["*"],
       "ExposeHeaders": ["ETag"]
     }
   ]

   ExposeHeaders is the one that fails silently. Without it the upload returns a perfectly good 200 and the browser simply cannot read the ETag back, so the file is rejected with nothing in the bucket’s logs to explain why.

4. Check Path-style addressing before connecting. It is on by default, and that default is right for almost everything — most S3-compatible providers require it. AWS itself does not: turn it off for a real AWS bucket.

5. Connect it, then press Test. Connecting writes and reads back a test object first, so wrong details are caught here rather than on somebody’s first upload. A green Direct uploads is the CORS rule working; Uploads via ANW means the test could not read the ETag — the files still arrive, and the file library works either way.

The connect dialog: provider, endpoint, bucket and credentialsOpen /a/settings/organization in the app

×

If your provider is not AWS

Most S3-compatible providers work unchanged. Two things to expect:

• The region is often a dummy. Infomaniak documents us-east-1 for data held in Switzerland. Type whatever their documentation says; it is stored verbatim and never inferred.
• Some cannot do Direct uploads at all. OpenStack Swift — which Infomaniak’s S3 API runs on — cannot expose ETag to a browser, so those connections stay on the proxied lane however the bucket is configured. That is not a misconfiguration and there is nothing to fix.

Setting up a WebDAV server

Nextcloud, ownCloud and anything else speaking WebDAV. The connection authenticates with a username and password over Basic auth.

1. Create a dedicated login, or an app password on an existing account. On a server with two-factor authentication an app password is usually the only credential that will work over Basic auth at all — and a separate one can be revoked without disturbing anything else.

2. Find the base path. It is the path under the server root where files should live, not the whole URL. On Nextcloud it looks like /remote.php/dav/files/your-username, optionally with a folder under it. Leave it empty to use the root.

   It must start with / and contain only letters, digits, dots, dashes and slashes.

3. Connect it. On connect the platform writes and reads back a small probe file under _anw-probe/, creating that folder if the server needs it — so the credentials need to be able to create a folder, write and read. A failure here names what the server refused.

4. Expect Uploads via ANW. WebDAV has no pre-authorised upload link a browser can use, so there is no Direct-uploads lane to enable. Everything else behaves identically — see the file library.

Two upload lanes, and which one you get

A connected backend shows one of two labels.

Direct uploads — files go straight from your browser to your bucket. Fastest, and the platform never handles the bytes.

Uploads via ANW — files are routed through the platform on their way to your storage. Slower for large files, identical in every other respect, and the file still ends up in your own bucket.

WebDAV is always the second one, and no amount of configuration changes that. WebDAV has no concept of a pre-authorised upload link a browser can use, so there is nothing to enable. It is a property of the protocol, not of your server.

For S3, the lane depends on your bucket’s CORS configuration, and there is a Test button that settles it. The test has to run in your browser and cannot be done for you on the server: a server does not enforce CORS, so a server-side check reports success for a bucket no browser can actually reach. Some providers also cannot expose the response header the test needs through their S3 API at all — OpenStack Swift, which Infomaniak uses, is one, so those connections stay on the proxied lane no matter how the bucket is configured.

If the test fails, nothing is broken. You are on the proxied lane; fixing the bucket’s CORS rules and testing again moves you to direct uploads.

What never follows your choice

Some files are deliberately kept on platform storage no matter what your organisation has connected:

• Verification documents. They are evidence about your organisation held for compliance, so the subject of that evidence must not be able to delete them.
• Anything published publicly — organisation page images, post assets and the renditions social networks fetch. A private bucket would break those the moment someone shared a link.

Organization settingsOpen in the app

https://actionnetwork.world/a/settings/organization