Set environment variables

Settings that must not be hard-coded — API keys, DB addresses — live in environment variables. In this guide you set values via the console or CLI, and read them by name from code.

Why keep them out of code

A value that lives in code stays in git history forever and is exposed to everyone who can see the repository. Kept as an environment variable, AxHub stores the value encrypted and supplies it at build time or when the app runs — only the name remains in code, as in process.env.DATABASE_URL.

What you need

• An app created on AxHub — environment variables are stored per app
• (To set them from the terminal) CLI login — the command tool whose commands start with axhub

Set them in the console

App console → Resources tab → Environment variables → Add variable. You set four things.

Naming rules — a Key starts with an uppercase letter and uses only uppercase letters, digits, and underscores (_) — pattern ^[A-Z][A-Z0-9_]*$. If the pattern looks unfamiliar, the examples below are enough.

DATABASE_URL   OPENAI_API_KEY   NEXT_PUBLIC_API_URL   ✅
databaseUrl    1ST_KEY          MY-KEY                ❌

Names starting with AXHUB_ are not allowed — that space is reserved for values AxHub injects itself.

Stage — for the same value, you decide at which point it enters the app. Some values are needed while your code is assembled into a runnable form — the build — and others are needed while the app actually runs.

Secret — leave it on and the value is stored encrypted and masked as *** in lists and responses. The trade-off: when you edit it later the field comes up empty and you have to retype the value. For values that don't need hiding (a public API address, say), turn it off and you can read and edit them right from the list.

If the app owner has locked the app with a viewing policy, even admins may be blocked from viewing environment variable values in the console.

Set them via the CLI

From the terminal, the commands look like this.

# A value that must stay hidden — read from stdin so it never hits your history
axhub env set DATABASE_URL --app demo --secret --stage runtime --from-stdin

# A value that needs no hiding — KEY VALUE as is
axhub env set NEXT_PUBLIC_API_URL https://api.example.com --app demo --plain --stage build

axhub env list --app demo
axhub env get DATABASE_URL --app demo
axhub env update DATABASE_URL new-value --app demo --stage runtime
axhub env delete DATABASE_URL --app demo

With --secret you can't type the value on the command line at all — it only comes through --from-stdin. That keeps secrets out of your command history and logs.

To use a different value in staging (the testing environment) only, axhub env set-staging-value keeps a value just for that environment. It isn't available for Build-stage values, since production and staging share the same build output.

Read them from code

In code, you read by name only — in node, that's process.env.OPENAI_API_KEY. The actual value never appears anywhere in code.

Which environment variables your app needs can be declared — names and stages only — in the repository's axhub.yaml (the manifest). Never the values.

env:
  required:
    - name: DATABASE_URL
      scope: runtime
    - name: NEXT_PUBLIC_API_URL
      scope: build

The manifest's scope means the same thing as Stage in the console and CLI (build · runtime · both).

You've succeeded when

axhub env list --app <app> (or the app console's Resources tab → Environment variables) shows the key you set, and the redeployed app reads the value and works — that's success.

Next, start wiring AxHub features into your app code in Install the SDK.