diff --git a/source/index.md b/source/index.md
index e45375c..548cf2c 100644
--- a/source/index.md
+++ b/source/index.md
@@ -41,7 +41,7 @@ In Docker, your Application related files are in a Docker Image, your Applicatio
 # Docker and Spectrum Protect
 ## Spectrum Protect Server
 So from a Spectrum Protect point of view, if we are to run a Spectrum Protect server, containerizing it enables you to leverage points all three points above:
-1. Regardless of whether you'll have 1 SP server or 100, you deploy it "once" and store it in your Docker Image library (aka a Docker Registry) and you can deploy it many times almost instantly.
+1. Regardless of whether you'll have 1 SP server or 100, you install it "once" and store it in your Docker Image library (aka a Docker Registry) and you can deploy it many times almost instantly.
 2. When you upgrade your Spectrum Protect server, you have easy upgrade and back-out plan, and in fact you can even "test" the upgrade before you do it live.
 3. When you deploy it, your "Application data files" will be your Spectrum Protect configuration (ie: the database), and the Spectrum Protect configuration data (ie: your disk storage pools).
  You can place those anywhere you like following your organisations data deployment policies, but when referenced inside the container, they are always referenced at the same point that SP has been prepared for when you have "installed it".