Case study 13 / 17CI/CD DevOps
Single-source runtime configuration for air-gapped installations
Each offline install reads every setting from one file at startup: no rebuilds, no values baked into code, and a build guard on what ships.
Stack
- Next.js
- TypeScript
- Node.js
- PowerShell
- Windows batch
- nginx
- CesiumJS
01 · How it works
- TodaytoChanged in this work
- Data flow
What it does
The monitoring platform runs on-premises: each customer has an isolated server with no internet access, running the API, the web client, the 3D map service and two databases.
Read more
I made one set of files the single source of every setting, each value defined once and read at startup. A build guard now prevents values, and data, from being baked into the code or the package again.
7 connections· select a part to trace it
- Per-install config files to Key table: read once at startup
- Key table to API: values; names missing keys
- Per-install config files to Runtime config script: browser values at startup
- Runtime config script to Web client: loads before the app
- Key table to Build guard: lists the allowed keys
- Build guard to Release package: fails on any baked value
- Release package to Per-install config files: ships a template, no values
02Results
- R01Lower is better
Values baked into the build
Before 25, after 0, eliminated. Lower is better.BeforeAfter - R02Lower is better
Port numbers hard-coded in deployment scripts
Before 58, after 1, 58× lower. Lower is better.BeforeAfter - R03Lower is better
Install and maintenance tools failing
Before 4, after 0, eliminated. Lower is better.BeforeAfter
What it achieved
- Changing a setting: a rebuild for 25 baked-in values → edit the file and restart, for every value
- Hidden configuration: 27 code defaults, 21 unread and 41 missing template keys → 0
- Deploying to a server: the whole folder with development values → a clean copy, settings backed up first
Read more
- Field data in packages: 3.2 MB of real readings → none, enforced on the finished package
- Network isolation: 6 calls to a hosted map service with no token set → 0
The challenge
Every installation is offline and customer-owned, so every setting must be correct on the server itself. An audit of where each value originated showed the configuration files were not authoritative: browser values were baked in at build time, the API ran silently on defaults written in code, some of them real customer values, and templates and code disagreed about which keys existed.
Read more
Deployments copied development settings over the server's own, every package shipped real field readings, and even with the map token removed, the application still called a hosted map service.
What I learned
An empty setting is not the same as off: with the token empty, the map library fell back to its own default, so no token now means no hosted map at all. Guard what ships, not only the source: the build's file tracer copied every JSON file the code might read, test data included, so the check runs on the finished package.
Read more
Missing keys with a safe default warn rather than block, and a backup is never restored silently, because it could resurrect an outdated configuration.
Stack
- Next.js
- TypeScript
- Node.js
- PowerShell
- Windows batch
- nginx
- CesiumJS
Skills
- Configuration management
- Build and release engineering
- On-premises deployment
- Security hygiene
- Code auditing
