# Who's using Cloud or Docker in production environments?

**URL:** <https://forum.inductiveautomation.com/t/whos-using-cloud-or-docker-in-production-environments/114731>\
**Category:** Ignition\
**Tags:** perspective, vision, ignition81\
**Created:** [March 27, 2026, 3:29pm UTC](https://forum.inductiveautomation.com/t/whos-using-cloud-or-docker-in-production-environments/114731 "2026-03-27T15:29:39Z")\
**Posts on this page:** 15\
**Page:** 1

<div class="post-metadata">

**Author:** ![drewdin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/drewdin/32/3363_2.png) [@drewdin](https://forum.inductiveautomation.com/u/drewdin)\
**Post date:** [March 27, 2026, 3:29pm UTC](https://forum.inductiveautomation.com/t/whos-using-cloud-or-docker-in-production-environments/114731/1 "2026-03-27T15:29:39Z")

</div>

I’m old school and think everything should be on-prem (VM, not physical) when it comes to HMI & SCADA, I see the trends of everything moving to cloud and docker based deployments.

I’m trying to get a feel from anyone who is using cloud based or docker based deployments and how its working for you. What issues have you come across and how do you like it? How are you dealing with possible internet outages?

I understand Docker is mostly on-prem (from my experience) but wasn’t sure if anyone is using it in the cloud.

This is just a high level question/discussion regarding kicking tires so let me know your thoughts and how well it did or didn’t work for you! Thanks!

---

<div class="post-metadata">

**Author:** ![lane.duncan](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/lane.duncan/32/83700_2.png) [@lane.duncan](https://forum.inductiveautomation.com/u/lane.duncan)\
**Post date:** [March 28, 2026, 6:13am UTC](https://forum.inductiveautomation.com/t/whos-using-cloud-or-docker-in-production-environments/114731/2 "2026-03-28T06:13:35Z")

</div>

I have a customer that deploys the Gateway to a private cloud….and as would be expected when the ISP goes down, their production goes down. It’s a silly design because IT will not venture to the plant floor.

The workaround is edge gateways…..but then IT has to venture to the plant floor.

Docker is really just about efficient use of resources and works the same regardless of the hardware location.

---

<div class="post-metadata">

**Author:** ![Brian\_Stilson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/brian_stilson/32/73410_2.png) [@Brian\_Stilson](https://forum.inductiveautomation.com/u/Brian_Stilson)\
**Post date:** [March 29, 2026, 5:00pm UTC](https://forum.inductiveautomation.com/t/whos-using-cloud-or-docker-in-production-environments/114731/3 "2026-03-29T17:00:44Z")

</div>

> I’m old school and think everything should be on-prem (VM, not physical) when it comes to HMI & SCADA

That’s because you don’t have experience with use cases where this approach isn’t viable. Oil fields, pump stations, wind farms, municipal utilities…anywhere you have nodes that are separated by miles and there is no single “premises” that exists, this is where Cloud applications come in.

Trying to accomplish this with traditional SCADA methods won’t be nearly as secure or reliable. Transmitting things over the internet with 1990s security technology (e.g., no security, which are the vast majority of “traditional” SCADAs) is inviting disaster. Cloud edition gives you functionality with modern security practices. SSL certification, multi-factor authentication, traffic encryption. There’s a whole lot out there in the world of internet security that us “old school” guys don’t have the first clue about, but are incredibly important all the same.

In my experience, the most important consideration when utilizing Cloud Edition, especially when you have a multi-tenant application like my team is working on, is scalability. Something that will work on a tiny single-project edge station will very often annihilate a Cloud server at scale. You have to _really_ consider every single method you use to accomplish what you need to accomplish or else you’ll be a big world of hurt down the road as more tenants move in.

For example, we had a situation where one of our servers was crashing and it turned out that someone had made a script transform on a binding that refreshed every 5 seconds inside of a template. That script included an alarm journal query, which is a pretty “expensive” scripting method as it is. When we had just a handful of tenants, it wasn’t a problem. But when we had 50, that means 50 alarm journal queries were happening every single second, _per perspective session._ So if 10 sessions were open, that meant 500 alarm journal queries per second. We ended up moving the script from the view template to a gateway timer script and changed it so that it would write its results to tags instead. Since it became a gateway timer script, that meant only one instance of the script would run no matter how many sessions were open, because each template would just read the tag the script populated instead. That’s just one example of something that’s typically “discouraged but tolerated” (using a script transform on a binding) being an absolutely unworkable solution at scale.

In order to use Cloud, imo, the most important thing is _really_ understanding _where_ to write your scripts and _why_. You need to really plan out and optimize everything.

---

<div class="post-metadata">

**Author:** ![AngrySparky](https://avatars.discourse-cdn.com/v4/letter/a/f07891/32.png) [@AngrySparky](https://forum.inductiveautomation.com/u/AngrySparky)\
**Post date:** [March 30, 2026, 1:12am UTC](https://forum.inductiveautomation.com/t/whos-using-cloud-or-docker-in-production-environments/114731/4 "2026-03-30T01:12:34Z")

</div>

Im pretty intrigued by the idea of hosting a central ignition in the cloud. Im looking at building out a hub and spoke system consisting of 4 facilities for a water/wastewater with 20+ miles between some of the facilities. Unfortunately I know zero about cloud stuff and I think it would be a touch expensive for our needs. Letting super professionals at aws take care of the hardware sounds great though.

---

<div class="post-metadata">

**Author:** ![lane.duncan](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/lane.duncan/32/83700_2.png) [@lane.duncan](https://forum.inductiveautomation.com/u/lane.duncan)\
**Post date:** [March 30, 2026, 6:36am UTC](https://forum.inductiveautomation.com/t/whos-using-cloud-or-docker-in-production-environments/114731/5 "2026-03-30T06:36:38Z")

</div>

In this case a hybrid approach of physical hardware with limited software at the plant, and then a full blown central SCADA in the cloud might make sense.

There are many factors to consider and there is no one-size-fits-all.

FWIW - AWS Lightsail is a great platform to dip your toe in the water for cloud hosting.

---

<div class="post-metadata">

**Author:** ![AngrySparky](https://avatars.discourse-cdn.com/v4/letter/a/f07891/32.png) [@AngrySparky](https://forum.inductiveautomation.com/u/AngrySparky)\
**Post date:** [March 30, 2026, 12:39pm UTC](https://forum.inductiveautomation.com/t/whos-using-cloud-or-docker-in-production-environments/114731/6 "2026-03-30T12:39:25Z")

</div>

Im already planning to do a edge panel install at each location that connects directly to the plcs, provides local fallback, provides backup short term data collection, etc. These will report back to a central gateway for system wide visualization, data logging, reporting, alarming, etc, etc. So really only difference would be using a local gateway vs the cloud edition. Seems like a decent use case for cloud, except I would be stuck endlessly explaining what the cloud is to operators. And IT could screw our internet up and sink the whole ship.

---

<div class="post-metadata">

**Author:** ![Nol](https://avatars.discourse-cdn.com/v4/letter/n/8e8cbc/32.png) [@Nol](https://forum.inductiveautomation.com/u/Nol)\
**Post date:** [March 30, 2026, 1:06pm UTC](https://forum.inductiveautomation.com/t/whos-using-cloud-or-docker-in-production-environments/114731/7 "2026-03-30T13:06:34Z")

</div>

We use it lots in O&G. Wells pads accessible via private radio towers or cell modems collected to a regional server then it's all accessible via a cloud front end so that the operators can control everything remotely on their tablets.

Works pretty well, though you have to be mindful of availability, even if cloud providers claim 99.99% uptime that still means instances of outages. Also in the era of AI slop we've seen more problems with places like cloudflare, aws, azure, etc having outages more frequently than in the past so be mindful to plan mitigations or backup routes.

We do not use cloud edition ever. It's not worth it financially unless you're just spinning up a short term install. Just buy a regular license.

---

<div class="post-metadata">

**Author:** ![AngrySparky](https://avatars.discourse-cdn.com/v4/letter/a/f07891/32.png) [@AngrySparky](https://forum.inductiveautomation.com/u/AngrySparky)\
**Post date:** [March 30, 2026, 2:33pm UTC](https://forum.inductiveautomation.com/t/whos-using-cloud-or-docker-in-production-environments/114731/8 "2026-03-30T14:33:10Z")

</div>

> [@Nol](#):
>
> We do not use cloud edition ever. It's not worth it financially unless you're just spinning up a short term install. Just buy a regular license.

This has just sent me down a new rabbit hole this morning. When I initially looked at the cloud stuff I was looking specifically at the cloud edition and it seemed pretty expensive. However it seems like paying for a cloud instance and installing a normal license would be the same or cheaper than maintaining appropriate hardware on site for a central gateway.

---

<div class="post-metadata">

**Author:** ![drewdin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/drewdin/32/3363_2.png) [@drewdin](https://forum.inductiveautomation.com/u/drewdin)\
**Post date:** [March 31, 2026, 12:47am UTC](https://forum.inductiveautomation.com/t/whos-using-cloud-or-docker-in-production-environments/114731/9 "2026-03-31T00:47:57Z")

</div>

This is great information, thanks everyone!

---

<div class="post-metadata">

**Author:** ![lane.duncan](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/lane.duncan/32/83700_2.png) [@lane.duncan](https://forum.inductiveautomation.com/u/lane.duncan)\
**Post date:** [March 31, 2026, 9:39am UTC](https://forum.inductiveautomation.com/t/whos-using-cloud-or-docker-in-production-environments/114731/10 "2026-03-31T09:39:04Z")

</div>

> [@AngrySparky](#):
>
> However it seems like paying for a cloud instance and installing a normal license would be the same or cheaper than maintaining appropriate hardware on site for a central gateway.

I was going to reply exactly this to you. 'Cloud Gateway' is not necessarily 'Cloud Edition.' Use a normal license on hardware that is located off-premises.

---

<div class="post-metadata">

**Author:** ![AngrySparky](https://avatars.discourse-cdn.com/v4/letter/a/f07891/32.png) [@AngrySparky](https://forum.inductiveautomation.com/u/AngrySparky)\
**Post date:** [March 31, 2026, 12:28pm UTC](https://forum.inductiveautomation.com/t/whos-using-cloud-or-docker-in-production-environments/114731/11 "2026-03-31T12:28:19Z")

</div>

It really does seem that the cloud edition would shine for non 24/7 use but when you cross over into 24/7/365 a regular license installed in the cloud makes more sense financially.

---

<div class="post-metadata">

**Author:** ![AngrySparky](https://avatars.discourse-cdn.com/v4/letter/a/f07891/32.png) [@AngrySparky](https://forum.inductiveautomation.com/u/AngrySparky)\
**Post date:** [March 31, 2026, 1:36pm UTC](https://forum.inductiveautomation.com/t/whos-using-cloud-or-docker-in-production-environments/114731/12 "2026-03-31T13:36:52Z")

</div>

That being said though, I could run cloud edition on a fairly substantial cloud instance for the same cost as the yearly service from Rockwell. So maybe cloud edition isnt that expensive after all.

---

<div class="post-metadata">

**Author:** ![drewdin](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/drewdin/32/3363_2.png) [@drewdin](https://forum.inductiveautomation.com/u/drewdin)\
**Post date:** [March 31, 2026, 1:43pm UTC](https://forum.inductiveautomation.com/t/whos-using-cloud-or-docker-in-production-environments/114731/13 "2026-03-31T13:43:34Z")

</div>

you could buy a small island with the cost of rockwell licenses

---

<div class="post-metadata">

**Author:** ![Brian\_Stilson](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/brian_stilson/32/73410_2.png) [@Brian\_Stilson](https://forum.inductiveautomation.com/u/Brian_Stilson)\
**Post date:** [March 31, 2026, 2:05pm UTC](https://forum.inductiveautomation.com/t/whos-using-cloud-or-docker-in-production-environments/114731/14 "2026-03-31T14:05:21Z")

</div>

If you aren’t already, I would utilize MQTT between your Edge and Cloud environments so you can have store-and-forward capability for your tag historical data. Since Edge can’t talk to a database directly, that’s going to fall to Cloud Edition, and while CE has store-and-forward to whatever database you’re storing data in, I don’t think (someone correct me if I’m wrong) that the same exists for a Remote Tag Provider you’ll have to set up via the Ignition Gateway Network. The Cirruslink MQTT Transmitter driver gives you the ability to Store and Forward your Edge tag data and write directly to Cloud’s historian when your connection returns.

---

<div class="post-metadata">

**Author:** ![michael.flagler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/michael.flagler/32/26272_2.png) [@michael.flagler](https://forum.inductiveautomation.com/u/michael.flagler)\
**Post date:** [March 31, 2026, 2:30pm UTC](https://forum.inductiveautomation.com/t/whos-using-cloud-or-docker-in-production-environments/114731/15 "2026-03-31T14:30:18Z")

</div>

That's what Edge Sync is for:

> **[Configuring Sync Services | Ignition User Manual](https://www.docs.inductiveautomation.com/docs/8.1/other-editions/ignition-edge/edge-gateway/configuring-sync-services)**
>
> Data Synchronization
