Upload builds

What to upload

Upload the folder that runs your app on a clean Windows PC: the .exe and every DLL, data file and resource it loads. Do not upload an installer, source code or secrets. Omnihorn builds the installer for you, and installed copies receive exactly the files you upload.

You can drop the folder itself, loose files, or exactly one archive. Archives in .zip, .7z, .rar, .tar, gzip, bzip2 and xz formats are unpacked in your browser. If you want the archive shipped as a file instead of unpacked, turn on the switch to upload the archive itself.

Upload from the dashboard

1. 1

   Open the upload page

   Open your app, go to the Builds tab and choose New build. In the app wizard, the First build step shows the same uploader.

2. 2

   Drop the folder or archive

   Drag it onto the drop area or choose it with the file picker. A summary shows the file tree. If everything sits inside one top folder, that folder is stripped so your .exe lands at the root; a switch turns this off.

3. 3

   Check the problems list

   Unsafe paths, paths that are too long, files that are too large, duplicate names and too many files are listed, and any of them blocks the upload. System junk such as __MACOSX, .DS_Store and Thumbs.db is dropped for you.

4. 4

   Confirm the program to launch

   If the build holds an .exe, the uploader offers it as the program to start after install and after each update. You can change this later in Installer Studio.

5. 5

   Set the version and release notes

   Type a version in MAJOR.MINOR.PATCH form, such as 1.4.0, or leave it blank to keep the last one. Add “What’s new” if you like; you can also write it later.

6. 6

   Upload

   Choose the Upload button. Progress runs through Reading, Checking, Uploading and Processing. When processing finishes, the build is active.

7. 7

   Assign it to a channel

   Open the Channels tab, open the channel, select the build in the Assigned build card and save. Installed copies on that channel get it on their next check.

To upload from GitHub Actions or another CI system instead, see CI/CD.

Versions

You set the base version; Omnihorn adds a build counter. Upload 1.4.0 and the build is stored as 1.4.0+build.42, where 42 is the app’s next build number. The number only goes up, so two uploads of the same base version stay distinct. If you leave the version blank, the last base version is reused with a new counter.

Release notes

The “What’s new” text is shown by the installer before an update. It is plain text with line breaks kept, up to 10,000 characters. You can add or edit it at any time on the build’s page, even after the build is live. Release notes are not part of the signed manifest, so an edit reaches installed copies on their next check.

Limits

Storage counts each distinct file once. A file that is identical in several builds, or that you already uploaded before, is not uploaded or counted again.

What happens after the upload

Your browser hashes every file with SHA-256 before anything is sent. Files your workspace already uploaded are skipped, and the rest go straight to storage. Omnihorn then scans each new file for malware, checks that its hash and size match, writes the build’s manifest and signs it with your app’s key. Only then does the build become active.

• An uploaded build is not released by itself. It reaches users when a channel points at it. In the app wizard, the first build goes live on production.
• A channel that follows a Git branch takes matching builds from CI automatically. Dashboard uploads are assigned by hand.
• You do not need a new installer. Installers download the channel’s current build, so new and existing installs get the new files.
• A build that failed shows the reason on its page. A malware hit or a hash or size mismatch is final: upload again. For other failures, the page offers a retry.

How old builds are kept and removed

Each plan keeps a number of builds per app and removes unused builds after a while; the numbers are on the pricing page. Some builds are never removed automatically: a build that is live on a channel, a pinned build, a build still processing, and the three newest active builds of the app.

The Builds tab shows how many builds the app has and how long unused builds are kept. While automatic removal is not switched on, it says Retention preview — nothing is deleted yet, and the dates it shows are previews.

• Pin a build to keep it for good, for example the last release a customer relies on. Unpin it to let the rules apply again.
• Delete a build you no longer need. A build that is live on a channel or pinned cannot be deleted until you move the channel or unpin it.
• A deleted build is never served again. Its storage comes back within minutes, except for files other builds still use.