One of the most requested features for TypeScript serverless functions has always been the ability to make HTTP requests to external APIs.

That's now supported 🚀.

HTTP Requests​

Rust serverless functions have been able to reach out to the outside world via HTTPS for a while. That comes naturally since Rust functions leverage the ic_cdk, which is maintained by the DFINITY foundation for the Internet Computer and therefore, supports it out of the box.

On the other hand, TypeScript serverless functions are unique to Juno, so features are added incrementally.

Performing those kind of requests happens through a feature called HTTPS outcalls. Using it, you can extend your Satellite to fetch data, trigger webhooks, call third-party services, whatever your use case requires. In Juno's own codebase, it is used to send emails and fetch the public keys of the OpenID providers supported for authentication.

Making a Request​

Here's a simple example using the Dog CEO API to fetch a random dog image URL and return it directly from an update function:

import { defineUpdate } from "@junobuild/functions";
import { httpRequest, type HttpRequestArgs } from "@junobuild/functions/ic-cdk";
import { j } from "@junobuild/schema";

const DogSchema = j.strictObject({
  message: j.url(),
  status: j.string()
});

export const fetchRandomDog = defineUpdate({
  result: DogSchema,
  handler: async () => {
    const args: HttpRequestArgs = {
      url: "https://dog.ceo/api/breeds/image/random",
      method: "GET",
      isReplicated: false
    };

    const result = await httpRequest(args);

    const decoder = new TextDecoder();
    const body = decoder.decode(result.body);

    return JSON.parse(body);
  }
});

Define the function, call the API, use the result. That's it.

Transformer​

Some APIs return response headers that vary between nodes, timestamps, request IDs, and so on. In replicated mode, where the request is run multiple times and reconciled to ensure its validity, this can cause the call to fail if all responses do not match.

To handle this, you can define a transform function that sanitizes the response before the nodes compare it. A common pattern is to strip the headers entirely:

import { defineQuery, defineUpdate } from "@junobuild/functions";
import {
  httpRequest,
  HttpRequestResultSchema,
  TransformArgsSchema,
  type HttpRequestArgs
} from "@junobuild/functions/ic-cdk";
import { j } from "@junobuild/schema";

const DogSchema = j.strictObject({
  message: j.url(),
  status: j.string()
});

export const fetchRandomDog = defineUpdate({
  result: DogSchema,
  handler: async () => {
    const args: HttpRequestArgs = {
      url: "https://dog.ceo/api/breeds/image/random",
      method: "GET",
      isReplicated: true,
      transform: "trimHeaders"
    };

    const result = await httpRequest(args);

    const decoder = new TextDecoder();
    const body = decoder.decode(result.body);

    return JSON.parse(body);
  }
});

export const trimHeaders = defineQuery({
  hidden: true,
  args: TransformArgsSchema,
  result: HttpRequestResultSchema,
  handler: ({ response: { status, body } }) => ({
    status,
    body,
    headers: []
  })
});

The transform field references the name of an exported query function. Marking it hidden: true keeps it out of the auto-generated client API, it's an implementation detail, not something you'd call from the frontend.

Guards​

This release also ships support for guards that let you protect your functions with access control logic, restricting who can call them before the handler even runs.

import { defineQuery } from "@junobuild/functions";
import { callerIsAdmin } from "@junobuild/functions/sdk";

export const ping = defineQuery({
  guard: () => {
    throw new Error("No pong today");
  },
  handler: () => {
    console.log("Hello");
  }
});

export const hello = defineQuery({
  guard: callerIsAdmin,
  handler: () => {
    console.log("Hello, admin!");
  }
});

References​

Following sections of the documentation have been updated:

• Guides
• References

HTTP requests were a feature often requested and led a few developers to choose Rust for that reason. Really happy to finally ship this one and hopefully see more devs embrace the simplicity of using TypeScript.

To infinity and beyond
David

The idea behind Juno's serverless functions is that you should be able to write them in either Rust or TypeScript following the same pattern and mental model. Parts of those, hooks, have been available in TypeScript for a while and are handy for reacting to events. But developers also often want to define their own functions, akin to adding custom endpoints to an HTTP API. That wasn't supported in TypeScript, until now 🚀.

Custom Functions​

Custom functions let you define callable endpoints directly inside your Satellite, which can be explicitly invoked from your frontend or from other services.

There are two kinds.

A query is read-only. It returns data without touching any state, and it's fast. Use it when you just need to fetch something.

An update can read and write. Use it when your logic needs to persist data, trigger side effects, or when you need an absolute tamper-proof guarantee on the result.

import { defineQuery } from "@junobuild/functions";

export const ping = defineQuery({
  handler: () => "pong"
});

The functions can be described with optional arguments and results. They are strongly typed both at runtime and at build time thanks to a new type system, and their handlers can be synchronous or asynchronous.

import { defineUpdate } from "@junobuild/functions";
import { j } from "@junobuild/schema";

const ArgsSchema = j.strictObject({
  name: j.string()
});

const ResultSchema = j.strictObject({
  message: j.string()
});

export const myUpdate = defineUpdate({
  args: ArgsSchema,
  result: ResultSchema,
  handler: async ({ name }) => {
    // your logic here
    return { message: `Saved ${name}.` };
  }
});

Auto-generated Bindings​

Another part that makes this genuinely fun to use: when you build your project, a type-safe client API is automatically generated based on your function definitions. No glue code, no manual wiring, no thinking about serialization. Your functions are simply available through the functions namespace.

import { functions } from "../declarations/satellite/satellite.api.ts";

await functions.ping();
await functions.myUpdate({ name: "David" });

Define the shape on the backend, call it from the frontend with full type safety. That's it.

Schema Types​

Arguments and return types are optional, but when you need them, Juno provides a type system built on top of Zod to let you define their shapes.

import { j } from "@junobuild/schema";

Those schemas are validated at runtime and used at build time to generate all the necessary bindings. You define the shape once, you get safety everywhere.

const Schema = j.strictObject({
  name: j.string(),
  age: j.number()
});

Since you will likely need some environment-specific types, j extends Zod with j.principal() and j.uint8array().

const Schema = j.strictObject({
  owner: j.principal(),
  data: j.uint8array()
});

And when your function needs to handle multiple distinct input shapes, reach for discriminatedUnion:

import { defineUpdate } from "@junobuild/functions";
import { j } from "@junobuild/schema";

const Schema = j.discriminatedUnion("type", [
  j.strictObject({ type: j.literal("cat"), indoor: j.boolean() }),
  j.strictObject({ type: j.literal("dog"), breed: j.string() })
]);

export const registerPet = defineUpdate({
  args: Schema,
  handler: ({ args }) => {
    if (args.type === "cat") {
      // handle cat
    } else {
      // handle dog
    }
  }
});

Long story short, j is Zod with a few extras and everything you need to strongly type your functions.

References​

Following sections of the documentation have been updated:

• Development
• Guides
• References (SDK, schema, etc.)

I'm genuinely excited about these improvements and can totally see myself not using Rust for writing serverless functions in most of my projects in a near future. Not entirely there yet, HTTPS outcalls support in TypeScript is still coming, but getting there.

To infinity and beyond
David

Two new features ship in that direction: a new recommended approach for automating deployments via GitHub Actions, and support for GitHub authentication in your applications 🚀.

Automation Without Secrets​

Until now, setting up GitHub Actions to deploy your frontend or publish serverless functions required storing a JUNO_TOKEN in your GitHub secrets. It worked, but it came with the usual headaches, tokens to generate, rotate, and keep out of the wrong hands.

The new recommended approach uses OpenID Connect (OIDC). Instead of a static token, GitHub and your Satellite establish a trust relationship, and each workflow run gets short-lived credentials (access keys) automatically. Once the run is done, the credentials are gone.

No tokens to rotate. No secrets to manage. And if a workflow is ever compromised, there's nothing long-lived to steal.

To support this, a new Deployments screen has been added to the Console. This is where you configure which repositories are allowed to deploy to your Satellite and where you can review past deployments.

👉 Documentation

GitHub Authentication​

You can now add GitHub authentication to your application, letting your users sign in with their GitHub account, a natural fit for developer-facing apps.

Unlike other providers, GitHub does not natively support OpenID Connect. That's why this authentication requires a small proxy that handles the OAuth exchange securely to avoid exposing a client secret directly within your Satellite.

Juno provides an open-source API for this: github.com/junobuild/api. You self-host it, point your configuration to it, and from there the flow is straightforward, the user signs in, the proxy issues a JWT, your Satellite verifies it, and a session is created.

One thing to be aware of though: because the proxy signs JWTs with RSA keys, your Satellite needs access to those public keys to verify them. Rather than having each Satellite make HTTPS outcalls to your proxy on every request, Juno uses a shared infrastructure module called Observatory to fetch and cache those keys. Since you're self-hosting the proxy, you'll also need to deploy your own Observatory instance and configure it to point to your proxy's JWKS endpoint.

It's a bit tricky to set up but worth the effort if you're targeting developers. Reach out if you have questions, always happy to help!

👉 Documentation

One could argue that instead of improving the integration with GitHub, I should spin up custom infrastructure and provide the entire CI/CD for building and deploying. I wouldn't disagree. If the goal were to compete with cloud providers like AWS, Vercel, you name it, that would probably be the path. But devops is not really my thing, and that would be quite an effort both in terms of development and maintenance for the sole developer I am, who already takes care of a gigantic codebase 😅. Maybe someday, but honestly it feels unlikely as I doubt Juno will ever become a company.

Until then, I think this is a great step in the right direction - a tighter integration between Juno and the tools you already use day to day. Hope you find it useful too!

To infinity and beyond
David

We're kicking off 2026 with a major release that ships significant changes in the architecture and design of the Juno Console with a single goal: making the DX more straightforward and comprehensive.

Mission Control and Monitoring merged​

Mission Control was originally designed as a dedicated control center for developers — a place to create and manage projects (Satellites) and analytics (Orbiters). Over time, it was also extended to include Monitoring.

The original idea was simple: the Console would only know a developer's identity and their Mission Control ID — nothing else.

While this approach had advantages, it also introduced significant drawbacks.

On every new sign-up, the Console had to automatically create a Mission Control. This meant that when a developer signed in and created their first (free) project, Juno had to provision two containers instead of one, increasing infrastructure costs.

It also led to a confusing user experience. Mission Control could not be hidden from the UI because modules must be provisioned with resources (cycles) to avoid being decommissioned. As a result, it was always visible, and many developers were unsure what Mission Control was or why it existed.

For these reasons, Mission Control and Monitoring have now been merged:

• A Mission Control is created only when a developer explicitly enables Monitoring
• Monitoring is now treated as a dedicated microservice

This architectural change brings clear benefits:

• For developers: a clearer, more straightforward experience and simpler long-term maintenance
• For Juno: acquisition costs for new developers are effectively cut in half

There are a few trade-offs to note:

• The Juno Console now keeps track of all containers created by developers (Satellites, Orbiters, and Mission Controls), whereas previously it only knew the Mission Control ID.
• When Monitoring is enabled, module metadata must be duplicated inside the Mission Control so it knows what to monitor. This introduces a risk of inconsistencies if a bug causes a mismatch between the Console and Monitoring data. To mitigate this, a Console feature is planned to compare and verify this information.

Deprecate ICP, use only Cycles​

Over the past year, I've been refining both the platform and its communication to reinforce Juno's vision: a platform to build, deploy, and run applications in WASM containers, with ownership and zero DevOps.

As part of this effort, I've aimed to remove all blockchain and crypto-slangs.

While merging Mission Control and Monitoring, a new wallet ID - derived from the developer's sign-in - had to be introduced.

During this work, it became really clear again that the onboarding for new developers was just confusing:

Why do I need ICP to get cycles?

Since this release already introduced breaking changes, it felt like the right moment to simplify the model further.

As a result, ICP is now deprecated in favor of using cycles only.

This significantly simplifies the user journey:

• You start using Juno for free
• You learn about cycles as the resource that powers your containers and services
• When you need more resources or want to spin up additional modules, you acquire cycles

To support this, the primary call to action for acquiring cycles now points to cycle.express, which allows developers to convert dollars directly into cycles. Third-party wallets like OISY remain supported, but are now positioned as secondary options for users already familiar with them.

Together with the other changes in this release, this should make both the developer experience and the mental model of how Juno works much more approachable.

Price increase​

Previously, creating new Satellites or Orbiters cost 0.4 ICP. In practice, this was undervalued: each module is provisioned with 1.5 T cycles, while 0.4 ICP corresponds to roughly 0.93 T cycles—effectively a significant bonus.

Going forward:

• Additional Satellites and Orbiters cost 3 T cycles (roughly $4).
• Enabling Monitoring (which spins up a Mission Control) requires the same fee.

I believe these changes represent a significant step forward in making Juno more accessible and easier to understand. Whether you're just getting started or have been with us for a while, I hope these improvements make your development experience that much better.

To infinity and beyond
David

Juno is now fully open-source. No more AGPL. The project is now entirely released under the MIT license.

While all the tools were already licensed under MIT, the platform itself, a few crates, and the documentation were still released under AGPL. That worked well in the early days but can create friction for those who want to reuse Juno, or parts of it, in commercial projects or corporate environments. Plus, AGPL is not that cool, no? 😎

You can also consider this a small Christmas gift 🎁😉

Thank you to everyone who followed, tested, used, and supported Juno this year. I wish you a Merry Christmas and a fantastic New Year 2026.

You can find the source code on GitHub: 👉 https://github.com/junobuild/juno

Merry Christmas from Zürich 🎄
David

If you like working with ic-js in the frontend...
Say hello to serverless canister functions in TypeScript ⚡️

Write backend logic using the same TypeScript you already love — now with:

• 💫 Built-in canister clients for the Internet Computer (ICP, ICRC, CMC, NNS, SNS...)
• ⚙️ Full type-safety
• 🔌 Zero agent setup
• 🧠 Caller identity handled automatically
• 🍱 ICP & ICRC transfers from serverless hooks

No Rust required. No backend headaches.

📚 Documentation​

Want to go straight to the point? Checkout the 👉 references

Example​

Transfer ICP directly from a Satellite serverless function:

import { IcpLedgerCanister } from "@junobuild/functions/canisters/ledger/icp";

export const onExecute = async () => {
  const ledger = new IcpLedgerCanister();

  const result = await ledger.transfer({
    args: {
      to: "destination-account-identifier",
      amount: { e8s: 100_000_000n }, // 1 ICP
      fee: { e8s: 10_000n },
      memo: 0n
    }
  });
};

And yes - this works inside datastore hooks like onSetDoc and assertSetDoc, fully atomic.

Browse the full working example 👉 Making Canister Calls in TypeScript

Cool cool cool?

To infinity and beyond
David

A new release was shipped with two sweet improvements to the Console.

🌐 Custom Domains New API​

The hosting features for registering or administrating custom domains have been migrated to the API from the DFINITY Boundary Nodes team.

This migration makes managing domains:

• More reliable
• Significantly faster
• Future-proof

Massive kudos to the team delivering this capability - awesome work 💪

🚀 Registering custom domains for your hosting just got a major upgrade!

The new API is more reliable, faster, and future-proof.

Shout-out to the awesome @dfinity Boundary Nodes team 💪 pic.twitter.com/MSPC81AOoc

— Juno (@junobuild) November 19, 2025

✨ UI Improvements​

Alongside the domain upgrade, we shipped a few visual refinements:

Stronger contrast on cards and buttons for a cleaner, more readable interface (amazing what you can achieve by nudging brightness 😄)

The Launchpad has been slightly redesigned: "Create a new satellite" is now a primary button, bringing more clarity and guidance.

To infinity and beyond
David

Hey everyone 👋

Today marks quite a milestone and I'm excited to share that Google Sign-In is now live across the entire Juno ecosystem.

From my perspective, though time will tell, this update has the potential to be a real game changer. It brings what users expect: a familiar, secure, and frictionless authentication flow.

It might sound a bit ironic at first - we're integrating Google, after all - but I'm genuinely happy to ship this feature without compromising on the core values: providing developers secure features and modern tools with a state-of-the-art developer experience, while empowering them with full control over a cloud-native serverless infrastructure.

Let's see how it all comes together.

💡 Why It Matters​

Authentication is one of those things every product needs but, it's complex, it touches security, and it's easy to get wrong.

Until now on Juno, developers could use Internet Identity, which has its strengths but also its weaknesses. It provides an unfamiliar login flow - is it an authentication provider or a password manager? - and it's not a well-known product outside of its niche.

Passkeys were also added recently, but you only have to scroll through tech Twitter to see that for every person who loves them, there's another who absolutely hates them.

That's why bringing native Google Sign-In to Juno matters. Developers can now offer their users a familiar, frictionless login flow - and let's be honest, most people are used to this signing and don't care much about doing it differently.

At the same time, this doesn't mean giving up control. The authentication process happens entirely within your Satellite, using the OpenID Connect standard.

You can obviously combine multiple sign-in methods in one project, offering your users the choice that best fits their needs.

When it comes to Juno itself, this also matters for two reasons: it potentially makes onboarding - through the Console - more accessible for web developers who don't care about decentralization but do care about owning their infrastructure ("self-hosting"). And it opens the door to future integrations with other providers. I still hope one day to have a better GitHub integration, and this might be a step toward it.

Long story short, it might look like a trivial change - just a couple of functions and a bit of configuration - but it's another step toward Juno's long-term goal of making it possible to build and scale modern cloud products without compromising on what matters most: empowering developers and their users.

⚙️ How It Works​

When a user signs in with Google, Juno follows the OpenID Connect (OIDC) standard to keep everything secure and verifiable.

1. The user signs in with Google.
2. Google verifies their credentials and issues a signed OpenID Connect token.
3. After redirecting to your app, that signed token (JWT) is sent to your Satellite.
4. Inside the container, the token and its signature are verified, and the user's information (such as email or profile) is extracted.
5. The Satellite then creates a secure session for the user.
6. Once authenticated, the user can start interacting with your app built on top of your container's features.

🧩 Infrastructure​

At this point, you get the idea: aside from using Google as a third-party provider, there's no hidden “big tech” backend behind this. Everything else happens within your Satellite.

The credentials you configure - your Google project and OAuth 2.0 Client ID - are yours. In comparison, those used in Internet Identity are owned by the DFINITY Foundation. So, this approach might feel less empowering for end users or more empowering for developers. You can see the glass half full or half empty here.

To validate tokens on the backend, your container needs access to the public keys Google uses to sign them. Since those keys rotate frequently, fetching them directly would introduce extra cost and resource overhead.

That's why the Observatory - a shared module owned by Juno (well, by me) - comes in. It caches and provides Google's public keys, keeping verification fast, efficient, and cost-effective.

Because Juno is modular, developers who want full control or higher redundancy can run their own Observatory instance. Reach out if you're interested.

🪄 Setup Overview​

Getting started only takes a short configuration. Once your Google project is set up, add your Client ID to your juno.config file:

import { defineConfig } from "@junobuild/config";

export default defineConfig({
  satellite: {
    ids: {
      development: "<DEV_SATELLITE_ID>",
      production: "<PROD_SATELLITE_ID>"
    },
    source: "dist",
    authentication: {
      google: {
        clientId: "1234567890-abcde12345fghijklmno.apps.googleusercontent.com"
      }
    }
  }
});

Then apply it using the CLI or manually through the Console UI. That's it, it's configured.

🧑‍💻 Usage​

To add the sign-in to your app, it only takes a single function call - typically tied to a button like "Continue with Google".

import { signIn } from "@junobuild/core";

await signIn({ google: {} });

For now, it uses the standard redirect flow, meaning users are sent to Google and then redirected back to your app.

You'll just need to handle that callback on the redirect route with:

import { handleRedirectCallback } from "@junobuild/core";

await handleRedirectCallback();

I'll soon unleash support for FedCM (Federated Credential Management) as well.

Aside from that, nothing new - the rest works exactly the same.

Regardless of which authentication provider you're using, you can still track a user's authentication state through a simple callback:

import { onAuthStateChange } from "@junobuild/core";

onAuthStateChange((user: User | null) => {
  console.log("User:", user);
});

And because type safety is the way, you can now safely access provider-specific data without writing endless if statements:

import { isWebAuthnUser, isGoogleUser } from "@junobuild/core";

if (isWebAuthnUser(user)) {
  console.log(user.data.providerData.aaguid); // Safely typed ✅
}

if (isGoogleUser(user)) {
  console.log(user.data.providerData.email); // Safely typed ✅
}

🛠️ Managing Users​

Once users start signing in, you can view and manage them directly in the Authentication section of the Console.

Each user entry displays key details such as:

• Name and email address
• Authentication provider
• Profile picture (if available)

This view also lets you filter, sort, refresh or ban users etc.

📚 Learn More​

You can find all the details - including setup, configuration, and advanced options - in the documentation:

• Google Authentication
• Authentication Overview

If you haven't tried Juno yet, head over to console.juno.build and sign in with Google to get started.

Ultimately, I can tell you stories, but nothing beats trying it yourself.

To infinity and beyond,
David

Reach out on Discord or OpenChat for any questions.

Stay connected with Juno on X/Twitter.

⭐️⭐️⭐️ stars are also much appreciated: visit the GitHub repo and show your support!

I tagged a new release as I deployed a new version of the Console UI to mainnet.

Aside from the updated navigation, which now displays the page title within breadcrumb-style navigation, and a few minor fixes, not much has changed feature-wise.

The biggest change in the frontend's codebase, which explains why so many files were touched, is a refactor to adopt the new pattern I’ve been using for DID declarations.

Instead of relying on auto-imported separate types, I now prefer grouping factories in a single module, exporting them from there, and importing the types through a suffixed module DID alias.

You can check out the pattern in Juno's frontend codebase or in the ic-client JS library. If you're curious about it, let me know.

It’s a small structural shift that makes the code much cleaner and more readable.

Finally, there are a few new E2E tests added in this repo and in the CLI.

To infinity and beyond 🍞✨
David

Here is a small but handy update for your toolbox: you can now download and upload snapshots offline with the Juno CLI. 🧰

That means you can:

• Keep a local copy of your module’s state
• Stash it somewhere safe, just in case 😅
• Restore it when needed
• Or even move it between Satellites

juno snapshot download --target satellite
juno snapshot upload --target satellite --dir .snapshots/0x00000060101

👋 No Juno livestream today, but here's a little gift for your toolbox.

You can now download and upload snapshots OFFLINE with the CLI. 🧰💾 pic.twitter.com/IW5jHyEBTD

— Juno (@junobuild) October 6, 2025

Build custom scripts that already know your env, profile & config.
Write them in JS/TS.
Run with the CLI. ⚡️

🍒 on top? Works out of the box in GitHub Actions!

For example:

import { defineRun } from "@junobuild/config";

export const onRun = defineRun(({ mode, profile }) => ({
  run: async ({ satelliteId, identity }) => {
    console.log("Running task with:", {
      mode,
      profile,
      satelliteId: satelliteId.toText(),
      whoami: identity.getPrincipal().toText()
    });
  }
}));

Run it with:

juno run --src ./my-task.ts

Now, let’s suppose you want to fetch a document from your Satellite’s Datastore (“from your canister’s little DB”) and export it to a file:

import { getDoc } from "@junobuild/core";
import { defineRun } from "@junobuild/config";
import { jsonReplacer } from "@dfinity/utils";
import { writeFile } from "node:fs/promises";

export const onRun = defineRun(({ mode }) => ({
  run: async (context) => {
    const key = mode === "staging" ? "123" : "456";

    const doc = await getDoc({
      collection: "demo",
      key,
      satellite: context
    });

    await writeFile("./mydoc.json", JSON.stringify(doc, jsonReplacer, 2));
  }
}));

Fancy ✨

And since it’s TS/JS, you can obviously use any libraries to perform admin tasks as well.

import { defineRun } from "@junobuild/config";
import { IcrcLedgerCanister } from "@dfinity/ledger-icrc";
import { createAgent } from "@dfinity/utils";

export const onRun = defineRun(({ mode }) => ({
  run: async ({ identity, container: host }) => {
    if (mode !== "development") {
      throw new Error("Only for fun!");
    }

    const agent = await createAgent({
      identity,
      host
    });

    const { metadata } = IcrcLedgerCanister.create({
      agent,
      canisterId: MY_LEDGER_CANISTER_ID
    });

    const data = await metadata({});

    console.log(data);
  }
}));

Coolio?

I’ll demo it next Monday in Juno Live. 🎥 https://youtube.com/@junobuild

Happy week-end ☀️

A new release is out — v0.0.57 🚀

✨ Host your frontend on heap or stable memory
🔑 Internet Identity login with https://id.ai
🦖 Fixes & improvements

Release notes 👉 Release v0.0.57 · junobuild/juno

A new release is out — v0.0.56 🚀

This release focuses on frontend changes in the Console:

• You can now label your Satellites with environment flags and tags. These appear in the launchpad, switcher, and overview. On the launchpad, they can also be used as search filters to quickly find the right Satellite.
• A new navigation feature – called “Spotlight” or “Quick Access” – lets you jump anywhere in the Console or run actions (such as changing the theme) in seconds. Open it with the search icon in the navbar or by pressing Ctrl/Cmd + K.

Hopefully these make building with the Console a little more fun (and faster)!

Authentication is a core part of building any app. Until now, developers on Juno have relied on third-party providers like Internet Identity and NFID. Today we're providing a new option: Passkeys.

This new authentication option is available to all developers using the latest Juno SDK and requires the most recent version of your Satellite containers. You can now enable Passkeys alongside existing providers, and the JavaScript SDK has been updated to make authentication APIs more consistent across sign-in, sign-out, and session management.

🔑 What Are Passkeys?​

Passkeys are a passwordless authentication method built into modern devices and browsers. They let users sign up and sign in using secure digital keys stored in iCloud Keychain, Google Password Manager, or directly in the browser with Face ID, Touch ID, or a simple device unlock instead of a password.

Under the hood, Passkeys rely on the WebAuthn standard and the web API that enables browsers and devices to create and use cryptographic credentials. Passkeys are essentially a user-friendly layer on top of WebAuthn.

When stored in a password manager like iCloud Keychain or Google Password Manager, passkeys sync across a user’s devices, making them more resilient, though this does require trusting the companies that provide those services. If stored only in the browser, however, they can be lost if the browser is reset or uninstalled.

The good news is that most modern platforms already encourage syncing passkeys across devices, which makes them convenient for everyday use, giving users a smooth and safe way to log into applications.

🤔 Choosing Between Providers​

Each authentication method has its strengths and weaknesses. Passkeys provide a familiar, device-native login experience with Face ID, Touch ID, or device unlock, relying on either the browser or a password manager for persistence. Internet Identity and NFID, on the other hand, offer privacy-preserving flows aligned with the Internet Computer, but they are less familiar to mainstream users and involve switching context into a separate window.

In practice, many developers will probably combine Passkeys and Internet Identity side by side, as we do in the starter templates we provide.

Ultimately, the right choice depends on your audience and product goals, balancing usability, privacy, and ecosystem integration.

🚀 How to Use Passkeys​

Using the new Passkeys in your app should be straightforward with the latest JavaScript SDK.

To register a new user with a passkey, you call signUp with the webauthn option:

import { signUp } from "@junobuild/core";

await signUp({
  webauthn: {}
});

For returning users, signIn works the same way, using the passkey they already created:

import { signIn } from "@junobuild/core";

await signIn({
  webauthn: {}
});

As you can notice, unlike with existing third-party providers, using Passkeys requires a distinct sign-up and sign-in flow. This is because the WebAuthn standard is designed so that an app cannot know in advance whether the user has an existing passkey, and this is intentional for privacy reasons. Users must therefore explicitly follow either the sign-up or sign-in path.

It is also worth noting that during sign-up, the user will be asked to use their authenticator twice:

• once to create the passkey on their device
• and once again to sign the session that can be used to interact with your Satellite.

Given these multiple steps, we added an onProgress callback to the various flows. This allows you to hook into the progression and update your UI, for example to show a loading state or step indicators while the user completes the flow.

import { signUp } from "@junobuild/core";

await signUp({
  webauthn: {
    options: {
      onProgress: ({ step, state }) => {
        // You could update your UI here
        console.log("Progress:", step, state);
      }
    }
  }
});

🛠️ Updates to the SDK​

Alongside introducing Passkeys, we also took the opportunity to clean up and simplify the authentication APIs in the JavaScript SDK.

Mandatory provider in signIn​

Previously, calling signIn() without arguments defaulted to Internet Identity. With the introduction of Passkeys, we decided to drop the default. From now on, you must explicitly specify which provider to use for each sign-in call. This makes the API more predictable and avoids hidden assumptions.

In earlier versions, providers could also be passed as class objects. To prevent inconsistencies and align with the variant pattern used across our tooling, providers (and their options) must now be passed through an object.

import { signIn } from "@junobuild/core";

// Internet Identity
await signIn({ internet_identity: {} });

// NFID
await signIn({ nfid: {} });

// Passkeys
await signIn({ webauthn: {} });

Page reload on signOut​

By default, calling signOut will automatically reload the page (window.location.reload) after a successful logout. This is a common pattern in sign-out flows that ensures the application restarts from a clean state.

If you wish to opt out, the library still clears its internal state and authentication before the reload, and you can use the windowReload option set to false:

import { signOut } from "@junobuild/core";

await signOut({ windowReload: false });

authSubscribe renamed to onAuthStateChange​

To make the API more consistent with the industry standards, we introduced a new method called onAuthStateChange. It replaces authSubscribe, which is now marked as deprecated but will continue to work for the time being.

The behavior remains the same: you can reactively track when a user signs in or out, and unsubscribe when you no longer need updates.

import { onAuthStateChange } from "@junobuild/core";

const unsubscribe = onAuthStateChange((user) => {
  console.log("User:", user);
});

// Later, stop listening
unsubscribe();

📚 Learn More​

Passkeys are now available, alongside updates to the authentication JS APIs. With passwordless sign-up and sign-in built into modern devices, your users get a smoother experience.

Check out the updated documentation for details on:

• signUp
• signIn
• signOut
• onAuthStateChange

👀 What's Next​

Passkeys are available today for developers building with Satellite containers and the JavaScript SDK.

Next, we'll bring Passkey support directly into the Console UI, so new developers can register easily and you can too.

To infinity and beyond,
David

Stay connected with Juno by following us on X/Twitter.

Reach out on Discord or OpenChat for any questions.

⭐️⭐️⭐️ stars are also much appreciated: visit the GitHub repo and show your support!

A new release is out — v0.0.54 🚀

Here are a few highlights:

⚡️ Faster deploys with proposals batching
📦 Smarter precompression (optional Brotli + replace mode)
🔀 Redirects fixed
✨ Shinier experience when deploying in your terminal

Checkout the release notes for details 👉 Release v0.0.54 · junobuild/juno

Example of the new configuration option precompress:

export default defineConfig({
  satellite: {
    ids: {
      production: "qsgjb-riaaa-aaaaa-aaaga-cai"
    },
    source: "dist",
    precompress: {
      algorithm: "brotli",
      pattern: "**/*.+(css|js|mjs|html)",
      mode: "replace"
    }
  }
});

A new release is out — v0.0.52 🚀

Here are a few highlights:
🧊 Longer default freezing thresholds
✅ Gzipped HTML
🔐 Allowed Callers
🛠 CLI Improvements
🖥 Polished Console UI

Checkout the release notes for details 👉 Release v0.0.52 · junobuild/juno

Let me know if anything looks fishy — and happy coding! 👨‍🔧

🖥️ Two screenshots from the Console new features

The new “Notifications” component:

The overall look: collapsible menu, redesigned tabs, more prominent actions, and more.

As a side note on this 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:

import { defineConfig } from "@junobuild/config";

/** @type {import('@junobuild/config').JunoConfig} */
export default defineConfig({
  satellite: {
    ids: {
      development: "jx5yt-yyaaa-aaaal-abzbq-cai",
      production: "fmkjf-bqaaa-aaaal-acpza-cai"
    },
    source: "build",
    predeploy: ["npm run build"],
    storage: {
      headers: [
        {
          source: "**/*.png",
          headers: [["Cache-Control", "max-age=2592000"]]
        }
      ]
    },
    collections: {
      datastore: [
        {
          collection: "notes",
          read: "managed",
          write: "managed",
          memory: "stable"
        }
      ]
    }
  },
  emulator: {
    runner: {
      type: "podman"
    },
    satellite: {}
  }
});

Documentation 👉 https://juno.build/docs/reference/configuration

One of the principles that shaped Juno from day one was the idea of building apps with full ownership — no hidden infrastructure, no opaque servers.

No hypocrisy either.

If developers are encouraged to deploy code in containers they control, it feels inconsistent to rely on centralized infrastructure — like AWS or other Web2 cloud providers — to manage deployment pipelines or run the platform. With the exception of email notifications, Juno currently runs entirely on the Internet Computer — and that's a deliberate choice.

That doesn't mean being stubborn for the sake of it. It just means trying to push things forward without falling back on the old way unless absolutely necessary.

At the same time, developer experience matters — a lot. It shouldn't take a degree in DevOps to ship a backend function. Developers who would typically reach for a serverless option should be able to do so here too. And for those who prefer to stay local, it shouldn't feel like a downgrade — no one should be forced into CI automation if they don't want to.

That's why the new GitHub Actions for serverless functions are now generally available — for those who want automation, not obligation.

🚀 Automated Deployments, No Compromise​

With the latest release, it's now possible to:

• Build serverless functions written in TypeScript or Rust
• Automatically publish them to a Satellite
• Optionally propose or directly apply upgrades

All within a GitHub Actions workflow. No manual builds, no extra setup — just code, commit, and push.

This makes it easier to fit Juno into an existing CI/CD pipeline or start a new one from scratch. The logic is bundled, metadata is embedded, and the container is ready to run.

🔐 What About Security?​

You might ask yourself: "But what about the risk of giving CI full control over my infrastructure?"

That's where the improved access key (previously named "Controllers") roles come in.

Instead of handing over the master key, you give CI just enough access to do its job — and nothing more.

Here's how the roles break down in plain terms:

• Administrator – Full control. Can deploy, upgrade, stop, or delete any module. Powerful, but risky for automation. Might be useful if you're spinning up test environments frequently.

• Editor (Write) – Ideal for CI pipelines that deploy frontend assets or publish serverless functions. Can't upgrade those or stop and delete modules. A good default.

• Submitter 🆕 – The safest option. Can propose changes but not apply them. Someone still needs to review and approve in the Console or CLI. No surprises, no accidents.

Use Editor for most CI tasks — it gives you automation without opening the blast radius.

Prefer an extra layer of review? Go with Submitter and keep a human in the loop.

🧰 Local or CI: Your Choice​

Nothing changes in the approach for developers who prefer local development. The CLI remains a first-class tool for building and deploying.

All the new capabilities — from publishing functions to proposing or applying upgrades — are available not just in GitHub Actions or the Console UI, but also fully supported in the CLI.

In fact, the CLI has been improved with a neat addition: you can now append --mode development to interact with the emulator. This allows you to fully mimic production behavior while developing locally. And of course, you can also use any mode to target any environment.

juno functions upgrade --mode staging
juno deploy --mode development

🛰️ Satellite's CDN​

While building serverless functions was never an issue, enabling GitHub Actions to publish and deploy without giving away full control introduced a challenge. How do you let CI push code without handing it the keys to everything?

That's where the idea of a sort of CDN came in.

Each Satellite now has a reserved collection called #_juno/releases. It's like a staging area where CI can submit new WASM containers or frontend assets. If the access key has enough privileges, the submission is deployed right away. If not, it's stored as a pending change — waiting for someone to approve it manually via the Console or CLI.

This builds on the change-based workflow that was added to the Console last year. Funny enough, it brought the Console so close to being a Satellite itself that it became... basically a meta example of what you can build with Juno.

And here's the cherry on top: because there's now a CDN tracking versions, developers can rollback or switch between different function versions more easily. A new CDN tab in the Console UI (under Functions) gives you access to all past versions and history.

🖼️ Frontend Deployments, Too​

Frontend deployment now benefits from the same change-based workflow. By default, when you run juno deploy or trigger a GitHub Action, the assets are submitted as pending changes — and applied automatically (if the access key allows it).

Want to skip that workflow? You still can. The immediate deployment path remains available — handy if something fails, or if you just prefer to keep things simple.

🛠️ GitHub Actions for Serverless Functions​

Alright, enough chit-chat — here's how to publish your serverless functions on every push to main, straight from CI:

name: Publish Serverless Functions

on:
  workflow_dispatch:
  push:
    branches: [main]

jobs:
  publish:
    runs-on: ubuntu-latest
    steps:
      - name: Check out the repo
        uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 24
          registry-url: "https://registry.npmjs.org"

      - name: Install Dependencies
        run: npm ci

      - name: Build
        uses: junobuild/juno-action@full
        with:
          args: functions build

      - name: Publish
        uses: junobuild/juno-action@full
        with:
          args: functions publish
        env:
          JUNO_TOKEN: ${{ secrets.JUNO_TOKEN }}

🌸 One Action, Two Flavors​

Noticed the @full in the previous step?

That's because the GitHub Action now comes in two flavors:

• junobuild/juno-action or junobuild/juno-action@slim – perfect for common use cases like deploying frontend assets or running simpler CLI tasks. No serverless build dependencies included, so it's faster and more "lightweight" (relatively, it still uses Docker underneath...).

• junobuild/juno-action@full – includes everything you need to build and publish serverless functions, with Rust and TypeScript support. It's heavier, but it does the job end to end.

The right tool for the right job. Pick what fits.

🧭 Where This Is Going​

This release isn't just about smoother deployments — it's a step toward making Juno feel like real infrastructure. Though, what is “real infrastructure” anyway? Whatever it is, this one doesn't come with the usual baggage.

Developers get to choose how they ship — locally or through CI. They get to decide what gets deployed and who can do it. They're not forced to rely on some big tech platform for their infra if they don't want to. And thanks to the new CDN and access control model, fast iteration and tight control can finally go hand in hand.

If you've been waiting for a way to ship backend logic without giving up on decentralization — or if you just like things working smoothly — this one's for you.

Go ahead. Build it. Push it. Submit it. Ship it.

To infinity and beyond,
David

Stay connected with Juno by following us on X/Twitter.

Reach out on Discord or OpenChat for any questions.

⭐️⭐️⭐️ stars are also much appreciated: visit the GitHub repo and show your support!

A new release v0.0.50 is out! 🚀

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.

Enjoy! 🧪📊

• Docs 👉 https://juno.build/docs/build/analytics/
• Release notes 👉 https://github.com/junobuild/juno/releases/tag/v0.0.50

The main change is the addition of a new Health Check section under “Monitoring”, along with a clearer breakdown of memory metrics.

I also revisited the notion of the “auto-refill threshold”, as the previous description was misleading or partial.

Lastly, the step related to the “authentication domain” in the hosting wizard has been simplified.

All these changes are, of course, documented.

• Monitoring
• Freezing Threshold
• Domain based User Identity

Happy weekend ☀️

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 ⚠️.

Reach out if you have questions, happy to help!