Product Decisions This Supports
- Build vs. buy for a runtime settings layer. This package represents the "buy" (well, "borrow") option for a specific problem: application settings that live in a datastore rather than in code, editable by admins without a deploy. Evaluating it forces the real question — is a settings service worth a dependency, or is it a 200-line key-value table plus a cache?
- Where configuration lives in the architecture. ONGR Settings stores settings as Elasticsearch documents organized into categories, resolved through a service. That's a meaningful architectural stance: settings become queryable, searchable, and versionable infrastructure rather than flat files. That supports roadmap decisions about admin-configurable behavior, per-tenant overrides, and operational tuning without releases.
- Multi-tenant and per-environment configuration strategy. The category/document model hints at scoping settings by namespace or tenant. If multi-tenancy is on the roadmap, this is a reference design worth studying even if the code isn't adopted.
- Defer vs. invest in an admin configuration UI. A settings bundle implies a CRUD surface for non-engineers. That's a product commitment (support burden, permissions, audit trail), not just a library choice — decide deliberately whether PMs/support staff get to change behavior in production.
- Dependency risk posture. Seven stars, zero dependents, last release October 2016, MIT. This is an abandoned artifact. Using it signals a decision about how much legacy risk the team will absorb for a non-differentiating capability.
Recommendation for the decision log: treat this as a design reference, not a dependency. It solves a real product problem (dynamic configuration) with a credible model (categorized, searchable setting documents), but it is a Symfony 2/3-era bundle bound to the ONGR Elasticsearch bundle — it will not drop into a Laravel application, and its Elasticsearch client assumptions are almost certainly incompatible with current ES versions.
When to Consider This Package
Consider it only when all of the following hold:
- The application is Symfony 2.x/3.x and already runs ONGR ElasticsearchBundle — the coupling is not incidental; the settings documents are ES documents managed by that bundle.
- You need admin-editable, categorized settings with search, and you want to avoid designing the storage schema yourself.
- The settings surface is small and stable — a handful of categories, low write volume, tolerant of eventual consistency.
- You are comfortable vendoring or forking an unmaintained MIT package and owning it, including PHP 7.x and Elasticsearch 1.x/2.x era compatibility work.
- You are doing archaeology or reference reading — extracting the category/service abstraction for your own implementation.
Look elsewhere — decisively — when:
- The stack is Laravel or any non-Symfony framework. There is no service provider, no facade, no compatible container wiring; you would be rewriting the useful 20% anyway.
- You are on PHP 8.x or Elasticsearch 7/8. Assume incompatibility until proven otherwise; the effort to modernize exceeds writing a fresh settings service.
- Your need is static or deploy-time configuration. Use env vars, config files, or a secrets manager. Elasticsearch for key-value config is over-engineering with an operational bill attached.
- You need maintained code: security patches, typed settings, schema validation, audit logs, or a support path. Zero dependents means zero community pressure to fix anything.
- You need transactional or strongly consistent reads of settings on every request. A remote ES query per settings read is a latency and availability liability; a cached database table or config service is the safer build.
Adoption criteria if you proceed anyway: pin the fork, add integration tests against your actual ES version, put a cache in front of reads, and budget an owner.
How to Pitch It (Stakeholders)
For executives (one paragraph): We evaluated ongr/settings-bundle, an MIT-licensed component that lets an application store editable settings in Elasticsearch so behavior can be changed without a deploy. The capability is genuinely useful and on our roadmap, but the package itself is a poor fit: it was last released in 2016, has essentially no user base, and only works inside an older Symfony/Elasticsearch stack that we don't run. Recommendation: do not adopt as a dependency. Borrow the design, build a small internal settings service (~2–5 engineering days), and keep ownership in-house. Adopting it would trade a few days of work for an indefinite maintenance liability on a non-differentiating feature.
For engineering (the practical case): The valuable idea is the abstraction — settings modeled as categorized documents with a dedicated read/write service, decoupled from application code. That maps cleanly onto a settings table with a category column, a typed accessor layer, and a cache in front of it, and it gives us the same admin-editability without Elasticsearch or a legacy bundle. If we ever need search or audit across settings, we can swap the storage behind the same service interface.
Ask: approve the small build, and record the build-vs-buy rationale so this doesn't get re-litigated the next time a settings package surfaces.