{
  "id": 12821751,
  "title": "One build, every environment: runtime configuration for micro frontends",
  "url": "https://urgent.news/2026/10/08/one-build-every-environment-runtime-configuration-for-micro-frontends",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-10-08T08:10:13.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/mfeorchestrator/one-build-every-environment-runtime-configuration-for-micro-frontends-58j6"
  },
  "original_language": "en",
  "account": "In software development, building separate versions for each environment can lead to wastefulness and complications when working with micro frontends. If a build only tests the staging environment, it may not catch issues that only arise in production, such as variable spelling differences, default flag behavior, or bundle behavior dependent on the build environment. This can cause bugs to appear only in production, making troubleshooting more challenging as the initial response is \"it works on staging.\"\n\nTo address these issues, runtime configuration can be implemented, avoiding the need for separate builds for each environment. Instead, the application asks for environment-specific values at startup and receives them in a small JSON document. This approach ensures that the bundle remains identical across all environments, as the only difference is the configuration document. This approach allows for a single, identical artifact to be tested by CI and served to all environments, reducing build waste and potential failures.\n\nThe browser fetches this configuration document early in the boot sequence, allowing the application to use it before rendering starts. Keeping the response small and the cache short ensures that the configuration does not interfere with the first paint and can be updated without negatively impacting the user experience. Secrets should remain on a server, as values shipped to the client are considered public.\n\nImplementing runtime configuration is possible with popular bundlers like Vite and Webpack, as the change primarily involves switching from reading environment variables at module scope to fetching values at runtime. Even in Module Federation setups, the configuration can still be achieved by keeping remote names at build time and loading URLs from the same configuration document. This approach allows for a single build per environment, enabling quick rollbacks and reducing the time and effort needed to revert to a previous version when needed.",
  "summary": "Look at your pipeline. If it builds staging and production separately from the same commit, you are shipping an artifact nobody tested. You tested the staging one. Most of the time this is fine, right up until the day it is not — a variable spelled differently in one environment, a flag that defaulted the other way, a bundle that behaved because of something only the staging build had. The bug…",
  "key_points": [
    "Implement runtime configuration to avoid separate builds for each environment in micro frontends.",
    "Application fetches environment-specific values as a small JSON document at startup.",
    "This approach reduces build waste, potential failures, and enables quick rollbacks."
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}