diff --git a/src/how-tos/deploy-operate.md b/src/how-tos/deploy-operate.md
index 79a82806..418fb7e0 100644
--- a/src/how-tos/deploy-operate.md
+++ b/src/how-tos/deploy-operate.md
@@ -176,6 +176,8 @@ Errors and misconfigured parts of the `zilla.yaml` file are detected by Zilla an
 
 This feature is demonstrated in the above Helm install command. Running a `helm update ...` with changes to the `zilla.yaml`, k8s will update the config map, which writes the new content into the running pods. Zilla will detect those file changes and load the new config.
 
+Zilla can load the `zilla.yaml` config from a remote source using the `-c` or `--config` [CLI flag](../reference/config/zilla-cli.md#c-config). The auto reconfigure feature will still work when pulling the config remotely.
+
 ## Auto Scaling
 
 Zilla will start workers that default to the CPU cores it is allowed to use. This makes horizontal scaling easy with a 1:1 ratio of instances to workers. Any of the default scaling metrics based on server CPU usage will enable Zilla to handle traffic spikes. Additionally, Zilla [Telemetry](../reference/config/overview.md#telemetry) configuration provides more data when determining how to scale. The [Prometheus autoscale example](https://github.com/aklivity/zilla-examples/tree/main/kubernetes.prometheus.autoscale) demonstrates using metrics from the [Prometheus exporter](../reference/config/telemetry/exporters/prometheus.md) to horizontally scale Zilla on k8s.
diff --git a/src/reference/config/zilla-cli.md b/src/reference/config/zilla-cli.md
index c1f41745..3048dc3b 100644
--- a/src/reference/config/zilla-cli.md
+++ b/src/reference/config/zilla-cli.md
@@ -180,12 +180,16 @@ started
 
 > `string`
 
-Set the path to the local `zilla.yaml` configuration file.
+Set the path to the local `zilla.yaml` configuration file or remote URI.
 
 ```bash:no-line-numbers
 zilla start -c ./path/to/zilla.yaml
 ```
 
+```bash:no-line-numbers
+zilla start -c http://example.com/zilla.yaml
+```
+
 #### -e --exception-traces
 
 > `flag`