Skip to main content
When Hoista builds a project on your computer, it runs code from the project and its dependencies, such as install and build scripts. Hoista runs that code in an OS sandbox. The build sees its own copy of the project, a package cache and the tools it needs. It can’t read your home folder, Hoista’s state and keys, or the keychain.

​
By operating system

Settings → Safety shows whether builds can be isolated on this computer.

​
When isolation isn’t available

Hoista stops the build with build.not_isolated. It never falls back to an unisolated build on its own. On Linux, install bubblewrap and try again. If you trust the project, you can turn on Build without isolation in Settings → Safety. Hoista asks you to confirm it’s you first. Build code then runs with your access to this computer. Where the provider can build the project itself, prefer that.

​
What isolation doesn’t cover

  • Builds keep network access, because installs need it.
  • Builds that run at the provider happen in the provider’s environment, outside Hoista’s sandbox.
  • A database migration can’t be undone by rolling back the deployment.

​
Secret scanning

Before a deploy is released, Hoista checks the code changes and every file the build produces for:
  • Known key formats, such as Stripe, OpenAI, AWS, GitHub, Supabase and npm keys, private keys and database URLs that contain a password
  • The exact values of secrets you keep in Hoista
If it finds one, the deploy stops and nothing is released. The agent is told which file and what kind of key, never the key itself. Remove the secret, rotate it at the service it belongs to and deploy again.

Plan and deploy

Plan a deploy, follow it and roll back.

Threat model and limits

What Hoista can’t protect against.

Credential storage

Where tokens are kept.