Skippr Docs

Appearance

What Network Access Skippr Needs for S3 ​

June 2026

S3 source access means the runner can list the bucket, read objects under the chosen prefix, and do it with the same AWS identity the job will actually use.

Short Answer ​

Skippr needs S3 access to the bucket and prefix you configured, with an AWS identity allowed to s3:ListBucket and s3:GetObject. The source docs make that boundary concrete through s3_bucket, optional s3_prefix, and an IAM policy example that covers the bucket ARN plus the object ARN pattern, so the real access question is whether the runner can enumerate and read the files under that exact prefix.

That is why S3 source readiness is more specific than we have AWS credentials. If the source points at bucket my-data-bucket and prefix raw/, the runner has to list my-data-bucket, see keys under raw/, and read the files that match the extract. A policy that allows object reads but not bucket listing, or a prefix pointed at the wrong folder, still leaves the source unusable even though the bucket name is correct.

Why Teams Struggle with This ​

Object-store sources often fail quietly because the problem is one level deeper than authentication. The bucket exists, the credentials exist, and the real miss is that the prefix is wrong or the policy is incomplete for how Skippr discovers files.

  • The IAM user or role needs both s3:ListBucket and s3:GetObject for the configured bucket and objects.
  • The s3_prefix must match where the intended files actually land, not where someone assumes they land.
  • Region settings still matter when the runner environment cannot infer the bucket location cleanly.
  • A local shell with one AWS profile does not prove a deployed runner has the same bucket access.

How Skippr Handles It ​

Skippr makes the S3 boundary explicit by centering the source on one bucket and one optional prefix. That keeps the request to platform teams simple: this runner needs to list this bucket and read these objects. There is very little ambiguity compared with a broad ask for object-store access.

It also helps the first validation stay practical. When the bucket and prefix are right, Skippr can detect supported file formats such as JSON, CSV, Parquet, or Avro from the objects it actually sees. If no files appear, you know the problem is almost always the prefix, the IAM policy, or the runtime identity.

  • Uses s3_bucket and optional s3_prefix as the source boundary.
  • Relies on standard AWS credentials or attached roles instead of a custom auth scheme.
  • Needs the documented ListBucket and GetObject IAM actions to work cleanly.
  • Auto-detects common file formats once the bucket path is actually readable.

What the First Useful Version Looks Like ​

The first useful version is one bucket, one narrow prefix, and a handful of known files that prove the runner can list and read the same path every time.

If the runner still cannot see the files under that prefix, do not widen the scope. Fix the bucket policy or the path before you make the source more complex.