diff --git a/ee/ucp/images/interlock-deploy-production-1.svg b/ee/ucp/images/interlock-deploy-production-1.svg
new file mode 100644
index 0000000000..48ccb3f7ca
--- /dev/null
+++ b/ee/ucp/images/interlock-deploy-production-1.svg
@@ -0,0 +1,207 @@
+
+
\ No newline at end of file
diff --git a/ee/ucp/interlock/deploy/index.md b/ee/ucp/interlock/deploy/index.md
new file mode 100644
index 0000000000..439df53949
--- /dev/null
+++ b/ee/ucp/interlock/deploy/index.md
@@ -0,0 +1,30 @@
+---
+title: Enable ayer 7 routing
+description: Learn about Layer 7 routing, an application routing and load balancing system
+ for Docker Swarm.
+keywords: ucp, layer 7, routing, load balancing
+ui_tabs:
+- version: ucp-3.0
+ orhigher: false
+- version: ucp-2.2
+---
+
+{% if include.version=="ucp-3.0" %}
+
+To enable support for layer 7 routing, also known as HTTP routing mesh,
+log in to the UCP web UI as an administrator, navigate to the **Admin Settings**
+page, and click the **Routing Mesh** option. Check the **Enable routing mesh** option.
+
+{: .with-border}
+
+By default, the routing mesh service listens on port 80 for HTTP and port
+8443 for HTTPS. Change the ports if you already have services that are using
+them.
+
+Once you save, the layer 7 routing service can be used by your swarm services.
+
+{% elsif include.version=="ucp-2.2" %}
+
+* [Configure UCP 2.2 HTTP routing mesh](/datacenter/ucp/2.2/guides/admin/configure/use-domain-names-to-access-services.md)
+
+{% endif %}
diff --git a/ee/ucp/interlock/deploy/production.md b/ee/ucp/interlock/deploy/production.md
new file mode 100644
index 0000000000..ea5b03d619
--- /dev/null
+++ b/ee/ucp/interlock/deploy/production.md
@@ -0,0 +1,92 @@
+---
+title: Configure layer 7 routing for production
+description: Learn about Interlock, an application routing and load balancing system
+ for Docker Swarm.
+keywords: ucp, interlock, load balancing
+ui_tabs:
+- version: ucp-3.0
+ orhigher: false
+---
+
+{% if include.version=="ucp-3.0" %}
+
+The layer 7 solution that ships out of the box with UCP is highly available
+and fault tolerant. It is also designed to work independently of how many
+nodes you're managing with UCP.
+
+
+
+For a production-grade deployment, you should tune the default deployment to
+have two nodes dedicated for running the two replicas of the
+`ucp-interlock-proxy` service. This makes sure:
+
+* The proxy services have dedicated resources to handle user requests. You
+can configure these nodes with higher performance network interfaces.
+* No application traffic can be routed to a manager node. This makes the
+deployment secure.
+* The proxy service is running on two nodes. If one node fails layer 7 routing
+still works.
+
+To achieve this you need to:
+
+1. Enable layer 7 routing. [Learn how](index.md).
+2. Pick two nodes that are going to be dedicated to run the proxy service.
+3. Apply labels to those nodes, so that you can constrain the proxy service to
+only run on nodes with those labels.
+4. Update the proxy service with the constraint.
+5. Configure your load balancer to route traffic to the dedicated nodes only.
+
+## Apply labels to nodes
+
+In this example, we've chose node-5 and node-6 to be dedicated just for running
+the proxy service. To apply labels to those nodes run:
+
+```bash
+docker node update --label-add nodetype=loadbalancer
+```
+
+To make sure the label was successfully applied, run:
+
+{% raw %}
+```bash
+docker node inspect --format '{{ index .Spec.Labels "nodetype" }}'
+```
+{% endraw %}
+
+The command should print "loadbalancer".
+
+## Configure the proxy service
+
+Now that your nodes are labelled, you can add a constraint to the
+`ucp-interlock-proxy`service, so make sure it only gets scheduled on nodes
+with the right label:
+
+```bash
+docker service update \
+ --detach \
+ --constraint-add node.labels.nodetype==loadbalancer \
+ --stop-signal SIGTERM \
+ --stop-grace-period 5s \
+ $(docker service ls -f 'label=type=com.docker.interlock.core.proxy' -q)
+```
+
+This updates the proxy service to only be scheduled on node with the the
+"loadbalancer" label. It also stops the task with a `SIGTERM` signal and gives
+them five seconds to terminate, which allows the proxy service to stop accepting
+new requests and finished serving existing requests from users.
+
+Now you can check if the proxy service is running on the dedicated nodes:
+
+```
+docker service ps ucp-interlock-proxy
+```
+
+## Configure your load balancer
+
+Once the proxy service is running on a dedicated node, configure your upstream
+load balancer with the domain names or IP addresses of the nodes running
+the proxy service.
+
+This makes sure all traffic is directed to these nodes.
+
+{% endif %}
diff --git a/ee/ucp/interlock/enable.md b/ee/ucp/interlock/enable.md
new file mode 100644
index 0000000000..e69de29bb2
diff --git a/ee/ucp/interlock/install/index.md b/ee/ucp/interlock/install/index.md
deleted file mode 100644
index ec3b23626a..0000000000
--- a/ee/ucp/interlock/install/index.md
+++ /dev/null
@@ -1,54 +0,0 @@
----
-title: Get started with Layer 7 routing
-description: Learn about Layer 7 routing, an application routing and load balancing system
- for Docker Swarm.
-keywords: ucp, layer 7, routing, load balancing
-ui_tabs:
-- version: ucp-3.0
- orhigher: false
-- version: ucp-2.2
----
-
-{% if include.version=="ucp-3.0" %}
-
-Docker Enterprise Edition has a routing mesh that allows you to make your
-services available to the outside world using a domain name. This is also
-known as a layer 7 load balancer.
-
-
-
-In this example, the WordPress service is being served on port 8000.
-Users can access WordPress using the IP address of any node in the cluster
-and port 8000. If WordPress is not running in that node, the
-request is redirected to a node that is.
-
-Docker EE extends this and provides a routing mesh for application-layer
-load balancing. This allows you to access services with HTTP and HTTPS
-endpoints using a domain name instead of an IP.
-
-
-
-In this example, the WordPress service listens on port 8000, but it is made
-available to the outside world as `wordpress.example.org`.
-
-When users access `wordpress.example.org`, the HTTP routing mesh routes
-the request to the service running WordPress in a way that is transparent to
-them.
-
-## Enable the routing mesh
-
-To enable the HTTP routing mesh, Log in as an administrator, go to the
-UCP web UI, navigate to the **Admin Settings** page, and click the
-**Routing Mesh** option. Check the **Enable routing mesh** option.
-
-{: .with-border}
-
-By default, the routing mesh service listens on port 80 for HTTP and port
-8443 for HTTPS. Change the ports if you already have services that are using
-them.
-
-{% elsif include.version=="ucp-2.2" %}
-
-* [Configure UCP 2.2 HTTP routing mesh](/datacenter/ucp/2.2/guides/admin/configure/use-domain-names-to-access-services.md)
-
-{% endif %}
diff --git a/ee/ucp/interlock/install/production.md b/ee/ucp/interlock/install/production.md
deleted file mode 100644
index 475d26c41f..0000000000
--- a/ee/ucp/interlock/install/production.md
+++ /dev/null
@@ -1,91 +0,0 @@
----
-title: Deploy Interlock for Production
-description: Learn about Interlock, an application routing and load balancing system
- for Docker Swarm.
-keywords: ucp, interlock, load balancing
-ui_tabs:
-- version: ucp-3.0
- orhigher: false
----
-
-{% if include.version=="ucp-3.0" %}
-
-## Production Deployment
-In this section you will find documentation on configuring Interlock
-for a production environment. If you have not yet deployed Interlock please
-see the [Getting Started](index.md) section as this information builds upon the
-basic deployment. This example will not cover the actual deployment of infrastructure.
-It assumes you have a vanilla Swarm cluster (`docker init` and `docker swarm join` from the nodes).
-See the [Swarm](https://docs.docker.com/engine/swarm/) documentation if you need help
-getting a Swarm cluster deployed.
-
-In this example we will configure an eight (8) node Swarm cluster. There are three (3) managers
-and five (5) workers. Two of the workers are configured with node labels to be dedicated
-ingress cluster load balancer nodes. These will receive all application traffic.
-There is also an upstream load balancer (such as an Elastic Load Balancer or F5). The upstream
-load balancers will be statically configured for the two load balancer worker nodes.
-
-This configuration has several benefits. The management plane is both isolated and redundant.
-No application traffic hits the managers and application ingress traffic can be routed
-to the dedicated nodes. These nodes can be configured with higher performance network interfaces
-to provide more bandwidth for the user services.
-
-
-
-## Node Labels
-We will configure the load balancer worker nodes (`lb-00` and `lb-01`) with node labels in order to pin the Interlock Proxy
-service. Once you are logged into one of the Swarm managers run the following to add node labels
-to the dedicated ingress workers:
-
-```bash
-$> docker node update --label-add nodetype=loadbalancer lb-00
-lb-00
-$> docker node update --label-add nodetype=loadbalancer lb-01
-lb-01
-```
-
-You can inspect each node to ensure the labels were successfully added:
-
-```bash
-{% raw %}
-$> docker node inspect -f '{{ .Spec.Labels }}' lb-00
-map[nodetype:loadbalancer]
-$> docker node inspect -f '{{ .Spec.Labels }}' lb-01
-map[nodetype:loadbalancer]
-{% endraw %}
-```
-
-## Configure Proxy Service
-Once we have the node labels we can re-configure the Interlock Proxy service to be constrained to those
-workers. Again, from a manager run the following to pin the proxy service to the ingress workers:
-
-```bash
-$> docker service update --replicas=2 \
- --constraint-add node.labels.nodetype==loadbalancer \
- --stop-signal SIGTERM \
- --stop-grace-period=5s \
- $(docker service ls -f 'label=type=com.docker.interlock.core.proxy' -q)
-```
-
-This updates the proxy service to have two (2) replicas and ensure they are constrained to
-the workers with the label `nodetype==loadbalancer` as well as configure the stop signal for the tasks
-to be a `SIGTERM` with a grace period of five (5) seconds. This will ensure that Nginx closes the connections
-before exiting to ensure the client request is finished.
-
-Inspect the service to ensure the replicas have started on the desired nodes:
-
-```bash
-$> docker service ps $(docker service ls -f 'label=type=com.docker.interlock.core.proxy' -q)
-ID NAME IMAGE NODE DESIRED STATE CURRENT STATE ERROR PORTS
-o21esdruwu30 interlock-proxy.1 nginx:alpine lb-01 Running Preparing 3 seconds ago
-n8yed2gp36o6 \_ interlock-proxy.1 nginx:alpine mgr-01 Shutdown Shutdown less than a second ago
-aubpjc4cnw79 interlock-proxy.2 nginx:alpine lb-00 Running Preparing 3 seconds ago
-```
-
-Once configured you can update the settings in the upstream load balancer (ELB, F5, etc) with the
-addresses of the dedicated ingress workers. This will direct all traffic to these nodes.
-
-You have now configured Interlock for a dedicated ingress production environment. See the [Configuration](/config/interlock/) section
-if you want to continue tuning.
-
-{% endif %}