This isn't a separate copy or a backup - it's a relocation. Once a project is switched over, every file Kord stores for it (revisions, review-session uploads, published versions) is read from and written to your bucket instead of Kord's. Nothing about how the team works changes: reviews, diffs, and publishing behave exactly the same either way.

How it's set up

1. An organization admin adds AWS access keys once, on the organization's Storage settings. Kord probes the bucket immediately - it runs the same put/read/copy/delete/list calls a real sync would, so a missing permission shows up as an actionable error on the spot rather than the first time a file fails to save.
2. A default bucket can be set for the organization, which new projects adopt automatically. Existing projects switch over one at a time.
3. Switching a project on is a full migration, not a toggle: every file the project already has moves into the bucket, and every new file lands there from that point on. There's no partial mode that only routes future uploads.

The bucket is configured at the organization level, not per project - one set of credentials, probed once, shared by every project that opts in.

Turning it off (or pausing)

Pausing is an emergency valve: new files fall back to Kord's storage while everything already in your bucket stays reachable, and resuming picks up the paused-era files along with the rest. Disabling runs the same migration in reverse - every file moves back to Kord's storage before the project is marked off. Either way, the switch is a real migration with a progress state, not a flag flip that leaves files scattered across two places.

IAM policy

Create an IAM user with access keys and attach a policy scoped to just this bucket:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:GetObject",
        "s3:DeleteObject",
        "s3:AbortMultipartUpload",
        "s3:ListBucket",
        "s3:GetBucketCors"
      ],
      "Resource": [
        "arn:aws:s3:::YOUR_BUCKET",
        "arn:aws:s3:::YOUR_BUCKET/*"
      ]
    }
  ]
}

GetBucketCorslets the connection probe confirm your bucket allows browser previews (see below); without it, the probe just can't verify that part and says so.

Browser previews need CORS

Kord's file and diff viewers don't proxy your files through its servers - the browser reads them directly from your bucket over a short-lived signed URL. A fresh bucket blocks that by default, so add a CORS rule allowing GET/HEADfrom withkord.com. Kord checks for this at connect time and flags it in the settings panel if it's missing, rather than letting it surface later as a broken preview.

Security

• Your bucket, your keys. Kord holds an encrypted copy of the access keys you provide - AES-256-GCM at rest - and uses them only for the file operations above. Nothing about your AWS account is otherwise visible to Kord.
• TLS 1.2+ in transit, for every request Kord makes to your bucket, same as the rest of the platform.
• Least-privilege by design. The policy above is scoped to one bucket and the handful of actions Kord actually calls - no account-wide access, no actions beyond object read/write/delete and listing.

Requirements

An AWS account and a bucket you control, a Kord account on an Enterprise plan, and someone with permission to create an IAM user. Setup is one form and a probe - most teams are through it in a few minutes.

Questions, or want a hand with the IAM policy or CORS rule? Email support@withkord.com or book a demo below.