When a Supabase S3 log drain works but still says it failed

Have you configured a Supabase log drain to AWS S3, watched the log files show up in the bucket, and still gotten this error?

internal server error

Let’s fix that!

The Supabase docs say the AWS credentials need write permission on the bucket. I started with a dedicated IAM user, no console access, and the narrowest interpretation of “write permission”:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::YOUR_BUCKET_NAME/*",
      "Condition": {
        "Bool": { "aws:SecureTransport": "true" }
      }
    }
  ]
}

The funny part was that this basically worked. Parquet log files appeared in S3, and so did _connection_test.parquet. The credentials, region, bucket, and upload permission were all fine. The Supabase connection test was just doing something else after the upload and failing with no useful detail.

Allowing deletion of only the test file still did not clear the error. What finally worked was letting Supabase inspect the target bucket, upload log objects, and manage only its own connection-test object:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "InspectTargetBucket",
      "Effect": "Allow",
      "Action": ["s3:GetBucketLocation", "s3:ListBucket"],
      "Resource": "arn:aws:s3:::YOUR_BUCKET_NAME",
      "Condition": {
        "Bool": { "aws:SecureTransport": "true" }
      }
    },
    {
      "Sid": "WriteLogObjects",
      "Effect": "Allow",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::YOUR_BUCKET_NAME/*",
      "Condition": {
        "Bool": { "aws:SecureTransport": "true" }
      }
    },
    {
      "Sid": "ManageConnectionTestObject",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:GetObjectAttributes",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::YOUR_BUCKET_NAME/_connection_test.parquet",
      "Condition": {
        "Bool": { "aws:SecureTransport": "true" }
      }
    }
  ]
}

After that, the test passed without giving the IAM user full s3:* access. It still could not read or delete the actual log files, or change the bucket’s configuration. Nice and boring, which is exactly how IAM should be.

I would treat this as a practical compatibility policy, not an official list of Supabase’s minimum permissions. But if your logs are landing successfully while the UI insists the connection failed, the connection-test permissions are a very good place to look.