CI/CD

Foundation uses TeamCity for continuous integration and deployment. Hypercade operates a shared instance. Your studio gets a project on that instance. You don’t configure TeamCity yourself - buildScripts templates do that automatically during onboarding.

How it works

Every time you push to a branch, TeamCity detects the change and runs a build. Builds use pre-configured templates for Unreal and Unity. Artifacts are produced automatically. Version numbers are set correctly. When you’re ready, one click pushes to Steam or Epic.

Build triggers

Builds trigger automatically on:

• Push to main branch (production build)
• Push to any feature or development branch (artifact build for QA testing)

You control which branches trigger builds by configuring your project settings in the Hypercade portal.

Build configurations

TeamCity projects include build configurations for each supported target. Today, that’s Windows for both Unreal and Unity:

Unreal Engine:

• Windows (Development, Shipping)

Unity:

• Windows (Development, Shipping)

macOS, Linux, and mobile targets are in development. See Supported Engines for the current status — if you need a target that isn’t shipping yet, email hello@hypercade.io and we can prioritise.

Each configuration handles compilation, symbol stripping, packaging, and versioning automatically. The buildScripts templates include engine-specific setup — no manual steps needed.

Artifacts

Build artifacts include:

• Compiled binaries
• Debug symbols
• Build logs
• Crash dump collection binaries (for BugSplat integration)
• Analytics SDK injection (if enabled)

Artifacts are stored in Hypercade’s artifact repository and retained for 30 days. You can download them from the Hypercade portal or retrieve them via API.

Adding extra files to your package

Some builds need a file that isn’t part of your cooked content — a readme, a EULA, a redistributable DLL, a config file your launcher reads. You can add these files yourself. No Hypercade config change is needed.

Create a folder named PackageOverlay in your project’s root directory, next to your .uproject file. Put the extra files there. The folder structure you use is the structure the files land in inside the final package.

Example: a file at PackageOverlay/readme.txt lands at readme.txt in the packaged build.

TeamCity copies this folder into every package it builds, after your game is cooked and staged.

Targeting a platform, build type, or server build

Add a suffix to the folder name to target it more narrowly:

Folder	Applied when
PackageOverlay	Always
PackageOverlay.WIN64 / PackageOverlay.Linux	The platform you’re building for matches
PackageOverlay.Development / PackageOverlay.Shipping	The build type you’re building matches
PackageOverlay.Server	The build is a server build

If the same file exists in more than one of these folders, the more specific folder wins. A file in PackageOverlay.Shipping overrides a same-named file in PackageOverlay.

Rules to know

• No PackageOverlay folder, or an empty one, is fine. Nothing in your build changes.
• Hypercade-managed files — the crash reporting configuration and steam_appid.txt — always win over a same-named file in your overlay. This keeps crash reporting and store detection working.
• If the copy step fails for any reason, the whole build fails, and the reason is in the build log.

Not sure which mechanism to use? Rule of thumb:

• Want the files inside your cooked pak? Add the path to DirectoriesToAlwaysStageAsUFS in your DefaultGame.ini.
• Want them as loose files under your game’s Content folder (not in the pak, but still read through Unreal’s file system)? Use DirectoriesToAlwaysStageAsNonUFS instead.
• Want them somewhere else in the package entirely — a readme next to the exe, a DLL in Binaries/Win64? That’s what PackageOverlay is for. Neither Unreal setting can place a file outside Content.

Deploying to Steam and Epic

When a build is ready for release:

1. Navigate to the build in the Hypercade portal.
2. Select your deployment target (Steam or Epic).
3. Click Deploy.

The system handles:

• Version number updates in your game’s metadata
• App credentials (passed securely from stored secrets)
• Upload to the platform’s depot system
• Build submission to release branches

No manual depot configurations needed. No version number conflicts. No lost uploads.

QA branch builds

QA can deploy builds to feature branches for testing without waiting for engineers to push to main. In the portal:

1. Select a branch build artifact.
2. Click “Deploy to QA.”
3. The artifact is packaged and made available for download or streamed to QA machines.

QA gets faster feedback. Engineers stay focused on code.

Build notifications

Build status is visible in the Hypercade portal in real time. You can also:

• Receive email notifications for build failures (configurable)
• Receive Slack notifications if your studio uses Slack
• Query build status via the Hypercade API

What buildScripts does

buildScripts is a separate automation system that configures TeamCity when you onboard. It:

• Clones your game repo
• Detects your engine (Unreal or Unity)
• Applies the appropriate build template
• Configures build triggers for your branches
• Sets up artifact storage and retention
• Configures credentials securely

You don’t run buildScripts yourself. Hypercade runs it during onboarding. If you need to reconfigure (e.g., add a new engine target or change branches), reach out to the team.

Troubleshooting

Build failed to start: Check that your repo credentials are valid and the repo is accessible.

Build timed out: Long builds may exceed the default timeout. Reach out to optimize your build configuration.

Artifact not found: Artifacts expire after 30 days. Re-run the build to generate a fresh artifact.

Deployment failed: Check your app credentials (Steam / Epic API keys). If they’re invalid, update them in the portal settings.

For help, contact the Hypercade team at hello@hypercade.io.