Back to browse
REP – build-once, with secure runtime env variables for front end apps

REP – build-once, with secure runtime env variables for front end apps

by olamide226·Mar 2, 2026·1 point·1 comment

AI Analysis

●●●BangerWizardrySolve My ProblemSlick

Finally fixes the frontend environment variable problem: one Docker image, any config, encrypted secrets at runtime.

Strengths
  • Inverts the build-time env problem with a reverse-proxy gateway—eliminating Docker image-per-environment waste and secret-in-build-logs risks
  • Three-tier classification (PUBLIC/SENSITIVE/SERVER) + automatic entropy scanning catches misconfigurations before deployment; strict mode makes this fail-safe
  • Hot config reload via SSE means feature flags and secret rotation without rebuild/redeploy—solves a genuine DevOps friction point that Dockerfile/ARG cannot
Weaknesses
  • Requires reverse proxy infrastructure (nginx, Caddy) or stateless frontend setup; not applicable to SSR frameworks or backends that pre-render with env values
  • No comparison to existing solutions (Doppler, Vault, AWS Secrets Manager integration via init containers)—marketing positions it against 'hacks' but doesn't benchmark real-world alternatives
Target Audience

Backend / DevOps engineers deploying containerized frontend applications with environment-specific secrets

Similar To

Doppler · HashiCorp Vault · Sealed Secrets (Kubernetes)

Post Description

Hey HN,

Every frontend framework bakes environment variables into the JavaScript bundle at build time (process.env, import.meta.env). This means your Docker image is environment-specific — you build one for staging, another for prod, and the image you tested is never the one you deploy.

I built REP (Runtime Environment Protocol) to fix this. It's a lightweight Go gateway (~6MB binary, zero deps) that sits in front of your static file server and injects env vars into HTML responses at container startup.

What makes it different from the dozens of window.__ENV__ hacks:

- Three-tier security classification: REP_PUBLIC_* (plaintext), REP_SENSITIVE_* (AES-256-GCM encrypted, decrypted via short-lived session key), REP_SERVER_* (never reaches the browser)

- Automatic secret detection — scans PUBLIC vars for high-entropy strings, AWS keys, JWTs, etc. and refuses to start in strict mode

- HMAC integrity verification on every payload

- Optional hot config reload via SSE

- Works with any SPA (React, Vue, Svelte, Angular, vanilla) — no build tool plugins

- FROM scratch compatible — the binary is all you need

The SDK is ~1.5KB gzipped and gives you synchronous access (rep.get('API_URL')) for public vars and async decryption (await rep.getSecure('KEY')) for sensitive ones.

Full RFC-style spec, security threat model, and reference implementation: https://rep-protocol.dev

I'd especially love feedback on the security model — I've tried to be honest about what the SENSITIVE tier actually protects against vs what it doesn't. The threat model doc doesn't pretend browser-side encryption is bulletproof.

Built this because I got tired of watching every team I've worked with reinvent the same env.sh → window.__ENV__ hack with zero security thought behind it.

Similar Projects

DesignMid

Japanese ma is the most underrated design system in front end

The visual concept is strong: generous negative space, a micro-typographic centerline and restrained UI that actually sells the idea of 'ma'. Unfortunately the page reads like a demo/theme — repeated copy blocks and zeroed stats suggest placeholder content rather than a finished system or component library. Useful as a quiet starting point for designers who like minimalism, but it needs real docs, components and examples to move beyond a pretty landing.

Eye CandyNiche Gem
Dontizi
204mo ago