# dk-flags Developer Reference Wiki > dk-flags is a Docker image factory that ships a fully pre-seeded FeatureHub party-server for Dark Kitchen local development and integration testing. The image uses a modular Node.js pipeline executed at build time to initialize admin credentials, portfolios, and typed feature flags via the FeatureHub Management REST API — so containers start ready to use with no post-start setup. This is a Grok-Wiki source-grounded repository wiki. Use the complete Markdown link when an agent needs the full repo context. ## Context Links - [Complete Markdown wiki](https://grok-wiki.com/public/wiki/vtex-dk-flags-0a8c140c3cfa/llms-full.txt) - [Complete Markdown alias](https://grok-wiki.com/public/wiki/vtex-dk-flags-0a8c140c3cfa.md) - [Human interactive wiki](https://grok-wiki.com/public/wiki/vtex-dk-flags-0a8c140c3cfa) - [GitHub repository](https://github.com/vtex/dk-flags) ## Repository - Repository: vtex/dk-flags - Generated: 2026-05-26T16:12:12.802Z - Updated: 2026-05-26T16:22:04.251Z - Runtime: Claude Code - Format: Technical - Pages: 6 ## Pages - [Technical Orientation](https://grok-wiki.com/public/wiki/vtex-dk-flags-0a8c140c3cfa/pages/01-technical-orientation.md): What dk-flags is, its core purpose, the build-time initialization strategy, the module layout, and how the rest of this reference is organized. Entry point for any engineer onboarding to the repo. - [Image Build & Runtime Lifecycle](https://grok-wiki.com/public/wiki/vtex-dk-flags-0a8c140c3cfa/pages/02-image-build-runtime-lifecycle.md): How the Dockerfile extends featurehub/party-server:latest, how build-setup.sh temporarily starts and stops the embedded party-server during docker build to run the setup pipeline, and how entrypoint.sh launches the server at runtime with no re-initialization. Covers the build-time vs run-time env var contract and the server discovery fallback chain. - [HTTP Client, Readiness Probe & Authentication](https://grok-wiki.com/public/wiki/vtex-dk-flags-0a8c140c3cfa/pages/03-http-client-readiness-probe-authentication.md): The api.js module: makeRequest() signature, Bearer token injection, JSON vs text response handling, and the waitForApp() readiness loop (60 s MAX_WAIT_TIME). The auth.js module: the two-phase authenticate() flow — initializeAdmin() via POST /mr-api/initialize, falling back to login() via POST /mr-api/login when the system is already bootstrapped. Token extraction and propagation to downstream calls. - [Portfolio, Application & Feature Flag Provisioning](https://grok-wiki.com/public/wiki/vtex-dk-flags-0a8c140c3cfa/pages/04-portfolio-application-feature-flag-provisioning.md): portfolio.js: getPortfolio() (selects the first portfolio from GET /mr-api/portfolio), createApplication() (POST to portfolio endpoint), getEnvironment() (resolves default environment). features.js: the createAllFeatures() orchestration loop — createFeature() (idempotent, 409 treated as skipped), unlockBooleanFlag() (BOOLEAN-only unlock step via PUT feature-environments), setFeatureValue() (typed value dispatch: valueBoolean / valueString / valueNumber / valueJson), and the created/skipped/errors summary. flags.js: loadFlags() 4-path search strategy. - [Flag Definition Schema & Supported Types](https://grok-wiki.com/public/wiki/vtex-dk-flags-0a8c140c3cfa/pages/05-flag-definition-schema-supported-types.md): The exampleFlags.json contract: required fields (key, type, defaultValue), optional fields (name, description), and the four supported type values (BOOLEAN, STRING, NUMBER, JSON). How each type maps to a typed value field in the FeatureHub API (valueBoolean, valueString, valueNumber, valueJson). The special BOOLEAN unlock step. How to add, remove, or change seed flags and rebuild. The seven seed flags shipped by default. - [Build, Deploy & Extension Points](https://grok-wiki.com/public/wiki/vtex-dk-flags-0a8c140c3cfa/pages/06-build-deploy-extension-points.md): How to build (docker build -f docker/Dockerfile) and run (docker run -p 8085:8085) the image with default and overridden env vars. The CI/CD pipeline: dkcicd build-and-push-image-v1 on push to main, publishing to AWS ECR account 053131491888 / us-east-1 / dk-flags-party-server:0.0.1. Production endpoint https://flags.vtex.com/. Backstage catalog registration (te-0034 / OG35ZXTZ). Downstream OpenFeature SDK consumers. Known risks: floating base image tag, mutable 0.0.1 ECR tag, build-time-only admin baking. Outstanding follow-ups from the spec: reconcile package.json#main, make portfolio/org/app names env-overridable, pin the base image. ## Source Files - `.vtex/catalog-info.yaml` - `.vtex/deployment.yaml` - `docker/api.js` - `docker/auth.js` - `docker/build-setup.sh` - `docker/config.js` - `docker/Dockerfile` - `docker/entrypoint.sh` - `docker/exampleFlags.json` - `docker/features.js` - `docker/flags.js` - `docker/package.json` - `docker/portfolio.js` - `docker/run-setup.sh` - `docker/setup.js` - `README.md` - `specs/dk-flags-party-server-image.md`