- Structured configuration - Store structured configuration segments, and not just key/value pairs. Internally, everything is represented as JSON (though, output in other formats is possible).
- Inheritance with overrides - define schemas for your configuration and extend/inherit from other configuration segments. For example, define a configuration segment for a service endpoint which you consume. Then, inherit that configuration segment in all the configurations that use that endpoint.
- Name-spaced configuration which understands environment (configuration segments are arbitrary length in dot notation, begining with the environment, so something like .prod.service.mongodb, or .qa.server.public.app. If you inherit from a global value in your schema, and omit an absolute environment value in the reference to that global value, the system will automatically select the config segment for the environment for which you are pulling a config. This is called a relative inherit and instead of using the namespace .prod.service.mongodb in your inheritance reference, you would put service.mongodb. Note that there is no leading dot with a relative reference.
- Catch all environments (you can define a configuration segment to be a wildcard. So, if a request is made for that segment from the REST api or by an inheritance from another segment, and an environment is specified explicitly or automatically by the environment resolution system which does not exist, the catch all segment will be returned in stead of not-found)