Updated docs, fixed broken links and moved things around.

docs/operating/mqs/README.md

@@ -0,0 +1,36 @@
+# Message Queues
+
+A message queue is used to coordinate asynchronous function calls that run through IronFunctions.
+
+We currently support the following message queues and they are passed in via the `MQ_URL` environment variable. For example:
+
+```sh
+docker run -e "MQ_URL=redis://localhost:6379/" ...
+```
+
+## [Bolt](https://github.com/boltdb/bolt) (default)
+
+URL: `bolt:///titan/data/functions-mq.db`
+
+See Bolt in databases above. The Bolt database is locked at the file level, so
+the file cannot be the same as the one used for the Bolt Datastore.
+
+## [Redis](http://redis.io/)
+
+See Redis in databases above.
+
+## [IronMQ](https://www.iron.io/platform/ironmq/)
+
+URL: `ironmq://project_id:token@mq-aws-us-east-1.iron.io/queue_prefix`
+
+IronMQ is a hosted message queue service provided by [Iron.io](http://iron.io). If you're using IronFunctions in production and don't
+want to manage a message queue, you should start here.
+
+The IronMQ connector uses HTTPS by default. To use HTTP set the scheme to
+`ironmq+http`. You can also use a custom port. An example URL is:
+`ironmq+http://project_id:token@localhost:8090/queue_prefix`.
+
+## What about message queue X?
+
+We're happy to add more and we love pull requests, so feel free to add one! Copy one of the implementations above as a starting point.
+

docs/operating/options.md

@@ -0,0 +1,90 @@
+# IronFunctions Runtime Options
+
+## Configuration
+
+When starting IronFunctions, you can pass in the following configuration variables as environment variables. Use `-e VAR_NAME=VALUE` in
+docker run.  For example:
+
+```
+docker run -e VAR_NAME=VALUE ...
+```
+
+<table>
+<tr>
+<th>Env Variables</th>
+<th>Description</th>
+<th>Default values</th>
+</tr>
+<tr>
+<td>DB_URL</td>
+<td>The database URL to use in URL format. See [Databases](operating/databases/README.md) for more information.</td>
+<td>$(pwd)/bolt.db</td>
+</tr>
+<tr>
+<td>MQ_URL</td>
+<td>The message queue to use in URL format. See [Message Queues](mqs/README.md) for more information.</td>
+<td>$(pwd)/queue.db</td>
+</tr>
+<tr>
+<td>API_URL</td>
+<td>The primary IronFunctions API URL to that this instance will talk to. In a production environment, this would be your load balancer URL.</td>
+<td>N/A</td>
+</tr>
+<tr>
+<td>PORT</td>
+<td>Sets the port to run on</td>
+<td>8080</td>
+</tr>
+<tr>
+<td>LOG_LEVEL</td>
+<td>Set to DEBUG to enable debugging</td>
+<td>INFO</td>
+</tr>
+<tr>
+<td>DOCKER_HOST</td>
+<td>Docker remote API URL</td>
+<td>/var/run/docker.sock:/var/run/docker.sock</td>
+</tr>
+<tr>
+<td>DOCKER_API_VERSION</td>
+<td>Docker remote API version</td>
+<td>1.24</td>
+</tr>
+<tr>
+<td>DOCKER_TLS_VERIFY</td>
+<td>Set this option to enable/disable Docker remote API over TLS/SSL. Default: 0</td>
+<td>0</td>
+</tr>
+<tr>
+<td>DOCKER_CERT_PATH</td>
+<td>Set this option to specify where CA cert placeholder</td>
+<td>~/.docker/cert.pem</td>
+</tr>
+</table>
+
+## Starting without Docker in Docker
+
+The default way to run IronFunctions, as it is in the Quickstart guide, is to use docker-in-docker (dind). There are
+a couple reasons why we did it this way:
+
+* It's clean. Once the container exits, there is nothing left behind including all the function images.
+* You can set resource restrictions for the entire IronFunctions instance. For instance, you can set `--memory` on
+the docker run command to set the max memory for the IronFunctions instance AND all of the functions it's running.
+
+There are some reasons you may not want to use dind, such as using the image cache during testing or you're running
+[Windows](operating/windows.md).
+
+### Mount the Host Docker
+
+One way is to mount the host Docker. Everything is essentially the same except you add a `-v` flag:
+
+```sh
+docker run --rm --name functions -it -v /var/run/docker.sock:/var/run/docker.sock -v $PWD/data:/app/data -p 8080:8080 iron/functions
+```
+
+### Run outside Docker
+
+You can of course just run the binary directly, you'll just have to change how you set the environment variables above.
+
+See [contributing doc](../CONTRIBUTING.md) for information on how to build and run.
+

docs/operating/production.md

@@ -1,6 +1,6 @@
 # Running IronFunctions in Production
 
-The [QuickStart guide](/README.md) is intended to quickly get started and kick the tires. To run in production and be ready to scale, you need
+The [QuickStart guide](/README.md#quickstart) is intended to quickly get started and kick the tires. To run in production and be ready to scale, you need
 to use more production ready components.
 
 * Put the IronFunctions API behind a load balancer and launch run several instances of them (the more the merrier).
@@ -21,14 +21,14 @@ Any load balancer will work, put every instance of IronFunctions that you run be
 
 We've done our best to keep the database usage to a minimum. There are no writes during the request/response cycle which where most of the load will be.
 
-The database is pluggable and we currently support a few options that can be [found here](/docs/databases/). We welcome pull requests for more!
+The database is pluggable and we currently support a few options that can be [found here](databases/README.md). We welcome pull requests for more!
 
 ## Message Queue
 
 The message queue is an important part of asynchronous functions, essentially buffering requests for processing when resources are available. The reliability and scale of the message queue will play an important part
 in how well IronFunctions runs, in particular if you use a lot of asynchronous function calls.
 
-The message queue is pluggable and we currently support a few options that can be [found here](/docs/mqs/). We welcome pull requests for more!
+The message queue is pluggable and we currently support a few options that can be [found here](mqs/README.md). We welcome pull requests for more!
 
 ## Logging, Metrics and Monitoring