Loading...
Uploading Your Own Build
The jar or zip upload in Project Settings → Publish, what it accepts, and how it is recorded as an unverified build.
When you need this
A published project needs something for people to download, and normally that is whatever Cloud Build compiled. If nothing has ever compiled successfully, there is nothing to hand out.
This upload is the way out of that corner: you upload the file yourself — one you built on your own machine, or one you already had — and it is recorded on the project as a build, marked as a manual, unverified upload.
Where it is
Open the project, go to Project Settings → Publish, and scroll to the bottom. The block is called Upload a jar/zip manually. Pick the file and it uploads straight away; while it works it says Uploading & scanning….
What it accepts
| Rule | What it means |
|---|---|
| **Who can do it** | Only the project's **owner**. That is checked on the server, not just hidden in the page — anyone else is refused |
| **File types** | `.jar` or `.zip` |
| **Maximum size** | **100 MB** |
| **It must really be one** | The file is opened and its own header is read. A program renamed to `.jar` is rejected |
| **What may be inside** | Ordinary jar contents, including other `.jar` files — a multi-module build zipped together is fine |
What gets refused from inside the archive
The upload is opened and every entry in it is checked before anything is stored. Two kinds are blocked:
- Things a person could be tricked into running —
.exe,.msi,.deb,.rpm,.dmg,.pkg,.app,.appimage, and scripts like.sh,.bat,.cmd,.ps1,.vbs. - Archives inside archives —
.zip,.rar,.7z,.tar,.gz,.bz2,.xz. A.jaris the exception, because that is the actual payload.
An archive with more than 5.000 entries, or one that claims to unpack to an absurd size, is refused as well.
When an upload is refused, for any of these reasons or because you are not the owner, the message on screen does not say why: it reads "Edge Function returned a non-2xx status code". If you see that, check the file against the rules above.
It is recorded as an unverified build
When an upload passes the checks the panel says Uploaded (labelled unverified), the file is stored, and a build is recorded on the project: a successful build carrying the file's name and size, marked as a manual upload and not verified, because VyroAI did not compile it. That build is what people download from your project.
If the build cannot be recorded, the stored file is removed again and you get an error instead of a success — you never end up with a file that nothing points at.
The unverified mark stays on it. Anyone downloading that file is trusting you rather than a VyroAI build, so only upload something you built yourself.
This is not how you add a library
Project Settings → Publish and Project Settings → Build both have a jar upload and they do completely different jobs. The one on this page is only meant for a download; it is never compiled against. To let the build use a library, upload it on the Build tab instead — see Custom Dependencies.
Passing the checks is not the same as being safe, and the scan says so itself. Only upload files you built or trust — everything here is defence in depth, and none of it is a guarantee on its own.
Where to next
- Next in Code Studio (IDE): Importing from GitHub
- Before uploading by hand: Cloud Build — The compile this stands in for — try it first.
- Keeping a build around: Build History — Where a real build goes, and how to keep one.
- Offering it to others: Selling Your Project — Where a project's download is offered.
25 of 37 in Code Studio (IDE) · Last checked 17 September 2026 · Previous: Build History