Juno Upgrades GitHub Integration With OIDC Deployments and Native Sign In

Juno has rolled out an upgraded GitHub integration aimed at simplifying deployments and bringing authentication closer to the workflows developers already use.

The update removes the need for storing static GitHub secrets when deploying through GitHub Actions. Previously, developers were required to generate and manage a JUNO_TOKEN, adding operational overhead and the risk associated with long lived credentials.

The new recommended approach uses OpenID Connect. Instead of relying on a fixed token, GitHub and a Juno Satellite establish a trust relationship. Each workflow run receives short lived credentials that expire automatically once the job is complete. There are no tokens to rotate and no persistent secrets stored in repositories. If a workflow were compromised, there would be no standing credential left behind.

To support the change, Juno has introduced a Deployments screen within its Console interface. Developers can configure which GitHub repositories are authorised to deploy to a given Satellite and review past deployment activity. For those who prefer working from the command line, the same configuration options remain available through the CLI.

Alongside deployment changes, Juno now supports GitHub authentication for applications built on the platform. This allows end users to sign in with their GitHub accounts, a feature that aligns naturally with developer focused products.

Because GitHub does not natively support OpenID Connect for authentication in this context, Juno’s implementation relies on a small self hosted proxy that manages the OAuth exchange. The proxy issues a JSON Web Token after successful authentication. The Satellite verifies the token and creates a session for the user.

The setup requires additional infrastructure. Since the proxy signs tokens using RSA keys, the Satellite must access the corresponding public keys to verify them. Rather than forcing each Satellite to make repeated outbound calls, Juno uses a shared module called Observatory to fetch and cache the keys. Developers self hosting the proxy are also required to deploy their own Observatory instance and configure it to point to the proxy’s key endpoint.

The configuration may demand more effort than plug and play authentication services offered elsewhere. Yet the approach reflects a broader philosophy. Rather than attempting to replicate the full stack CI and CD environments provided by larger cloud platforms, Juno is focusing on tighter integration with tools developers already rely on, particularly GitHub.

The project’s creator acknowledged that building a fully managed deployment platform could be another route. Competing directly with established cloud providers would, however, require sustained infrastructure development and maintenance. For now, the emphasis is on improving compatibility and reducing friction within existing workflows.

For developers building products aimed at other developers, GitHub remains the centre of daily activity. By aligning more closely with that environment, Juno is positioning itself as a platform that adapts to established habits rather than asking teams to rework them.

Juno has rolled out an upgraded GitHub integration aimed at simplifying deployments and bringing authentication closer to the workflows developers already use.

The update removes the need for storing static GitHub secrets when deploying through GitHub Actions. Previously, developers were required to generate and manage a JUNO_TOKEN, adding operational overhead and the risk associated with long lived credentials.

The new recommended approach uses OpenID Connect. Instead of relying on a fixed token, GitHub and a Juno Satellite establish a trust relationship. Each workflow run receives short lived credentials that expire automatically once the job is complete. There are no tokens to rotate and no persistent secrets stored in repositories. If a workflow were compromised, there would be no standing credential left behind.

To support the change, Juno has introduced a Deployments screen within its Console interface. Developers can configure which GitHub repositories are authorised to deploy to a given Satellite and review past deployment activity. For those who prefer working from the command line, the same configuration options remain available through the CLI.

Alongside deployment changes, Juno now supports GitHub authentication for applications built on the platform. This allows end users to sign in with their GitHub accounts, a feature that aligns naturally with developer focused products.

Because GitHub does not natively support OpenID Connect for authentication in this context, Juno’s implementation relies on a small self hosted proxy that manages the OAuth exchange. The proxy issues a JSON Web Token after successful authentication. The Satellite verifies the token and creates a session for the user.

The setup requires additional infrastructure. Since the proxy signs tokens using RSA keys, the Satellite must access the corresponding public keys to verify them. Rather than forcing each Satellite to make repeated outbound calls, Juno uses a shared module called Observatory to fetch and cache the keys. Developers self hosting the proxy are also required to deploy their own Observatory instance and configure it to point to the proxy’s key endpoint.

The configuration may demand more effort than plug and play authentication services offered elsewhere. Yet the approach reflects a broader philosophy. Rather than attempting to replicate the full stack CI and CD environments provided by larger cloud platforms, Juno is focusing on tighter integration with tools developers already rely on, particularly GitHub.

The project’s creator acknowledged that building a fully managed deployment platform could be another route. Competing directly with established cloud providers would, however, require sustained infrastructure development and maintenance. For now, the emphasis is on improving compatibility and reducing friction within existing workflows.

For developers building products aimed at other developers, GitHub remains the centre of daily activity. By aligning more closely with that environment, Juno is positioning itself as a platform that adapts to established habits rather than asking teams to rework them.

Juno has rolled out an upgraded GitHub integration aimed at simplifying deployments and bringing authentication closer to the workflows developers already use.

The update removes the need for storing static GitHub secrets when deploying through GitHub Actions. Previously, developers were required to generate and manage a JUNO_TOKEN, adding operational overhead and the risk associated with long lived credentials.

The new recommended approach uses OpenID Connect. Instead of relying on a fixed token, GitHub and a Juno Satellite establish a trust relationship. Each workflow run receives short lived credentials that expire automatically once the job is complete. There are no tokens to rotate and no persistent secrets stored in repositories. If a workflow were compromised, there would be no standing credential left behind.

To support the change, Juno has introduced a Deployments screen within its Console interface. Developers can configure which GitHub repositories are authorised to deploy to a given Satellite and review past deployment activity. For those who prefer working from the command line, the same configuration options remain available through the CLI.

Alongside deployment changes, Juno now supports GitHub authentication for applications built on the platform. This allows end users to sign in with their GitHub accounts, a feature that aligns naturally with developer focused products.

Because GitHub does not natively support OpenID Connect for authentication in this context, Juno’s implementation relies on a small self hosted proxy that manages the OAuth exchange. The proxy issues a JSON Web Token after successful authentication. The Satellite verifies the token and creates a session for the user.

The setup requires additional infrastructure. Since the proxy signs tokens using RSA keys, the Satellite must access the corresponding public keys to verify them. Rather than forcing each Satellite to make repeated outbound calls, Juno uses a shared module called Observatory to fetch and cache the keys. Developers self hosting the proxy are also required to deploy their own Observatory instance and configure it to point to the proxy’s key endpoint.

The configuration may demand more effort than plug and play authentication services offered elsewhere. Yet the approach reflects a broader philosophy. Rather than attempting to replicate the full stack CI and CD environments provided by larger cloud platforms, Juno is focusing on tighter integration with tools developers already rely on, particularly GitHub.

The project’s creator acknowledged that building a fully managed deployment platform could be another route. Competing directly with established cloud providers would, however, require sustained infrastructure development and maintenance. For now, the emphasis is on improving compatibility and reducing friction within existing workflows.

For developers building products aimed at other developers, GitHub remains the centre of daily activity. By aligning more closely with that environment, Juno is positioning itself as a platform that adapts to established habits rather than asking teams to rework them.

Juno has rolled out an upgraded GitHub integration aimed at simplifying deployments and bringing authentication closer to the workflows developers already use.

The update removes the need for storing static GitHub secrets when deploying through GitHub Actions. Previously, developers were required to generate and manage a JUNO_TOKEN, adding operational overhead and the risk associated with long lived credentials.

The new recommended approach uses OpenID Connect. Instead of relying on a fixed token, GitHub and a Juno Satellite establish a trust relationship. Each workflow run receives short lived credentials that expire automatically once the job is complete. There are no tokens to rotate and no persistent secrets stored in repositories. If a workflow were compromised, there would be no standing credential left behind.

To support the change, Juno has introduced a Deployments screen within its Console interface. Developers can configure which GitHub repositories are authorised to deploy to a given Satellite and review past deployment activity. For those who prefer working from the command line, the same configuration options remain available through the CLI.

Alongside deployment changes, Juno now supports GitHub authentication for applications built on the platform. This allows end users to sign in with their GitHub accounts, a feature that aligns naturally with developer focused products.

Because GitHub does not natively support OpenID Connect for authentication in this context, Juno’s implementation relies on a small self hosted proxy that manages the OAuth exchange. The proxy issues a JSON Web Token after successful authentication. The Satellite verifies the token and creates a session for the user.

The setup requires additional infrastructure. Since the proxy signs tokens using RSA keys, the Satellite must access the corresponding public keys to verify them. Rather than forcing each Satellite to make repeated outbound calls, Juno uses a shared module called Observatory to fetch and cache the keys. Developers self hosting the proxy are also required to deploy their own Observatory instance and configure it to point to the proxy’s key endpoint.

The configuration may demand more effort than plug and play authentication services offered elsewhere. Yet the approach reflects a broader philosophy. Rather than attempting to replicate the full stack CI and CD environments provided by larger cloud platforms, Juno is focusing on tighter integration with tools developers already rely on, particularly GitHub.

The project’s creator acknowledged that building a fully managed deployment platform could be another route. Competing directly with established cloud providers would, however, require sustained infrastructure development and maintenance. For now, the emphasis is on improving compatibility and reducing friction within existing workflows.

For developers building products aimed at other developers, GitHub remains the centre of daily activity. By aligning more closely with that environment, Juno is positioning itself as a platform that adapts to established habits rather than asking teams to rework them.