The Short Answer
ibl.ai documents three deployment paths for apps built on the platform from one codebase: platform-hosted with nothing but your existing API key, a container you run on your own server, or a signed build submitted to the App Store and Google Play. All three ship as public, MIT-licensed files. On ibl.ai you own all the code and the data, which is why there are three exits instead of one.
The count is the point. A platform offering exactly one way to ship what you build on it has made a decision about your future portability, and it made it before you wrote a line of code.
Why is the number of deployment paths a measure of lock-in?
The number of deployment paths measures lock-in because it tells you what happens on the day your hosting requirement changes, and that day arrives for reasons outside your control.
A security review adds a data-residency requirement. A public sector customer requires on-premise. A hospital requires that inference never leaves the building. An acquisition consolidates cloud vendors.
None of these are exotic, and each one converts "the platform hosts it for us" from a convenience into a blocker.
If the platform supports one path, the answer at that moment is a rewrite. If it supports three, the answer is a configuration change and a rebuild.
This is why the question is worth asking during evaluation rather than during the incident. Lock-in is rarely a clause anyone reads; it is a set of options that were never built.
What are the three paths, concretely?
The three paths are platform hosting, your own container, and the mobile app stores — and all three build from the same Next.js application.
Platform-hosted. Zip the app and POST it to the platform hosting endpoint using the API key already in your environment file, then poll until the build reports READY. There is no third-party hosting account to create, no separate token to manage, and no additional CLI to install. Redeploying under the same project slug replaces the same URL.
Your own server. The same application as a container image, built once for every environment — no tenant identifier and no backend URL baked into the image. That constraint is what makes the guarantee meaningful: the digest that passed staging is byte-for-byte the digest that runs in production, and repointing it at a different backend is a restart rather than a rebuild. It runs on-premise, on Cloud Run, on Kubernetes, or fully air-gapped.
The app stores. A generated Makefile plus Fastlane configuration, where make ios-release produces the signed .ipa and pushes it to TestFlight, and make android-release produces the .aab and pushes it to the Play internal track.
The platform deployment guide also documents the two steps Apple and Google do not permit anyone to automate, rather than pretending the pipeline is fully hands-off — which is the part most deployment documentation quietly omits.
How do five native platforms come from one frontend?
Five native platforms come from one frontend because the native applications are thin shells that load the web app rather than separate implementations of it.
macOS, Windows, Linux, iOS, and Android each ship as a Tauri shell rendering the same Next.js application in a webview. You deploy the web app once, then rebuild each shell against your own domain using your own signing credentials.
That collapses what is normally seven deployment problems into two configuration decisions: which domain the shells point at, and whose certificates sign them. It also means a fix to the web application propagates to every surface without five separate release cycles.
The trade-off is honest and worth stating: a webview shell is not the right choice for an application that needs deep native platform integration or heavy offline computation.
For a business application whose logic lives on the server, it eliminates most of the cost of being on five platforms.
Who controls the memory an AI application accumulates?
Memory control belongs at the organization level, which is why administrators can manage every user's and every agent's memories from a single tab — including whether anything is captured at all.
An AI application that remembers is more useful and more sensitive at the same time. The governance question is not whether memory exists but who can inspect it, who can delete it, and who decides that it is collected in the first place.
Shipped alongside the deployment paths: administrators manage memories across every user and every agent from one organization-level view, with the switches controlling capture, and every user can review and export their own conversations from their profile.
Export matters most of the three. A user who can take their conversation history out, and an administrator who can turn capture off, together make the retention policy demonstrable rather than asserted.
What does "you own all the code and the data" mean at deployment time?
At deployment time, ownership means your infrastructure, your certificates, your developer accounts, and your users — with nothing in the chain requiring a vendor to stay cooperative.
All three paths ship as public, MIT-licensed files: two agent skills in iblai/vibe and the platform deployment guide in iblai/os, alongside 73 other skills in the toolkit.
That licensing is the operative detail. A documented deployment path published under a permissive licence cannot be withdrawn from you in a pricing change, and it can be audited before you depend on it.
The pricing model is the other half of the same question.
Per-seat licensing at roughly $30–60 per user per month bills by headcount, so a 5,000-person organization pays $150,000–300,000 a month regardless of how much the application is used — and pays it for software with one deployment path.
On ibl.ai you own all the code and the data, run it model-agnostic across any LLM, and pay with no per-seat pricing — so you can deploy anywhere, from your own cloud to a fully air-gapped network. 1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University.
ibl.ai is family-owned and operated from New York, NY — a U.S.-headquartered, domestically-owned long-term partner, not a vendor that sells licenses and moves on. If you are choosing the inference layer underneath all of this, see our guide to the self-hosted LLM serving stack.
Frequently asked questions
Does platform-hosted deployment require a third-party hosting account?
No. The application is zipped and posted to the platform hosting endpoint with the API key already in your environment file. There is no separate hosting account, token, or CLI to install.
Can the same container image run in staging and production?
Yes, and that is the design constraint. No tenant identifier or backend URL is baked into the image, so the digest validated in staging is the one that runs in production and repointing is a restart.
Can these applications run air-gapped?
Yes. The container path runs on infrastructure with no outbound connectivity, which is the same posture required for classified, clinical, and other regulated environments.
The bottom line
Most platform evaluations spend their time on features, which converge, and very little on exits, which do not.
Three documented paths from one codebase, published under a permissive licence, is a narrower claim than it sounds — but it is a checkable one. Ask any platform you are evaluating how many ways you can ship what you build on it, and whether you can read the code for each.