diff --git a/docs/flyte_fundamentals/registering_workflows.md b/docs/flyte_fundamentals/registering_workflows.md
index 4a46fc6d93..6460232776 100644
--- a/docs/flyte_fundamentals/registering_workflows.md
+++ b/docs/flyte_fundamentals/registering_workflows.md
@@ -72,6 +72,8 @@ run it with the supplied arguments. As you can see from the expected output, you
 can visit the link to the Flyte console to see the progress of your running
 execution.
 
+You may also run `run --remote --copy-all`, which is very similar to the above command. As the name suggests, will copy the source tree rooted at the top-level __init__.py file. With this strategy, any modules discoverable on the PYTHONPATH will be importable.
+
 ```{note}
 `pyflyte run` supports Flyte workflows that import any other user-defined modules that
 contain additional tasks or workflows.
@@ -182,6 +184,12 @@ of your project. You can also use `.gitignore` or `.dockerignore` if you'd like
 to avoid adding another file.
 ```
 
+```{note}
+`WORKDIR`, `PYTHONPATH`, and `PATH`
+
+When executing any of the above commands, the archive that gets creates is extracted wherever the WORKDIR is set. This can be handled directly via the WORKDIR directive in a Dockerfile, or specified via source_root if using ImageSpec. This is important for discovering code and executables via PATH or PYTHONPATH. A common pattern for making your Python packages fully discoverable is to have a top-level src folder, adding that to your PYTHONPATH and making all your imports absolute. This avoids having to "install" your Python project in the image at any point e.g. via `pip install -e`.
+```
+
 ### Productionizing your workflows
 
 Flyte's core design decision is to make workflows reproducible and repeatable.