Environment variables

Set constants and secrets on a site with the CLI or API, understand why marking a variable secret is irreversible, and use the REVENEXX_SITE_* variables the platform injects for you.

Environment variables on a site pass constants and secrets — API keys, connection strings, feature flags — to your build and to your runtime.

Setting a variable

From the CLI:

Shell
revenexx sites create-variable \
    --site-id <SITE_ID> \
    --key PSP_PUBLIC_KEY \
    --value pk_live_...

The rest of the set, for scripting:

Shell
revenexx sites list-variables  --site-id <SITE_ID>
revenexx sites get-variable    --site-id <SITE_ID> --variable-id <VARIABLE_ID>
revenexx sites update-variable --site-id <SITE_ID> --variable-id <VARIABLE_ID> --value <NEW_VALUE>
revenexx sites delete-variable --site-id <SITE_ID> --variable-id <VARIABLE_ID>

Over the API:

Shell
# Create a variable on a site
curl -s -X POST 'https://api.revenexx.com/v1/sites/<SITE_ID>/variables' \
  -H 'X-Revenexx-Tenant: <tenant-slug>' \
  -H 'X-Revenexx-Api-Key: <api-key>' \
  -H 'Content-Type: application/json' \
  -d '{"key":"PSP_PUBLIC_KEY","value":"pk_live_..."}'

# List variables
curl -s 'https://api.revenexx.com/v1/sites/<SITE_ID>/variables' \
  -H 'X-Revenexx-Tenant: <tenant-slug>' \
  -H 'X-Revenexx-Api-Key: <api-key>'

A key can be up to 255 characters and a value up to 8192.

GET /v1/sites/<SITE_ID>/variables/<VARIABLE_ID> returns one variable. PUT /v1/sites/<SITE_ID>/variables/<VARIABLE_ID> updates it, and its body takes key (required), secret and value. DELETE /v1/sites/<SITE_ID>/variables/<VARIABLE_ID> deletes it.

Variables apply to the next deployment. Setting one does not change the running build. This is the most common surprise: a variable set, a page refreshed, nothing different. Create a new deployment.

Secret variables are one-way

A variable can be marked secret, at creation or afterwards:

Shell
revenexx sites create-variable \
    --site-id <SITE_ID> \
    --key ERP_API_TOKEN \
    --value <token> \
    --secret true
Marking a variable secret is irreversible. A secret variable's value is never readable again through Cockpit or the API — only the site itself can read it, during build and at runtime. You can update it and you can delete it, but you cannot read it back.

Use it for anything you would not want printed in a support session. And keep a copy wherever your team keeps credentials before you set it, because the platform will not give it back.

The practical rule: if it would be a problem in a screenshot, make it secret.

Variables the platform injects for you

Every deployed site receives these without you setting anything. REVENEXX_SITE_API_KEY is set for the build only (as of 2026-10); the others are also set at run time:

VariableDescription
REVENEXX_SITE_API_ENDPOINTAPI endpoint the site should call
REVENEXX_SITE_API_KEYScoped API key issued to this site's runtime
REVENEXX_SITE_IDThe site's ID
REVENEXX_SITE_NAMEThe site's name
REVENEXX_SITE_DEPLOYMENTID of the running deployment
REVENEXX_SITE_PROJECT_IDThe project the site belongs to
REVENEXX_SITE_RUNTIME_NAMERuntime name
REVENEXX_SITE_RUNTIME_VERSIONRuntime version
REVENEXX_SITE_CPUSRuntime CPU specification
REVENEXX_SITE_MEMORYRuntime memory specification

REVENEXX_SITE_API_KEY is available while the site builds. It is not a runtime value, and a theme does not read it. At run time the platform supplies the tenant and credentials for each request, so your server routes do not need a key variable on a deployed site. Never expose any of these to the browser. See The BFF pattern.

REVENEXX_SITE_DEPLOYMENT is worth surfacing in a health endpoint or a response header. When someone asks "is this the new build?", you want an answer that doesn't require reading logs.

The variables a theme reads

A theme's own configuration comes through Nuxt's runtime config, which means NUXT_-prefixed names rather than the REVENEXX_SITE_* set:

VariableWhat it sets
NUXT_REVENEXX_API_URLThe gateway to call
NUXT_REVENEXX_TENANTThe tenant slug
NUXT_REVENEXX_API_KEYThe key the server routes authenticate with
NUXT_CHECKOUT_SESSION_SECRETSigning secret for the checkout session token — set it explicitly on a multi-tenant deployment, as a secret variable
NUXT_PUBLIC_CART_INACTIVITY_TTLHow long an idle cart survives, in milliseconds
Only NUXT_PUBLIC_* values reach the browser. Everything else is private runtime config, readable server-side only. Never move a credential under a public name.

Full explanation of the local versions: Local development.

Build time versus run time

Worth being precise about, because it decides whether a change needs a rebuild:

Static siteServer-rendered site
Build time✓✓
Run timenothing executes per request✓

A static site can only bake a variable in at build time, so changing one always means a new deployment. A server-rendered site reads run-time values per request — but the variable still only reaches the runtime on the next deployment.

Debugging

  • A variable I set isn't there. It applies from the next deployment. Create one.
  • I can't read a value back. It's marked secret, and that's irreversible.
  • A public variable is undefined in the browser. Only NUXT_PUBLIC_* names are serialized to the client. Anything else is server-only, by design.
  • The site works locally and fails deployed with a 401. Your local NUXT_REVENEXX_API_KEY is not what a deployed site authenticates with. Check that no key for another tenant is set as a site variable, and that the call goes through your server routes.

Related

Was this page helpful?