Should I rely on K6_CLOUD_TOKEN validation or explicit --out=cloud flag to prevent accidental public test exposure?

Answer: Use both K6_CLOUD_TOKEN validation and the explicit --out=cloud flag

To guarantee that a test cannot accidentally publish results to the public k6 Cloud dashboard, you must require both a valid authentication token and an explicit output directive.

Confirmed facts

• The K6_CLOUD_TOKEN environment variable only authenticates the client; it does not trigger any upload by itself.
• The --out=cloud flag (or its script equivalent) tells k6 to send results to the cloud service; without this flag k6 runs locally and no data leaves the machine.
• If either the token is missing/invalid or the flag is absent, k6 aborts the upload or runs locally, preventing public exposure.

Likely explanation

In automated environments the risk is that a script or CI step unintentionally includes --out=cloud while a valid token is present (e.g., leaked from a shared secret store). When both conditions are true, k6 will authenticate and upload the test, making it visible in the Cloud UI. Conversely, having only one of the two conditions results in a safe outcome: a token without the flag yields a local run, and the flag without a valid token causes an authentication error and aborts the upload.

Steps to enforce safety in CI/CD

1. Validate that K6_CLOUD_TOKEN is set and non‑empty; treat an empty or missing value as a failure.
2. Require the --out=cloud flag (or out: cloud in a script) as part of the test invocation; do not rely on default behavior.
3. Make the test step fail if either validation fails – this guarantees that a run cannot reach the cloud unless both conditions are satisfied.
4. Optionally, mask the token in logs and use a secret‑management tool to prevent leakage.

If you can confirm that your CI system never exposes the token in logs, the combined validation alone is sufficient. If token leakage is a concern, you must add secret‑masking or short‑lived tokens to the workflow.