On-Premise QuantumLayers Deployment: How It Works and When to Choose It Over the Cloud
QuantumLayers runs as a hosted service by default, with your datasets, statistics, and reports living on QuantumLayers infrastructure. An on-premise deployment moves that same application inside your own network, so the data never leaves your environment. This post covers what an on-premise install includes, what stays identical to the cloud version, the two decisions that are unique to running it yourself, and a side-by-side table of the tradeoffs against the online version.
What On-Premise Means for QuantumLayers
QuantumLayers is a self-contained server application. It bundles the web interface, the single AJAX action endpoint that every feature is built on, the Python statistical engine that computes findings, and the charting layer. In the hosted product that stack runs on QuantumLayers servers. On-premise, the identical stack runs on hardware you control: a virtual machine, a container, or a cluster inside your own firewall. Your browser reaches it over your internal network, and it reaches your databases the same way.
What Stays the Same
An on-premise install is the same product, not a reduced one. Datasets, AI Insights, the chart library, Scheduled Reports, Monitors, QL-Agent, the MCP server, and the embedded analytics API and JDK all behave the way they do in the cloud. A report you build in one runs unchanged in the other, because the code path is identical. The difference is entirely about where that code runs and where the data sits while it runs.
The Data Path
In the hosted product, a database connection has to be reachable from QuantumLayers servers, so an internal production database usually sits behind an IP allowlist, a read replica exposed for the purpose, or a tunnel. On-premise, the QuantumLayers server is already inside your network, so it connects to an internal host directly and nothing about that connection crosses the public internet. Consider a dataset whose source only resolves inside a hospital network:
Dataset Name: Claims, Last 12 Months
Database Type: postgresql
Host: pg-prod.internal.hospital.local
Port: 5432
Database: claims
Username: analytics_ro
Query: SELECT claim_date, amount, department
FROM claims
WHERE claim_date >= '2025-09-01'That hostname does not resolve outside the hospital network. In the hosted product it would be unreachable without extra exposure. On-premise it is an ordinary internal connection, and the rows it returns stay on the same network the whole time they are analyzed.
Where the AI Narration Runs
AI Insights works in two stages. First the Python engine computes the statistics deterministically, on your server: the correlations, trends, outliers, and significance tests. Then a language model turns those validated results into a plain-language summary. That second stage is the one external dependency, and on-premise you decide where the model lives. There are three common choices:
- Hosted model. Allow outbound access to the hosted language model API. Only the computed findings are sent for narration, not the raw rows. This is the simplest option and matches how the cloud version behaves.
- Your own gateway. Route the narration request through an AI gateway you operate, so every call is logged and filtered under your own policy before it leaves.
- Self-hosted model. Point the narration at a model you run inside the network. Nothing leaves your environment at any stage, which is what an air-gapped deployment requires.
The endpoint is a single setting. The statistics are computed the same way regardless of which one you use:
# Hosted model (default)
LLM_ENDPOINT = https://api.anthropic.com/v1/messages
# Your own gateway, requests logged and filtered by your policy
LLM_ENDPOINT = https://ai-gateway.internal/v1/messages
# Self-hosted model, nothing leaves the network
LLM_ENDPOINT = http://llm.internal:8000/v1/messagesUpdates and Maintenance
The hosted product updates itself, and scaling, backups, and patching are handled for you. On-premise, that work moves to your team. You provision the hardware, apply new releases on your own schedule, and own the backups and monitoring. This is the real cost of running it yourself, and it is the reason on-premise suits organizations that already operate infrastructure of their own rather than those looking for the shortest path to a first result.
The Tradeoffs at a Glance
The rows below set the two options against each other on the dimensions that usually decide between them.
| Dimension | On-Premise | Online |
|---|---|---|
| Where your data lives | Inside your own network the whole time | On QuantumLayers infrastructure |
| Time to first insight | After you provision and install the stack | Minutes after you sign in |
| Database access | Direct to internal hosts, no allowlist or tunnel | Source must be reachable from QL servers |
| AI narration | Hosted API, your gateway, or a self-hosted model | Hosted model |
| Updates | You apply them on your schedule | Applied automatically |
| Maintenance | Your team runs patching, backups, and scaling | Handled by QuantumLayers |
| Compliance fit | Strong where data residency is mandated | Depends on vendor certifications and a data agreement |
| Cost shape | Infrastructure and IT time you provide | Subscription with seats |
| Best suited to | Regulated data, air-gapped or firewalled networks | Teams that want to start now with nothing to run |
Which One Fits
Choose on-premise when a regulation or a risk assessment says the data cannot leave your environment, which is common in healthcare, finance, government, and defense, or when the data sits on networks the cloud cannot reach. Choose online when you want to be running today with nothing to maintain and your data can sit with a vendor under a standard agreement. The two are not exclusive. A good number of organizations run online for general analytics and reserve on-premise for the regulated subset of their data, using the same product across both.
Conclusion
On-premise and online run the same QuantumLayers: the same datasets, statistics, charts, reports, monitors, and agent. What you are choosing between is location and responsibility. On-premise keeps the data and the compute inside your network and hands you the upkeep. Online hands the upkeep to QuantumLayers and asks that your data sit on its infrastructure. The statistics engine runs locally in both, and only the narration step ever needs to reach outward, which on-premise you can close off entirely.
This post is part of the QuantumLayers blog series on building analytics workflows. For the full list of connectors and deployment details, see the help page. For how database sources load, see Connecting a Database to QuantumLayers. Plans are described on the pricing page. Start at www.quantumlayers.com.