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.

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 at build time and at run time, without you setting anything:

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 the useful one: your server routes can call the platform with it rather than you provisioning and rotating a key by hand. It is a runtime value — read it server-side, and never expose it 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
NUXT_PUBLIC_TAX_INCLUDED_PRICESWhether displayed prices include tax
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. You're probably expecting REVENEXX_SITE_API_KEY where your code reads NUXT_REVENEXX_API_KEY, or the reverse. Map one to the other explicitly.

Related

Was this page helpful?