Environment variables

Environment variables let you pass configuration into your service without hard-coding it in your repository. Database URLs, API keys, feature flags, third-party secrets — anything you don't want committed to Git lives here.

Variables are encrypted at rest and only made available to your running service.

Adding a variable

1. Open your service.
2. Go to the Environment Variables tab.
3. Click + Add variable.
4. Enter a KEY and VALUE.
5. Click Save.

By convention, keys are uppercase with underscores (DATABASE_URL, STRIPE_SECRET_KEY).

Reading variables in your app

Each variable becomes an environment variable inside your service's processes. Read them the way you'd read any other env var:

const dbUrl = process.env.DATABASE_URL
const stripeKey = process.env.STRIPE_SECRET_KEY

import os
db_url = os.environ["DATABASE_URL"]
stripe_key = os.environ.get("STRIPE_SECRET_KEY")

dbURL := os.Getenv("DATABASE_URL")
stripeKey := os.Getenv("STRIPE_SECRET_KEY")

db_url = ENV.fetch("DATABASE_URL")
stripe_key = ENV["STRIPE_SECRET_KEY"]

Editing or deleting

• Click a row to edit its value. Values are masked by default; click the eye icon to reveal.
• Click the trash icon to delete. Confirmation is required.

Both actions take effect on the next release of your service.

Bulk import from .env

If you already have a .env file:

1. Open the Environment Variables tab.
2. Click the ⋯ menu → Import .env.
3. Paste the contents.

DATABASE_URL=postgres://user:pw@host:5432/db
STRIPE_SECRET_KEY=sk_live_xxxxx
ALLOWED_ORIGINS=https://app.example.com,https://example.com

Rules:

• Lines starting with # are treated as comments.
• Quotes around values are removed on import.
• Existing keys are overwritten by the import.

Bulk export

From the same ⋯ menu, click Download .env. The download is plaintext — handle with care, especially on shared screens.

Build-time vs runtime

Inhank Cloud makes your environment variables available in both phases:

• During the build — useful for frameworks that bake values into the output (e.g. NEXT_PUBLIC_API_URL for Next.js, VITE_* for Vite).
• During runtime — your server reads them at startup with process.env.X, os.environ["X"], etc.

For most apps, you don't need to think about which phase a variable is used in — adding it once just works.

Reserved variables

A handful of variables are managed by the platform. Setting them yourself has no effect:

Best practices

• Never commit secrets to Git. Even in a private repo — once it's in history, it's hard to remove.
• Use one secret per service. Don't share a single env-var set across multiple services from one repo; each service should have its own.
• Rotate credentials regularly. Database passwords, API keys, signing secrets — update them every few months and on team changes.
• Use sandbox credentials in development. Production credentials should only live in your production service's environment.
• Read once at startup. Cache process.env.X into a constant at boot. Most apps don't pick up env var changes without a restart, and reading process.env on every request is slower than necessary.

Common mistakes

"My app starts fine locally but crashes on Inhank Cloud"

The most common cause: a variable that's in your local .env file is not set in Inhank Cloud. Compare your .env against the Environment Variables tab and add anything missing.

"I added a variable but it isn't showing up"

You probably haven't redeployed yet. Variables take effect on the next release. Click Redeploy on the service overview.

"I changed PORT and now my app is broken"

PORT is reserved — your custom value is overridden by the platform. Always read the PORT env variable and listen on whatever value it has.

"My build script can't see a variable"

Variables are available during both build and runtime, but only after they're saved. If your build runs immediately after you save a new variable, it should be picked up. If not, click Deploy again — the new build will see the new value.

Limits

Security

• Variables are encrypted at rest with industry-standard ciphers; the encryption key is stored separately from the database.
• Decrypted values exist only in memory when the service is running.
• Inhank Cloud staff cannot read your variable values.
• Values are masked in build logs by default; if you ever see an unmasked secret, please report it.