Not a private tenant of our cloud. The actual system, deployed on your infrastructure, working against your repositories, behind your controls, with your source code never crossing the boundary.
Whiteboxing is our word for the on-premise model. You take delivery of the product and run it yourself. It is the same system we use internally, which matters more than it sounds: the thing we would sell you is the thing we depend on, so it does not get to quietly rot while a hosted version gets the attention.
It is not a stripped-down agent or a container that phones home for the interesting parts. The pipeline, the gates, the approval checkpoints and the order records all live in your environment.
Being straight about the stage: Whiteboxing is what the product is built for and it is not yet generally available. We are working through the release engineering that a supportable on-premise product demands, including versioned releases and a tested upgrade path. If this is the deployment you need, say so on the waitlist and it will weight where we put the effort.
For a lot of organisations the codebase is the most valuable thing they own, and sending it to a shared service to be processed is not a risk decision anyone wants to sign. Whiteboxing removes the question rather than answering it.
Defence, health, utilities, resources and government workloads routinely run in segmented or air-gapped environments. A tool that assumes it can call a public API is not a candidate, no matter how good it is.
Where the inference happens matters as much as where the data sits at rest. Running the model inside your own boundary is the only version of that answer which does not depend on someone else honouring a policy.
Single tenant is a design decision, not a pricing tier. One install serves one organisation, which makes the isolation story short enough to survive a security review.
The code host, the tracker and any application domain are configuration. There are no built-in defaults pointing at our infrastructure, and the system fails loudly rather than quietly falling back to something of ours.
Model routing is configurable per role in the pipeline. You can point the build, review and security stages at models you host yourself, which is what makes an isolated deployment possible at all.
It sits behind your access controls and talks to your code host and tracker with credentials you issue and can revoke.
Every order retains the request, the approved specification, each gate result and each approval. That record is what an internal audit or a change advisory board will want to see.
IntelliInfra AI is an Australian company. Intelli-Dev is designed and built here, and the on-premise model exists because the organisations we talk to have obligations about where their data and their intellectual property are allowed to go.
If your answer to a shared AI development service has always been no, this is the version that was built with that answer in mind.
Tick the on-premise box on the waitlist form. Those requests are the ones shaping the release order.