Zero-clone mobile builds: why Corenna never copies your code
The usual way: your code on someone else's servers
A typical hosted build service clones your repo onto its build machines, installs your dependencies, compiles, signs and hands back the app. It works, but every build leaves your code in one more place you don't control. Copies end up on build machines, in caches and sometimes in backups, and each copy is another place a leak can start.
If you built your app with Lovable, Bolt or v0, that repo may hold your whole business: your database URL, your API routes, your product. It should live in as few places as possible.
What zero clone means at Corenna
Corenna's servers never download a copy of your repository. Here is everything they do touch:
- Reads. To check your setup, Corenna reads your repo's file list and a few config files, such as
package.jsonorcapacitor.config.ts, through GitHub's API. That is how the free repo check answers in seconds. - Writes. It commits one build workflow file to
.github/workflows, plus the Capacitor setup files when a web app needs them. You can read both in your commit history. - The build. When you press Build, GitHub Actions starts a fresh machine inside your repo, builds and signs the app there, and throws the machine away. Corenna only receives the finished app file and the log.
GitHub's security does the heavy lifting
Because the build runs inside your repo, the protections you already rely on at GitHub apply to it:
- Access you choose. Corenna's GitHub App only reaches the repos you select when you install it. Uninstall it and the access is gone.
- Encrypted secrets. Signing keys and passwords are saved as GitHub Actions secrets, encrypted with GitHub's sealed-box encryption for your repo, and only opened inside the build machine. They never appear in your code or in logs.
- Throwaway machines. Each build gets a new GitHub-hosted runner that is deleted when the build ends, so nothing is left behind for the next job.
- Your account controls. Two-factor sign-in, organization rules and GitHub's audit log all still cover your repo.
Minimal storage, and what Corenna does keep
Zero clone doesn't mean zero data, so here is the full list of what Corenna stores:
- The finished, signed app file, so your download link works.
- Your signing keys and their passwords, encrypted.
- Build logs, with known secret patterns removed.
- Your project settings: app name, app ID, branch and similar.
No source code, no node_modules, no build caches. Old sandbox build records are cleared after 30 days. A copy of each build also sits in your repo's GitHub Actions artifacts for 30 days, in your own GitHub storage.
Your GitHub Actions minutes
Building in your repo means builds run on your GitHub account's runners. For public repos, GitHub's hosted runners are free. Private repos use your plan's included minutes, 2,000 a month on GitHub Free, and macOS minutes for iOS builds count about ten times. An Android build typically takes 3 to 10 minutes.
Corenna runs no build farm, so there is no compute bill hidden in the price: the subscription pays for the service, and the build minutes are GitHub's, at GitHub's price.
Your Apple account, your Android key
iOS apps are signed with your own Apple Developer certificate and provisioning profile. The app is published under your developer name, and you upload the signed .ipa to App Store Connect yourself. Corenna never asks for your Apple ID or its password. The iOS code signing guide walks through making the certificate.
On Android, Corenna can make the signing key for you, but it is still yours: you can view its passwords and download it from the project's Signing tab. Every future update must be signed with that same key, so save a copy.
The trade-offs
Zero clone is a choice, and it comes with conditions:
- Your app needs to be in a GitHub repo. GitLab and Bitbucket aren't supported.
- Builds of private repos use your GitHub minutes, like any other workflow.
- iOS needs your own Apple Developer membership, which Apple charges $99 a year for.
In return your code stays where it already lives, and leaving is easy: the workflow is in your repo, your keys can be downloaded, and Settings has a self-host export.
See the summary on the zero-clone page, or the full detail on the Security page.