惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

博客园_首页
B
Blog
V
V2EX
T
Tailwind CSS Blog
Hugging Face - Blog
Hugging Face - Blog
博客园 - 【当耐特】
博客园 - 聂微东
博客园 - 叶小钗
博客园 - 三生石上(FineUI控件)
The Cloudflare Blog
J
Java Code Geeks
H
Help Net Security
雷峰网
雷峰网
Apple Machine Learning Research
Apple Machine Learning Research
H
Hackread – Cybersecurity News, Data Breaches, AI and More
Engineering at Meta
Engineering at Meta
F
Fortinet All Blogs
Martin Fowler
Martin Fowler
D
Docker
L
LangChain Blog
人人都是产品经理
人人都是产品经理
爱范儿
爱范儿
WordPress大学
WordPress大学
V
Visual Studio Blog

DEV Community

Authentication Security Deep Dive: From Brute Force to Salted Hashing (With Java Examples) Why AI Systems Don’t Fail — They Drift Spilling beans for how i learn for exam😁"Reinforcement Learning Cheat Sheet" I Replaced Chrome with Safari for AI Browser Automation. Here's What Broke (and What Finally Worked) How Python Borrows Other People's Work The $40 Architecture: Processing 1 Billion API Requests with 99.99% Uptime Vibe Coding: A Workflow Guide (From Zero to SaaS) Most webhook security guides protect the wrong side. The scary part is delivery. Headless CMS for TanStack Start: Build a Blog with Cosmic EU Age Verification App "Hacked in 2 Minutes" — What Actually Happened Comfy Cloud’s delete function does not actually remove files Running AI Models on GPU Cloud Servers: A Beginner Guide Event-driven media intelligence with AWS Step Functions and Bedrock I scored 500 AI prompts across 8 quality dimensions — here's what broke How to Call Google Gemini API from Next.js (Free Tier, No Backend Needed) The Portal Protocol: Reclaiming Human Connection in the Age of AI How to Fix Your Team's Scattered Knowledge Problem With a Self-Hosted Forum Intro to tc Cloud Functors: A Graph-First Mental Model for the Modern Cloud Designing Multi-Tenant Backends With Both Ownership and Team Access I Built a Neumorphic CSS Library with 77+ Components — Here's What I Learned PostgreSQL Performance Optimization: Why Connection Pooling Is Critical at Scale Cómo construí un SaaS multi-rubro para gestionar expensas en Argentina con FastAPI + Vue 3 🚀 I Built an Ethical Hacking Scanner Tool – Open Source Project I Replaced /usage and /context in Claude Code With a Single Statusline A Pythonic Way to Handle Emails (IMAP/SMTP) with Auto-Discovery and AI-Ready Design I Collected 8.9 Million Polymarket Price Points — Here's What I Found About How Markets Really Move EcoTrack AI — Carbon Footprint Tracker & Dashboard Everyone's Using AI. No One Agrees How. 5 self-hosted ebook managers worth trying in 2026 Building Your First AI Agent with LangChain: From Chatbot to Autonomous Assistant
I Built My Own Config Format for Node.js That Separates S...
KANISHQ R PU · 2026-05-12 · via DEV Community

The problem with dotenv that nobody talks about, and how I fixed it with kq-config.


The Problem

Every Node.js project I've worked on has the same setup:

DB_PASS=supersecret
SECRET_KEY=myjwtsecret
API_URL=http://localhost:3000
THEME=dark
PORT=3000

Enter fullscreen mode Exit fullscreen mode

One .env file. Everything in one place. Server secrets, client settings, database passwords, all mixed together.

This works fine until we think: who can see what?

Your frontend code runs process.env.API_URL, works fine. But what stops it from also reading process.env.DB_PASS? In most setups, nothing. The same object holds everything.

I kept thinking: why do we give everyone access to everything?


The Idea

What if your config file had separate blocks: one for the server, one for the client, and each side could only read its own?

config.kq
├── ::shared     → merged into both
├── ::server     → server only
└── ::client     → client only

Enter fullscreen mode Exit fullscreen mode

Server reads ::server. Client reads ::client. Neither can see the other's block.

I built this as an npm package called kq-config. The .kq extension stands for Konfig Query, and comes from the first and last letters of my name, Kanishq.


What it looks like

Create a single config.kq file:

@version = 1.0

::shared
  app_name = MyApp
  version  = 1.0
::end

::server
  host       = localhost
  port       = 3000
  db_host    = localhost
  db_name    = mydb
  db_user    = $ENV:DB_USER
  db_pass    = $ENV:DB_PASS
  secret_key = $ENV:SECRET_KEY
  debug      = true
  log_level  = info
::end

::client
  api_url = http://localhost:3000
  theme   = dark
  timeout = 5000
  retry   = 3
::end

Enter fullscreen mode Exit fullscreen mode

Then in your code:

const { KQParser } = require("kq-config");
const path = require("path");

// Server reads ::shared + ::server only
const server = new KQParser(
  path.join(__dirname, "config.kq"),
  "server"
).load();

console.log(server.get("port"));    // 3000
console.log(server.get("db_pass")); // "supersecret" (from .env)

// Client reads ::shared + ::client only
const client = new KQParser(
  path.join(__dirname, "config.kq"),
  "client"
).load();

console.log(client.get("api_url")); // "http://localhost:3000"
console.log(client.get("db_pass")); // undefined, client can NEVER see this

Enter fullscreen mode Exit fullscreen mode

The database password is invisible to the client. Not hidden by convention but blocked by design.

Note: add .env in the same path for DB_USER,DB_PASS,SECRET_KEY


Built-in .env support, no dotenv needed

kq-config automatically finds and loads .env from the same folder as your config.kq file. You don't need to install or configure dotenv:

your-project/
├── config.kq
└── .env        ← loaded automatically

Enter fullscreen mode Exit fullscreen mode

// No require("dotenv").config() needed
const server = new KQParser("config.kq", "server").load();
// $ENV: variables resolved from .env automatically

Enter fullscreen mode Exit fullscreen mode


Environment overrides

Create config.prod.kq with only what changes in production:

::server
  host      = 0.0.0.0
  port      = 8080
  db_host   = prod-db.example.com
  debug     = false
  log_level = warn
::end

::client
  api_url = https://api.example.com
::end

Enter fullscreen mode Exit fullscreen mode

Load it based on APP_ENV:

const env = process.env.APP_ENV || "development";

const overrides = {
  production: "config.prod.kq",
  staging:    "config.staging.kq",
};

const overrideFile = overrides[env]
  ? path.join(__dirname, overrides[env])
  : null;

const server = new KQParser("config.kq", "server", overrideFile).load();

Enter fullscreen mode Exit fullscreen mode

node server.js                    # development → port 3000
set APP_ENV=production&node server.js # cmd:production  → port 8080
$env:APP_ENV="production"; node server.js # powershell:production  → port 8080

Enter fullscreen mode Exit fullscreen mode


Schema validation

Validate your config at startup. Fail immediately with clear errors instead of mysterious crashes later:

const server = new KQParser("config.kq", "server")
  .load()
  .validate({
    host:       { type: "string",  required: true },
    port:       { type: "number",  required: true },
    secret_key: { type: "string",  required: true },
    debug:      { type: "boolean", required: false, default: false },
    log_level:  { type: "string",  required: false, default: "info" },
  });

Enter fullscreen mode Exit fullscreen mode

If anything is wrong, you get all errors at once:

KQValidationError: Config validation failed for role 'server':
  ✗ Required key 'secret_key' is missing in [server] config.
  ✗ 'port' — expected number, got string (value: "3000")

Enter fullscreen mode Exit fullscreen mode


Runtime overrides

Override any value without touching any file:

$env:KQ_SERVER_PORT=9999; node server.js
$env:KQ_CLIENT_THEME="light"; node server.js

Enter fullscreen mode Exit fullscreen mode

Pattern: KQ_<ROLE>_<KEY>=value. Values are automatically type-cast.


AES-256-GCM encryption — built in

This is where it gets interesting. You can store encrypted secrets directly in your config file:

Step 1 : Generate a master key:

node -e "console.log(require('crypto').randomBytes(32).toString('hex'))"
# 3a7bd3e2360a3d29eea436fcfb7e44c735d117c7888a8660b1e5c8c51b9ff59f

Enter fullscreen mode Exit fullscreen mode

Step 2 : Encrypt your secrets:

const { KQParser } = require("kq-config");

process.env.KQ_MASTER_KEY = "3a7bd3e2...";
const enc = KQParser.encrypt("mysupersecretpassword");
// → ENC:aGVsbG8gd29ybGQ=:abc123:xyz456

Enter fullscreen mode Exit fullscreen mode

Step 3 : Put it in config.kq:

::server
  db_pass = ENC:aGVsbG8gd29ybGQ=:abc123:xyz456
::end

Enter fullscreen mode Exit fullscreen mode

Step 4 : Load as normal — decryption is automatic:

const server = new KQParser("config.kq", "server").load();
server.get("db_pass"); // "mysupersecretpassword" 

Enter fullscreen mode Exit fullscreen mode

Even if someone gets your config.kq — they cannot read the secrets without KQ_MASTER_KEY.


Secret masking

Prevent secrets from leaking into logs:

server.all();       // { port: 3000, db_pass: "supersecret" }
server.all(true);   // { port: 3000, db_pass: "***MASKED***" } 

// Or always mask
new KQParser("config.kq", "server", null, { mask: true })

Enter fullscreen mode Exit fullscreen mode


Auto type casting

Everything from a config file is a string — but kq-config automatically casts types:

Value in file Parsed as
3000 3000 (number)
true / false true / false (boolean)
null null
"hello world" "hello world" (quotes stripped)

So server.get("port") gives you a real number, not "3000".


Security protections built in

kq-config has professional-grade security with zero extra configuration:

  • Path traversal../../etc/passwd attacks blocked
  • Prototype pollution__proto__, constructor keys blocked
  • ReDoS — values over 10,000 chars rejected
  • Memory exhaustion — files over 1MB rejected
  • Null byte injection — null bytes in values blocked
  • Env hijacking.env cannot overwrite NODE_OPTIONS, PATH etc.
  • Zero dependencies — no supply chain attack surface

- npm provenance — every release cryptographically signed

TypeScript support

Full type definitions included:

import { KQParser, KQSchema, KQOptions } from "kq-config";

const schema: KQSchema = {
  port:  { type: "number", required: true },
  debug: { type: "boolean", required: false, default: false },
};

const server = new KQParser("config.kq", "server")
  .load()
  .validate(schema);

const port = server.get("port") as number;

Enter fullscreen mode Exit fullscreen mode


ESM and CJS

Works with both import and require:

// CommonJS
const { KQParser } = require("kq-config");

// ES Module
import { KQParser } from "kq-config";

Enter fullscreen mode Exit fullscreen mode


The full feature list

  • Block separation — ::server / ::client / ::shared
  • Built-in .env loading — no dotenv needed
  • $ENV:VAR injection — secrets never hardcoded
  • ENC: encryption — AES-256-GCM built in
  • Secret masking — ***MASKED*** in logs
  • Raw secret detection — warns on plain secrets
  • Layered overrides — dev → staging → prod
  • Runtime overrides — KQ_SERVER_PORT=9999
  • Schema validation — required, type, default
  • Auto type casting — numbers, booleans, null
  • TypeScript types — full definitions
  • ESM + CJS — both supported

- Zero dependencies — nothing to audit

Install

npm install kq-config

Enter fullscreen mode Exit fullscreen mode

GitHub: github.com/kanishq-9/kq-config

npm: npmjs.com/package/kq-config


Why I built this

I was tired of the same pattern in every project, one flat list of environment variables, no structure, no separation, no way to know which values are safe to expose to the frontend and which ones would be catastrophic if leaked.

The .kq format is my answer to that. One file, clear blocks, each side reads only what it needs. The encryption came from realizing that even .env files can be accidentally committed, so why not make the secrets safe to commit?

If you try it out, let me know what you think. Issues and PRs are welcome on GitHub.