Juno has released a major update that reshapes how developers interact with its platform, combining architectural simplification with a clearer pricing and resource model. The changes touch core parts of the system, including how monitoring is handled, how resources are paid for, and how much it costs to create new modules. Together, they signal a move towards reducing friction for new users while tightening up long-term sustainability.
One of the most visible shifts is the merger of Mission Control and Monitoring. Mission Control was originally conceived as a central hub for developers to create and manage projects, known as Satellites, alongside analytics components called Orbiters. Over time, monitoring features were added to this structure, gradually increasing its scope and complexity.
The original design rested on a narrow view of identity. The Juno Console only recognised a developer and their Mission Control ID, and little else. While that approach had benefits in terms of separation and simplicity on paper, it created practical issues as the platform grew.
Every new developer sign-up triggered the automatic creation of a Mission Control. When a developer logged in and launched their first free project, Juno had to provision two containers instead of one. That doubled infrastructure requirements at the earliest stage of onboarding, pushing up costs before users had even committed to the platform.
It also created confusion. Mission Control could not be hidden from the interface because modules need to be provisioned with cycles to avoid being decommissioned. As a result, developers were often presented with a component they had not actively chosen to create, with little clarity around its purpose. Feedback suggested that many were unsure why it existed at all.
The latest release addresses this by merging Mission Control and Monitoring into a more deliberate flow. A Mission Control instance is now created only when a developer explicitly enables Monitoring. Monitoring itself is treated as a dedicated microservice, rather than an always-present control layer.
For developers, this means a cleaner interface and fewer concepts to understand upfront. Monitoring becomes something you opt into when it is needed, rather than a default element that demands attention from day one. From Juno’s perspective, the change reduces the cost of acquiring new developers, since fewer resources are provisioned automatically.
There are trade-offs. The Console now tracks all containers created by developers, including Satellites, Orbiters and Mission Controls. Previously, it only needed to know the Mission Control ID. When Monitoring is enabled, metadata about modules has to be duplicated inside the Mission Control so it knows what to observe. That duplication introduces the possibility of mismatches if a bug causes the two sources of data to fall out of sync.
Juno acknowledges this risk and plans to introduce a Console feature that compares and verifies the information held by Monitoring against the primary records. It is a pragmatic admission that simplification in one area can introduce complexity elsewhere, even when the net effect is positive.
Alongside the architectural changes, Juno has taken a firm stance on how users pay for resources. ICP has been deprecated in favour of a cycles-only model. This follows a broader effort over the past year to refine both the platform and how it is described, with a clear intention to move away from blockchain-specific language where possible.
The trigger for this change came during the work on Mission Control and Monitoring, when a new wallet ID derived from developer sign-in had to be introduced. That process highlighted how confusing onboarding could be for new users, particularly around the question of why ICP was needed simply to acquire cycles.
With breaking changes already part of this release, Juno chose to simplify further. New users can now start for free, learn about cycles as the resource that powers containers and services, and acquire cycles only when they need to scale or create additional modules. The main call to action for purchasing cycles points to cycle.express, which allows developers to convert dollars directly into cycles. Third-party wallets such as Oisy remain supported, though they are positioned as secondary options for those already comfortable using them.
This shift clarifies the mental model of how Juno works. Instead of introducing a token first and explaining how it maps to resources later, the platform now centres on cycles from the outset. For developers who are less interested in crypto mechanics and more focused on deploying applications, that clarity may reduce hesitation at the onboarding stage.
The release also revises pricing. Previously, creating new Satellites or Orbiters cost 0.4 ICP. In practice, this price did not reflect the resources being allocated. Each module was provisioned with 1.5 trillion cycles, while 0.4 ICP corresponded to roughly 0.93 trillion cycles. The difference effectively amounted to a subsidy that became harder to justify as usage grew.
Under the new structure, additional Satellites and Orbiters cost 3 trillion cycles, which Juno estimates at around four dollars. Enabling Monitoring, which spins up a Mission Control, carries the same cost. The increase aligns pricing more closely with actual resource consumption, though it does raise the bar slightly for developers looking to expand beyond the free tier.
From a developer perspective, reactions are likely to be mixed. Some will welcome the clearer pricing and simpler onboarding, particularly those who value predictable costs over token conversions. Others may view the higher entry cost for additional modules as a constraint, especially for experimentation-heavy workflows. Much will depend on how the free tier and early-stage experience feel in practice.
What is clear is that Juno is refining its identity as a platform for building, deploying and running applications in WASM containers, with ownership and minimal operational overhead. The latest release reinforces that direction by stripping away concepts that caused friction and aligning costs with reality.
As with any major release, the impact will become clearer over time. Developers will judge the changes by how intuitive the Console feels, how reliable Monitoring proves to be, and whether the cycles-only model delivers the simplicity it promises. For now, the update marks a deliberate recalibration rather than a cosmetic refresh, grounded in lessons drawn from real-world use.
Dear Reader,
Ledger Life is an independent platform dedicated to covering the Internet Computer (ICP) ecosystem and beyond. We focus on real stories, builder updates, project launches, and the quiet innovations that often get missed.
We’re not backed by sponsors. We rely on readers like you.
If you find value in what we publish—whether it’s deep dives into dApps, explainers on decentralised tech, or just keeping track of what’s moving in Web3—please consider making a donation. It helps us cover costs, stay consistent, and remain truly independent.
Your support goes a long way.
🧠 ICP Principal: ins6i-d53ug-zxmgh-qvum3-r3pvl-ufcvu-bdyon-ovzdy-d26k3-lgq2v-3qe
🧾 ICP Address: f8deb966878f8b83204b251d5d799e0345ea72b8e62e8cf9da8d8830e1b3b05f
🪙 BTC Wallet: bc1pp5kuez9r2atdmrp4jmu6fxersny4uhnaxyrxau4dg7365je8sy2q9zff6p
Every contribution helps keep the lights on, the stories flowing, and the crypto clutter out.
Thank you for reading, sharing, and being part of this experiment in decentralised media.
—Team Ledger Life
