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.
September 26, 2025
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

AI
Compliance
 minutes
April 10, 2026
Agentic AI infrastructure: moving beyond Copilots to autonomous operations

The shift from AI copilots to autonomous agents is redefining infrastructure requirements. Discover how to build secure, stateful, and compliant Agentic AI systems using Kubernetes, sandboxing, and observability while meeting EU AI Act standards

Mélanie Dallé
Senior Marketing Manager
Kubernetes
8
 minutes
April 10, 2026
The 2026 guide to Kubernetes management: master day-2 ops with agentic control

Effective Kubernetes management in 2026 demands a shift from manual cluster building to intent-based fleet orchestration. By implementing agentic automation on standard EKS, GKE, or AKS clusters, enterprises eliminate operational weight, prevent configuration drift, and proactively control cloud spend without vendor lock-in, enabling effective scaling across massive fleets.

Mélanie Dallé
Senior Marketing Manager
Kubernetes
 minutes
April 9, 2026
Building a single pane of glass for enterprise Kubernetes fleets

A Kubernetes single pane of glass is a centralized management layer that unifies visibility, access control, cost allocation, and policy enforcement across § cluster in an enterprise fleet for all cloud providers. It replaces the fragmented practice of switching between AWS, GCP, and Azure consoles to govern infrastructure, giving platform teams a single source of truth for multi-cloud Kubernetes operations.

Mélanie Dallé
Senior Marketing Manager
Kubernetes
 minutes
April 6, 2026
How to deploy a Docker container on Kubernetes (and why manual YAML fails at scale)

Deploying a Docker container on Kubernetes requires building an image, authenticating with a registry, writing YAML deployment manifests, configuring services, and executing kubectl commands. While necessary to understand, executing this manual workflow across thousands of clusters causes severe configuration drift. Enterprise platform teams use agentic platforms to automate the entire deployment lifecycle.

Mélanie Dallé
Senior Marketing Manager
Kubernetes
Terraform
 minutes
April 2, 2026
Managing Kubernetes deployment YAML across multi-cloud enterprise fleets

At enterprise scale, managing provider-specific Kubernetes YAML across multiple clouds creates crippling configuration drift and operational toil. By adopting an agentic Kubernetes management platform, infrastructure teams abstract cloud-specific configurations (like ingress controllers and storage classes) into a single, declarative intent that automatically reconciles across 1,000+ clusters.

Mélanie Dallé
Senior Marketing Manager
Kubernetes
Cloud
AI
FinOps
 minutes
April 1, 2026
GPU orchestration guide: How to auto-scale Kubernetes clusters and slash AI infrastructure costs

To stop GPU costs from destroying SaaS margins, teams must transition from static to consumption-based infrastructure by utilizing Karpenter for dynamic provisioning, maximizing hardware density with NVIDIA MIG, and leveraging Qovery to tie scaling directly to business metrics.

Mélanie Dallé
Senior Marketing Manager
Product
AI
Deployment
 minutes
March 31, 2026
Stop Guessing, Start Shipping. AI-Powered Deployment Troubleshooting

AI is helping developers write more code, faster than ever. But writing code is only half the story. What happens after? Building, deploying, debugging, scaling. That's where teams still lose hours.We're building Qovery for this era. Not just to deploy your code, but to make everything that comes after writing it just as fast.

Alessandro Carrano
Head of Product
AI
Developer Experience
Kubernetes
 minutes
March 27, 2026
MCP Server is the future of your team's incident’s response

Learn how to use the Model Context Protocol (MCP) to transform static runbooks into intelligent, real-time investigation tools for Kubernetes and cert-manager.

Romain Gérard
Staff Software Engineer

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.

Talk to an expertGet Qovery free