LibraOS

Deploying AI in Customer Environments: A Checklist by LibraOS

Tracy Giang

02 Nov 2026 • 4 min read

Sooner or later, a customer you want to sign says: "We like it, but it has to run in our environment." A bank wants model traffic inside its network. A law firm wants client files on its own servers. A public-sector buyer has no internet connection at all.

For an AI product, that request touches more than hosting. The agents, the knowledge stores, the logs and the model all have to land somewhere the customer controls, and someone has to own each piece after go-live. This checklist is written for the vendor: the SaaS founder or agency delivering an AI product built on LibraOS into a customer's environment.

Deployment patterns you can offer

Pattern	What it means	Notes
Customer's infrastructure	LibraOS runs on-premise or in the customer's private cloud, with models, knowledge stores and application services placed where their requirements allow	For buyers with data-placement requirements
Air-gapped	The Runtime runs in an isolated network with local models and connectors	Validate all network dependencies, logs and update paths
Canadian jurisdiction	Customer data, model traffic, logs and knowledge stores placed in Canada	Confirm placement within the selected environment
Your hosted product	You run it; LibraOS Cloud is a hosted edition in private beta	For customers without a placement requirement
OEM	LibraOS inside your own branded product	Discuss private deployment and OEM licensing with the LibraOS team

Decide which of these you'll actually support before the sales conversation, not during it. Offering every pattern to every customer multiplies the environments you have to test and support.

Before kickoff: settle these with the customer

Most deployment problems are questions nobody asked at the start. Get written answers to these before anyone installs anything:

Question	Why it matters
Who operates the infrastructure day to day: you, the customer, or both?	Decides who patches, monitors and answers the 3 a.m. call
Where must customer data, model traffic, logs and knowledge stores sit?	Shapes the whole deployment, including the model choice
Which models are allowed, and where do they run?	A local model server, the customer's own provider, or hosted inference
Does the environment have internet access?	If not, every install, model and update has to be brought in
Which systems will the AI connect to, and what may it change?	Becomes your tool list and your approval points
How will updates be delivered and approved?	Air-gapped and regulated customers often need a change process
Who supports what after go-live?	Avoids gaps between you, the customer and LibraOS

Delivering the Runtime

LibraOS ships as one binary with published SHA-256 checksums. Linux builds (x86_64 and ARM64) are available today; macOS and Windows are coming soon.

On a connected machine, one line installs the latest release:

# installs the latest release
curl -fsSL https://libraos.com/install.sh | sh

Verify every download against its published checksum before it touches the customer's network:

# compare the binary with its published checksum
curl -fsSLO \
  https://github.com/libraos/releases/releases/latest/download/SHA256SUMS
sha256sum -c SHA256SUMS --ignore-missing

Know what that check proves. A checksum detects transfer corruption or a mismatch; it does not independently authenticate the publisher. Review the release notes and verification instructions in the release repository as part of your delivery process.

With containers, pull the images pinned by digest, not by a moving tag, or deploy the reference docker-compose stack: the core server plus optional companion apps. Check that the stack's pinned versions match the release you plan to deliver.

Into an air-gapped network, download the binary and the checksum file on a trusted connected machine, verify integrity there, then transfer both into the isolated environment through the customer's approved process. Plan updates the same way before you need them.

Models, controls and responsibilities

Models. In the customer's environment, the model decides where prompts go. Connect a compatible model server on their network alongside the Runtime, or the customer's own OpenAI-compatible provider with their credentials. For open-weight models, check the model card: base model, publisher, license, modifications and deployment requirements. Select models that fit the hardware the customer actually has.

Controls. Configure permissions, approval points and audit for the tasks your app runs through LibraOS, and review the execution path against the customer's real actions before go-live. Remember where those controls stop: tools, shell commands and network activity outside the Runtime need their own enforcement, even on the customer's servers. If you connect the AI to the customer's systems, map every tool that changes data and show where each is controlled.

Responsibilities. Write down who owns what after go-live:

Area	Typical owner to agree on
Infrastructure, network and backups	Customer, or you under a managed agreement
Runtime installation and updates	You, the customer, or both under a change process
Models and their terms	Whoever runs the model server or holds the provider key
Permissions, approval points and who approves	Customer, with your configuration
Audit access and retention	Customer
Application support	You

For regulated use cases, confirm the agreements, responsibilities and technical controls required before deployment. Running inside the customer's environment doesn't make the product compliant on its own.

The checklist

Before kickoff

☐ Deployment pattern agreed: customer infrastructure, air-gapped, Canadian placement, hosted or OEM.
☐ Placement of customer data, model traffic, logs and knowledge stores written down.
☐ Model choice agreed, with where it runs and whose terms apply.
☐ Internet access, or its absence, confirmed.
☐ Systems the AI will connect to, and what it may change, listed.

Delivery

☐ Binary or container images downloaded and verified against published checksums; images pinned by digest.
☐ Air-gapped: binary, checksum file and model files transferred through the approved process.
☐ Every network dependency, log destination and update path validated.

Before go-live

☐ Permissions, approval points and audit configured for the tasks your app runs through LibraOS.
☐ Execution path reviewed and tested against the customer's real actions.
☐ Tools outside the Runtime have their own enforcement.
☐ Responsibilities after go-live written down and signed off.
☐ Update path agreed and tested once.

Licensing. The Runtime is free for personal use; business production use falls under the commercial terms on the pricing page. For private deployments and OEM licensing, talk to the LibraOS team before you quote the customer.

Conclusion

Deploying an AI product inside a customer's environment is mostly agreement work done early: which pattern, where data and models sit, how the Runtime is delivered and verified, and who owns each piece after go-live. Settle those in writing, verify every download, configure and test the controls against real actions, and plan the update path before you need it.

Explore LibraOS: libraos.com

Sources

What’s Next?

Sign up and explore now.

🔍 Learn more: Visit our blog and documents for more insights or contact us for a demo of how MegaNova can power your AI products.

📬 Get in touch: Join our Discord community for help or Contact Us.

Stay Connected

💻 Website: meganova.ai

📖 Docs: docs.meganova.ai

🎮 Discord: Join our Discord

👽 Reddit: r/MegaNovaAI

𝕏 X: @meganovaai