Your playtesters shouldn’t need a terminal.
BoardFlight is how a game gets from you to somebody else’s Board: a private playtest for the four people you trust, or the public library anybody can browse. You publish a build and say who gets it, and they install it themselves with no cable, command line or call.
Always free: no card, seats or per-build fees. The Unity plugin downloads without an account.
Why free? We love the Board and want it to do well. The more people who can get a build in front of a player, the more there is to play on it.
Here to play something? The library is this way. Holding a code? Redeem it.
Unity is one way in. A browser tab is the easy one.
If Unity is where you already are, stay there. But a Board game does not have to start with installing an engine. Open a playground and you are in a workspace in a browser tab: Board’s starter project already running in the preview, and an AI beside it that writes the game as you describe it. When it plays the way you meant, Publish makes it a build you can install on your Board.
Open one
Press New game, then Create and start building. A machine boots, Board’s own starter project is restored into it, and the preview starts running it. It takes a few seconds, and nothing is installed on your side. You choose PixiJS or Canvas at this step, and that choice is final.
Say what you want
In a sentence, the way you would put it to a person. The assistant edits the project and the preview reloads as it goes. It has a browser of its own, opens your game at the Board’s screen size (1920×1080, touch) and looks at it before it tells you it is done.
Touch it up by hand
On a PixiJS game, click anything in the preview and drag it where it belongs; Save writes the position into the project, where the assistant reads it too.
Publish
One button. It builds, packs and uploads through the same path a Unity build takes, counts the version for you, and writes the release note from what you asked for. A copy of the game that is already running shows a card within a minute: a new build is ready.
Your own ChatGPT account
The assistant signs in with your own ChatGPT account through a device-code flow. Those credentials move between your browser and your container and are never held by a BoardFlight server. There is no key to buy from us and no usage of ours to run out of.
A version before every turn
The project is saved before each AI turn and on every publish, and the History dialog puts one back.
It writes the library page too
Ask, and it fills in the tagline, description and genres and takes the screenshots itself, tapping its way to the level worth showing first. Putting the game in the library stays a button only you can press.
The playground runs in a container: your files are saved to BoardFlight seconds after every change and come back with the next session, and assets go in a library beside the project that the build reads too. Already in Unity? Nothing here asks you to leave: the plugin publishes to the same games, channels and testers, and everything below this point works the same for a build from either.
The part that isn’t making the game
A build you want somebody else to play is a build you hand over yourself, to a person who bought a games console and not a development kit. That is true of the stranger who might install your finished game, and four times a week of the friend testing the unfinished one.
Today
- Export the APK. Upload it to Drive. Paste the link into Discord.
- Explain which of the files in that folder is the new one.
- Wait.
- “It didn’t work.” No version, and no way to tell which build they had.
- Ask them to photograph the screen.
- Ship the fix. Do all of it again.
With BoardFlight
- Press Build & Upload in Unity, or run one command in CI.
- Your tester presses Install on the game’s page and always gets the newest build.
- BoardFlight on their computer puts it on their Board. No cable or command line.
- With the feedback button on, what they report from inside the game arrives with its build, and with a screenshot if they include one.
- Run the hardware check, and a build Board refuses is caught in Board’s own words before a tester has it.
Three steps, and your tester does the third
Publish from where you already are
In Unity: Window ▸ BoardFlight ▸ Publish, write release notes, press Build & Upload. In a terminal or in CI: one boardflight upload. Channels such as internal and beta decide who gets which build, so an experiment never lands on the people who wanted something stable.
Say who gets it
An email address, for somebody who already has an account. A redeem code, with a link you paste straight into a chat, for somebody who doesn’t. The link shows them the game before it asks them for anything. Limit a code by uses or by date, and revoke either at any time: revoking takes the game back off everyone who redeemed it.
They install it themselves
Your tester opens the game’s page on boardflight.app and presses Install. With BoardFlight on their computer and their Board paired, that puts your newest build on their Board in one press. The next build arrives by itself, unless they have switched automatic updates off, and is an Update then.
And then to everybody else
Publish the game to the library and it goes on the shelves at boardflight.app, where anybody can browse it without an account and install it with one. It is the same game and the same build you already uploaded, and one switch puts it there or takes it back off.
Five things make a library page
A tagline, a description, at least one genre, an icon and at least one screenshot. The dashboard shows you what is still missing before the button is live, and the server checks the same list again when you press it. Genres are what put you on a shelf: declare up to three and you are on three.
How the shelves fill
Popular, New, and one per genre. Popular is counted from plays, and nobody chooses it. There are no ratings, reviews or hand-picked rows to get into, and no ranking to negotiate with.
Reversible, and quiet about your numbers
Unpublish and the game leaves the catalogue immediately: nothing is deleted, and the copies already on people’s Boards are left alone. What a stranger sees of your figures is rounded (“120+ plays”), and the exact number stays in your own dashboard.
Once any hardware runner has taken work on this instance, a build has to have installed on a Board before it can appear on public at all. For a tester you invited, that check is your choice; for a stranger it is not.
“It didn’t work” is not a bug report
When a Board refuses a build, it says why, in its own words. The hardware check (next on this page) brings that string back from a Board to your build timeline word for word, with nothing summarised, translated or guessed at. You read it before any tester has the build.
[install_failed] INSTALL_FAILED_VERSION_DOWNGRADE: Downgrade detected: Update version code 899 is older than current 900
A real rejection from a Board running OS 2.3.0. It is precise enough to act on without anybody interpreting it for you.
Find out before your testers do
Only a Board can tell you whether a build installs. Run the checker on any machine with a Board on the network and every new build gets tried on real hardware: downloaded, hashed, installed, launched, watched. A tester’s failed install does reach you in the channel’s Activity, but only after it has already failed for them. This is how you find out first.
boardflight runner --name "bench b5438"
What a pass means
It downloaded, the SHA-256 matched, Board accepted the install, and it was still alive eight seconds later. It does not mean the game is good, or even that it renders. Instead of thinking a build installs, you know it installed on a B5438 running 2.3.0.
Turn on Hide a build from testers until it passes and a build that never installed can no longer displace one that works.
A bug report from inside the game
Switch the feedback layer on for a channel and every build published there carries one floating button. The player presses it, picks bug or feature request, types a sentence and, if they want, includes a screenshot of what they were looking at a second ago. It arrives in the game’s Feedback tab, where you tag it a colour that means whatever your team needs it to mean.
Per channel, and off unless you say so
The colour, opacity, size and corner of the button are yours to set per channel, with a live preview, so the button your playtesters see need not exist on any other channel. An APK and a .webapp.zip both get the layer.
What turning it on does
BoardFlight unpacks the build, adds the layer, re-signs it if it is an APK, and re-checks the package id with the same parser it uses on a stranger’s upload. A patched build that fails that check does not publish. Your own code, resources and DEX are never read or rewritten, and your original bytes are kept: turning the layer off republishes them.
The signing key changes
A re-signed APK has a different signing key from the one you shipped before, so the first patched build costs your testers one uninstall. Upload your own keystore and it costs nothing: every patched build is signed with it, and the password is stored wrapped, never logged and never returned.
Whether anybody played it
Analytics, per channel, and off by default except for plays on a web game’s public channel. They count what the system can see and leave out what it would have to guess.
Installs, where BoardFlight did them
An install that BoardFlight on a tester’s computer does is recorded, with the Board’s own message when a Board refuses one.
Sessions, and how long they lasted
How many plays, at what time of day, and for how long (total and median), per channel, per build and per tester, so a team running a playtest can see who has actually played. This is the in-game layer, a separate switch from the feedback button. It is on for a web game’s public channel, because the library’s Popular shelf is counted from plays, and off everywhere else until somebody switches it on.
Nowhere else
No third-party analytics service is involved, sessions need no SDK in your game, and there is no crash reporting. The figures live in BoardFlight’s own database and are read by your team. Verified end to end on a Board running OS 2.4.1.
What BoardFlight never does
You are about to upload an unreleased game to somebody else’s server. These are the five things that server will not do with it.
It reads one thing out of your build.
The package id, from an APK’s manifest or a web bundle’s harness-config.json, and only to prove the build installs as a package id your team is authorised for. It is the only reader in the system, and the package id is all it reads. Version name and version code are your word, the SHA-256 is recorded, and whether the bytes install at all is discovered on hardware rather than guessed at from the file.
It only adds, and only what the channel has on.
The in-game layer (the feedback button, play sessions and the update notice) is set per channel and only ever adds. On a web game, the public channel counts plays and the playground and public channels show the update notice unless you switch them off; everything else is off until you switch it on. Every classes.dex you shipped comes out byte-identical, every entry of a web bundle but the one HTML document comes out byte-identical, and the patched file goes back through the same package-id check a stranger’s upload gets before anyone can install it. Turn it off and your original bytes are what republishes. A build on a channel with none of it on is never opened at all.
It never sees your Board’s token.
Pairing stays on the machine that did the pairing. The bearer token your Board issues is never sent to BoardFlight and never written to a log.
It keeps secrets as hashes.
CI tokens, invites and redeem codes are shown to you once and stored only as SHA-256. There is nothing on our side that could be handed back to anyone, including you.
Nobody else can publish as you.
Claim com.acme and no other team may claim anything overlapping it. An upload declaring a package id outside your prefixes is refused. That check is what the package-id reader is for.
Whatever you build it in
The editor plugin
Window ▸ BoardFlight ▸ Publish builds and uploads in one press, and reads the package id, version and version code straight out of Player Settings. Free to download with no account; you sign in from inside the plugin.
The command line
One curl installs it, checksummed, bringing its own Node if the machine has none. Then boardflight upload, which makes the same call the plugin makes, so a build from your laptop and a build from CI are the same kind of thing.
Everything else
A Board web app packs to a .webapp.zip and installs through the same endpoint as an APK; the device detects the bundle type. Godot exports go up through the CLI.
The playground
A web game made in a browser tab, with an AI that writes it alongside you and a Publish button that uses the same upload path as everything else. It is the easy way in, shown near the top of this page, and needs no engine, toolchain or laptop that can compile anything.
Download the Unity plugin → No account needed, and every published version stays downloadable with its digest listed beside it.
Questions
How do I make a game for Board?
Do my testers need an account?
Do they need their own Board?
What does it cost?
Is this made by the people who make Board?
Can I take a build back?
How long before my first build is on somebody’s Board?
Your next build could be on a tester’s Board tonight
Always free. Read the guide first or make the account now; step one is the same either way.
Here to install something you were given? You want Redeem a code.