Environment variables in E2E scripts: safe secrets in JMO Labs

When you write E2E scripts that interact with real applications, sooner or later you need data that shouldn't live in the code: API tokens, login credentials, URLs for private environments. Hardcoding these values is a security risk and a maintenance problem. At JMO Labs we solved this with script variables.

What script variables are

Script variables are key-value pairs that you define once in the JMO Labs configuration and that get injected automatically into every E2E script run. You access them with the variables.NOMBRE syntax, with no imports or extra configuration in the script. If you're interested in the solution we adopted, we explain it in detail in secret management with Infisical.

Each variable has three fields:

• The name, an identifier in SCREAMING_SNAKE_CASE format (for example, API_KEY, PRIVATE_TOKEN).

• The value, the data that will be injected into the script.

• An optional description that documents what the variable is for.

Private mode: protecting sensitive data

Not all variables are the same. A BASE_URL can show up in logs without any problem, but a PRIVATE_TOKEN shouldn't be visible anywhere. That's what private mode is for.

When a variable is marked as private:

• Its value is shown masked (••••••••) in the admin interface.

• It's automatically redacted in console output and execution logs.

• It's still accessible normally inside the script through variables.NOMBRE.

The interface clearly shows which variables are in private mode with a visual label, and the edit and delete controls are always accessible.

How they're used in an E2E script

Inside a script, variables are available as properties on a variables object that gets injected automatically into the execution sandbox. The object is read-only (Object.freeze) to avoid accidental changes.

Let's look at a real example: a private mode test that needs a token to enable a protected feature.

The script checks whether variables.PRIVATE_TOKEN is defined. If it isn't, the test skips the activation part. If it exists, it uses it to navigate to the private mode activation URL:

The important part is that the token never appears in the script, because it's passed from the API through the injected variables. If someone reviews the test code, they won't see credentials. If they check the execution logs, the value shows up redacted.

Technical implementation details

Under the hood, variables are managed with these constraints:

• Maximum of 100 variables per instance.

• Each value can be up to 10 KB.

• Names must follow the [A-Z][A-Z0-9_]{0,63} pattern, uppercase letters, numbers, and underscores only.

• The variables are inserted into the Node.js sandbox VM as a frozen, immutable object.

• Secret variable values are intercepted in standard output and replaced with [REDACTED].

The API endpoint (/api/script-variables) allows full CRUD operations, with strict validation of the name format and a secret flag that controls masking.

Why this matters

In E2E testing, secret management is usually a blind spot. Teams end up with tokens in .env files shared over Slack, credentials hardcoded in test scripts, or CI/CD variables that aren't accessible when someone runs the tests locally.

Script variables in JMO Labs solve this with a centralized approach: you define them once in the platform, they're available in every script, and sensitive ones are never exposed in the interface or in the logs. Simple, safe, no friction. If you want to go deeper, we cover it in detail in Playwright as the testing engine in JMO Labs.