How to Publish and Monetize Your Indie Game on Steam

Publishing a game on Steam is a checklist with two halves: a store page people can see, and a build Steam can install. Money after release, including how wishlists behave and how discounts are scheduled, is a later job. This article stops at a reviewed store presence and a build you can release on purpose. It does not quote Steam’s revenue share. Fee terms live in the Steamworks agreement and related docs, and you should read the current pages rather than a blog.

Valve’s process changes. The pages used here are the Steamworks Release Process, Uploading to Steam, Depots, Builds, and Store Page docs. Open those for your app before you click through a wizard, and prefer them over any menu name in this article.

What you are setting up

You need a Steamworks partner account and an app for the game. The app landing page is home base. Steamworks shows two checklists there, one for store presence and one for the game build. The Release Process page says both must be completed, reviewed, and approved before release, and that you submit the store page for review before you can submit the build.

Releasing also depends on permissions. The same page says publishing a coming soon page or releasing a game requires permission to publish app changes to Steam and permission to manage pricing and discounts. If a button errors, check who on the partner account has those permissions before you rebuild the game.

Set a price when the checklist asks for one. Choosing the number is your decision. This article does not suggest a price, and it does not estimate how many copies you will sell. A launch discount, if you want one, is configured near the release date on the app landing page, not in the general discount dashboard. Read the current Discounting documentation before you enter one. The rules for length and cooldown are specific, and they are easy to get wrong if you are copying an old post.

The store page

From the app landing page, Edit Store Page is where the description, trailer, screenshots, and written details live. Steamworks marks the required items. Fill those before you invent extra sections. The written description should match the build you will upload. If the page promises a mode the game does not have, the build review is the wrong time to discover that.

Graphical assets have their own size list in the Steamworks Graphical Assets documentation. Do not take capsule pixel sizes from memory or from this article. Export what that page currently requires: the capsules and library images it lists, plus screenshots that show the game as it is. A trailer is part of the same store presence. Keep it short enough that a stranger can tell what they do in the game.

Tags, system requirements, and the content survey are part of the same pass. Requirements should match what you have actually run, not an aspirational spec. If you support one operating system, say so.

Publishing the store page pushes its assets to Steam’s public servers. The Store Page documentation warns that this can happen even when the app is still unreleased or hidden, and that third parties may scrape what you publish. Use the store beta preview when you only want to check layout yourself. Do not publish a page for an unannounced project and assume it stays private.

When the store checklist is done, you mark it ready for review. The Release Process page says store-presence review typically takes 3 to 5 business days, and it tells you to submit at least 7 days before you want the page live so there is room for changes. Those are Valve’s figures, not a guarantee. If review sends notes, fix the notes and resubmit. Do not argue from a blog post.

A coming soon page is the usual public step before launch. The Release Process page says that once the store page is approved and its presence has been set to coming soon for at least two weeks, and the build is reviewed, you can release. Plan the calendar from that rule. Wishlists can accumulate during coming soon. What those wishlists will do on launch day is not something this checklist can tell you. Look at your own Steamworks reports later.

Depots, launch options, and the build

A depot is a group of files Steam delivers together. Each depot has an ID. The Depots page in App Admin is where you name them and set filters such as operating system, architecture, language, or DLC. If you ship one Windows build and nothing else, you do not need a clever depot split. Rename the default depot to something you will recognize, leave language and OS broad unless you truly have separate files, and save.

Steamworks notes that a new depot has to be included in a package before your accounts own it. Games get a Developer Comp package for the partner. Add the depot there, or to another package that should include it, from the associated packages page. If you upload and then cannot install the result on a test account, the package assignment is an early thing to check.

A launch option tells Steam what to run after the depot is mounted. On General Installation Settings you set the executable path and any arguments. Do this before you declare the build done. A depot full of the right files still fails if the launch option points at a binary you did not ship.

A build is a snapshot of one or more depots at upload time. You create it with SteamPipe, using the content builder scripts that ship in the Steamworks SDK, not by dragging a zip into the store page. The Uploading to Steam documentation walks through the script layout: an app build script that lists depots, and a depot script that points at a content root on disk. Follow that current example. Script field names are exactly the sort of thing that is not worth guessing.

Build from a clean output of your engine, the same way a player would get files, not from your project folder with source art and editor configs mixed in. Install that output locally once before you upload it. If it does not boot on your machine, Steam will not fix it.

Upload, then open Your Builds in App Admin. Set the build live on a branch. For an unreleased game, the Builds documentation says setting a build live should not affect customers, because only partner accounts, and anyone who redeemed a key, own it. For a released game, setting the default branch live ships an update to owners. Treat that button as a release even when you are “just testing” after launch.

Install from Steam with a partner account, using the Steam client, not only from your local folder. Check the launch option, a save path you can write to, and one full session. If you have a second operating system depot, install that too, on that operating system.

When the build checklist is complete, mark the build ready for review. The store page still has to go first. You can keep uploading newer builds during review. The page you submitted should still describe the game honestly.

Releasing, and what this article leaves alone

Approved games do not go live by themselves. The Release Process page describes a Release App control on the app landing page. You use it when you mean to launch. It shows a summary, including publishing the store package and setting a launch discount live if you staged one, and then you confirm. Press it when you are awake and able to patch, not as the last step of a night you cannot stay up for.

After that button, patches still go through a tested depot upload on the branch you mean to ship. Discount calendars and sales reports are a different pass. Read the current Steamworks pages for those, including the fee terms. Do not copy a revenue split from a blog.

If a label in Steamworks does not match this piece, the in-product checklist and the official doc win. Publishing is finished when a stranger with a partner key can install the build from Steam, the store page matches that build, and both reviews are approved. Everything after that is running the game you already shipped.