Environment variables

Use environment variables for configuration and secrets: database URLs, API keys, feature flags.

Set variables

• When creating an app: in Advanced Settings → Environment Variables, one KEY=value per line. Lines starting with # are ignored, and export prefixes and surrounding quotes are handled.
• Later: open the app, go to Builds & Settings → Environment Variables, click Add Variable, then Save Environment.
• From the CLI: hivepod deploy --env DATABASE_URL=postgresql://... (repeat --env for each).
• From the MCP server: the set_env tool.

Example

DATABASE_URL=postgresql://usr_1a2b3c4d:[email protected]:10042/app?sslmode=require
SESSION_SECRET=change-me
NODE_ENV=production

Rules

• Names start with a letter or _ and contain only letters, digits and _ (up to 128 characters).
• Values are a single line.
• Up to 200 variables and 64 KB in total per app.
• PORT is set for you.

Secrets stay secret

Every value is encrypted at rest and hidden in the console: existing values appear as •••••••• (unchanged). Only the app’s owner can read them back, through an explicit reveal request to the API. Values that appear in build or health-check output are replaced with ***.

Available at build time and at runtime

Your variables are available while your app is built and when it runs. That means values that frameworks inline into the client bundle during the build work as you’d expect:

Framework	Build-time (public) prefix
Next.js	NEXT_PUBLIC_*
Vite (React, Vue, Svelte, Solid)	VITE_*
SvelteKit, Astro	PUBLIC_* (and $env/static/* in SvelteKit)
Nuxt	NUXT_PUBLIC_*
Create React App	REACT_APP_*
Angular (@ngx-env)	NG_APP_*
Gatsby	GATSBY_*

Server-side code (API routes, server components, Django or Rails settings read during collectstatic or assets:precompile) can read every variable during the build, too.

Anything in a client bundle is public

Values a framework inlines into the browser bundle can be read by anyone who visits your site. Only use the public prefixes for values that are meant to be public (an API base URL, a publishable key). Keep secrets in variables without a public prefix and read them on the server.

Secrets you set are passed to the build without being stored in your app’s image or its build history, and they’re masked as *** in the build log.

Your own Dockerfile

If you deploy with your own Dockerfile, you have two options:

• ARG for public values. Every variable your Dockerfile declares with ARG is passed to the build with your app’s value:

  ARG NEXT_PUBLIC_API_URL
  RUN npm run build

  Docker records ARG values in the image history, so use ARG only for values that are public anyway.

• The build secret, for everything else. All of your variables are available as a build secret named dockhive_env, a file of NAME='value' lines. Mount it on the step that needs it:

  RUN --mount=type=secret,id=dockhive_env,mode=0444 \
      sh -c 'set -a; . /run/secrets/dockhive_env; set +a; npm run build'

  The file exists only while that step runs and never ends up in your image.

When changes take effect

Saving variables doesn’t restart your app. They apply on the next deploy, which rebuilds your app with the new values: click Redeploy (or push a commit with push to deploy on). The console shows when a redeploy is needed.

A rollback starts an earlier build with your current variables. Runtime values update, but values that were inlined into the bundle at build time (for example NEXT_PUBLIC_* or VITE_*) stay as they were when that build was made. Redeploy to rebuild with the new values.