Introduce APP_ENV variable to frontend

[Bentroen]

Overview

Some website features, such as crawler indexing (robots.txt), ads, and analytics should only ever be enabled in production deployments. So far, we had been using NODE_ENV to signal whether or not we were running a production deployment. As mentioned in the Node.js documentation, this usage is considered an antipattern. The only acceptable value for the NODE_ENV variable is production which by convention indicates we're running with production-mode optimizations (or the absence of it, which signals otherwise) for some libraries.

This means that NODE_ENV=production is the appropriate mode for us to run our development/staging environments on, which we already do. However, this means that our previous checks/assumptions for whether we're running in production were wrong, because our development environment also runs with NODE_ENV=production. In turn, robots.txt was not avoiding crawling, ad code was being loaded etc. in our development environment.

This PR introduces the APP_ENV environment variable on the frontend, which can assume values local, development, staging and production.
NODE_ENV is always supposed to be production` in non-development environments.

Additions

APP_ENV utility

New shared helper at apps/frontend/src/lib/appEnv.ts:

• Values: local, development, staging, production
• Reads APP_ENV (server/build) or NEXT_PUBLIC_APP_ENV (client)
• Defaults to local if unset or invalid
• Helpers: getAppEnv(), isProductionAppEnv(), isLocalAppEnv()

next.config.mjs

APP_ENV is forwarded to the client at build time via NEXT_PUBLIC_APP_ENV, so client components can use the same value without duplicating env vars.

Updated call sites

All behavioral NODE_ENV checks in the frontend now use APP_ENV:

File	Change
robots.ts	Allows crawling only when APP_ENV=production
layout.tsx	Google Analytics only in production
GoogleAdSense.tsx	AdSense script only in production
useAdSenseClient.tsx	AdSense client ID only in production
login.util.ts	Cookie domain logic uses isLocalAppEnv() instead of NODE_ENV === 'development'

Configuration

Set APP_ENV per deployment:

# Local (.env.local)
APP_ENV=local

# Staging
APP_ENV=staging

# Production
APP_ENV=production

On staging, set APP_ENV=staging (or development) even if NODE_ENV=production for the Next.js build. That keeps build optimizations while blocking crawlers, ads, and analytics.

apps/frontend/.env.local.example already includes APP_ENV=local.

This matches the Node.js guidance: keep NODE_ENV=production for builds, and use APP_ENV for deployment-specific behavior.

[railway-app]

🚅 Deployed to the NoteBlockWorld-pr-98 environment in Note Block World

Service	Status	Web	Updated (UTC)
Next.js frontend Bun	✅ Success (View Logs)	Web	Jun 19, 2026 at 1:50 am
Nest.js API Bun	✅ Success (View Logs)	Web	Jun 19, 2026 at 1:50 am