Skip to main content
Environment variables are how your app gets API keys, feature flags, and config without hardcoding them into source files. Hiveku manages them per environment and injects them automatically.

​
Where to Find Them

Go to Settings > Environment in your project. You’ll see tabs for:
  • Production — your live site
  • Staging — pre-release testing
  • Development — local dev / preview branches
Each tab has its own set of variables.

​
Adding a Variable

1

Open the right environment

Click Production (or Staging/Development) based on where this variable should apply.
2

Click Add Variable

Enter a Key (like STRIPE_SECRET_KEY) and a Value (like sk_live_...).
3

Save

Click Save. The variable is encrypted at rest and injected into your runtime.
4

Redeploy if needed

Runtime vars take effect immediately. Build-time vars (NEXT_PUBLIC_*) need a redeploy to actually propagate to the browser bundle.

​
Or Ask the AI

Add STRIPE_SECRET_KEY=sk_live_abc123 to production

Set NEXT_PUBLIC_ANALYTICS_ID to "G-ABC123" in production and staging
The AI confirms what it’ll add, then writes the vars. Great for batch updates.

​
Build-Time vs Runtime

This distinction matters.
Variables prefixed with NEXT_PUBLIC_ are baked into the browser bundle at build time.
  • Used on the client (React components, browser JS)
  • Visible to anyone who views source — never put secrets here
  • Require a redeploy after changing the value
Examples: NEXT_PUBLIC_ANALYTICS_ID, NEXT_PUBLIC_API_URL, NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY.
Never put a secret in a NEXT_PUBLIC_* variable. Those end up in the browser where anyone can read them.

​
Auto-Injected Variables

Hiveku sets these for you automatically — you don’t need to add them:
VariableMeaning
NODE_ENVproduction, development, etc
AWS_REGIONThe region your project runs in
HIVEKU_PROJECT_IDUnique project identifier
DATABASE_URLPostgres connection (if a DB is provisioned)
Your code can use these directly: process.env.DATABASE_URL.

​
Never Hardcode Secrets

Bad: 
const stripe = new Stripe("sk_live_abc123...");
Good: 
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);
If you hardcode a key into source, it ends up in git history, logs, and potentially the browser bundle — rotate it immediately if that happens.

​
Per-Environment Variables

You’ll often want the same key with different values per environment. 
Production:   STRIPE_SECRET_KEY = sk_live_abc...
Staging:      STRIPE_SECRET_KEY = sk_test_def...
Development:  STRIPE_SECRET_KEY = sk_test_xyz...
Hiveku automatically picks the right value based on which environment your app is running in.

​
Reading Variables in Code

const apiKey = process.env.STRIPE_SECRET_KEY;
if (!apiKey) throw new Error("Missing STRIPE_SECRET_KEY");

​
Verifying a Variable Is Set

After adding or changing a variable:
1

Redeploy if it's NEXT_PUBLIC_*

Click Deploy — the new value won’t reach the browser until then.
2

Add a test route

Create a quick API route like /api/env-test:
export async function GET() {
  return Response.json({
    hasKey: !!process.env.MY_VAR,
  });
}
3

Hit the route

Visit the URL. hasKey: true confirms the variable is injected.
4

Never log the value itself

Logging the value can leak it into your logs. Log only presence (hasKey: true/false).

​
Troubleshooting

Only NEXT_PUBLIC_* variables reach the browser. Rename to NEXT_PUBLIC_MY_VAR and redeploy. Regular env vars work server-side only.
Two common causes:
  1. You added it to Staging but your app is running Production (check the environment tab)
  2. It’s a build-time var (NEXT_PUBLIC_*) and you haven’t redeployed yet — runtime vars take effect on the next container restart, build-time vars need a full redeploy
Rotate the key immediately at the provider (Stripe, OpenAI, etc.) — assume it’s compromised. Then remove it from your source, commit the removal, and store the new value in Hiveku env vars only.
Most env systems have a size limit. For large blobs (like a full JSON config or a certificate), store them in AWS Secrets Manager or a similar store, and keep just the pointer / reference in env vars.
Check you’re reading from the right environment. process.env.NODE_ENV should match the tab where you set the variable. If it still fails, redeploy — occasionally runtime injection lags a previous deploy.

​
What’s Next?

Deploy your site

Push env changes live

Set up a database

Uses DATABASE_URL automatically