GameMaker to Steam and itch.io: The Correct Build, Upload, and Release Workflow

Build the game separately for every operating system, then package each build for the storefront that will deliver it. For Steam, GameMaker’s documented Windows workflow produces a ZIP that you upload through SteamPipe; Steamworks then serves that package through platform-specific depots. For itch.io, publish the portable GameMaker install folder to a platform channel, preferably with itch.io’s Butler command-line tool. Steam adds onboarding, a per-app fee, store and build review, and a deliberate release step. itch.io is more direct: create the project page, push a channel build, and publish updates to that channel.

The important distinction is between the build artifact GameMaker creates and the distribution service that delivers it. A reliable launch keeps those layers separate, maintains Windows, macOS, and Linux deliverables independently, and validates the exact files players will download.

What do you need before packaging a GameMaker game?

Decide which desktop platforms you will support before exporting anything. Treat Windows, macOS, and Linux as separate deliverables rather than assuming one archive can run everywhere. GameMaker’s Steam guidance uses platform-specific launch options and depots, and its SDK guidance notes that requirements differ by target and build type.

• A target-platform plan: list the operating systems you will ship at launch and which, if any, will receive later updates.
• A release build: use the intended configuration, assets, save-path behavior, input settings, and optional integrations rather than a development run.
• Store accounts: Steam requires a Steamworks account and onboarding; itch.io requires a project page and upload channels.
• Platform-specific integration decisions: Steamworks features may require GameMaker’s Steamworks extension and compatible SDK expectations. Keep a non-Steam build path when those features are optional or unavailable.

Make a clean output directory for each platform. Do not mix a Windows executable and DLLs with macOS or Linux files, and do not let an installer become the only copy of the files you need for storefront upload.

How should you export the Windows, macOS, and Linux builds?

Use GameMaker’s platform export for each target, then preserve the resulting files as the source artifacts for storefront packaging. The exact export controls vary with the target and build type, but the storefront rules below are the decisions that matter after compilation.

Windows

GameMaker’s current Windows compilation guidance, last updated October 22, 2026, uses the Create Executable flow. For Steam, that guidance calls for a ZIP package rather than an installer executable. Keep the complete generated runtime folder and compress the files in the form expected by the Steam upload process; do not substitute a setup program simply because it is convenient for direct distribution.

For itch.io, retain the generated install folder as a portable build. itch.io specifically recommends pushing the install folder instead of shipping an installer, and identifies folders generated by engines such as GameMaker as suitable Butler uploads.

macOS

Export a macOS build independently and publish it as its own storefront artifact or channel. Do not place it in the Windows ZIP or label a universal archive as if it were platform-neutral. Verify the macOS executable and its launch behavior on a representative Mac before release.

Linux

Maintain a Linux build separately from Windows and macOS. GameMaker’s manual distinguishes a ZIP package for Steam from an AppImage for non-Steam Linux distribution. Follow the format required by the destination: the Steam package belongs in the Steam upload workflow, while an AppImage can be the appropriate direct-download artifact outside Steam. Check executable permissions and the launch command before publishing.

How do you package a GameMaker game for Steam?

Steam packaging has four connected parts: Steamworks onboarding, platform-specific depots, a SteamPipe upload, and a release that passes Valve’s store and build gates. The ZIP produced for the Windows Steam workflow is only the file payload; Steamworks configuration tells the client which executable to launch and which files belong to each platform.

1. Register the Steamworks app and complete onboarding

Create the app in Steamworks and complete Valve’s digital paperwork. The onboarding process includes bank and tax information, identity verification, store-page preparation, build upload, and review.

Valve’s Steam Direct Fee documentation, accessed October 29, 2026, lists a $100 USD fee for each new Steam app. The fee is not refundable, but Valve says it can be recouped after that product reaches $1,000 in adjusted gross revenue from Steam Store or in-app purchases.

Valve’s current Steam Direct program also describes a waiting period after the fee is paid and requires a publicly visible Coming Soon page before release. Indexed versions of Valve’s documentation have shown different wording for the exact waiting period, so confirm the live timing displayed in your Steamworks account rather than relying on an old calendar estimate.

2. Create launch options and platform depots

Configure a launch option for every supported operating system. Associate each option with the correct compiled executable; a launch option that points to the wrong file can make a valid upload appear broken to players.

Create a depot for each platform and keep the files platform-specific. A Windows depot should contain the Windows package, a macOS depot the macOS build, and a Linux depot the Linux build. GameMaker’s Steam setup guidance describes depots as the containers for application files and directs developers to SteamPipe for uploading them.

3. Prepare the Steam package

For the documented Windows GameMaker workflow, create the executable and then provide Steam with the ZIP package, not an installer executable. Include the runtime files the generated game needs. If your game uses optional Steamworks functionality, build and package it with the matching GameMaker extension and SDK expectations; otherwise, preserve a non-Steam build that does not depend on those services.

Before uploading, inspect the archive as a player would receive it. Confirm that the launch executable is present at the path configured in Steamworks, that required data files are included, and that no development-only files or alternate platform binaries have been mixed into the depot.

4. Upload with SteamPipe and associate a build

Use SteamPipe to upload each depot’s files. After the upload finishes, create or select a build and associate the correct depots with it. The build association is what connects the uploaded content to the app’s platform launch options; uploading files without assigning them to a build does not make a release-ready package.

1. Open the Steamworks app and verify the depot definitions.
2. Upload the matching platform files through SteamPipe.
3. Create a build from the uploaded depot content.
4. Associate that build with the app’s launch configuration.
5. Check that each operating system points to its own executable and depot.

What Steam must approve before launch?

Steam separates the Store Presence checklist from the Game Build checklist. Submit the store page before submitting the build for review; both areas must be completed and approved before you can release.

• Store Presence: the public-facing page and its required information must be submitted for review.
• Game Build: the uploaded depots, launch options, and playable build must satisfy the build review process.
• Release control: approval does not publish the game automatically.

Valve’s Steamworks Release Process documentation states: Approved titles will not release themselves — you need to use these controls yourself at the moment you wish your product to be released. After approval, use Steamworks’ release controls when you are ready to make the app live. A Coming Soon page and the app’s release timing are separate from the technical act of uploading a build.

How do you package and upload a GameMaker game to itch.io?

itch.io’s practical path is shorter: export a portable folder for each platform, create a project page, and push each folder to its own channel. Butler is itch.io’s preferred upload method because it can validate builds, retry interrupted transfers, create manifests, and send only changed data on later uploads.

1. Keep the portable install folder

For Windows, use the complete GameMaker-generated install folder as the distributable artifact. Do not replace it with an installer when the goal is an itch.io download; itch.io recommends the folder itself. Preserve the executable and all runtime files generated with it.

For macOS and Linux, export and maintain separate folders. Give each channel the artifact for its own operating system, and verify executable permissions and platform-specific launch behavior before making the channel public.

2. Create a project and platform channels

Create the itch.io project page and define one channel per platform. Conventional names are windows, osx, and linux; the key requirement is consistency between the channel label and the artifact it contains. A channel should not alternate between operating systems from one release to the next.

3. Push the first build with Butler

itch.io’s Butler quick-start documentation calls Butler the best way to upload a game. A typical command has this shape:

butler push path/to/build user/game:windows

Replace path/to/build with the exported folder and replace user/game with your itch.io account and project identifier. The final channel name should match the platform channel you created. This example describes the command’s structure; it is not a command that has been run for a particular project.

Butler associates a version with the channel, validates the upload and manifest, and can retry a poor connection. On later pushes to the same channel, it uploads only changed data where possible, reducing update time and transfer size compared with sending an entirely unrelated archive each time.

4. Publish updates to the same channel

Push a new Windows build to the existing windows channel, a new macOS build to osx, and a new Linux build to linux. Reusing the channel lets the itch.io app and its patching system identify what changed. Keep a release’s files internally consistent; do not use a channel as a general-purpose storage bucket for multiple platforms.

Butler also documents an experimental steam-sync workflow that maps Steam depots to itch.io channels. Treat that as an optional experiment rather than the default publishing path: direct Butler pushes are easier to reason about when you are establishing your first release or when the two storefronts need different files.

What is the difference between publishing on Steam and itch.io?

Both services deliver GameMaker builds, but they impose different operational gates. Steam is a reviewed storefront with app-level onboarding and depots; itch.io is an upload-oriented project page where Butler channels can become available more directly.

Concern	Steam	itch.io
Entry requirements	Steamworks account, digital paperwork, bank and tax details, identity verification, a $100 USD fee per new app, store-page preparation, and review.	Create a project page and upload platform channels; the cited workflow does not describe a comparable app fee or review gate.
Windows packaging	GameMaker’s documented workflow calls for a ZIP package for Steam, not an installer executable.	Upload the portable GameMaker install folder rather than an installer.
Platform separation	Use separate launch options and depots for Windows, macOS, and Linux.	Use separate channels such as windows, osx, and linux.
Upload system	SteamPipe uploads depot files, which you then associate with a build.	Butler pushes folders, validates manifests, retries transfers, and can upload changed data only.
Release control	Store Presence and Game Build checklists must be approved, then you manually release the app.	Publishing is centered on making the project page and channel build available after upload.
Integration	Steamworks features may require GameMaker’s Steamworks extension and matching SDK expectations.	Keep the channel independent of Steam-specific services unless you intentionally maintain that integration.

The official material documents mechanics, not comparative sales, conversion rates, or audience outcomes. Choose based on the storefront features you need, the amount of release administration you can support, and whether your build depends on Steamworks services—not on an unsupported promise that either platform will sell more.

How should you validate the files players receive?

Validate the distributable artifact and the storefront channel, not just the game inside the GameMaker editor. The package a player downloads can differ from the folder you tested during development.

1. Start from a clean or representative system. Use an environment that does not contain your development tools, local asset paths, or stale save data.
2. Install or extract the exact artifact. For Steam, use the ZIP/depot content associated with the build. For itch.io, download the channel build or reproduce the Butler-published folder.
3. Launch through the storefront path. Check the Steam launch option or the itch.io channel download, not only a direct double-click from your project directory.
4. Check runtime completeness. Confirm that required data files, redistributable runtime components, and platform-specific permissions are present.
5. Exercise first-run behavior. Verify resolution selection, input detection, save creation, and the location where saves are written.
6. Check optional integration boundaries. If Steamworks features are enabled, confirm the Steam build’s behavior; also confirm that the non-Steam build starts and remains playable when those services are absent.
7. Repeat for every supported operating system. A passing Windows check says nothing about macOS signing behavior, Linux permissions, or a different launch executable.

The cited GameMaker, itch.io, and Steam documentation supports validating the intended distributable build, but it does not prescribe one universal test matrix. Define the matrix around your supported operating systems, input devices, save behavior, display modes, and integrations.

What commonly goes wrong, and how do you recover?

Uploading an installer to Steam

Symptom: the Steam upload completes, but the client cannot launch the game as configured. Fix: rebuild the Windows deliverable using GameMaker’s Create Executable flow and provide the ZIP package called for by the Steam guidance. Recheck that the launch option points to the compiled executable inside that package.

Mixing operating systems in one artifact

Symptom: one platform downloads files intended for another, or a launch option works on one system only. Fix: split the exports into platform-specific depots on Steam and channels on itch.io. Keep the archive or folder for each platform self-contained.

Uploading files without associating a Steam build

Symptom: SteamPipe shows uploaded depot content, but the app has no usable release build. Fix: create a build from the uploaded depots and associate it with the app’s launch configuration before submitting the Game Build checklist.

Replacing an itch.io channel with a different platform

Symptom: an update replaces a Windows download with macOS or Linux files. Fix: push each platform to its established channel and verify the channel name before confirming the upload.

Relying on a development folder

Symptom: the game runs locally but fails after a storefront download because a runtime file, save path, permission, or optional integration is missing. Fix: test the exact Steam package or Butler channel artifact on a clean or representative system and correct the export, not just the local project directory.

Which publishing path should you choose?

Use Steam when you need its storefront, Steamworks integration, depot-based platform delivery, and formal release controls, and you can complete the fee, paperwork, waiting period, review, and store preparation. Use itch.io when a direct project page and portable platform folders fit your launch, and you want Butler’s straightforward channel uploads and incremental updates.

• Choose Steam first: when Steam-specific features are central, your launch schedule allows onboarding and review, and you are prepared to maintain launch options and depots.
• Choose itch.io first: when you want to publish portable builds through platform channels with less storefront administration and no documented equivalent of Steam’s per-app fee in this workflow.
• Publish on both: when you can maintain two distribution paths. Keep the GameMaker exports separate, use the Steam ZIP/depot rules for Steam, and use portable folders and Butler channels for itch.io.

Whichever route you use, the durable workflow is the same: export per platform, package for the destination, upload through its native distribution tool, validate what a player receives, and release only after the platform’s own checks are complete.

Frequently Asked Questions

Can I publish a GameMaker game on Steam without Steamworks features?

Yes. Steamworks integration is needed for features that depend on Steam services, but a basic game can retain a non-Steam build path when those features are optional or unavailable. Keep any Steam-integrated and non-integrated exports clearly separated so the latter does not require Steam services to start.

Does Butler replace the itch.io project page?

No. Butler uploads and versions the files, while the itch.io project page is where the game, channel availability, and player-facing information are presented. Set up the page and channels first, then use Butler for repeatable uploads.

Should Steam and itch.io use identical update archives?

They should contain the same intended game version only when your release plan calls for that, but the packaging containers differ. Steam’s documented Windows path uses a ZIP associated with a depot, while itch.io receives the portable install folder through a channel, so keep separate release artifacts even when the game content matches.

What should I verify when a storefront build opens but saves do not persist?

Check the save location in the packaged build and test it under a normal player account rather than a development directory with special permissions. Repeat the check after downloading the Steam or itch.io artifact, because a local project run can use paths and permissions that the distributed build does not have.