Choosing your platform
During Build Environment setup you first pick your project’s platform — Linux / macOS or Windows — and then choose Modelcode Hosted versus Self hosted. The platform decides the shell your lifecycle scripts are written in and the image your sandbox is built from, and neither choice can be changed afterwards — so pick the platform your application already builds on. Windows is fully supported on Modelcode Hosted. If you write lifecycle scripts for Windows, see the note on shell syntax — the PowerShell version differs between hosted and self-hosted machines.Why Use Modelcode Hosted
The hosted environment is the fastest way to get running. Because there is no local daemon to install or manage, onboarding is immediate - works out how to build and run your project with you in chat and takes care of the rest. This option works best for projects with publicly accessible dependencies: open-source packages, public container registries, and services reachable from the internet. If your project already builds cleanly from source using publicly available dependencies, the hosted environment is the right choice.When to Use Modelcode Hosted
- Your project’s dependencies are publicly accessible (npm, PyPI, Maven Central, Packagist, etc.)
- You want to get started quickly without installing anything on your own machine
- Your team does not have a stable, long-lived build server to run ModelDaemon on
- You prefer a fully managed, zero-maintenance build environment
For projects that depend on private services - such as internal APIs, private package registries, or databases not accessible from the public internet - choose Self Hosted instead. With Self Hosted, you install ModelDaemon inside your own network so it inherits access to your private infrastructure directly.
Enterprise Applications with Private Infrastructure
If your application needs private artifact repositories, complex network allowlists, or a site-to-site VPN to reach internal services, the standard hosted environment may not meet your requirements as it stands. supports enterprise configurations for exactly these cases, including:- Your own certificate authority. A private root CA can be trusted inside the sandbox, so builds work behind a TLS-inspecting proxy without disabling verification.
- Dedicated and isolated deployments, including air-gapped installations.
- Private build hosts reached over mutually authenticated TLS.