Security and trust
Each build in its own box. Your code is not kept.
We designed jikobi.com to hold as little as possible, and to say plainly what each build could reach.
A sandbox for every build step
Every step runs in its own sandbox: separate processes, a read-only system, only its own workspace writable, no extra privileges, and limits on memory, processes and CPU. If the sandbox cannot be set up, the build fails. It never runs without it.
Your code is not kept
The revision is fetched for one build into a temporary workspace. The workspace is deleted after every build, whether it worked, failed or was cancelled.
No secrets in builds
Build steps start with an empty environment. They never see our tokens, signing keys or other accounts' data.
Private networks blocked
Builds can download dependencies from the public internet, but cannot reach our private network, other machines inside it or cloud metadata.
Signing stays outside
Builds make unsigned files. Signing, when you ask for it, happens in a separate step that builds cannot reach.
Everything is recorded
Adding a project, starting, cancelling and downloading are written to an audit log with the exact commit and file hashes.
What the sandbox does not do
We prefer to say it plainly. Builds share the machine's operating system kernel, so a kernel flaw could break out. Builds can reach the public internet. Each build has limits, but this is not a place to run code you do not trust. We will publish an independent review of the sandbox before we open building to everyone.
Found a problem?
Email [email protected]. We reply quickly and do not take action against good-faith research that follows our acceptable use policy.