diff --git a/doc/0-INSTALL.mkd b/doc/0-INSTALL.mkd
index 15f9532..4351a46 100644
--- a/doc/0-INSTALL.mkd
+++ b/doc/0-INSTALL.mkd
@@ -28,6 +28,7 @@ In this document:
       * upgrades
       * other notes
   * system install / user setup
+      * multiple gitolite instances
   * next steps
   * appendix A: server and client requirements for user install
       * server
@@ -165,6 +166,28 @@ the server and run the same command as above.
 `$GL_PACKAGE_CONF` and `$GL_PACKAGE_HOOKS`.  If you remove or change either of
 them, expect trouble :-)
 
+#### multiple gitolite instances
+
+With this mode of install, it's easy to create multiple gitolite instances
+(say one for each department, on some mega company-wide server).  You can even
+do this without giving shell access to the admins.  Here's an example with
+just two "departments", and their admins Alice and Bob:
+
+  * create userids `webbrowser_repos` and `webserver_repos`
+  * ask Alice and Bob for their pubkeys; copy them to the respective home
+    directories for convenience
+  * run `su - webbrowser_repos`, then `gl-setup alice.pub`
+  * (similarly with `webserver_repos` and `bob.pub`, and so on for others)
+
+That's it.  The URL for all web browser projects is now something like
+`webbrowser_repos@server:reponame`, and similarly for the others.
+
+Notice that you only have to do this once for each "department", and it's
+really just one command after creating the userid.  None of these admins need
+to have a command line on the server, so don't give them the passwords if you
+don't need to -- the pubkey will allow them to be gitolite admins on their
+domain, and that's quite enough for normal operations.
+
 ### next steps
 
 The last message produced by the easy install script should tell you how to
diff --git a/doc/5-delegation.mkd b/doc/5-delegation.mkd
index 9260046..e3403ca 100644
--- a/doc/5-delegation.mkd
+++ b/doc/5-delegation.mkd
@@ -97,3 +97,24 @@ Naturally, a successful push invokes the post-update hook that the admin repo
 has, which eventually runs the compile script.  The **net effect** is as if
 you appended the contents of all the "fragment" files, in alphabetical order,
 to the bottom of the main file.
+
+----
+
+### Security/Philosophy note
+
+The delegation feature is meant only for access control rules, not pubkeys.
+Adding/removing pubkeys is a much more significant event than changing branch
+level permissions for people already on staff, and only the main admin should
+be allowed to do it.
+
+Gitolite's "userids" all live in the same namespace.  This is unlikely to
+change, so please don't ask -- it gets real complicated to do otherwise.
+Allowing delegated admins to add users means username collisions, which also
+means security problems (admin-A creates a pubkey for Admin-B, thus gaining
+access to all of Admin-B's stuff).
+
+If you feel the need to delegate even that, please just go the whole hog and
+give them separate gitolite instances!  It's pretty easy to setup the
+*software* itself system-wide, so that many users can use it without all the
+"easy install" fuss.  See the "system install / user setup" section in
+doc/0-INSTALL.mkd for details.