Lifecycle Sigils

A Sigil is a special prefix that allows you to surgically intercept the orchestrator's processing behavior before the core merging logic executes.

They can be applied to physical filenames inside a Templates folder, or bound to injection keys mapped inside Docker CONFIG_PATHS (Configuration Injection).

Breakdown of Action Sigils

• !force:<name>

  • Behavior: Ensures the file is copied if it doesn't exist, and recursively deep-merged if it does. This guarantees that your configuration block arrives safely regardless of the original container state.

• !replace:<name>

  • Behavior: Completely bypasses the deep-merge logic. The target file is overwritten fully by your input data. Use this when you absolutely need a pure 1:1 replica without outside pollution.

• !delete:<name>

  • Behavior: Instructs the orchestrator to physically delete the target file in the /runtime folder. This is invaluable when managing sunset rules, allowing you to forcefully remove deprecated plugins, configs, or data folders from old setups programmatically!

• <name>

  • Behavior: This is the default behavior when no sigil is present. It instructs the orchestrator to merge the target file if it exists, and do nothing if it doesn't.

File Trees Example

If used inside a templates directory physically mapping to runtime:

Template Source

Deep Merging Behavior

Keep in mind that unless you bypass it with !replace:, standard matching files are processed intelligently depending on their extension.

To read explicitly how JSON, YAML, TOML, and Properties behave during this procedure, read the Deep Merging guide.