itch.io Playtest: How to Run a Closed Beta on itch.io

An itch.io playtest is the quickest way most indie developers can get a build in front of real players: a free page, a browser or download build, and full control over who gets in. This guide walks through the whole setup, from picking the right visibility mode to handing out download keys, pushing new builds with butler, and collecting feedback that you can act on. Everything below comes from itch.io's own creator docs, read in October 2026, so the menu names match what you will see on your dashboard.

Pick the playtest you are running first

Before you touch the dashboard, decide which of three playtests this is, because each one maps to a different itch.io setting.

• Closed playtest. A handful of people you invited. You want honest notes on a rough build, and you don't want strangers or search engines finding it. Use a Restricted page.
• Semi-open playtest. Anyone with the link can play, but you don't want it showing up in itch.io browse or Google yet. Use Public with "Unlisted in search & browse".
• Open playtest or public demo. You want discovery: tags, browse pages, comments from strangers. Use plain Public.

Most developers should start closed. Our guide on how many playtesters you need explains why five or six people on one build usually find the biggest problems, and a small closed round is far easier to run than a public one.

Step 1: Create the project page

1. Go to itch.io/game/new while signed in. butler and every other upload route need this page to exist first.
2. Give it a working title. You can rename it later, but the URL slug is what butler uses, so pick something you are happy to keep.
3. Under Kind of project, choose Downloadable for Windows, Mac, Linux or Android builds, or HTML if the game runs in the browser.
4. Set the pricing to free or "No payments" for a playtest. If you later switch to paid, anyone who already holds a download key keeps access.
5. Leave visibility on Draft while you upload. Draft pages are only visible to the project owners.

Should the playtest be a browser build?

If your engine can export to the web, seriously consider it. Testers who don't know you are often wary of running an unknown executable, and a web build removes that worry and the install step together. itch.io's HTML5 docs ask for a ZIP with an index.html at its root, no more than 1,000 files, 500MB extracted and 200MB for any single file. The most common failures are absolute paths (paths starting with /), file name case that works on Windows but breaks on itch.io's case-sensitive server, and non-HTTPS calls to outside APIs. If your game works on phones, tick Mobile friendly in the embed options so mobile testers aren't warned off.

Step 2: Lock it down with a Restricted page

When the build is uploaded, scroll to Visibility & access at the bottom of the edit page and choose Restricted. According to itch.io's access-control docs:

• Only people you have approved can see the page, download files, or use the community area.
• Restricted pages don't appear in itch.io browse, search or on your profile, and external search engines don't index them.
• You can tick Also allow a password to view page. You can put the password in the URL itself, so testers just click one link and never type anything.
• People who already have access through a download key skip the password.

That gives you two ways to run a closed round:

• Password link only. Fast. Good for a Discord group or a small peer swap. The downside is that anyone who gets the link gets in, and you can't remove a single person.
• Download keys. One key per tester. Slower to hand out, but you can see who downloaded and revoke anyone. Best for anything you would mind leaking.

A developer on r/SoloDevelopment described a setup that works well for early builds: a shortened web build on itch.io, Restricted with a password to keep bots out, shared with Discord groups they were already part of, followed by one-on-one sessions over screen share and a short exit interview. That combination is hard to beat for a first round.

Step 3: Generate and send download keys

Download keys live on the Distribute tab of your project's edit page, under Download keys. itch.io gives you two options:

• Single keys. Recommended for individual testers, press or friends. You can add a label (use the tester's name or handle), track how many times it has been used to download, and revoke it.
• Bulk keys. For a larger batch, such as a list you are handing to a community. Bulk keys can also unlock specific priced files or external keys.

A few practical rules:

1. Label every single key. When a key leaks or a tester goes quiet, you want to know whose it was.
2. Send keys privately. itch.io's docs note a key URL is unique and shouldn't be shared. Once a key is linked to an account, only that account can use it.
3. Ask testers to claim the key while signed in. That attaches the game to their library, so updates are easy for them to find.
4. Revoke keys when the round ends, or when you move to the next closed group, so old testers don't wander into a build meant for fresh eyes.

If you are also on Steam, keep in mind that itch.io keys and Steam keys are separate. The Steam route is covered in our guide on how to set up a Steam Playtest, and Steam Playtest vs demo helps if you are deciding which store should host your test.

Step 4: Ship updates with butler

Uploading ZIPs through the browser is fine once. For a playtest where you fix things between sessions, use butler, itch.io's command-line uploader. It only sends what changed, so the second push of a big build is usually much faster than the first.

1. Download butler from itchio.itch.io/butler. If you would rather not use a terminal, itch.io says the itch app (version 26.12.0 or later) can push builds with butler from a Builds page.
2. Run butler login once. It opens a browser window to authorize your account.
3. Push your build folder to a channel: butler push "C:/mygame/build" yourname/yourgame:windows-playtest
4. Push to the same channel again to update that file on the page. Testers with the itch app can update in place.

Things that trip people up:

• yourname is your itch.io subdomain and yourgame is the URL slug, both lowercase. A mismatch gives an "invalid target" error.
• Channel names set the platform tag: anything containing win or windows is tagged Windows, linux is Linux, mac or osx is Mac, and android is Android.
• Push a folder rather than a ZIP. butler handles compression itself.
• For CI, set BUTLER_API_KEY as a secret environment variable. If the key ever shows up in a public log, revoke it.
• Builds over 30GB uncompressed are rejected.

Whatever route you use, put the build number on the title screen or pause menu. When a tester sends a bug, you need to know which push they were on.

Step 5: Give testers one place to leave feedback

itch.io gives each project a community area you can switch on from the edit page: either Comments (threaded and votable) or a Discussion board (a small forum with topics and moderators). You only get one at a time. On a Restricted page, the community is only open to people with access, so it is a private space for your testers.

For a closed playtest, a discussion board with three pinned topics works well:

• Bugs. Ask for build number, what they were doing, and what happened.
• Where I got stuck. The single most useful thread you will have.
• First impressions. What they thought the game was in the first five minutes.

Comments and boards are good for bugs. They are weak for the questions that matter most, because people write what they remember rather than what happened. Pair the page with a short form. Our game feedback form template is a ready-made starting point, and the playtest survey questions guide has more prompts to swap in. Put the form link in three places: the top of the page description, the game's pause menu, and the message you send with the key.

Step 6: Write a page that sets up the test

A playtest page is not a store page. Testers need instructions, not a pitch. Put this at the top of the description:

Playtest build 0.4 (Windows, web). Thanks for testing. Please play for at least 20 minutes, ideally in one sitting. Don't read anything else about the game first. When you are done, fill in the 6-question form here: [link]. Found a bug? Post it in the Bugs topic with the build number from the pause menu. This round closes on Sunday.

Then add, briefly:

1. What platforms and inputs the build supports.
2. Any warning they might see (for example Windows SmartScreen on an unsigned build), and that they should never need to turn antivirus off.
3. The one or two things you want them to pay attention to, framed as moments rather than opinions. "Tell us the first time you weren't sure what to do" beats "was the tutorial good?"
4. A known-issues list, so you don't get thirty reports of the same placeholder art.

Step 7: Find people to play it

This is where itch.io stops helping. A Restricted page is invisible by design, and even a public page with no audience tends to sit quietly. One developer on r/SoloDevelopment put it bluntly: itch.io is a fine place to put a build but not a place that brings people. You have to bring them.

Options that work for itch.io builds:

• Peer exchange jams. The Playtest & Feedback Exchange Jam on itch.io, run by Indie Playtest Fest, is a monthly developer-to-developer event, not a competition. You submit a build at any stage and in return give feedback on at least three other entries. The current edition is open for submissions until November 1, 2026. Other developers are patient with rough builds and give sharper notes than the public.
• Communities you already belong to. Engine Discords, genre servers, local dev meetups. Read each server's rules on sharing builds first.
• Subreddits with playtest rules. r/playtesters and r/playmygame both exist for this, with strict rules on how often and what you post. Read the live rules before every post.
• Get Playtests. You can post your itch.io build on Get Playtests for free, no credit card. You write the exact questions you want answered and set a minimum play time, and players who choose your game claim it and deliver a written, video or livestream review by a deadline. You approve or reject every review before it counts. Restricted pages work well here: put the password link in your posting so players land straight on the build with no extra steps. Post your itch.io playtest when the page is ready.

For a full breakdown of where testers come from, see how to find playtesters.

Step 8: Run the round and close it cleanly

1. Set a window. Five to seven days is enough for most closed rounds. Put the end date on the page.
2. Watch a few people live. Written notes tell you what players remember. Watching tells you what happened. Our remote playtesting guide covers screen share and recording with consent.
3. Don't push mid-session. If someone is halfway through a run, a new build can wipe saves or change what they are reporting on. Batch fixes and push between sessions, and say so on the page.
4. Tag every note with the build number and group them by moment, not by tester.
5. Close the round. Revoke keys or change the password, post a thank-you in the community area, and tell testers one thing you changed because of them. That last step is what makes people say yes to your next round.

Common itch.io playtest mistakes

• Leaving the page on Public by accident. Check visibility before you share anything. A Public page can be indexed by search engines.
• One shared key for everyone. You lose the ability to revoke a single person and you can't tell who played.
• No instructions. Testers who don't know what you want will tell you whether they liked the art.
• Asking for feedback in the comments only. Comments favour the loudest testers. Use a form as well.
• A build that doesn't start. Install from the exact link testers will get, on a machine that has never run your game, before you send a single key.
• Testing too many things at once. Pick one question per round, such as "do players understand the core loop in ten minutes?", and judge the round on that.

Quick checklist

• Project created, kind of project set, build uploaded
• Web build considered, ZIP under itch.io's limits, mobile friendly ticked if it works on phones
• Visibility set to Restricted (or Unlisted for a semi-open round)
• Password in the URL or labelled single keys generated
• butler set up with a named playtest channel
• Build number visible in game
• Discussion board or comments on, with pinned Bugs and Stuck topics
• Feedback form linked on the page, in the game and in the invite
• Testers lined up, round dates on the page
• Keys revoked and thank-you posted when it ends

Once your itch.io page is set up, the hard part is getting the right people through the door. Post the build on Get Playtests with your questions and minimum play time, and the players who pick it will tell you what actually happened in your game.