In your own cloud

One container in your own cloud account, on a private network with nothing going out, your sign-in in front and your keys on the data. Azure, AWS, Google Cloud or your own Kubernetes, what we have tested, what we have not, and what the Norwegian rules say.

In your own cloud, locked down by default.

Auge runs on a machine you control. If that machine is in your cloud, in your account, it runs there the same way: one container, on a private network, with nothing going out. We do not host anyone's plant data, and the container does not need us.

How it fits together

  1. The plant exports, as it already does, to a share in its own DMZ. Nothing new connects to the control system.
  2. One way out: a scheduled copy moves the files to a private storage account or bucket in your cloud. Nothing travels back to the plant. In IEC 62443 terms that is one conduit between two zones.
  3. One container, in a private subnet with no public address, reads the files from a mount it can only read.
  4. No way out: the network denies all outbound traffic. The container needs none: the language model runs inside your network too.
  5. Your sign-in in front: the console sits behind your own identity provider, Entra ID, Okta or any OpenID Connect, reached over your private network.
  6. Your keys, your logs: storage is encrypted with keys you hold, and every sign-in and change lands in your own log store.

The same image on every cloud

Microsoft AzureAmazon Web Services Google CloudYour own Kubernetes
Run itContainer Apps, internal environment ECS on Fargate, private subnets Cloud Run, internal ingress a Deployment and a ClusterIP service; manifests included
No way outa user-defined route through Azure Firewall VPC endpoints, no NAT all egress through the VPC, VPC Service Controls a default-deny NetworkPolicy, included
Files in, read onlyAzure Files, read-only mount EFS through an access point a Cloud Storage volume, read only a read-only volume
Your keysKey Vault, customer-managed keys KMS customer managed keys Cloud KMSyour storage class's encryption
Your sign-inEntra ID, built in an internal load balancer with OIDC Identity-Aware Proxy oauth2-proxy, example included
In NorwayNorway East no Norwegian region; the nearest is Stockholmno Norwegian region yet; the nearest are Finland and Stockholm wherever your cluster is

Signing in is the one thing that needs a path out: the sign-in proxy has to reach your identity provider. The container behind it gets nothing.

What we have tested, and what we have not

Tested on every change, on a GitHub runner: the image builds; it runs as a user that is not root, with a read-only file system, every Linux capability dropped and no network at all; it compiles a folder of exports into its work area and writes nothing into the exports; every attempt to reach the internet from inside it fails, and a control run with a network shows that the attempts would have worked; the console answers its health check and refuses a request for a host name it does not serve; the MCP server answers with read-only tools only; the Kubernetes manifests validate. A software bill of materials is produced with every build, and the image is scanned for known vulnerabilities.

Not tested: we have not deployed it to Azure, AWS, Google Cloud, OpenShift or a managed Kubernetes. The table above is built from each vendor's documentation, linked, and the first customer deployment is where it gets proved. We will write down what we find.

What the rules say

We have found no Norwegian or EU rule that forbids analysis like this in a cloud. What the rules ask for is control: waterworks must protect their control systems against unauthorised access (drikkevannsforskriften § 10) and, under the Digital Security Act, follow up their suppliers (Mattilsynet). For power, the rules are stricter: a report SINTEF wrote for NVE in 2025 concludes that class 1 and 2 control systems cannot move to a cloud under today's rules, and tag lists and system configuration count as power-sensitive information (kraftberedskapsforskriften, NVE's guide to § 6-2). For a power company we recommend a machine on site, and we do not claim that any setup is compliant on your behalf: that is your assessment, and we will give you what it needs.

If you would rather use your cloud's own language model

You can, and then the questions people ask, with the plant data in them, leave the container for that service, under your contract with your cloud provider. That is your choice to make, and a setting you change on purpose. With the model inside the container, nothing leaves.

Sources and data

The results on this page are read from results files built from the data below, not typed by hand. Who made each data set, and its licence, is on the sources page.

Back to the front page

Start with one export.

We sit with you and run it on a machine you control, so nothing leaves the site. You keep the mapping report: every tag with its quantity, unit and machine and the evidence for each, what could not be told and why, and the data that went wrong this week, in Norwegian or English.

Write to [email protected]. If you would rather send us an anonymised export, we sign your data processing agreement first.

What a pilot costs · What your security team can check · Steps 3 and 5 of Norsk Vann 300 · For integrators

Read next

Shipping, district heating and data centres

Three industries, each tested on published data, one result a plain fail.

Read more

The market, and where we are going

A large market, an expensive problem, rules that now require the answer, and the road ahead, every figure linked to its source.

Read more

Price, and the work it replaces

What it costs, the work it replaces, and what it will not claim.

Read more