DEV Community: SrijanCodes

Catching config drift before it breaks prod

SrijanCodes — Sun, 11 Oct 2026 14:49:49 +0000

It's 5pm on a Friday. CI is green, tests pass, the image is built. You deploy — and the app
crashes on boot because DATABASE_URL isn't set in the environment. It was in the .env on
your machine. It just never made it into the Kubernetes deployment. Nobody notices, because
nothing checks that the three places agree.

This is config drift, and it's one of the most common causes of "it worked on my machine."

Why `.env` linters don't catch this

Most env-var tooling validates a .env file against a schema you write by hand. That
schema drifts too, and — crucially — it doesn't know what your code actually reads.
If someone deletes a key your app requires, or mistypes DB_HOST as DBHOST, the linter is
happy because the file matches the schema.

The source of truth is your code. So I built a linter that reads it.

What conflint does

conflint parses your source to find every env var /
config key your app actually reads, then reconciles that set against every place the value
should exist — .env, docker-compose, GitHub Actions, Kubernetes and Terraform.

It knows:

Rule	Meaning
CL001	read in code, defined nowhere
CL002	defined for real, never read by code
CL003	undefined name is one edit away from a known one (typo)
CL004	high-entropy secret committed in a config source
CL005	documented in `.env.example` but no real source provides it (drift)
CL006	required value defined but empty
CL007	defined twice / conflicting across sources
CL008	secret equals a weak/default placeholder
CL009	used or provided, but undocumented in the example file

Scanners today: Python (AST), JavaScript/TypeScript, Go, Ruby.

A concrete example

Say your app looks like this:

# app.py
import os

DATABASE_URL = os.environ["DATABASE_URL"]
API_KEY = os.getenv("API_KEY")
REDIS_URL = os.environ.get("REDIS_URL", "redis://localhost:6379")

and your .env looks like this:

API_KEY=sk-live-4f9a2b7c8d1e6f3a5b0c9d8e7f6a5b4c
DATABSE_URL=postgres://localhost:5432/app

Running confl check gives you:

conflint checked 2 files (3 config reads, 2 definitions) in 7ms

.env:1:1
  CL004 error: 'API_KEY' looks like a committed secret in dotenv:1
    hint: Move real secrets to a secrets manager; keep placeholders in .env.example

app.py:3:16
  CL001 error: 'DATABASE_URL' is read in code but not defined in any configuration source:3
    hint: Add it to your .env (then run `confl sync` to refresh .env.example)

app.py:5:13
  CL001 warning: 'REDIS_URL' is read in code but not defined in any configuration source:5
    hint: Add it to your .env (then run `confl sync` to refresh .env.example)

2 files checked - 2 errors, 3 warnings, 0 infos

Three real problems caught in 7 milliseconds: a committed secret, a missing required variable,
and (implicitly) a typo — note DATABSE_URL is defined but never read, which is why
DATABASE_URL is "missing."

Quickstart

pip install conflint
confl check            # lint the whole project
confl sync             # regenerate an accurate .env.example
confl explain DATABASE_URL   # who reads it? where is it defined?

Wire it into CI and pre-commit

GitHub Action (inline PR annotations):

- name: Lint configuration
  uses: conflint/conflint@v0.1.2
  with:
    reporter: github
    fail-level: error

Or a pre-commit hook:

- repo: https://github.com/conflint/conflint
  rev: v0.1.2
  hooks:
    - id: conflint

Output formats: text, --json (stable schema), --sarif (GitHub/GitLab/Azure code scanning),
--github (workflow annotations), and JUnit XML for Jenkins.

Honest limitations

It's early (v0.1.2, MIT). The rule set and source coverage are opinionated and evolving.
Static analysis means it infers reads; dynamically constructed keys (e.g. os.environ[prefix + x]) can't be resolved and may need ignore-names.
It's not a secret scanner replacement — it catches secrets specifically in config sources, not across full git history (use gitleaks/trufflehog for that).

Try it / feedback

Repo: https://github.com/conflint/conflint
Docs: https://conflint.readthedocs.io
PyPI: https://pypi.org/project/conflint

I'd love feedback on the rule set and which scanners/sources to add next. If it's useful,
a ⭐ helps others find it.

Afterlight Atlas: Designing Planetary Futures

SrijanCodes — Sat, 18 Apr 2026 21:57:53 +0000

This is a submission for Weekend Challenge: Earth Day Edition

What I Built

I built Afterlight Atlas, a cinematic Earth Day web experience for imagining, comparing, and presenting better planetary futures.

A lot of climate tools are useful, but they often focus on damage, guilt, or optimization. I wanted to build something that answered a different question:

What does a repaired future actually feel like?

So instead of making another carbon calculator or eco dashboard, I made an interactive world-building instrument where people can:

choose a future seed such as Mycelial City, Tidal Commons, Canopy Republic, or Solar Bazaar
tune seven planetary levers across energy, mobility, food, water, materials, biodiversity, and civic care
watch a live world respond through narrative, metrics, atmosphere, and visual tone
compare that future against a baseline and immediately see whether it is actually stronger

The part I think makes this project stand out is that Afterlight Atlas is not just a pretty sustainability interface.

It does four things at once:

It makes climate action feel emotionally tangible.
The app turns policy and infrastructure choices into a world you can feel through tone, language, atmosphere, and future storytelling.
It frames sustainability as composition, not punishment.
You are not being told how bad things are. You are composing a better civilization and seeing how different systems reinforce each other.
It gives judges a fast evaluation layer.
The app includes Judge Mode, which compares the active future against either the seed baseline or a saved alternate scenario and explains the delta clearly.
It works as both a product and a presentation.
It includes Present Mode, saved snapshots, comparison export, and a one-click Best Future preset so it can be explored, pitched, and judged quickly.

Core features:

four original future seeds with distinct climate philosophies
seven adjustable planetary levers
live planet score and world-state generation
six speculative systems signals: atmosphere, biodiversity, community, ocean, circularity, and heat
story-rich future dispatches instead of dry dashboard copy
three-horizon future timelines for 2035, 2060, and 2085
repair rituals that turn the scenario into grounded action prompts
save/load alternate futures
Judge Mode for baseline comparison
Present Mode for cleaner walkthroughs
exportable comparison card image
one-click Best Future preset

Demo

Live app:

https://afterlight-atlas.vercel.app/

The app is fully deployed and ready to explore in the browser.

Code

GitHub repository:

https://github.com/ionfwsrijan/Afterlight-Atlas

Key files:

src/main.ts for rendering, interactions, Judge Mode, Present Mode, sharing actions, and export flows
src/engine.ts for world derivation, scoring, baseline comparison, and share-state helpers
src/data.ts for world seeds, lever metadata, and theme definitions
src/style.css for the editorial UI system and presentation layer

How I Built It

I started with one strong constraint:

If judges only spend a short time on each project, the experience needs to explain itself almost immediately.

That shaped the build in a few important ways.

1. I avoided the default Earth Day pattern

The obvious path would have been a calculator, green tips app, or climate dashboard.

Instead, I designed Afterlight Atlas as a speculative climate composition instrument. That let me build something more memorable, more visual, and more emotionally resonant while still staying grounded in meaningful systems like energy, mobility, water, biodiversity, and care.

2. I made Judge Mode a first-class feature

One of the hardest parts of any challenge entry is not just making something good, but making it easy to judge.

So I built Judge Mode, which compares the current world against either:

the original seed baseline
a saved alternate snapshot

It then surfaces:

score delta
strongest gain
main watchout
metric swings
lever shifts
a verdict
a recommendation

That means a judge does not have to guess why one version is better. The app tells them.

3. I optimized for fast evaluation

Challenge judges usually review a lot of projects quickly, so I added presentation-oriented features that reduce friction:

Present Mode for a cleaner walkthrough
Export Comparison Card for a pitch-friendly PNG
Best Future for a one-click strong scenario

Together, those features make the project faster to understand and easier to remember.

4. I treated Earth Day as both emotional and technical

I wanted the project to fit the Earth Day theme more deeply than just using green colors and eco language.

Emotionally, it fits because it is about hope, repair, stewardship, and imagination. It asks users to picture what a healthier relationship with the planet could feel like in everyday life.

Technically, it fits because the underlying levers and comparisons are built around real systems-level concerns:

distributed clean energy
lower-emission mobility
watershed resilience
circular material flows
biodiversity recovery
civic resilience and care

So the project is not just atmospheric. It is structured around meaningful planetary systems.

5. I kept the simulation honest

Afterlight Atlas is a speculative decision-and-storytelling interface, not a climate science model.

The goal is not to predict the future precisely. The goal is to make tradeoffs, futures, and systemic thinking vivid enough that people can compare them, discuss them, and care about them.