Morning! Great news for the Juno community, which has always used identity.internetcomputer.org as the default domain for authentication.
Internet Identity now supports passkeys on both of its domains!
This means it should no longer matters whether devs or users sign in via identity.internetcomputer.org or identity.ic0.app — the registered identity should work seamlessly across both. There are a few limitations, which is why II may prompt you to register your current device.
As a result, I’ve just launched a new, clean sign-in page with a single call to action!
To address potential sign-in issues, the page still offers domain-specific methods as a fallback. Plus, I added a brand-new footer accessible on scroll—kind of really happy with that design.
I spent the last two days reviewing the Juno CLI and all admin tasks—init, config, deploy, upgrade, etc.—and I can confirm that it is now fully supported on Windows (without WSL)!
Local development features still need some love, and I plan to work on them in the coming weeks.
A new version of the CLI is out, and it includes a breaking change: the juno backup command has been renamed to snapshot because what I originally called “backup” wasn’t really a backup but snapshot as described and provided on the IC. I still need to document the reasoning behind this change.
This release also improves the CLI’s behavior by displaying the correct follow-up commands after running juno init, based on your package manager—since, yeah, yarn and pnpm have both been supported for a while now.
Additionally, I bumped the required version of ic-wasm to v0.8.5 for those developing serverless functions (still not happy that devs need to install these tools on their sides, but I’m exploring ways to improve DX).
Lastly, I added a comment in the function template to clarify that Satellite modules are initialized with all hooks by default, but for readability, you can select only a subset (as already documented).
// All the available hooks and assertions for your Datastore and Storage are scaffolded by default in this `lib.rs` module.
// However, if you don’t have to implement all of them, for example to improve readability or reduce unnecessary logic,
// you can selectively enable only the features you need.
//
// To do this, disable the default features in your `Cargo.toml` and explicitly specify only the ones you want to use.
//
// For example, if you only need `on_set_doc`, configure your `Cargo.toml` like this:
//
// [dependencies]
// junobuild-satellite = { version = "0.0.22", default-features = false, features = ["on_set_doc"] }
//
// With this setup, only `on_set_doc` must be implemented with custom logic,
// and other hooks and assertions can be removed. They will not be included in your Satellite.
#[on_set_doc]
async fn on_set_doc(_context: OnSetDocContext) -> Result<(), String> {
Ok(())
}
// etc.
Hey! I shipped a change in the local development approach.
By default, devs on Juno now get a full environment that closely mirrors production — including the Console UI — running entirely on their machine inside a container.
I believe there’s real value in mimicking the production experience as closely as possible during development. And compared to most common cloud platforms, that’s something pretty special.
Plus, it’s genuinely fun to have everything running locally without the setup headache.
Got Node.js and Docker? Run juno dev start — that’s it.
I rolled out the change along with updates to the documentation, templates, and tooling. Also started adding little handy touches, like a “Get ICP” button directly in the local wallet.
Easter, everything’s quiet, so I finally wrapped up the latest Juno release.
This update includes the support for TypeScript serverless functions, a redefined local developer experience (as announced last week), and lay the foundation for a more future-proof module metadata.
No modules (Satellites, etc.) are included in the release, so there’s no rush to upgrade anything on that side. But on the tooling side… I went absolutely bananas . Feel free to update your tools!
This new release brings a major upgrade to Juno Analytics — now powered by native HTTP requests with no more web workers or IndexedDB.
The JS client is now over 90% () smaller (just 3KB gzipped!), and the dashboard supports paginated views, top time zones, and OS metrics.
There are a few breaking changes (), so check the notes if you’re using analytics — and make sure to upgrade your Orbiter and JS libraries at the same time .
I just published a new version of the Juno Docker setup. All images — Skylab, Satellite, and Console — have been updated to include the latest Internet Computer canisters (ICP Ledger, Index, Internet Identity, Governance, and CMC).
If you upgrade these images, you might encounter issues when restarting your environment. For example:
Canister called ic0.trap with message: 'Panicked at 'Cannot upgrade from scratch stable memory, please upgrade to memory manager first.', rs/ledger_suite/icp/ledger/src/main.rs:788:13'.
I’ve assumed it’s acceptable not to handle these types of upgrades explicitly, at least this time as I don’t mind doing a bit of Docker cleanup from time to time to free up space and don’t know anyone who mentionning before have a super important local state. But if that assumption is off, please let me know.
In other words, it’s adviced to start after upgrade with a clean volume state.
This one brings two improvements to the Analytics:
Campaign tracking is now supported! Just use standard UTM tags in your links — traffic sources like newsletters, ads, and social posts will show up directly in your dashboard. No extra setup needed.
# For example
https://myapp.com/?utm_source=newsletter&utm_medium=email&utm_campaign=spring-launch
Bot detection has also been improved by using HTTP headers directly from the container smart contract (instead of those passed in the requests). More accurate and secure that way.
Build and publish serverless functions from GitHub Actions Deploy your frontend using the new change-based flow “Controllers” are now called Access Keys (finally less confusing!) New Upgrade Dock in the Console to review all upgrades shipped by Juno New CDN for functions — easily switch or roll back versions of your code View system collections in Storage (super handy to browse your deployed frontend assets) Monitoring can now send you an email if top-up fails
Give it a spin — and as always, shout if something breaks (or if you just love it)
A few fresh screenshots from the Console new features
Let’s start with a new Upgrade Dock to find all upgrades shipped by Juno
This is a really cool feature.
Although, I didn’t find it intuitive that I have to click on the ... button next to the “Collections” title to see the option:
Haha, me neither . I just didn’t have a better idea to add the action relatively cheaply without breaking the all interface . If you or anyone has an idea that fits gracefully into the design, let me know!
And the cherry on top? You don’t even need to create a Juno project to use it .
If you have the CLI installed (npm i -g @junobuild/cli) and Docker, you can spin up a local container that runs PocketIC, along with the Juno Console, Internet Identity, Ledger ICP, and the CMC — all out of the box!
This week I released @junobuild/core JS library v1.0.0!
After many releases and tweaks, the API hasn’t changed much lately, so I’d say it’s stable enough .
From now on: proper semantic versioning .
Cherry on top: as of this version, any read call accepts an optional certified parameter, allowing you to fetch data using update calls — for those of you who care about security.
As a side note on yesterday’s release: aside from the custom domain feature, I think it’s now possible to configure your entire project — including authentication, data, storage, and emulator — directly within the Juno config file. Plus with type safety as the cherry on top.
This is especially handy for maintainability or if your project can be forked.
Here’s an example config that shows where and how the project is deployed, which headers to apply to assets, defines the structure of that data, and which image to use when running the emulator with Podman:
Create Juno just got a big upgrade!
Local dev is now the default for apps (!)
Scaffold serverless functions
Sputnik preview (WIP)
Updated all template dependencies
Onboarding revamped
. Feel free to update your tools! 
) smaller (just 3KB gzipped!), and the dashboard supports paginated views, top time zones, and OS metrics.
), so check the notes if you’re using analytics — and make sure to upgrade your Orbiter and JS libraries at the same time 
.
Say hello to the new memory metrics and radar chart - now live in the 
Campaign tracking is now supported! Just use standard UTM tags in your links — traffic sources like newsletters, ads, and social posts will show up directly in your dashboard. No extra setup needed.
Bot detection has also been improved by using HTTP headers directly from the container smart contract (instead of those passed in the requests). More accurate and secure that way.
Deploy your frontend using the new change-based flow
“Controllers” are now called Access Keys (finally less confusing!)
New Upgrade Dock in the Console to review all upgrades shipped by Juno
View system collections in Storage (super handy to browse your deployed frontend assets)
Monitoring can now send you an email if top-up fails
A few fresh screenshots from the Console new features
. I just didn’t have a better idea to add the action relatively cheaply without breaking the all interface 
. If you or anyone has an idea that fits gracefully into the design, let me know!
Updated to the latest framework (Angular, React, Next.js, SvelteKit, Vue, Astro, and Vanilla)
GitHub Actions template to publish your Serverless functions added
Bonus: something new for local dev ! 
.
.
New navbar design
Collapsible menu (space saver)
Top-up and friends, easier to spot
Longer default freezing thresholds
