diff --git a/_data/home-content.yml b/_data/home-content.yml
index a72908c1..c2155b4f 100644
--- a/_data/home-content.yml
+++ b/_data/home-content.yml
@@ -1,5 +1,21 @@
 
 
+
+- title: Getting started
+  icon: images/home-icons/started.svg
+  url: ''
+  links:
+    - title: Introduction to Codefresh
+      localurl: /docs/getting-started/intro-to-codefresh/
+    - title: Codefresh for CI
+      localurl: /docs/getting-started/ci-codefresh/
+    - title: Codefresh for CD 
+      localurl: /docs/getting-started/cd-codefresh/
+    - title: Codefresh for GitOps 
+      localurl: /docs/getting-started/gitops-codefresh/
+    - title: Concepts in Codefresh
+      localurl: /docs/getting-started/concepts/
+
 - title: Dashboards & insights
   icon: images/home-icons/guides.png
   url: ''
@@ -41,6 +57,7 @@
     localurl: /docs/ci-cd-guides/progressive-delivery/ 
     
 
+
 - title: Example catalog
   icon: images/home-icons/tutorial.svg
   url: ''
diff --git a/_data/nav.yml b/_data/nav.yml
index fa3b888f..a4d78166 100644
--- a/_data/nav.yml
+++ b/_data/nav.yml
@@ -1,6 +1,23 @@
 
 
 
+- title: Getting started
+  url: "/getting-started"
+  pages:
+    - title: Introduction to Codefresh
+      url: "/intro-to-codefresh"
+    - title: Codefresh for CI
+      url: "/ci-codefresh"
+    - title: Codefresh for CD
+      url: "/cd-codefresh"
+    - title: Codefresh for GitOps 
+      url: "/gitops-codefresh"
+    - title: Concepts in Codefresh
+      url: "/concepts"
+
+
+
+
 - title: Dashboards & Insights
   url: "/dashboards"
   pages:
diff --git a/_docs/getting-started/cd-codefresh.md b/_docs/getting-started/cd-codefresh.md
new file mode 100644
index 00000000..2dc6a70f
--- /dev/null
+++ b/_docs/getting-started/cd-codefresh.md
@@ -0,0 +1,91 @@
+---
+title: "Codefresh for CD"
+description: "Continuous deployment (CD) with Codefresh pipelines"
+group: getting-started
+toc: true
+---
+
+Work in progress TBD
+
+<!--Focus on
+
+Connecting K8s cluster
+Deploying K8s
+Running kubectl
+Connecting to Helm registries
+Building Helm charts
+Pushing Helm charts
+Deploying Helm charts
+Dashboards -->
+
+
+## Connecting to Kubernetes 
+Continuous deployment starts with Kubernetes clusters, and Codefresh integrates with any known cluster provider for Kubernetes through a few simple steps. Connect your Google, Azure, Amazon Kubernetes cluster to Codefresh through simple integration steps. 
+For those Kubernetes clusters that are not in our list of cluster providers, you can manually enter your cluster settings to add any generic Kubernetes cluster.
+
+See [Connecting a Kubernetes cluster]({{site.baseurl}}/docs/integrations/kubernetes/#connect-a-kubernetes-cluster).
+
+## Deploying to Kubernetes 
+Codefresh offers a variety of options for you to choose from when deploying to Kubernetes.
+Deploy to Kubernetes from the Codefresh UI, or programmatically through dedicated steps in pipelines, avoiding the need for `kubectl` commands.    
+
+**On-demand deployment**  
+For quick and easy deployment, deploy on-demand from the Codefresh UI.
+
+**Dedicated steps in pipelines**  
+We have the `deploy` step, and the more advanced `cf-deploy-kubernetes`step that enables simple templating on Kubernetes manifests.   
+
+Codefresh pipelines also support Kustomize and Helm for deployments through freestyle steps. 
+
+Finally, if you are familiar with and want to work with `kubectl`, run your own custom `kubectl` commands in a freestyle step. Read more in [kubectl](#kubectl).
+
+See [Deployment options for Kubernetes]({{site.baseurl}}/docs/deployments/kubernetes/deployment-options-to-kubernetes/).
+
+## kubectl
+`kubectl` is the command line interface for managing kubernetes clusters. Running custom `kubectl` commands in a freestyle step gives your maximum flexibility with cluster deployments.
+Codefresh automatically sets up your config context with your connected clusters. The config context is the value of the `$CF_KUBECONFIG_PATH` variable, which expands to `/codefresh/volume/sensitive/.kube/config` within the shared step volume.
+
+Codefresh has a public Docker image for kubectl at [Docker Hub](https://hub.docker.com/r/codefresh/kubectl/tags){:target="\_blank"} that you can use.
+
+Because Codefresh automatically sets up your `kubeconfig` files with the information from your cluster integrations, you can modify the current config context and run any `kubectl` command you want applied to that context. For example, leverage the parallel capability of Codefresh pipelines to create two Docker images and deploy them to two different clusters with custom `kubectl` commands. 
+
+See [Running custom kubectl commands]({{site.baseurl}}/docs/deployments/kubernetes/custom-kubectl-commands/).
+
+## Helm and Codefresh
+Codefresh supplies a built-in Helm repository with every Codefresh account. And supports, besides public HTTP repositories, several private, authenticated Helm repositories. 
+
+**Connect to Helm repositories**  
+In addition to the official Helm repositories which are displayed in the Helm charts, Codefresh allows you connect with any external Helm repository through simple integrations. You can then inject the Helm repository context into your pipelines by selecting the repository name.
+
+**Build Helm charts**  
+Install Helm charts from Helm repositories, or build a new one.
+
+<!--Codefresh has a dedicated step for Helm step to easily integrate Helm in Codefresh pipelines, and authenticate, configure, and execute Helm commands.
+The Helm step can operate in one of three modes covering most scenarios:
+* Install the chart into a Kubernetes cluster. This is the default mode if not explicitly set.
+* Package the chart and push it to the defined repository.
+Authentication to  set up authentication and add the repo to Helm. This is useful if you want to write your own helm commands using the freestyle step’s commands property, but you still want the step to handle authentication. -->
+
+Deploy Helm charts
+Deploy the Helm chart to a Kubernetes cluster, Helm repo, or both.  
+
+
+## Dashboards
+
+TBD
+<!--Dashboards are key to providing the right information at the right time.
+
+Helm Boards
+
+
+Helm Releases
+The Helm Releases dashboard provides a unique view into your production Kubernetes cluster, and actions for . You can see the current status of your cluster, including the currently deployed releases, their previous revisions including change tracking, and even roll back to a previous release.
+
+perational Dashboards ~ Exposing the most commonly needed application and environmental information to developers so that they can troubleshoot without needing assistance from the DevOps teams; even in production
+
+Analytical Dashboards ~ Developers often need to reach out to the DevOps team to get statistics and metrics around builds and deployments. Codefresh automatically generates DORA metrics as well as many other key indicators of build and deployment efficiency, which can be easily viewed in seconds by product owners and management alike.
+
+Kubernetes Services
+
+Environments
+-->
\ No newline at end of file
diff --git a/_docs/getting-started/ci-codefresh.md b/_docs/getting-started/ci-codefresh.md
new file mode 100644
index 00000000..6d0015b2
--- /dev/null
+++ b/_docs/getting-started/ci-codefresh.md
@@ -0,0 +1,98 @@
+---
+title: "Codefresh for CI"
+description: "Continuous integration (CI) with Codefresh pipelines"
+group: getting-started
+toc: true
+---
+
+<!--Focus on: 
+Building Docker images
+Compiling code
+Running unit tests
+Running integration tests
+Security scans
+Code quality  -->
+
+Work in progress 
+
+
+## Docker images
+WBuilding a Docker image from the source code is probably the most common and  basic requirement for a CI pipeline. In Codefresh you can build, push, and promote Docker images, using declarative YAML and credentials that are defined once stored centrally.
+
+**Build and push image**  
+Building a Dockerfile in a pipeline works in the same way as building the Dockerfile locally on your workstation. The `build` step in Codefresh enables you to build a Docker image in a completely declarative manner, and to automatically push it to your default Docker registry without any configuration.  
+
+See:    
+[Build and push Docker images]({{site.baseurl}}/docs/example-catalog/ci-examples/build-and-push-an-image/)  
+
+
+**View image**  
+The Images dashboard displays images from all registries connected to Codefresh. Every image is enriched with Git branch, Git hash and commit message, and any tags defined for the image. 
+
+See:    
+[Viewing Docker images]({{site.baseurl}}/docs/ci-cd-guides/working-with-docker-registries/#viewing-docker-images)
+
+
+
+**Promote image**  
+Promote an image by copying it from one registry to another. You can promote images either from the Codefresh UI, or automatically from pipelines by specifying an existing image in the pipeline step.
+
+See:    
+[Promoting Docker images]({{site.baseurl}}/docs/ci-cd-guides/working-with-docker-registries/#viewing-docker-images)
+
+
+## Code compilation
+TBD
+
+## Unit testing
+Codefresh supports all testing frameworks, including mocking frameworks, for all popular programming languages. Easily run unit tests on the source code of the application for every commit or pull request (PR) through our freestyle step in pipelines. 
+
+Run any type of unit tests in Codefresh pipelines, from smoke tests in a dockerfile, to tests with external or application images for simple applications, and evenrun them on a special testing image for complex applications.
+You can create test reports and view them whenever you need. 
+
+See:  
+[Run unit tests example]({{site.baseurl}}/docs/example-catalog/ci-examples/run-unit-tests/)
+
+
+## Integration testing
+Compared to unit tests that run on the source code, integration tests run on the application itself. You need to either launch the application itself, or one or more external services such as a database.  
+In Codefresh, you can launch these sidecar containers within the pipeline through compositions and service containers.
+
+
+See:  
+[Run integration tests example]({{site.baseurl}}/docs/example-catalog/ci-examples/run-integrations-tests/)
+
+## Security scanning
+Security scans are critical to deploying quality code. With Codefresh, in addition you can control when to implement the security scan, and then view the scan results in the Codefresh UI, without having to go to the security platform.  
+
+**Security scan platforms**  
+Codefresh can integrate with any security scanning platform that scans source code or Docker images for vulnerabilities. We already have ready-to-use Docker images for several security platforms such as Anchore, Aqua Security, Clair, Twistlock and WhiteSource. For the full list, visit our [Plug-ins library](https://codefresh.io/steps/){:target="\_blank"}.
+
+**Scan timing in pipeline step**  
+The security scan is implemented through a freestyle step, inserted anywhere in the pipeline. The fact that you can insert the step anywhere allows you to control when the scan is executed, for example, before the source code is packaged in a container, or before the container is stored in a registry or deployed to production, or any combination of these.
+
+**View scan results**  
+As with any scan, the final step is viewing the scan results. Make the scan results available in Codefresh release dashboards (Test Report button) by attaching analysis reports to the pipeline build. 
+
+**Security annotations**  
+Correlate the Docker images in Codefresh with the results of the security scanning platform by adding annotations for custom metatdata. For example, you can add annotations such as the number of issues or the URL of the full report.
+
+See:  
+[Security scanning tests]({{site.baseurl}}/docs/testing/security-scanning/)  
+[Test reporting modes]({{site.baseurl}}/docs/testing/test-reports/)  
+[Metadata in Docker images]({{site.baseurl}}/docs/pipelines//docker-image-metadata/)  
+
+
+
+## Code quality coverage
+Good quality code is central to any CI platform or tool. Codefresh integrates with the top code quality platforms/tools in the market to track code coverage, inspect code quailty, and generate code-coverage analysis reports. 
+
+Three steps to 
+* Set up integrations with the platforms/tools (Coverall, SonarQube, Codecov, for example). 
+* Copy and paste the ready-to-use step for your platform/tool into your pipeline from our [Plug-ins library](https://codefresh.io/steps/){:target="\_blank"}.
+* Reference them by name in the pipeline step, and view the updated reports in the respective UIs.
+
+See:  
+[Code coverage examples]({{site.baseurl}}/docs/example-catalog/examples/#code-coverage-examples)
+
+
diff --git a/_docs/getting-started/concepts.md b/_docs/getting-started/concepts.md
new file mode 100644
index 00000000..66b1e573
--- /dev/null
+++ b/_docs/getting-started/concepts.md
@@ -0,0 +1,113 @@
+---
+title: "Concepts in Codefresh"
+description: "Understand terminology and nuances in Codefresh"
+group: getting-started
+toc: true
+---
+Work in progress 
+
+
+### Runtime
+A Runtime in Codefresh is a  GitOps installation in your Codefresh account, in either a Hosted or Hybrid installation environment. Hosted Runtimes are installed on a Codefresh cluster and managed by Codefresh. Hybrid Runtimes are installed on customer clusters, and managed by the customers.
+You can install a  single Hosted runtime, and multiple Hybrid Runtines in a Codefresh account.  
+
+
+<!--add diagram -->
+A single Runtime can connect to and manage multiple remote clusters.  
+
+
+See:  
+[GitOps runtime architecture]({{site.baseurl}}/docs/installation/runtime-architecture)  
+[Hybrid GitOps Runtime installation]({{site.baseurl}}/docs/installation/hybrid-gitops)  
+[Hosted GitOps Runtime installation]({{site.baseurl}}/docs/installation/hosted-runtime)
+
+
+
+### Runner
+The Runner is the hybrid installation option for CI/CD pipelines in your Codefresh account. The Runner is installed as a Kubernetes native application on any Kubernetes-compliant cluster. It allows you to run pipelines on your own Kubernetes cluster, including private clusters behind company firewalls.
+
+Codefresh Runner gives you: 
+* Access to secure services (such as Git repositories or databases) that are behind the firewall and normally not accessible to the public cloud.
+* The ability to use special resources in your Codefresh pipeline that are unique to your application, GPU nodes or other special hardware only present in your data center.
+* Complete control over the build environment in addition to resources for pipelines.
+
+Every Runner installation creates a runtime enviroment in your account. Assign the Runner to any pipeline to automatically run the pipeline in your own cluster. External integrations (such as Docker registry or Helm repositories) are also available to the Runner making pipelines exactly the same regardless of their runtime environment.
+
+You can have multiple Runner installations in the same Codefresh account. A Runner can also manage multiple remote clusters in your account. 
+
+See:  
+[Codefresh Runner installation]({{site.baseurl}}/docs/installation/codefresh-runner)   
+[Runner installation behind firewalls]({{site.baseurl}}/docs/reference/behind-the-firewall)  
+
+
+### Project
+A project is a top-level entity in Codefresh for grouping related pipelines. Projects can group pipelines according to any criteria that is relevant to your enterprise. The criteria can be logical and based on teams, departments, or location for example, or funtional, and based microservices in applications. 
+Projects centralize viewing and configuration settings for the pipelines that belong to them:
+* Selecting  a pipeline shows the other pipelines in the same project.
+* Define access control and user-defined variables for the project, and they are inherited by all the pipelines assigned to the project
+
+There are no limits to the number of projects you can create in your account. You can also create standalone pipelines and assign them later to a project, or detach a pipeline assigned to a project. 
+
+See:  
+[Projects in pipelines]({{site.baseurl}}/docs/pipelines/pipelines/#pipeline-concepts)
+
+### Pipeline
+The pipeline is the central component in Codefresh that implements CI/CD processes. Everything for CI/CD in Codefresh starts and ends with pipelines.  a pipeline can do only CI, only CD, both CI and CD, or run any custom action, such as unit and integration tests.
+
+A CI pipeline can compile and package code, build and push Docker images. A CD pipeline can deploy applications/artifacts to VMs, Kubernetes clusters, FTP sites, S3 buckets, and more. And a CI/CD pipeline can combine code compilation, integration, and deployment for full CI/CD.  
+
+More to be added...
+
+<!-- ### Workflow
+A workflow is type of Kubernetes resource that lets you define and run automated workflows, and stores their state. 
+Argo Workflows is an open source workflow engine that orchestrates parallel tasks on Kubernetes, implemented as a set of Kubernetes custom resource definitions (CRDs). 
+
+Argo Workflows is part of the Argo project, which provides Kubernetes-native software delivery tools including Argo CD, Argo Events and Argo Rollouts. 
+
+What are worklfows in Codefresh?
+Workflows in Codefresh refers to our integration with Argo Workflows to implement continours integration topped with our unique functionlaity on top of vanilla 
+
+Triggers: Codefresh offers a rich set of triggers that you can select and define through the Codefresh UI as part of creating an Argo Workflow. These include Git and Cron triggers. The triggers and the event that are mapped to sensors and 
+
+Workflow Templates: Predefined library of  for Argo Workflows.   
+
+
+
+Build view dashboard: The Workflows dashboard provides 
+See Delivery Pipelines.  -->
+
+
+### Applications
+An application is a deployment to a Kubernetes, or any Kubernetes-compatiale cluster or clusters.
+Codefresh supports two types of applications:
+* Containerized applications packaged as Docker images or 
+* Argo CD applications 
+
+**Containerized applications**  
+Containerized applications are compiled, packaged, and deployed through Codefresh pipelines. Codefresh has native support for Docker artifacts, and also supports non-Dockerized applications that don’t use a Dockerfile for the actual build.
+
+Deploy an application directly to Kubernetes through the Codefresh UI, or use Helm as a package manager to deploy to Kubernetes, again from Codefresh. 
+Codefresh offers several levels of visibility into your deployments :
+* The Kubernetes dashboard displays the status of pods and Docker images.
+* The Helm dashabord displays the applications deployed to the cluster through Helm packages.
+* The Environment dashbaord displays both Helm and Kubernetes releases, the status of the cluster, and most importantly that of the builds that affect it. 
+
+See: 
+
+
+**Agro CD applications**  
+Argo CD applications conform to Argo CD's application definition CRD (Custom Resource Definition). Argo CD supports several types of Kubernetes manifests, including Jsonnet, Kustomize applications, Helm charts, and YAML/json files, and supports webhook notifications from Git. 
+
+Create Argo CD applications that are fully GitOps-compliant from the Codefresh UI. Work in form mode or directly in YAML in the Create Application wizard. Built-in validation makes it easy to identify and fix errors before commit. The application manifest is generated, committed to Git, and synced to your cluster. 
+After creation, you can edit and optimize the application, 
+
+Just as with Dockerized applications, you get full visibily into the applications and their deployment thorugh the global Analytics, DORA metrics, and the Application dashboards. The Applications dashboard displays the individual deployments across your enterprise. Drill down shows the current state of all the resources in the application with actions and detilaed information for each resource.
+
+
+
+### Triggers
+TBD
+
+### Events
+TBD
+
diff --git a/_docs/getting-started/gitops-codefresh.md b/_docs/getting-started/gitops-codefresh.md
new file mode 100644
index 00000000..059a2136
--- /dev/null
+++ b/_docs/getting-started/gitops-codefresh.md
@@ -0,0 +1,8 @@
+---
+title: "Codefresh for GitOps"
+description: "Argo CD  with Codefresh GitOps"
+group: getting-started
+toc: true
+---
+
+Work in progress TBD
\ No newline at end of file
diff --git a/_docs/getting-started/intro-to-codefresh.md b/_docs/getting-started/intro-to-codefresh.md
new file mode 100644
index 00000000..850aad11
--- /dev/null
+++ b/_docs/getting-started/intro-to-codefresh.md
@@ -0,0 +1,113 @@
+---
+title: "Introduction to Codefresh"
+description: "What is Codefresh?"
+group: getting-started
+toc: true
+---
+
+TBD
+
+
+<!--- What's different in Codefresh when it comes to continuous integration (CI) and continuous delivery (CD)?
+There is a long answer and a short one.
+
+Let's start with the short answer: 
+
+Codefresh:
+* Is a _complete CI/CD solution_, and not just CI.
+* Works with all major Git platforms and cloud providers. There is no lock-in with any particular vendor.
+* Has pipelines with Has several unique features such as a distributed Docker layer cache, an auto-mounted shared volume, a private Docker registry and a private Helm repository.
+* Built-in Kubernetes and Helm dashboards 
+* Helm charts browser, and Helm environment board 
+
+As you can see, Codefresh is turbo-charged CI/CD. We cover the full software lifecycle. View a release in the Kubernetes dashboard, click on it and go to the Docker image, click on the Docker image and go to the build that created it, all from a single interface. 
+
+
+How does Codefresh do it?
+Everything for CI/CD in Codefresh starts and ends with pipelines. In Codefresh, a pipeline can do pretty much anyhting, only CI, only CD, both CI and CD.
+
+Your CI pipeline can compile and package code, build and push Docker images. The CD pipeline can deploy applications/artifacts to VMs, Kubernetes clusters, FTP sites, S3 buckets, and more. And yet another pipeline combines both integration and deployment for full CI/CD.
+Other pipelines can run unit tests, integration tests, acceptance tests etc. CI/CD pipeline to create and deploy your applications, or a pipeline run any custom action, such as tests.
+
+
+
+
+
+Completely programmatic approach
+Unlike other CI/CD platforms which can be tightly coupled to a single Git provider, or a specific vendor or set of tools, Codefresh supports a fully programmtic implementation. Pipelines are create pipelines and define the pipeline’s steps, triggers, and variables.
+
+Everything in the pipeline is defined as code and applied with the command line. Storing the definitions in a code repo ensures consistenct. Upscaling or expanind Doing so means we can create all of our pipelines in a consistent way and store those definitions in a code repository. Taking this one step step deeper, we could then create a bootstrap pipeline in Codefresh that generates pipelines when new definitions are added to this repo. See our previous post Programmatic Creation of Codefresh Pipelines (part 2) for more on this.
+
+
+The Docker registry integrations and all cluster integrations are automatically available to all pipelines. You don’t need docker login commands or kubectl commands to set up a Kube context inside your pipeline.
+
+
+
+Pipelines can Run unit tests, integration tests, acceptance tests etc.
+
+
+
+
+
+Pipeline extras
+We support all Git providers: Both on-premises and cloud 
+provides a rich set of triggers: Trigger pipelines  on a schedule, from a push to a docker registry or from a push to a helm registry or from actions that happened in Git.
+Has a rich, modern API With Codefresh, you can trigger a pipeline
+
+Since Codefresh is decoupled from any single pipeline source, we provide a programmatic way to 
+
+
+## CI/CD pipelines
+
+As mentioned earlier, everything in Codefresh CI/CD starts and ends with pipelines. 
+A Codefresh pipeline has two distinct aspects:
+
+* Pipeline specifications
+  Specifications define the pipeline:
+  * Metadata such as name, project, tags, in Codefresh
+  * Events that trigger the pipeline, such as webhooks, cron events, etc.
+  * Steps to use for this pipeline (inline, from a repo, etc.)
+
+* Pipeline steps
+  Pipeline steps are essentially a collection of Docker images that define the:
+  * Jobs to run
+  * Sequence in which to run the jobs
+  * CI and CD processes to implement
+
+  Step types range from clone, build, deploy, and, a freestyle step when no size fits.  
+  For ready-to-use collections of pipeline steps, check out our [Plugin marketplace](https://codefresh.io/steps/){:target="\_blank"}
+
+
+
+To see how pipeline work, start with the [Introduction to Codefresh pipelines]({{site.baseurl}}/docs/configure-ci-cd-pipeline/introduction-to-codefresh-pipelines/), or jump to [pipeline creation]({{site.baseurl}}/docs/configure-ci-cd-pipeline/pipelines/).
+
+## Releases and dashboards
+Dashboards are key to providing information at the right time and in 
+perational Dashboards ~ Exposing the most commonly needed application and environmental information to developers so that they can troubleshoot without needing assistance from the DevOps teams; even in production
+
+Analytical Dashboards ~ Developers often need to reach out to the DevOps team to get statistics and metrics around builds and deployments. Codefresh automatically generates DORA metrics as well as many other key indicators of build and deployment efficiency, which can be easily viewed in seconds by product owners and management alike.
+
+## Integrations
+For a seamless CI/CD experience, Codefresh has native integrations with alomst every major provider.
+Easily connect Git providers, registry providers, storage providers, secret stores, and notification channels 
+
+Docker registry and all cluster integrations are automatically available to all pipelines. You don’t need Docker login commands or `kubectl` commands to set up a Kube context inside your pipeline.
+
+Go to Pipeline Integrations in the UI, and see how to 
+## Where to go from here
+Here are several links we think wouuld be useful t
+
+### Quick starts
+To get up and running, follow our quick starts. The quick start modules are a series of flows that guide you from setting up your first account in Codefresh, to creating a basic pipeline, and deploying to Kubernetes.
+See XREF TBD 
+
+### Example catalog
+For those who are familiar with CI/CD, we have an extensive collection of examples, covering several CI and CD scenarios:
+[CI examples]({{site.baseurl}}/docs/example-catalog/ci-examples/)
+[CD examples]({{site.baseurl}}/docs/example-catalog/cd-examples/)
+
+### Guides
+And finally, if you want more meat, dive in to our detailed guides.
+XREF TBD
+
+-->
\ No newline at end of file