Browser tests need files more often than teams expect. A signup flow may require a profile image. A document portal may need uploads, downloads, or replacement of a generated PDF. A workflow test may need a CSV, a zip file, or a fixture that is easy to reset between runs. Once those tests leave the local developer machine and enter CI, the question becomes less about the browser and more about file infrastructure.

AWS S3 is a common place to put those fixtures, because it is durable, scriptable, and already present in many teams’ AWS accounts. The problem is that a simple object bucket can become a small platform of its own if you are not deliberate. You need naming conventions, TTLs, access control, signed URLs, cleanup, and a clear story for how tests discover files. Without that discipline, the fixture pipeline becomes another maintenance surface that consumes more time than it saves.

This article walks through a practical AWS S3 fixture pipeline for browser tests, from bucket layout to CI access policies to cleanup rules. It also explains where the line is between sensible ownership and unnecessary plumbing, because not every team should build this forever.

What the pipeline actually needs to do

At a minimum, a fixture pipeline for browser tests should provide four things:

  1. Stable storage for uploaded file fixtures and downloadable test files.
  2. Predictable object names so tests can address the right file without brittle guesses.
  3. Controlled access from local runs and CI jobs without exposing the bucket publicly.
  4. Cleanup so stale artifacts do not accumulate and confuse future runs.

The test concern is simple, even if the implementation is not. A browser test needs to upload file A, verify the application response, maybe download file B, and then assert on the browser state or the downloaded content. The storage concern is broader. AWS S3 has a strong durability model, but it does not manage test intent for you. You still have to decide what is a fixture, what is a result artifact, what is temporary, and what should be deleted.

For context, Amazon S3 documentation covers buckets, object storage, presigned URLs, lifecycle policies, and access control. Those are the building blocks. The rest is engineering discipline.

A fixture bucket is not a place to dump random files. It is part of test infrastructure, which means it needs naming, ownership, and disposal rules just like test code does.

Start with the right bucket model

A common mistake is to create one bucket and let everything grow there. That usually mixes together at least three classes of data:

  • Static input fixtures, such as small PDFs, PNGs, CSVs, or ZIP files
  • Ephemeral test outputs, such as screenshots, traces, and downloaded artifacts
  • Ad hoc developer uploads used to debug a specific failure

Those should not share the same operational rules. A cleaner model is to separate them by purpose.

A simple layout that scales

One workable pattern is:

  • my-team-test-fixtures for versioned input files
  • my-team-test-artifacts for run outputs and diagnostics
  • my-team-test-temp for short-lived scratch objects, if you really need it

Inside the fixture bucket, keep the prefix structure boring and explicit:

  • uploads/profile-images/v1/avatar-small.png
  • uploads/docs/v2/sample-invoice.pdf
  • downloads/reports/v1/report-template.csv
  • browser/fixtures/forms/contact-form.json

A versioned prefix is important because test files tend to change over time. If a PDF template changes, you do not want to overwrite the old object in place and then spend an afternoon figuring out which branch or CI job consumed which version. Versioned object keys make it easier to keep old test expectations available while you migrate tests gradually.

Do not encode logic into object names. If the pipeline only works when the file name contains a timestamp, branch name, and test ID, you have probably made the fixture path more dynamic than it should be. Keep the object path readable, and carry runtime variability in metadata or signed URL query parameters, not in the key itself.

Object naming rules that prevent self-inflicted pain

Good naming reduces human confusion and automates cleanly. Bad naming creates ambiguity that no tool can rescue.

A practical object naming scheme has these properties:

  • Human readable, so a failed test tells you what file it used
  • Deterministic, so the same input gets the same key
  • Versioned, so changes are deliberate
  • Free of collision-prone ad hoc suffixes unless the object is intentionally ephemeral

For static fixtures, prefer names like:

text uploads/invoice-pdf/v1/invoice-sample-a.pdf uploads/invoice-pdf/v1/invoice-sample-b.pdf

For run-specific artifacts, use a stable prefix plus a run identifier:

text runs/2026-07-27/github-actions-18472/downloaded-report.csv runs/2026-07-27/github-actions-18472/browser-log.json

When tests need unique scratch files, generate them from the CI run ID or a UUID, not from timestamps alone. Timestamps can collide in parallel jobs and are hard to reason about when debugging.

If your browser tests need a file name that the application displays to the user, keep the display name separate from the object key. The object key is for infrastructure. The filename in the browser is part of the behavior under test.

Signed URLs are usually the right access model

For browser tests, presigned or signed URLs are often the least bad way to let a test fetch a file from S3 without making the bucket public. They are time-limited, they scope access to a single object, and they fit naturally into CI workflows.

AWS documents presigned URL support in the S3 API and SDKs. The exact implementation depends on your language, but the pattern is the same, generate a short-lived URL for the object the test needs, then let the browser or test runner use that URL.

This works well for downloadable test files. It also works for upload flows when the application under test needs a file available at a predictable URL before the browser interacts with it.

Example, generating a signed URL in Node.js

import { S3Client, GetObjectCommand } from '@aws-sdk/client-s3';
import { getSignedUrl } from '@aws-sdk/s3-request-presigner';

const s3 = new S3Client({ region: process.env.AWS_REGION });

const command = new GetObjectCommand({ Bucket: process.env.FIXTURE_BUCKET, Key: ‘downloads/reports/v1/report-template.csv’ });

const url = await getSignedUrl(s3, command, { expiresIn: 300 }); console.log(url);

A five-minute expiration is often enough for a test step, but the exact number should reflect your CI latency and browser startup time. If jobs regularly sit in queue before execution, do not make the signed URL expire before the test can even click the link.

Failure modes to expect

Signed URLs are not magic. The common failures are:

  • The URL expires before the browser uses it
  • The object key is wrong, often because of an environment mismatch
  • The IAM principal generating the URL does not have s3:GetObject
  • The application caches or rewrites the URL in a way that breaks the test assumption

Short expirations help security, but they also increase flakiness if the job setup is slow. That tradeoff needs to be evaluated in your environment rather than guessed.

A CI access model that is secure enough and not painful

CI access control should answer one question: which jobs are allowed to read or write which prefixes?

If every build can read and write everything, you have reduced security and made debugging harder. If every permission is hand-managed per job, the infrastructure becomes brittle. The middle path is usually a dedicated IAM role for test execution, with scoped permissions to specific buckets and prefixes.

A simple access policy might allow read access to fixture prefixes and write access only to run-output prefixes. It should not allow tests to overwrite source fixtures.

Example IAM policy shape

{ “Version”: “2012-10-17”, “Statement”: [ { “Sid”: “ReadFixtures”, “Effect”: “Allow”, “Action”: [“s3:GetObject”, “s3:ListBucket”], “Resource”: [ “arn:aws:s3:::my-team-test-fixtures”, “arn:aws:s3:::my-team-test-fixtures/uploads/” ] }, { “Sid”: “WriteArtifacts”, “Effect”: “Allow”, “Action”: [“s3:PutObject”, “s3:AbortMultipartUpload”], “Resource”: “arn:aws:s3:::my-team-test-artifacts/runs/” } ] }

In real setups, you may also need s3:DeleteObject for cleanup jobs and s3:GetObjectVersion if you use versioning. Keep the policy minimal, then expand only when a concrete need appears.

Best practice for CI authentication

Prefer short-lived credentials from your CI provider’s OIDC integration or an assumed role, rather than static access keys stored in secrets. The operational difference matters. Short-lived credentials are easier to rotate and reduce the blast radius if a token leaks into logs.

For browser test environments, a common pattern is:

  • CI job assumes an AWS role
  • Role can read static fixtures and write run artifacts
  • Test setup script generates signed URLs or downloads files locally
  • The browser test consumes local paths or ephemeral URLs

This keeps AWS access in the setup layer rather than scattered across the test codebase.

How browser tests should discover fixture files

The test should not know bucket internals unless the bucket structure is itself part of the contract being tested. Most browser tests should consume a fixture manifest, not hardcoded bucket keys.

A fixture manifest can be a small JSON file that maps logical names to object keys, content types, and optional expected hashes.

{ “profileImageSmall”: { “key”: “uploads/profile-images/v1/avatar-small.png”, “contentType”: “image/png” }, “invoicePdf”: { “key”: “uploads/invoice-pdf/v1/invoice-sample-a.pdf”, “contentType”: “application/pdf” } }

This buys you two things:

  • Tests refer to invoicePdf, not a bucket path
  • Renaming storage keys becomes a manifest update, not a test rewrite spree

If you maintain many file fixtures, put the manifest in source control and treat it like any other test contract. That is often better than letting test code infer paths dynamically.

Upload and download flows need separate thinking

Upload tests and download tests use the same bucket, but they fail in different ways.

Uploaded file fixtures

For upload flows, the file usually starts in S3, gets downloaded locally in the CI job, then is attached through the browser automation framework. This is often the easiest model because browser automation libraries can reliably attach a local file path.

Playwright, for example, supports file uploads through a file chooser or input element. A test setup step can download the S3 object to a temp directory, then attach it.

import fs from 'node:fs/promises';
import path from 'node:path';
import os from 'node:os';

const tmpDir = await fs.mkdtemp(path.join(os.tmpdir(), ‘fixture-‘)); const localFile = path.join(tmpDir, ‘invoice-sample-a.pdf’);

// Download from S3 here, then use localFile in the browser test.

await page.setInputFiles('input[type="file"]', localFile);

Downloadable test files

For download tests, do not just check that a click happened. Verify that the file content exists and that the browser actually received a valid artifact. In practice this means capturing the response, saving the downloaded file, and asserting on content or name.

A simple browser-side check in Playwright might look like this:

typescript

const downloadPromise = page.waitForEvent('download');
await page.getByRole('button', { name: 'Download report' }).click();
const download = await downloadPromise;
await download.saveAs('/tmp/report.csv');

The test can then compare the downloaded content to a known fixture or assert that the file includes expected rows or headers.

A test that only checks the presence of a download button does not prove the file pipeline works. It proves only that the button exists.

Cleanup policies, because stale files become silent bugs

Cleanup is not a nice-to-have. It is the thing that stops the fixture bucket from becoming a history museum of broken assumptions.

There are three cleanup layers to consider:

  1. Automatic expiration for temporary artifacts, usually via S3 lifecycle rules
  2. Explicit deletion in test teardown, for objects created during a run
  3. Periodic audit jobs, which identify unexpected growth or orphaned prefixes

S3 lifecycle rules are a good fit for run artifacts and temp files. For example, any object under runs/ can expire after a short retention window, while static fixtures under uploads/ stay in place. Keep the policies prefix based, because prefix based rules are easier to reason about than trying to infer intent from file names.

Lifecycle rules do not replace explicit cleanup when tests create mutable objects that can confuse later runs. If a test uploads a file into the application and the application stores it back into S3, your cleanup strategy may need to remove the generated object after the test finishes. Otherwise, future tests may read the wrong version and pass or fail for the wrong reason.

Observability matters more than people expect

When a browser test cannot fetch a file, the useful question is not “did S3 fail?” It is “which step failed, with which key, under which identity?”

Log these facts in CI:

  • Bucket and key, or manifest entry name
  • Role or identity used to access S3
  • Whether the object was read, uploaded, or deleted
  • The final local path of downloaded fixtures
  • The response code or AWS error, if a request fails

If a test uses presigned URLs, log the expiration window and generation time. If a test fails only after a long queue time, that detail may explain the entire failure.

For browser test artifacts in S3, store metadata that makes runs searchable later. Run ID, branch name, and test suite name are usually more helpful than a raw timestamp.

Common mistakes that create maintenance debt

A few patterns show up repeatedly in file infrastructure that looked simple at first.

1. Treating S3 as a universal scratchpad

If every team and every test writes to the same bucket prefix, collisions become inevitable. Keep fixture storage and run artifacts separated.

2. Overfitting the bucket layout to one framework

The fixture pipeline should serve browser tests, not only one Playwright suite or one Selenium helper. If the structure only works with a specific helper library, it will be harder to adopt across teams.

3. Ignoring versioning until a fixture changes

Versioning is easiest to add before the first breaking change. Put it in the layout early, even if you only use one version at the start.

4. Using public buckets for convenience

Public access removes friction in the short term and adds security and governance burden later. Signed URLs or scoped IAM access are a better baseline for most teams.

5. Letting cleanup depend on perfect test success

Teardown code often fails when the test already failed. Lifecycle policies and periodic cleanup jobs reduce the chance that a broken test leaves behind confusing state.

When to keep the pipeline, and when to stop owning it

Owning a custom AWS S3 fixture pipeline makes sense when your team already has AWS expertise, your file workflows are unique, and the test suite needs strict control over object placement, retention, or access. If your CI system and application logic both depend on S3 semantics, building the pipeline may be a natural extension of existing infrastructure.

The tradeoff is that every additional rule becomes something the team must remember. Bucket policy changes, IAM role assumptions, lifecycle exceptions, manifest updates, download failures, and cleanup regressions all become part of test maintenance. That can be reasonable, but it is not free.

Teams should reevaluate the build-versus-buy decision when the main cost is not storage, but the surrounding plumbing. If the work is mostly about keeping evidence organized, reducing flakiness, and making browser runs easier to review, a maintained platform can be less work than hand-rolling the entire flow. For example, Endtest, an agentic AI [Test automation](https://en.wikipedia.org/wiki/Test_automation) platform,’s self-healing tests are designed to reduce locator maintenance, and its editable, platform-native steps are easier to review than large generated codebases. That is not a replacement for every file workflow, but it can be a simpler path when the bigger problem is stable execution and evidence capture rather than custom S3 plumbing.

If your team is comparing options for browser-test infrastructure, it is worth also reading about test evidence capture workflows and how teams structure CI-friendly browser runs around artifact retention, upload flows, and reproducibility. Those operational details often matter more than the framework choice itself.

A practical decision checklist

Before you commit to an S3 fixture pipeline, answer these questions:

  • Do tests need a small, stable set of files, or a constantly changing corpus?
  • Will the same fixtures be used by multiple suites or services?
  • Do you need signed URLs, local downloads, or both?
  • Can cleanup be automated with lifecycle rules and teardown code?
  • Who owns IAM policy changes and bucket layout changes?
  • What happens when a file fixture changes shape or content?
  • Is the effort mainly about file storage, or about evidence and workflow management more broadly?

If the answers point to a stable, well-scoped file workflow, S3 is a sensible foundation. If the answers point to a growing need for evidence capture, retries, UI maintenance, and artifact review, then the file bucket may be only one small piece of a larger automation problem.

Closing thought

An AWS S3 fixture pipeline for browser tests can be reliable, but only if it is treated as infrastructure rather than a helper script. The successful version is boring in the right ways: clear prefixes, signed URLs, minimal IAM permissions, explicit cleanup, and a manifest that keeps test code away from storage trivia.

The difficult part is not getting files into S3. It is keeping the system understandable six months later, when a teammate wants to know why a download started failing or which fixture version a CI job used. If your design answers that question quickly, you are on the right track. If it cannot, the pipeline has already become the maintenance project you were trying to avoid.