Cloud Engines Update1

Developers
1

Cloud Engine

​In reality, the biggest obstacle facing ICP isn’t the technology itself, but simple human fear. Imagine a large company that has its entire system built on Google Cloud or AWS. For them, moving everything to an on-chain environment all at once feels like a massive risk, no matter how revolutionary it sounds. They are simply afraid of an “unfamiliar” environment.

​This is exactly where the idea comes in: instead of begging them to “come over to our side,” we tell them – “Keep your Google Cloud, just create a Live Shadow Mirror of it on ICP.”

​That’s the core of it – creating a mirror is technically much simpler and doesn’t disrupt anything. Using HTTPS Outcalls, canisters can automatically pull data from their existing API and create an identical copy of the site or application on our network. The user then watches both systems side-by-side: they see that the original is running, and this mirror is functioning exactly the same way, except it is tamperproof and decentralized.

​This is the shortest path to building trust. When a CTO sees that for weeks this “shadow” hasn’t stopped for a second and everything is in sync, the fear disappears. From there, it’s just a one-click process – once they are convinced that ICP is reliable, they can switch the nodes to sovereign hardware, and that’s it, the migration is complete without any headaches. This approach turns Cloud Engine from some abstract technology into a practical tool that you test first and trust later.

2

I don’t want to burst anyone’s bubble, but moving applications or websites from AWS or other providers to Cloud Engine is not something that can be done that easily.

You can migrate a static site without much trouble. You can probably also migrate a Rust application or a JavaScript framework-based app, but mainly if it does not depend on a database. In most cases, you still need to rewrite parts of the code to adapt the application to ICP. You also cannot simply run PHP, Python, C#, or other common languages as-is. There is no direct equivalent to services like Supabase, MongoDB, or SQL Server either.

So in practice, you are mostly limited to building new applications from scratch, migrating existing ones by rewriting them for Rust, Motoko, or JavaScript, or just running static websites. That means the effort required to move from a traditional cloud provider to ICP remains relatively significant.

Over the last few years, I personally ported PHP to ICP, but because of canister limitations (5B and 40B instruction limits), I eventually had to move toward an intermediate solution using external VPSs.

I hope that in the near future, with the arrival of Cloud Engine, we will be able to go beyond the current 5B instruction limit on execution servers, making it possible to run PHP, Python, C#, and other languages more realistically, while also integrating technologies like PostgreSQL and other Web2 components. I also hope this will open the door to more serious AI workloads, including inference, orchestration, and agent-based systems that currently remain difficult to support directly under the existing execution constraints. But from what I understand today, the underlying direction still seems to be about rebuilding applications almost entirely in Caffeine.

3

How exactly is this any sort of Update ?

4

The new aspect is that the user does not have to abandon Google or AWS immediately and switch to ICP Cloud at once. Instead, both environments can run in parallel, and the user decides when to leave Google or AWS.

Real differences are:

  • Parallel usage: Both systems are visible side by side in one dashboard, with real‑time synchronization.
  • Step‑by‑step transition: Shadow Mirror, then Hybrid Cloud Engine, then Sovereign Migration — reducing onboarding fear.
  • No forced takeover: The model does not push users to abandon Google/AWS abruptly; the choice remains theirs.
  • Full sovereignty at the end: Once trust is established, everything moves to ICP sovereign hardware with one click and no downtime.
5

Here’s another very intelligent developer who could materially assist with a MIGRATION/COMPATIBILITY STRATEGY here that DFINITY is not collaborating with.

In the Bad Marine LLC thread I pointed out how we need a strategy for useful hardware deployments that would help make our nodes become invaluable to local, state, and federal governments. Not all node deployments are equal and now here I would point out that we should have always been thinking about how do we get people here to ICP with the least amount of resistance.

It should have always been obvious from day 1 that we needed such a strategy.

Michel points this out:

  1. Why have we not pursued allowing legacy web2 tech to run inside canisters? This would allow many businesses to very easily begin migrating over to web3 without having to rewrite everything from scratch. I know DOM mentioned “SNORKEL” and having AI do the porting which sounds great but may take a very long time to perfect in the meantime.

If we could enable Michel’s work, we could already have a lot of WordPress sites burning ICP here with the added value of allowing them to have greater security, greater uptime, more control than centralized infra, the ability to start integrating crypto, and all the rest ICP and web3 has to offer.

  1. Why don’t we have tools to migrate databases over here? Or at least allows them to run inside the canister?

  2. Why don’t we have more support for more languages like Python, C#, etc.?

If we want people here but tell them “you must rewrite everything from scratch”…this will be a very difficult way to get them here. If we had easier ways to get them here first, then I’m sure using SNORKEL in the future would be a great thing for them or even having a team of devs do it manually.

I’m not a great chess player but business is truly all about strategy and focusing on areas that can truly make a difference in terms of bringing business here.

Just being able to run PHP inside a canister is a cool thing for all the PHP devs.

6

There is no strategy

8

There’s a reason why there’s a 20-year roadmap! :slightly_smiling_face: