A build artifact's format belongs in its consumer contract
Non-zipped GitHub Actions artifacts change what consumers receive. Check single-file limits, action versions, filenames and permission requirements.
By 
Paul. Architecture and infrastructure
A build artifact's packaging is part of the interface its consumer uses. Removing a ZIP wrapper can make a single report or image easier to receive, but it also changes assumptions about filenames, extraction and supported download tools. Treat that change as an agreement between producer and consumer. The person opening the result should not need to discover the agreement by accident.
In the week beginning 25 February 2026, GitHub's 26 February announcement introduced non-zipped artifact support. The useful lesson is broader than convenience: packaging choices belong in the description of the output, alongside its content. This retrospective concerns that change, without claiming that any upload or download job was run for the article.
A wrapper can become part of the interface
Consider a hypothetical workflow that produces one PDF. Its consumer wants the PDF, while the old artifact path supplies a ZIP containing it. A person needs an extraction step; another program may have built that extraction into its own process. Removing the wrapper can help the person and break the program if the producer changes the output without notice. Both reactions follow from the same interface change.
An archive can also be intentional. A producer might already create a compressed package with the structure or metadata its consumer needs. Wrapping that package in another ZIP adds a second layer without changing the inner contract. GitHub's announcement specifically presented avoiding this double packaging as a use case. That supports removing an unnecessary outer layer, rather than treating every archive as unnecessary.
The relevant question is what the recipient expects to receive. A single file, a directory tree and an explicitly prepared archive represent different outputs. They should not be grouped together merely because each can be called an artifact. Naming the actual object makes compatibility decisions easier to review before a workflow changes.
The option has narrow conditions
The announcement tied the behavior to actions/upload-artifact v7 with archive set to false. It retained the default of true for compatibility and required actions/download-artifact v8 when that action is used. Older uploads and previously uploaded artifacts remain zipped. Those conditions come from the dated changelog, rather than a claim that all historical artifacts have changed in place.
The v7.0.0 release contract is more specific about the unarchived mode: archive: false accepts a single file, and the configured artifact name is ignored. The file's name therefore deserves attention in the consumer agreement. An integration should not assume that the old artifact label continues to rename the downloaded object. The single-file restriction also rules out treating this option as a direct replacement for a directory bundle.
The upload and download sides need to be considered together. Updating the producer while leaving an incompatible consumer unchanged is an incomplete migration. Likewise, a browser download and a download action are different consumer paths. State which path the agreement covers and preserve an appropriate route for consumers that still require the previous packaging.
A filename can carry meaning
A filename may determine which application opens a result or how a downstream script selects it. If the configured artifact name is ignored in the new mode, the producer should deliberately choose the output file's own name. A name such as a generic “output” may be adequate inside an archive whose label supplies context, yet confusing when received alone.
This does not imply that names establish identity or authenticity. A convincing filename can still point to the wrong build. The consuming process should know which workflow result it is handling and what checks are required for its use. Packaging helps communicate the object; it does not prove that the object is trusted. Those are separate parts of a release or reporting process.
Historical artifacts need particular care during migration. If older results remain zipped while newer results can be direct files, a consumer of both eras cannot assume one uniform format from the workflow's current configuration. A migration note should explain the boundary. The fact that a producer has changed today does not rewrite what a recipient downloaded yesterday.
Keep explicit archives where they serve the result
The strongest counterargument to direct files is that many useful outputs are not single files. A report with separate assets or a package containing several related files still needs a suitable container. The single-file option does not make those relationships disappear. Preparing an explicit archive can preserve the grouping the consumer needs while avoiding an additional automatic wrapper.
Unix permission requirements are another reason to retain an intentional archive format. The transport choice should not be treated as a promise that executable bits or other metadata survive exactly as the consumer expects. If those properties matter, define how the prepared package preserves them and how the recipient should interpret it. The February announcement itself mentions uploading compressed files to maintain permissions; it does not grant a universal permission guarantee to direct uploads.
Access permission is a different issue again. Receiving an unzipped artifact does not mean every person is authorized to obtain it or use its contents. Repository and artifact access rules remain relevant. Reducing extraction steps should not be described as widening access. A packaging migration should preserve the application's intended audience unless a separate, authorized decision changes it.
For a custom software project, write down the result the recipient gets: one named file or an explicit package, the compatible download path and any required metadata. That description can be small, but it should be precise. GitHub's February change offers a simpler path for the right output. Its value depends on matching that path to the consumer who actually uses the file.