Blog
Engineering
2
minutes

GitHub Variables and Nx Reusable Workflows

At Qovery, we build our frontend using Nx and rely on the official nrwl/ci GitHub Actions. Our frontend requires third-party tokens during compile time, but we would like to avoid hardcoding them or using the .env file to define our tokens. The latter exposes our source code directly on GitHub, and even though it's not sensitive data, we don't want it to be easily scraped. As probably many others, we've faced issues when we dug into environment variables using this reusable workflow: https://github.com/nrwl/ci?tab=readme-ov-file#limited-secrets-support https://github.com/nrwl/ci/issues/92 https://github.com/nrwl/ci/issues/44 So, I wanted to share the lessons I learned from this experience.
Camille Tjhoa
Senior Software Engineer
Summary
Twitter icon
linkedin icon

First and foremost, we need to better understand GitHub Actions and its capabilities.

GitHub Secrets vs Variables

Github differentiates secrets from variables.

The main differences that are going to be important here for our use case are:

  • Secrets are for sensitive data and cannot be shared with reusable workflows
  • Variables are non-sensitive data and are shared to reusable workflows through the keyword vars

As mentioned earlier, our data consists of frontend third-party tokens that are not sensitive because they can be found in our public JS source code. Additionally, nx-cloud-main and nx-cloud-agents are reusable workflows.

Therefore, our solution should revolve around Variables.

Note that you can create repository variables in GitHub like this.

Secrets and Variables screen from GitHub

Nrwl/ci reusable workflow configuration

Although GitHub Variables may appear perfect in our case, the reusable workflows from nrwl/ci do not directly utilize the vars keyword internally. Therefore, variables are not used by those workflows as they are.

Upon closer examination of the workflow configuration, we find a parameter called "environment-variables". Unfortunately, this parameter requires environment variables in dotenv format:

NX_MY_TOKEN=1234
NX_MY_OTHER_TOKEN=4567

whereas our vars are an object

{
NX_MY_TOKEN: 1234
NX_MY_OTHER_TOKEN: 4567
}

GitHub script to the rescue

To achieve the desired format, we require some intermediate scripting. Luckily, the actions/github-script is the ideal tool for this task. It enables us to convert GitHub variables into the expected Nx format.

  env-vars:
runs-on: ubuntu-latest
outputs:
variables: ${{ steps.var.outputs.variables }}
steps:
- name: Setting global variables
uses: actions/github-script@v7
id: var
with:
script: |
const varsFromJSON = ${{ toJSON(vars) }}
const variables = []
for (const v in varsFromJSON) {
variables.push(v + '=' + varsFromJSON[v])
}
core.setOutput('variables', variables.join('\\n'))
nx-main:
needs: [env-vars]
name: Nx Cloud - Main Job
uses: nrwl/ci/.github/workflows/[email protected]
with:
environment-variables: |
${{ needs.env-vars.outputs.variables }}
# ...

agents:
needs: [env-vars]
name: Nx Cloud - Agents
uses: nrwl/ci/.github/workflows/[email protected]
with:
number-of-agents: 3
environment-variables: |
${{ needs.env-vars.outputs.variables }}

Conclusion

We have learned more about the capabilities of GitHub Actions and are taking our CI to the next level!

We can leverage our environment variables without exposing them directly by using a bit of scripting and the options provided by Nx workflows.

And the best part is we can achieve this without hardcoding them or using a .env file.

Share on :
Twitter icon
linkedin icon
Tired of fighting your Kubernetes platform?
Qovery provides a unified Kubernetes control plane for cluster provisioning, security, and deployments - giving you an enterprise-grade platform without the DIY overhead.
See it in action

Suggested articles

DevOps
16
 minutes
Enterprise DevOps Automation: Moving from Scripts to Platform Engineering

Stop writing fragile scripts. Discover how top enterprises use Kubernetes Management Platforms to automate governance (Policy-as-Code), scale ephemeral environments, and enforce FinOps with Spot Instances.

Mélanie Dallé
Senior Marketing Manager
DevOps
Kubernetes
 minutes
Top 10 Platform9 Alternatives: Best managed Kubernetes solutions for scale

Need a better way to manage on-prem Kubernetes? Review 10 alternatives to Platform9, categorized by "Infrastructure Ops" (Rancher) vs. "Developer Experience" (Qovery).

Mélanie Dallé
Senior Marketing Manager
DevOps
Kubernetes
 minutes
Top 10 Rafay alternatives for enterprise Kubernetes operations

Is Rafay's complexity slowing you down? Compare the top 10 Rafay alternatives for 2026. From fleet managers like Rancher to developer platforms like Qovery, find the balance between control and velocity.

Mélanie Dallé
Senior Marketing Manager
DevOps
Kubernetes
 minutes
Top 10 Spectro Cloud alternatives for multi-cluster fleet management

Don't just manage clusters. Modernize your stack. Compare Spectro Cloud vs. Qovery vs. Rancher to decide between "Fleet Operations" and "Developer Self-Service.

Mélanie Dallé
Senior Marketing Manager
DevOps
Kubernetes
 minutes
Top 10 VMware alternatives after the Broadcom acquisition

Hit by Broadcom's VMware price hikes? Compare the top 10 alternatives for 2026, from direct replacements like Proxmox and Nutanix to modernization platforms like Qovery.

Mélanie Dallé
Senior Marketing Manager
DevOps
Kubernetes
Platform Engineering
6
 minutes
10 Red Hat OpenShift alternatives to reduce licensing costs

Is OpenShift too expensive? Discover the best alternatives for 2026. Whether you need Developer Self-Service (Qovery) or Hybrid Cluster Ops (Rancher), find the right fit for your team.

Morgan Perry
Co-founder
Kubernetes
 minutes
Kubernetes management: Best practices for enterprise scaling and cost optimization

Master enterprise Kubernetes management in 2026. Learn best practices for security, FinOps, and reliability, and see how AI-agentic platforms simplify operations.

Mélanie Dallé
Senior Marketing Manager
Kubernetes
Platform Engineering
Infrastructure Management
 minutes
The top 3 OpenShift pains in 2026 (and how platform teams respond)

Is OpenShift becoming too expensive or complex for your team? Discover the top 3 OpenShift pain points; from the "pricing inversion" to vendor lock-in and see why agile platform teams are migrating to modular, developer-first alternatives like Qovery.

Mélanie Dallé
Senior Marketing Manager

It’s time to change
the way you manage K8s

Turn Kubernetes into your strategic advantage with Qovery, automating the heavy lifting while you stay in control.