continON is deployed as one thing. What changes is whose ground it stands on.
It runs as a set of containerized services on a Kubernetes cluster, delivered through a governed release pipeline. That does not change between deployments. What changes is whose cluster it is, who holds the public hostname and its certificate, and who is answerable when a machine needs attention. This page is about that line.
- Operated for you
- The environment is run on infrastructure we operate. The cluster, the public hostname and its certificate, and the application of each release are ours.
- On infrastructure you control
- The same workload is deployed onto a cluster your organization owns or rents. The licence activates the product where you put it; the machines, the hostname and the operating of it are yours.
Four boundaries, from the outside in.
The public edge
Operated for you We hold the hostname and its certificate.
On infrastructure you control Your organization holds the hostname and its certificate.
A service is reachable from outside only if it has been given an explicit public hostname with a certificate. Everything that has not been given one is reachable inside the environment and nowhere else — that is the default, not a setting somebody remembered to switch on.
What crosses itBrowser traffic to the applications that have a hostname. Nothing else.
The environment
Operated for you We operate the cluster and apply releases.
On infrastructure you control Your team operates the cluster; releases are still delivered as a governed, versioned unit.
One cluster running the product’s services. Releases are applied to it by the delivery pipeline rather than by hand: the application repositories own their source and nothing else, and cannot change where or how the product is deployed. That separation is the change-control story, and it holds in both placements.
What crosses itReleased images, applied by the pipeline. Outbound calls the product makes to systems you have connected.
The product
Held byIdentical either way.
The applications, the one authorization server every application signs in against, the organization and position model, the Builder definitions and the shared data layer. This is the same software in both placements — there is no cloud edition and no cut-down on-site edition.
What crosses itNothing new. A record crossing from one application to another stays inside this boundary.
Your organization’s records
Held byYours either way.
Every record is scoped to the organization it belongs to, and an encrypted licence file — validated on upload, carrying the organization name, the deployment type and an expiry — decides which applications exist for that organization at all.
What crosses itOnly what a signed-in identity is permitted to read or write, decided by the seat that identity holds.
Moving the envelope does not move any of this.
- The access model
- Permission groups bound to positions in the org chart, not to accounts. See it
- The licence
- The same encrypted file, validated on upload, gating the same modules. See it
- The integration mechanisms
- The same saved queries against your own sources and the same per-organization credential store. See it
- The organization model
- The same units, positions and seats every other part of the product resolves against. See it
What this page does not assert.
- Availability targets, backup and recovery are agreed per engagement. This page does not assert an uptime figure, and there is no service level implied by the deployment model itself.
- Where the cluster is yours, operating it — capacity, patching of the host, monitoring, and the backups of your own database — remains your organization’s responsibility.
- continON is delivered as one containerized workload. It is not offered as a managed service on a third-party cloud provider’s own platform, and this page does not present one.
How the platform holds together
Bring your infrastructure constraints.
A working session on where the environment would sit, who would hold the hostname, what your team would operate and what we would — before anything is signed.