Managing environment-specific configurations like API endpoints, feature flags, or secret keys is a fundamental challenge in frontend development. Hardcoding these values directly into your codebase is unsustainable, insecure, and error-prone when deploying to different environments. Vite, a modern and fast build tool, provides a streamlined and explicit way to handle environment variables, offering clarity and security for different deployment targets.

This guide dives into Vite’s specific mechanisms for managing environment variables, moving beyond a simple overview to practical application with code examples, focusing on how and why these approaches work. We’ll explore import.meta.env, .env files, and the concept of ‘modes’.

Core Concept: Vite’s Approach to Environment Variables

Vite’s approach to environment variables differs significantly from traditional Node.js-based setups. While Node.js applications often rely on process.env, Vite applications primarily use import.meta.env within client-side code. This distinction is crucial because Vite performs a static replacement during the build process for variables prefixed with VITE_, making them available in your bundled frontend code.

Variables without the VITE_ prefix are not exposed to the client bundle. They are only accessible within the Vite config file (vite.config.js) or during Node.js server-side operations (e.g., custom Vite plugins or SSR setups). This mechanism helps prevent accidental exposure of sensitive information.

Defining Environment Variables with .env Files

To manage variables, Vite leverages .env files, similar to the popular dotenv library. These files are loaded based on the mode your application is running in. The mode is a string that indicates the environment, typically ‘development’ (for vite or vite dev) or ‘production’ (for vite build).

Vite provides a hierarchy for .env files:

• .env: General defaults.
• .env.local: Local overrides, ignored by Git.
• .env.[mode]: Mode-specific overrides (e.g., .env.development, .env.production).
• .env.[mode].local: Local, mode-specific overrides, ignored by Git.

Let’s set up a common scenario with three files:

.env             # General defaults
.env.development # Overrides for development mode
.env.production  # Overrides for production mode

Here’s an example of their content:

./.env

VITE_APP_NAME="My Awesome App"
VITE_API_BASE_URL="https://api.example.com/v1"
SECRET_API_KEY="this-should-not-be-exposed" # Not prefixed, thus not exposed to client

./.env.development

VITE_API_BASE_URL="http://localhost:3001/api/v1"

./.env.production

VITE_API_BASE_URL="https://prod-api.example.com/v1"

Explanation: In these files, we define key-value pairs. Variables prefixed with VITE_ (e.g., VITE_APP_NAME, VITE_API_BASE_URL) will be exposed to your client-side code via import.meta.env. Variables without this prefix (like SECRET_API_KEY) are not exposed to the client, making them suitable for server-side configurations or within vite.config.js. Vite automatically loads .env files based on the current mode, with .env.[mode] taking precedence over the generic .env.

Accessing Variables in Your Application

Within your frontend JavaScript or TypeScript code, you access these environment variables through the special import.meta.env object. This object is populated by Vite during the build or development server startup.

// src/main.js or src/App.vue

// Accessing custom environment variables
console.log("App Name:", import.meta.env.VITE_APP_NAME);
console.log("API Base URL:", import.meta.env.VITE_API_BASE_URL);

// Vite also exposes built-in environment flags
if (import.meta.env.DEV) {
  console.log("Running in development mode");
} else if (import.meta.env.PROD) {
  console.log("Running in production mode");
}

// Accessing the current mode string
console.log("Current Mode:", import.meta.env.MODE);

// Attempting to access an unprefixed variable will result in 'undefined'
console.log("Secret API Key (should be undefined):", import.meta.env.SECRET_API_KEY);

const element = document.getElementById('app-info');
if (element) {
  element.textContent = `App: ${import.meta.env.VITE_APP_NAME}, API: ${import.meta.env.VITE_API_BASE_URL}`;
}

Explanation: import.meta.env is a special object that Vite populates with your environment variables. VITE_APP_NAME and VITE_API_BASE_URL are successfully logged, reflecting the values from the appropriate .env file for the active mode. Vite also provides useful boolean flags like DEV and PROD to conditionally execute code based on the current environment, eliminating the need to manually parse NODE_ENV. Note that import.meta.env.SECRET_API_KEY correctly returns undefined, preventing accidental exposure of sensitive data to the client, reinforcing the importance of the VITE_ prefix.

Running with Different Modes and Customizing Build Behavior

Vite commands inherently use a mode. When you run vite (or vite dev), it defaults to development mode. When you run vite build, it defaults to production mode. You can explicitly specify a mode using the --mode CLI flag.

This is particularly useful for environments like staging or test, which require their own distinct configurations without being ‘development’ or ‘production’.

Let’s add a build:staging script to package.json and a corresponding .env.staging file:

package.json

{
  "name": "vite-env-example",
  "private": true,
  "version": "0.0.0",
  "type": "module",
  "scripts": {
    "dev": "vite",
    "build": "vite build",
    "preview": "vite preview",
    "build:staging": "vite build --mode staging",
    "dev:staging": "vite --mode staging"
  }
}

Now, create the ./.env.staging file:

./.env.staging

VITE_API_BASE_URL="https://staging-api.example.com/v1"
VITE_APP_ENVIRONMENT="staging"

Explanation: The scripts section in package.json demonstrates how to use the --mode flag. npm run dev:staging will start the development server using staging mode, causing Vite to load variables from .env.staging (and then .env). Similarly, npm run build:staging will create a production build configured specifically for the staging environment. This explicit mode control allows for distinct configurations tailored to various deployment pipelines without altering your core application code.

Common Mistakes / Gotchas

• Forgetting VITE_ prefix: This is the most common mistake. Only variables prefixed with VITE_ are exposed to your client-side code via import.meta.env. Variables like API_KEY=123 will not be accessible in your components. If you need to access non-prefixed variables, they are typically for vite.config.js or server-side scripts.
• Using process.env: This is a common habit from Node.js development. In a Vite frontend application, process.env is not available at runtime in the browser. Always use import.meta.env for client-side variables.
• Exposing Sensitive Information: Even with the VITE_ prefix, remember that any variable exposed via import.meta.env is eventually bundled into your client-side JavaScript. This means it’s publicly visible if someone inspects your deployed code. Never put truly sensitive information (like private API keys, database credentials) directly into .env files that will be used for client-side builds. Instead, use a backend proxy or server-side logic to handle such secrets securely.
• Understanding mode vs. NODE_ENV: While import.meta.env.MODE reflects the current mode (e.g., ‘development’, ‘production’, ‘staging’), import.meta.env.DEV and import.meta.env.PROD are specific boolean flags Vite provides. NODE_ENV is not directly used by Vite for mode resolution but might be present as a fallback from other tools. Always rely on import.meta.env.MODE, import.meta.env.DEV, import.meta.env.PROD for consistency within Vite.

Key Takeaways

• Vite uses import.meta.env for client-side environment variables, not process.env.
• Variables must be prefixed with VITE_ to be exposed to the client bundle.
• .env files (e.g., .env, .env.development, .env.production, .env.[mode]) allow for environment-specific configuration.
• The --mode CLI flag explicitly controls which .env files Vite loads for development or build processes.
• Never expose truly sensitive secrets directly to the client bundle; use a backend or server-side rendering for true privacy.

Conclusion

Effectively managing environment variables is crucial for building robust and adaptable frontend applications. Vite’s clear and explicit mechanism, leveraging import.meta.env and mode-specific .env files, simplifies this process significantly. By understanding these conventions and avoiding common pitfalls, you can ensure your application behaves predictably across development, staging, and production environments, enhancing both security and developer experience. Implement these practices today to streamline your configuration workflow and enhance your application’s deployment reliability.

Hey everyone, I’ve been building an open-source workflow engine that runs natively on Kubernetes called Tiny Systems (still working on the name). Not “deployed on Kubernetes” – actually native. Flows are CRDs. Nodes are CRDs. So entire state lives in etcd. No external database.

Think n8n or Node-RED, but designed for people who already run Kubernetes and want automation that feels like part of their cluster.

Problems I’m solving right now

These are ready-to-use solutions you can clone and deploy:

• Cluster Cost Saver — scales down your deployments every evening, brings them back every morning. Dead simple, saves real money. No Lambda functions, no cronjobs, no external schedulers – just a flow inside your cluster.

• Pod Failure Alerts — watches pods in real time, catches CrashLoopBackOff, OOMKilled, image pull errors, and sends a Slack message before your users start complaining. Yes, Alertmanager exists, but I get my slack message next second after the crash (not like 1-5min it takes for prometheus chain).

• GitHub Deploy Bot — receives a webhook after CI builds an image, updates the Kubernetes deployment, posts the result to Slack. A lightweight GitOps pipeline without ArgoCD/FluxCD overhead for simpler setups. Using it for really tiny (the title!) clusters.

• Firestore to ConfigMap Sync – listens to a Firestore collection and syncs changes to a Kubernetes ConfigMap in real time. Useful for feature flags. Got idea from app managements, thought why not to use that for K8s.

• Service Status Page — a self-hosted status page that pings your endpoints and serves a page. No Statuspage.io subscription, no cron jobs, just a flow.

What workflow engine does today

You build flows visually – drag nodes, connect them, configure, deploy. Each component module runs as its own pod. Nodes in the same module talk over Go channels, across modules — gRPC. Everything stays inside your cluster.

There’s also an AI assistant that can build flows from a prompt, but that’s a story for another post.

Where I’m headed next

These are the solutions I’m planning to build:

• CronJob failure alerter — Kubernetes CronJobs fail silently. This would watch them and alert on failure via Slack or PagerDuty.
• TLS certificate expiry watcher — scan ingresses across namespaces, alert before certs expire (sometimes I miss emails from acme)
• Slack command bot — slash commands that trigger Kubernetes actions: restart a pod, get logs, scale a deployment. ChatOps without writing a bot from
  scratch.
• Webhook relay and transformer — receive webhooks from external services, reshape the payload, forward to internal services. A lightweight alternative to writing one-off HTTP handlers.

Why I’m writing this

I’ve been building in isolation for too long. The engine works. The solutions work. But I keep guessing what people actually need instead of asking.

So – if you run Kubernetes at work:

• Which of the solutions above would you actually use?
• What’s a recurring ops task you’ve been meaning to automate but haven’t?
• What’s keeping you on n8n / Airflow / bash scripts?

Thanks!

From Inline Code to OOP: What Building a Python Calculator Taught Me About Testability

I am a self-taught learner. So when I decided to build a Python calculator, I didn’t start with classes or design patterns. I started with the messiest, most beginner thing possible — everything crammed into one script. And honestly? That was the right decision.

This article is about how I evolved that calculator through three versions, and what each step taught me about writing code that’s actually testable — which matters a lot when you’re learning QA automation like I am.

👉 GitHub: https://github.com/enayetrashid/python-calculator-evolution

Version 1: The “Just Make It Work” Phase

My first version was pure chaos by design. No functions, no classes; just raw logic from top to bottom.

a = float(input("Enter first number: "))
b = float(input("Enter second number: "))
operation = input("Enter operation (+, -, *, /): ")

if operation == "+":
    print(a + b)
elif operation == "-":
    print(a - b)
elif operation == "*":
    print(a * b)
elif operation == "/":
    print(a / b)

It worked. But the moment I asked myself “how do I test this?” I had no answer. You can’t test code that demands user input just to run. This was my first real lesson:

If input and logic live together, testing becomes nearly impossible.

Version 2 — Introducing Functions

I pulled the calculation logic out into separate functions. A small change — but it changed everything.

def add(a, b):
    return a + b

def subtract(a, b):
    return a - b

Now I could write an actual test:

def test_add():
    assert add(2, 3) == 5

No input prompts. No manual interaction. Just pure logic I could verify instantly. This felt like a superpower.

The lesson: Functions are the foundation of testable code. If you can’t call it in isolation, you can’t test it properly.

Version 3 — Moving to OOP

Finally I wrapped everything in a class and added proper error handling:

class Calculator:
    def add(self, a, b):
        return a + b

    def divide(self, a, b):
        if b == 0:
            raise ZeroDivisionError("Division by zero")
        return a / b

The divide method was a turning point for me. Adding that guard clause meant I could now test failure scenarios too — not just the happy path.

def test_divide_by_zero():
    calc = Calculator()
    with pytest.raises(ZeroDivisionError):
        calc.divide(10, 0)

The lesson: OOP isn’t just about organisation — it’s about making your code extensible and testable at scale.

Why This Matters Beyond the Calculator

I’m learning QA automation, and this little project taught me something that no tutorial explained clearly:

The structure of code directly affects how easy it is to test.

In real automation work with tools like Pytest or Playwright, you never test everything in one place. You separate test logic, business logic, and test data. This calculator evolved through exactly that same pattern:

Key Takeaways

• Start simple — but don’t stay simple
• Refactoring is a skill, not just a task
• Testability should guide your design decisions from the beginning
• Even the smallest projects can teach big engineering concepts

Final Thought

This wasn’t really about building a calculator. It was about learning to think like someone who cares about quality — not just getting something to run, but building it so it can be verified.

What’s the simplest project that taught you something fundamental? I’d love to hear it in the comments.

I’m a self-taught QA learner from Bangladesh documenting my journey into software testing and automation. If you’re on a similar path, feel free to connect!

The Wasp team published something worth reading today — they gave
Claude Code the exact same feature prompt for two identical apps, one in Next.js and one in Wasp, and measured everything.

The numbers:

The last row is the interesting one. The AI wrote almost exactly
the same amount of code. But it cost 80% more to do it in Next.js.

The reason: cache creation and cache reads. Every LLM call re-reads the codebase context from scratch. A bigger codebase means every single turn costs more — not just for reading, but for loading into cache in the first place.

Next.js cache creation was 113% more expensive. Not because the AI did more. Because it had more boilerplate to read before it could start.

What this actually means

We’ve been evaluating frameworks on DX, performance, and ecosystem.
Add a new one: context efficiency.

How much of an AI’s context window goes to signal (your business logic) vs noise (framework boilerplate)?

Wasp’s declarative config means auth, routing, and jobs are defined in ~10 lines. Next.js equivalent is spread across middleware, route handlers, session files, and API directories. Same result, 4x the tokens.

The compounding problem

This test was a single feature. Real apps accumulate features. Every new route, every new model, every new API handler adds to the context that gets re-read on every single LLM call.

The performance degradation isn’t linear either — research shows that AI performance degrades well before the context window fills.
You’re not just paying more per call, you’re getting worse output.

What to do about it

1. Measure your codebase token count now.
   Run: find . -name "*.ts" -o -name "*.tsx" | xargs wc -c
   That’s roughly your AI cost baseline.

2. Audit your boilerplate ratio.
   How much of that is business logic vs glue code?
   The higher the glue ratio, the worse your AI economics.

3. Consider framework choices through this lens.
   Wasp, Rails, Laravel — highly opinionated frameworks
   have a new advantage they didn’t have 2 years ago.
   Less boilerplate = cheaper AI = faster iteration.

The irony

The same properties that make a codebase easy for humans to navigate — explicit, verbose, self-documenting — are exactly what’s expensive for AI. The abstractions we used to see as “magic” are now genuinely economical.

I’ve been thinking about this for ToolDock — a browser-based
dev tools platform I’m building. Every tool page is pure business logic with almost no framework boilerplate, because everything runs statically. The AI token efficiency on it is noticeably better than client projects I’ve worked on with heavier stacks.

Worth checking the full Wasp post for the methodology details — they open-sourced both apps and the measurement scripts, which is the right way to publish a benchmark.

What’s your current codebase token count?

Node has process permission flags like allowNet, allowFsRead, etc. The catch is that they apply to your entire running app, and we all know dependencies can get… creative.

https://github.com/bluelibs/sandboxify
npm: sandboxify
Current version: 0.0.1

The idea is pretty simple: run selected packages in a separate Node child process with restricted permissions, while keeping your app code relatively normal. Under the hood, it creates RPC-like adapters so you can call into those sandboxed packages without having to redesign your app around workers or a custom RPC layer.

So instead of fully trusting every dependency, you can isolate the ones you’d rather keep on a shorter leash.

It can sandbox:

• npm packages (including their dep trees)
• local files
• even local folders

This feels especially useful for things like PDF generation, HTML sanitizing, parsing, templating, and other workloads where:

• the dependency does meaningful work per call
• a little process-boundary/RPC overhead is acceptable
• reducing the dependency’s permissions is worth it

Performance is definitely the main tradeoff, so I tried to design around that a bit. sandboxify supports batching, and one of the more practical patterns is to move heavier logic into a local file inside the same sandbox bucket so you can export a higher-level function and do fewer cross-process calls. In other words: less chatty RPC, more useful work per hop.

That said, one practical way to reduce the overhead is to move heavier logic into a local file, put that file in the same sandbox bucket, and export a higher-level function from there. That way, instead of doing lots of tiny cross-process calls, you do fewer, heavier ones.

It’s also still early. First-class support is for ESM, and CJS support currently works in a more hacky way. Even so, it already covers a lot of scenarios.

I put together a small example here you can start playing with it:
https://github.com/theodorDiaconu/sandboxify-test

So yeah, this project is still rough around the edges, but I think the model is promising: dependency-level sandboxing in Node, without having to rebuild everything around workers or hand-rolled RPC.

• Is this something you’d actually use?
• Which dependency types feel like the best fit?
• What limitations would be a deal-breaker for you?

If nothing else, this has been a fun excuse to make untrusted code sit at the kids’ table.

I love when this ‘thing’ do stuff while I’m doing something else. We discussed, corrected plan, or it is in the middle of investigation, anyway, it’s 5+ minutes. And I want to close the lid of the laptop, but continue this thing to work.

The modern systemd allows me that. This simple script prevent laptop to go to sleep by timeout or by closed lid, as long as it’s running. Press Ctrl-C to terminate.

systemd-inhibit --what=handle-lid-switch:idle --who='manual' --why='nosleep script' sleep infinity

Bingo, you can close lid and have stuff continue to be done.

Problem

You want your application to support multiple languages (internationalization), allowing users to view content in their preferred language.

This guide shows how to implement localization in a Next.js App Router project using the next-intl library.

Step 1: Install the Library

Prerequisites

• Make sure you have Node.js and npm installed on your system.
• A Nextjs app with app router initialized.

Installation

Run the following command in the terminal:

npm install next-intl

Step 2: Configure Localization Routing

Create a folder at the root of your project named i18n, then add a file called routing.ts.

This file defines the supported locales and the default language.

i18n/routing.ts

import {defineRouting} from 'next-intl/routing';

export const routing = defineRouting({
  // A list of all locales that are supported
  locales: ['fr', 'en'],

  // Used when no locale matches
  defaultLocale: 'fr'
});

Step 3: Create Translation Files

At the root of your project, create a folder named messages.

Inside this folder, create one JSON file per supported language:

• en.json (English)
• fr.json (French)

Each file must have the same structure and keys. Only the values should differ based on the language.

⚠️ Note: JSON files must not contain trailing commas, or your app will throw errors.

messages/en.json

{
    "homepage": {
        "greetings": "Welcome",
        "navbar": {
            "appname": "Beautiful Day",
            "home": "Home",
            "services": "Services",
            "rentals": "Rentals",
            "contact": "Contact",
            "about": "About"
        }
    }
}

messages/fr.json

{
    "homepage": {
        "greetings": "Bienvenue",
        "navbar": {
            "appname": "Beautiful Day",
            "home": "Accueil",
            "services": "Services",
            "rentals": "Locations",
            "contact": "Contact",
            "about": "À Propos"
        }
    }
}

Step 4: Configure Request-Based Translations

Create a file named request.ts inside the i18n folder.

This file loads the correct translation messages based on the current locale.

This ensures that:

• The correct language is loaded per request.
• Unsupported locales fall back to the default locale.

i18n/request.ts

import {getRequestConfig} from 'next-intl/server';
import {hasLocale} from 'next-intl';
import {routing} from './routing';

export default getRequestConfig(async ({requestLocale}) => {
  // Typically corresponds to the `[locale]` segment
  const requested = await requestLocale;
  const locale = hasLocale(routing.locales, requested)
    ? requested
    : routing.defaultLocale;

  return {
    locale,
    messages: (await import(`../messages/${locale}.json`)).default

  };
});

Step 5: Set Up Dynamic Locale Routing

Create a dynamic folder named [locale] inside your app directory.

Move your layout.tsx and page.tsx into this folder.

This enables locale-based routes such as:

• /en
• /fr
• /en/services

// Folder structure
-app
   |--[locale]
          |--layout.tsx
          |--page.tsx

Step 6: Wrap Your App with NextIntlClientProvider

Update your layout.tsx to wrap your application with NextIntlClientProvider.

This makes translations available throughout your app.

Note: In some setups, you may also need to pass messages to the provider depending on how your configuration is structured.

app/[locale]/layout.tsx

import { NextIntlClientProvider, hasLocale } from "next-intl";
import { setRequestLocale } from "next-intl/server";

import { notFound } from "next/navigation";
import { routing } from "@/i18n/routing";


type Props = {
  children: React.ReactNode;
  params: Promise<{ locale: string }>;
};

export default async function LocaleLayout({ children, params }: Props) {
  const { locale } = await params;
  // Setup locale for the rest of the app.
  setRequestLocale(locale);

  // Validate locale
  if (!hasLocale(routing.locales, locale)) {
    notFound();
  }

  return (
    <NextIntlClientProvider locale={locale}>
      {/* UI that depends on locale */}
      {children}
    </NextIntlClientProvider>
  );
}

Step 7: Use next-intl Navigation Helpers

Since your app is now locale-aware, you should use navigation utilities provided by next-intl.

These helpers ensure that routing automatically includes the correct locale.

This prevents issues where navigation might ignore the current language.

i18n/navigation.ts

import {createNavigation} from 'next-intl/navigation';
import {routing} from './routing';

// Lightweight wrappers around Next.js' navigation
// APIs that consider the routing configuration
export const {Link, redirect, usePathname, useRouter, getPathname} =
  createNavigation(routing);

Step 8: Use Translations in Components

You can access translations using the useTranslations hook.

The argument passed to useTranslations defines the namespace (top-level key).

app/[locale]/page.tsx

import { useTranslations } from "next-intl";

export default function HomePage() {
    const t = useTranslations("homepage");

    return (
        <div>
        <p>{t("navbar.appname")}</p>
        <p>{t("greetings")}</p>
        <ul>
        <li>{t("navbar.home")}</li>
        <li>{t("navbar.services")}</li>
        <li>{t("navbar.rentals")}</li>
        <li>{t("navbar.contact")}</li>
        <li>{t("navbar.about")}</li>

        </ul>
        </div>
    )
}

For example:

const t = useTranslations("homepage");

This means all keys will be resolved relative to homepage.

Step 9: Configure Locale Detection with proxy.ts

Create a proxy.ts file at the root of your project.

This enables automatic locale detection and routing.

import createMiddleware from 'next-intl/middleware';
import {routing} from './i18n/routing';

export default createMiddleware(routing);

export const config = {
  // Match all pathnames except for
  // - … if they start with `/api`, `/trpc`, `/_next` or `/_vercel`
  // - … the ones containing a dot (e.g. `favicon.ico`)
  matcher: '/((?!api|trpc|_next|_vercel|.*\..*).*)'
};

This ensures that:

• Users visiting / are redirected to a default locale (e.g., /fr)
• Locale-based routing works automatically

Conclusion

In this guide, we walked through how to set up localization in a Next.js App Router project using the next-intl library. You learned how to configure routing, structure translation files, load messages dynamically, and use translations within your components.

At this stage, you can switch languages by manually navigating to different locale routes (e.g., /en, /fr). For a better user experience, consider implementing a language switcher that allows users to change languages seamlessly using a button.

With this foundation in place, you can further enhance your application by adding features such as automatic locale detection, persistent language preferences, and SEO optimization for multi-language content.

Localization is a key step toward building scalable and user-friendly applications, especially for a global audience.