From commit to store, in one window.
The build that reaches players should come from the work you committed, and getting it there should not cost you a weekend. USourceControl packages your Unreal Engine project with the engine you already have, stamps the version into the build, and uploads it to Steam, the Epic Games Store, and itch.io. No build script, no CI service, no second machine. Your store credentials never leave your computer.
Everything between your last commit and the store page
Packages with your own engine
USourceControl reads your .uproject, finds the Unreal install it asks for, and runs the same BuildCookRun the engine ships with. Windows, Linux, and Mac targets in Development, Test, or Shipping.
Three stores, one dialog
Steam through SteamPipe, the Epic Games Store through BuildPatchTool, itch.io through Butler. Fill each one in once and every build after that is a click.
Credentials stay on your machine
Every key, secret, and password is encrypted by your operating system's keychain, never written into a command line, and never sent to our servers. We could not read them if we wanted to.
Publishes the moment a build succeeds
Turn on auto-publish and a finished build uploads itself to the stores you picked, unattended. A store you have not finished setting up is skipped with a reason rather than breaking the chain.
You can watch it work
Named phases, real transfer rates, and a detector that tells you exactly how long a tool has been silent. You will never sit in front of a frozen progress bar guessing whether it died.
Every build knows where it came from
The commit, the branch, the engine version, and whether anything was still uncommitted are recorded against the build. Switch on the clean tree rule and a build can only come from committed work.
Build the whole matrix at once
Pick several platforms and configurations and they queue up from one action, running one at a time so a single machine is never fighting itself for the engine.
Catches the failures before the cook
Disk space, long paths, a writable output folder, build output kept out of your project, the engine your .uproject asks for. Checked in seconds, so nothing fails forty minutes in.
A hung build still ends
A deadlocked shader compile used to mean a machine tied up overnight. Set a time limit and anything past it is stopped and marked failed, with the log kept.
What actually happens when you press Build
USourceControl does not ship its own build system. It drives the one Epic already gave you: RunUAT BuildCookRun, the same command a technical director would type by hand, against the engine your .uproject asks for. That matters because it means your build is not a special USourceControl build. It is your build, made reproducibly. Before anything starts, a preflight pass checks the boring things that ruin long builds: free disk space, whether Windows long paths are enabled, whether the output folder is writable, whether your project actually excludes the directories packaging writes into, and whether the engine version your project targets is installed on this machine. Failures stop you in seconds instead of forty minutes. While it runs you get phases rather than a spinner. Compiling, cooking, staging, packaging, archiving, verifying, each with progress where Unreal reports it and an elapsed clock where it does not. If a build wedges, a time limit you control kills the whole process tree and marks it failed, so a bad night never costs you a machine. When it finishes, the artifact is archived outside your project folder, so packaged output is never mistaken for project files and never lands in a commit. Old builds are pruned automatically, and any build you pin survives that pruning forever.
The version in the build matches the version on the box
The quietest way to lose an afternoon is a bug report with a screenshot showing a version number that does not exist. It happens because the version string in Config/DefaultGame.ini is typed by hand and the label on the build is typed somewhere else, and the two drift the first week nobody is paying attention. USourceControl writes the version you are packaging into the project before the cook, so the number the game reports is the number on the build, the number in the Steam build description, and the number in your publish history. It is on by default, and because it is the one place a build writes into your working tree, it is also the one place you can switch that off. Alongside it, every build records the commit sequence it was made from, the branch, the engine version, and whether the working tree was dirty at the moment the build started. Not at the end, when the tree may look nothing like it did ninety minutes earlier. If you want a harder rule than a record, turn on the clean tree gate and a dirty tree becomes a refusal to build at all.
What the stores let a tool do, and what they don't
This is where most publishing tools quietly oversell, so here is the honest shape of it. Steam uploads through SteamPipe and can set your build live on a beta branch. It cannot set the default branch live, because Valve does not allow that from the command line at all. Promoting to default stays a deliberate click in Steamworks App Admin, and that is a good thing. The Epic Games Store uploads through BuildPatchTool. Self-service organizations cannot label a binary from the tool, so making a build the live one is an action in the Epic Developer Portal. itch.io is the exception. A Butler push goes live immediately, because that is how itch works. If that is not what you want, push to a separate channel. So USourceControl tells you a build was uploaded, never that it was published to players, and every finished upload gives you a link straight to the page where the store's own promotion step lives. Two of the three platforms deliberately keep a human between the upload and the players, and we are not going to pretend otherwise.
Nothing about publishing touches our servers
Your Steam builder password, your Epic client secret, your itch API key: these are the credentials that can push code to your own store page, and they belong on your machine and nowhere else. They are encrypted with your operating system's keychain, they are never placed in a command line where any other process on a Windows session could read them, and they are never sent to USourceControl. The app's own interface can write them but cannot read them back, so a secret never sits in a window that could be inspected or crash-dumped. If your machine cannot encrypt them, we refuse to store them at all and say so up front rather than failing later. The builds themselves are just as local. Packaging runs on your hardware with your engine, the artifacts sit in a folder you chose, and the upload goes from your machine directly to the store. We version your project. We do not stand between you and your players.
Publishing without pressing anything
Once a project has shipped a few times, the Publish click stops being a decision and starts being a chore. Turn on auto-publish and a build that succeeds uploads itself to the stores you chose, in order, one at a time. It is deliberately conservative. A store that is only half configured is skipped with a sentence telling you exactly what is missing, rather than failing the whole chain and leaving the stores that were ready without the build. And automating the upload does not automate the store's own promotion step, because neither Steam nor Epic allows that. What you get back is a nightly build that is already sitting in Steamworks waiting for you, not a surprise release.
When you would rather a machine did it
Packaging in the desktop app is on-demand and runs on the computer you are sitting at. That is exactly right for a solo developer and for the run-up to a release, and it is the wrong shape for a team that wants every commit built while everyone is asleep. That job belongs to USourceControl Forge, a separate app you install on a spare machine and enroll against your organization once. It watches for commits, rebuilds the exact committed state of your project, runs a full package, and publishes the result as a versioned release your whole team downloads from the dashboard. It can also run checks instead of full packages, and upload to Steam once a build succeeds. Both are included on every plan, Free included, for the same reason: the hardware is yours.
Three steps, and the last two are buttons
Commit your work
Same commit you already make. The build records the commit it came from, so months later you can still answer what shipped.
Package it
Pick a platform and a configuration and press Build. Preflight runs first, the version is stamped into the project, and the artifact lands outside your project folder.
Send it to the store
Choose Steam, Epic, or itch.io and press Publish. Do a dry run first if you want to validate without uploading a byte.
Common questions
Can I really upload to Steam from USourceControl?
Yes. Point the app at the steamcmd.exe from your Steamworks SDK, fill in your App ID, depot ID, and builder account once, and every future build is one click from an upload. The build appears in your Steamworks build list exactly as if you had run SteamPipe by hand, because that is what happened. Setting it live on the default branch is still a click in Steamworks App Admin, because Valve does not permit that from the command line.
Does this cost extra, or is it on a higher plan?
Neither. Packaging and store publishing are included on every plan, Free included. The build runs on your machine with your engine and your store accounts, so there is nothing for us to meter.
Do you ever see my Steam, Epic, or itch.io credentials?
No. They are encrypted by your operating system's keychain and stay on your computer. They are never sent to our servers, never written into a command line, and never readable back out of the interface that set them. If your machine cannot encrypt them, we refuse to store them rather than storing them weakly.
Do I need Steamworks, Epic, or itch.io accounts already?
Yes. USourceControl automates the upload, not the store relationship. You bring an app that exists in Steamworks, an artifact that exists in the Epic Developer Portal, or a page that exists on itch.io, and we handle the part between your build and their servers.
Which tools do I have to install myself?
steamcmd comes from your Steamworks SDK, and Butler comes from itch.io, because both are their licenses to grant rather than ours to redistribute. BuildPatchTool the app can download for you, around 90 MB, or point it at a copy you already have.
Can I test a publish without uploading anything?
Yes. Every target has a dry run that validates the whole path, credentials, identifiers, content root, launch executable, without transferring the build. It is the right first move on a new project, and it costs you a minute instead of a bad build in your store's history.
What platforms can I package for?
Windows and Linux from a Windows machine, using Unreal's Linux cross-compile toolchain, and Mac from a Mac. The picker greys out anything this computer cannot build, so you find out before the cook rather than during it.
What happens if a build or upload gets stuck?
You see it. Uploads report which phase they are in, how fast bytes are moving, and how many seconds it has been since the tool said anything at all, so a silent steamcmd reads as silent rather than broken. Builds have a time limit you set, and anything past it is stopped and marked failed with the log kept.
How is this different from Forge?
The desktop app packages on the machine you are sitting at, when you ask it to, and publishes to Steam, Epic, and itch.io. Forge is a separate app for a spare machine that builds automatically on commit and publishes downloadable releases for your team. Both are on every plan, because both run on your own hardware.
Ship the build you meant to ship
Version your project, package it with your own engine, and send it to Steam, the Epic Games Store, or itch.io from the same window. Included on every plan, Free included.
Create your first project