diff --git a/content/prologue/deployments/cloud-less-then-5.svg b/content/prologue/deployments/cloud-less-then-5.svg
deleted file mode 100644
index 7b4349d..0000000
--- a/content/prologue/deployments/cloud-less-then-5.svg
+++ /dev/null
@@ -1,554 +0,0 @@
-
diff --git a/content/prologue/deployments/cloud-more-then-5.svg b/content/prologue/deployments/cloud-more-then-5.svg
deleted file mode 100644
index 0ad913d..0000000
--- a/content/prologue/deployments/cloud-more-then-5.svg
+++ /dev/null
@@ -1,628 +0,0 @@
-
diff --git a/content/prologue/deployments/deployment-basic.svg b/content/prologue/deployments/deployment-basic.svg
new file mode 100644
index 0000000..a7d626c
--- /dev/null
+++ b/content/prologue/deployments/deployment-basic.svg
@@ -0,0 +1,394 @@
+
diff --git a/content/prologue/deployments/deployment-chaining.svg b/content/prologue/deployments/deployment-chaining.svg
new file mode 100644
index 0000000..90cbbd7
--- /dev/null
+++ b/content/prologue/deployments/deployment-chaining.svg
@@ -0,0 +1,206 @@
+
diff --git a/content/prologue/deployments/deployment-cloud.svg b/content/prologue/deployments/deployment-cloud.svg
new file mode 100644
index 0000000..3f8ef22
--- /dev/null
+++ b/content/prologue/deployments/deployment-cloud.svg
@@ -0,0 +1,460 @@
+
diff --git a/content/prologue/deployments/deployment-home-setup.svg b/content/prologue/deployments/deployment-extended.svg
similarity index 100%
rename from content/prologue/deployments/deployment-home-setup.svg
rename to content/prologue/deployments/deployment-extended.svg
diff --git a/content/prologue/deployments/deployment-hub-vault.svg b/content/prologue/deployments/deployment-hub-vault.svg
deleted file mode 100644
index a80e6c8..0000000
--- a/content/prologue/deployments/deployment-hub-vault.svg
+++ /dev/null
@@ -1,637 +0,0 @@
-
diff --git a/content/prologue/deployments/deployment-hub.svg b/content/prologue/deployments/deployment-hub.svg
deleted file mode 100644
index 8ad5a80..0000000
--- a/content/prologue/deployments/deployment-hub.svg
+++ /dev/null
@@ -1,655 +0,0 @@
-
diff --git a/content/prologue/deployments/deployment-cloud-first.svg b/content/prologue/deployments/deployment-hybrid.svg
similarity index 100%
rename from content/prologue/deployments/deployment-cloud-first.svg
rename to content/prologue/deployments/deployment-hybrid.svg
diff --git a/content/prologue/deployments/deployment-saas.svg b/content/prologue/deployments/deployment-saas.svg
new file mode 100644
index 0000000..8dc764b
--- /dev/null
+++ b/content/prologue/deployments/deployment-saas.svg
@@ -0,0 +1,250 @@
+
diff --git a/content/prologue/deployments/index.md b/content/prologue/deployments/index.md
index b29b32f..62083f2 100644
--- a/content/prologue/deployments/index.md
+++ b/content/prologue/deployments/index.md
@@ -28,28 +28,71 @@ Starting something new is not easy, there is always a steep learning curve. Whil
- Can I self-host [Kerberos Hub](/hub/first-things-first/) or do I need to install it in managed cloud?
- And probably many more questions..
-We will discuss some of the most common setups we have seen, however this doesn't mean that your setup will not work if it's not shown identically in this section.
+We will discuss some of the most common setups we have seen, however this doesn't mean that your setup will not work if it's not shown as identical in the sections below.
-## Home setup
+## Basic setup
-If you are starting with a small deployment - for example for your home - than probably you want to keep it simple. Either you'll only host a couple of [Kerberos Agents](/agent/first-things-first) or an additional [Kerberos Vault](/vault/first-things-first/).
+If you are starting with a basic deployment - for example for your home - then you probably prefer to have it rather simple. In this case you can host one or more [Kerberos Agents](/agent/first-things-first) on a compute of choice, in the network you desire.
-{{< figure src="deployment-home-setup.svg" alt="The home-setup deployment" caption="The home-setup deployment" class="stretch">}}
+{{< figure src="deployment-basic.svg" alt="The basic deployment" caption="The basic deployment" class="stretch">}}
-In a home setup you'll probably rely on `docker` instead of `kubernetes`, mainly because of simplicity. In this setup, [Kerberos Agents](/agent/first-things-first) are installed on a compute at the edge, next to a [Kerberos Vault](/vault/first-things-first/). For both components you can leverage `docker` or `docker compose` to setup and configure the system.
+In a home setup you'll probably rely on [`docker`](https://github.com/kerberos-io/agent/tree/master/deployments/docker#1-running-a-single-container) instead of [`kubernetes`](https://github.com/kerberos-io/agent/tree/master/deployments/kubernetes), mainly because of simplicity. However nothing is stopping you utilise Kubernetes for your local deployment.
+
+## Extended setup
+
+[Kerberos Agents](/agent/first-things-first) store recordings on the host system. You might want to have a more elegant and centralised storage setup. Run [Kerberos Vault](/vault/first-things-first/) next to your
+[Kerberos Agents](/agent/first-things-first) and connect to an edge or cloud storage system such as S3, Minio, etc.
+
+{{< figure src="deployment-extended.svg" alt="The home-setup deployment" caption="The home-setup deployment" class="stretch">}}
+
+Similar to the basic installation, Kerberos Vault can be installed through [`docker`](https://github.com/kerberos-io/vault/tree/master/docker) and [`kubernetes`](https://github.com/kerberos-io/vault/tree/master/kubernetes). In this setup, [Kerberos Agents](/agent/first-things-first) are installed on a compute at the edge, next to a [Kerberos Vault](/vault/first-things-first/).
The advantage with [Kerberos Vault](/vault/first-things-first/) is that even if it's deployed at the edge, you can still target a cloud storage system like S3, GCP Storage, etc. Next to that the main advantage is speed, you typically setup an [Kerberos Agents](/agent/first-things-first) within 5 minutes, and a [Kerberos Vault](/vault/first-things-first/) installation within 30 minutes using `docker compose`.
-## Cloud-first setup
+When leveraging [Kubernetes](https://github.com/kerberos-io/vault/tree/master/kubernetes) it might take you a bit more time, as you'll need to create the relevant Kubernetes resources in the cluster.
-One of the most common setups is the **cloud-first** setup, where you install the majority of the components in a managed cloud or your own private cloud.
+## Hybrid setup
-{{< figure src="deployment-cloud-first.svg" alt="The cloud-first deployment" caption="The cloud-first deployment" class="stretch">}}
+One of the most common setups is a hybrid setup, where you install the majority of the components in a managed cloud or your own private cloud.
+
+{{< figure src="deployment-hybrid.svg" alt="The hybrid deployment" caption="The hybrid deployment" class="stretch">}}
The huge benefit of this approach is that your [Kerberos Agents](/agent/first-things-first) are installed next to the camera infrastructure, and ideally in the same network. This will bring latency and data transfer to a minimum.
The [Kerberos Vault](/vault/first-things-first/) is installed in the cloud together with some scalable cloud storage. The [Kerberos Hub](/hub/first-things-first/) is installed in the same or other cloud as the [Kerberos Vault](/vault/first-things-first/).
-The benefit of this deployment is that you only need to install [Kerberos Vault](/vault/first-things-first/) and [Kerberos Hub](/hub/first-things-first/) once. Most of the work is setting up the [Kerberos Agents](/agent/first-things-first).
+The benefit of this deployment is that you only need to install [Kerberos Vault](/vault/first-things-first/) and [Kerberos Hub](/hub/first-things-first/) once. Most of the work is setting up the [Kerberos Agents](/agent/first-things-first) at your customers and/or sites.
-Another benefit is that is latency and bandwidth consumption, as we have compute at the edge for running the [Kerberos Agents](/agent/first-things-first). Only data (recordings) that are relevant will be send over the network to [Kerberos Vault](/vault/first-things-first/).
+Another benefit is low latency and bandwidth consumption, as we have compute running at the edge for the [Kerberos Agents](/agent/first-things-first). Only data (recordings) that are relevant will be send over the network to [Kerberos Vault](/vault/first-things-first/). A possible disadvantage of this setup is that you will require some hardware at the site, although the maintenance is low it does come with a cost; have a look at [Cloud setup](/prologue/deployments/#cloud-setup) instead.
+
+## Cloud setup
+
+With this setup we are moving from a Hybrid setup to a complete Cloud approach. As described before, it might be a challenge to host hardware at the edge, as you or your customers don't want to invest in additional hardware. Therefore it might be an option to move your [Kerberos Agents](/agent/first-things-first) to the cloud, and leverage a secure connection between the cameras at the edge, and the [Kerberos Agents](/agent/first-things-first) in the cloud.
+
+{{< figure src="deployment-cloud.svg" alt="The cloud deployment" caption="The cloud deployment" class="stretch">}}
+
+The main advantage is here, is that you'll avoid any extra hardware costs on site. On the otherhand you'll need a secure connection, which might already be available, to setup a remote connection between the camera streams at the edge and the [Kerberos Agents](/agent/first-things-first) in the cloud.
+
+A noticable disadvantage is that a continuous stream of data is send over the network for each camera stream. Which might become more expensive than buying the additional hardware at the edge. Build up a usecase, of what setup makes sense for which customer.
+
+> In the end you might go with a mixed hybrid and cloud setup depending on the use case and customer requirements.
+
+## SAAS setup
+
+As described above you might mix a Hybrid and Cloud setup, in the end you decide where to host your [Kerberos Agents](/agent/first-things-first). Within the SAAS setup, you'll utilise our [Kerberos Hub SAAS](/hub/first-things-first/) edition, and connect your [Kerberos Agents](/agent/first-things-first) and [Kerberos Vault](/vault/first-things-first/).
+
+{{< figure src="deployment-saas.svg" alt="The SAAS deployment" caption="The SAAS deployment" class="stretch">}}
+
+The main advantage of this setup is that you have full control over your [Kerberos Agents](/agent/first-things-first) and [Kerberos Vault](/vault/first-things-first/), but consult the Kerberos.io team for visualizing your video landscape through [our Kerberos Hub SAAS](/hub/first-things-first/) edition.
+
+This means that you, and only you, own the data and at the same time doesn't have to maintain, install and configure [Kerberos Hub](/hub/first-things-first/).
+
+## Chained setup
+
+If you need more and better redundancy then the Chained setup might be of interest. In this setup we move data (recordings) from one [Kerberos Vault](/vault/first-things-first/) to another [Kerberos Vault](/vault/first-things-first/).
+
+{{< figure src="deployment-chaining.svg" alt="Kerberos Vault chaining" caption="Kerberos Vault chaining" class="stretch">}}
+
+The advantage of [chaining (or forwarding)](/vault/forwarding/) is that you create a cache between two environments. Shown on the architecture above data is first stored at an edge [Kerberos Vault](/vault/first-things-first/), and synchronised with a cloud [Kerberos Vault](/vault/first-things-first/). When the connection goes down between the two [Kerberos Vaults](/vault/first-things-first/), the data will still be stored in the edge [Kerberos Vault](/vault/first-things-first/), and synced to the cloud [Kerberos Vault](/vault/first-things-first/) once the connection is back up.
+
+Another advantage is that [chaining (or forwarding)](/vault/forwarding/) can be configured in different modes, whereas the previously mentioned advantage is illustrating `continuous` forwarding, it's also possible to have `ondemand` forwarding. In the latter, the user or administrators can decide programmatically or through our [Kerberos Hub](/hub/first-things-first/) which recordings needs to be synchronised to the cloud [Kerberos Vault](/vault/first-things-first/). This allows us to only send the information we prefer to our cloud [Kerberos Vault](/vault/first-things-first/).
diff --git a/content/prologue/deployments/kerberos-agent-docker.svg b/content/prologue/deployments/kerberos-agent-docker.svg
deleted file mode 100644
index 9f814ca..0000000
--- a/content/prologue/deployments/kerberos-agent-docker.svg
+++ /dev/null
@@ -1,432 +0,0 @@
-
diff --git a/content/prologue/deployments/kerberos-agent-edge.svg b/content/prologue/deployments/kerberos-agent-edge.svg
deleted file mode 100644
index 9606cd5..0000000
--- a/content/prologue/deployments/kerberos-agent-edge.svg
+++ /dev/null
@@ -1,1922 +0,0 @@
-
diff --git a/content/prologue/deployments/kerberos-enterprise-suite.svg b/content/prologue/deployments/kerberos-enterprise-suite.svg
deleted file mode 100644
index ddd23da..0000000
--- a/content/prologue/deployments/kerberos-enterprise-suite.svg
+++ /dev/null
@@ -1,379 +0,0 @@
-
diff --git a/content/prologue/deployments/onpremise-less-then-5-docker.svg b/content/prologue/deployments/onpremise-less-then-5-docker.svg
deleted file mode 100644
index 74ecc7a..0000000
--- a/content/prologue/deployments/onpremise-less-then-5-docker.svg
+++ /dev/null
@@ -1,553 +0,0 @@
-
diff --git a/content/prologue/deployments/onpremise-less-then-5.svg b/content/prologue/deployments/onpremise-less-then-5.svg
deleted file mode 100644
index f80e83b..0000000
--- a/content/prologue/deployments/onpremise-less-then-5.svg
+++ /dev/null
@@ -1,689 +0,0 @@
-
diff --git a/content/prologue/deployments/onpremise-more-then-5.svg b/content/prologue/deployments/onpremise-more-then-5.svg
deleted file mode 100644
index 0385ac6..0000000
--- a/content/prologue/deployments/onpremise-more-then-5.svg
+++ /dev/null
@@ -1,626 +0,0 @@
-
diff --git a/content/prologue/how/index.md b/content/prologue/how/index.md
index 71d9952..a082b3f 100644
--- a/content/prologue/how/index.md
+++ b/content/prologue/how/index.md
@@ -1,7 +1,7 @@
---
title: "How it works"
-description: "From one to a myriad of cameras"
-lead: "From one to a myriad of cameras"
+description: "From zero to a myriad of cameras"
+lead: "From zero to a myriad of cameras"
date: 2020-10-06T08:48:57+00:00
lastmod: 2022-12-14T22:37:57+00:00
draft: false
diff --git a/content/vault/forwarding/deployment-chaining.svg b/content/vault/forwarding/deployment-chaining.svg
new file mode 100644
index 0000000..90cbbd7
--- /dev/null
+++ b/content/vault/forwarding/deployment-chaining.svg
@@ -0,0 +1,206 @@
+
diff --git a/content/vault/forwarding/index.md b/content/vault/forwarding/index.md
index 97e0a0b..d9e07a1 100644
--- a/content/vault/forwarding/index.md
+++ b/content/vault/forwarding/index.md
@@ -7,8 +7,8 @@ lastmod: 2020-10-06T08:49:31+00:00
draft: false
images: []
menu:
- vault:
- parent: "vault"
+ vault:
+ parent: "vault"
weight: 309
toc: true
---
@@ -17,7 +17,7 @@ Multiple Kerberos Vaults can be installed in your video landscape. You may have
Kerberos Vaults can be chained and configured in forwarding mode. This configuration makes it possible to enable offline capabilities and keep the majority of your recordings at the edge. Only a subset of your recordings will be transferred from the edge to the cloud by requesting a forward from Kerberos Hub or building your own forwarding application code.
-{{< figure src="vault-forwarding-chaining.svg" alt="Synchronise recordings between multiple Kerberos Vault" caption="Synchronise recordings between multiple Kerberos Vault" class="stretch">}}
+{{< figure src="deployment-chaining.svg" alt="Synchronise recordings between multiple Kerberos Vault" caption="Synchronise recordings between multiple Kerberos Vault" class="stretch">}}
Forwarding can be configured in two modes: continuous forwarding and on-demand recording.
@@ -31,7 +31,7 @@ Recordings are stored at the edge, and only a subset is forwarded to a Kerberos
## Configuration
-Go to the integrations page, and click (+ Add Integration). Select the Kerberos Vault option, and choose on-demand or continuous forwarding.
+Go to the integrations page, and click (+ Add Integration). Select the Kerberos Vault option, and choose on-demand or continuous forwarding.
Define the account credentials of the remote Kerberos Vault, to which you are forwarding recordings. If not yet created make sure an account is set up with a valid storage provider.
@@ -45,6 +45,6 @@ Once the integration is created, you still need to activate the integration for
Two examples of on demand forwarding:
-1. A machine learning filter: recordings are stored in a Kerberos Vault at the edge, and are processed by a machine learning model. Every time the machine learning model finds a match, e.g. a pedestrian detected, it will forward the recording to Kerberos Vault in a cloud environment. By doing this you will send limited recordings (storage) into the cloud.
+1. A machine learning filter: recordings are stored in a Kerberos Vault at the edge, and are processed by a machine learning model. Every time the machine learning model finds a match, e.g. a pedestrian detected, it will forward the recording to Kerberos Vault in a cloud environment. By doing this you will send limited recordings (storage) into the cloud.
2. An on demand request through Kerberos Hub: From Kerberos Hub a user can initiate a request for forwarding. By default, no recordings are forwarded from your Kerberos Vault at the edge to your Kerberos Vault in the cloud. However, you can enable the thumbnail option to send thumbnails to Kerberos Hub. Only when an end user requests one or more recordings, the forwarding will start for the requested recordings.