Aias00 opened a new issue, #7652: URL: https://github.com/apache/shenyu/issues/7652
## Feature request Allow ShenYu Bootstrap to start with declarative configuration from a local file and serve configured traffic without running ShenYu Admin, an Admin database, or an external configuration center. This supports small deployments, local development, container-mounted configuration and Git-managed configuration. The file should be the configuration source for this mode. Starting an empty gateway and then posting configuration through its HTTP management API is not the requested end state. ## Current behavior and reuse opportunities Reviewed commit: `b4e115367fd57adc8aba332d655b1009932ba394` (source inspection; no Admin-free deployment test was run). - [LocalPluginController](https://github.com/apache/shenyu/blob/b4e115367fd57adc8aba332d655b1009932ba394/shenyu-web/src/main/java/org/apache/shenyu/web/controller/LocalPluginController.java#L254) already applies local plugin/selector/rule/upstream data through subscribers. Local metadata and application-auth controllers exist as well. - [`shenyu.local.enabled`](https://github.com/apache/shenyu/blob/b4e115367fd57adc8aba332d655b1009932ba394/shenyu-spring-boot-starter/shenyu-spring-boot-starter-gateway/src/main/java/org/apache/shenyu/springboot/starter/gateway/ShenyuConfiguration.java#L182) controls local management API dispatch. It is not a file configuration loader, and local API changes live in memory. - [WebSocket sync auto-configuration](https://github.com/apache/shenyu/blob/b4e115367fd57adc8aba332d655b1009932ba394/shenyu-spring-boot-starter/shenyu-spring-boot-starter-sync-data-center/shenyu-spring-boot-starter-sync-data-websocket/src/main/java/org/apache/shenyu/springboot/starter/sync/data/websocket/WebsocketSyncDataConfiguration.java#L46) activates from the presence of `shenyu.sync.websocket.urls`; the default bootstrap configuration contains an Admin URL. - [Bootstrap defaults](https://github.com/apache/shenyu/blob/b4e115367fd57adc8aba332d655b1009932ba394/shenyu-bootstrap/src/main/resources/application.yml#L223) also include Admin heartbeat settings. A file mode must explicitly handle these defaults rather than assume that enabling local management disables synchronization. - Gateway plugins already consume runtime caches populated by subscribers, so file loading can reuse the existing request-processing engine. ## Proposed initial scope 1. Add an opt-in file configuration source with a separately selectable starter/auto-configuration, using existing project dependencies where practical. 2. Support a documented external YAML configuration file; JSON may be supported if inexpensive with existing tooling. Keep the application runtime settings distinct from the declarative gateway configuration and provide a complete example. 3. Translate file entries into existing configuration DTOs and apply them directly through subscribers/plugin data handlers. Do not call the gateway's own HTTP endpoints during initialization or bypass handler/cache initialization. 4. Start with explicit plugin enablement/configuration, selectors, rules and static HTTP upstreams. Document the supported schema. Define how metadata and application-auth entries are represented when needed; reject unsupported entries clearly instead of silently ignoring them. 5. Use stable, deterministic object identities and validate duplicate IDs, references, plugin availability, ordering and handler schemas before applying configuration. Loading the same file after a restart must reproduce the same routes. 6. Make file mode mutually exclusive with Admin/external-sync configuration sources in the first version. Resolve inherited bootstrap sync defaults explicitly, and do not create Admin sync connections, heartbeat calls or Admin-dependent readiness checks in file mode. 7. Complete file validation and application before marking the gateway ready. Missing/invalid files or application failures must prevent readiness and surface a clear startup error. No business traffic should be accepted as ready with partially applied configuration. 8. Reuse existing configuration/environment mechanisms for sensitive values, avoid logging secrets, and do not require enabling local HTTP management APIs for file loading. Define whether those APIs are disabled or rejected as conflicting writers in file mode. 9. Preserve existing Admin-managed behavior when file mode is not selected. Document activation, deployment, supported features and how to switch configuration modes. Automatic watching/hot reload, file write-back, multiple-source merging and a new routing engine are outside the initial delivery. A later reload feature should validate before publication and retain the previous valid configuration on failure. ## Acceptance criteria - [ ] A clean, documented launch command starts bootstrap with a mounted configuration file, no Admin process/database and no external sync service. - [ ] An end-to-end test proves HTTP route matching, static upstream forwarding, plugin enablement and a failed/unmatched request. - [ ] A test starts with the normal bootstrap defaults present and confirms file mode does not create or attempt Admin sync/heartbeat traffic. - [ ] Startup/readiness remains unsuccessful for missing/malformed files, duplicate identities, invalid references, missing required plugins and configuration application failures. - [ ] Restarting with the same file restores equivalent configuration without duplicate selectors/rules or generated identity drift. - [ ] Supported metadata/auth behavior and unsupported capabilities are explicit and tested where included. - [ ] Configuration ownership is enforced: no silent overwrite by Admin sync or local management APIs. - [ ] Existing Admin-managed startup/synchronization tests continue to pass; no file-mode defaults are imposed on existing users. - [ ] Example YAML, schema/validation behavior and deployment/mode-switching instructions are included. No benchmark gain is claimed without measurement. ## Related - #7649 — minimal HTTP gateway distribution; a useful companion, but file mode is a distinct runtime capability and should not depend on a full packaging redesign. - #7650 — performance baseline and optimization tracking. This issue primarily improves deployment independence and declarative configuration, not measured request throughput. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
