Deploy latest docs to Prod

.gitignore

@@ -1,5 +1,6 @@
 
 site/
+lib/
 .idea/
 .vscode/
 .DS_Store

CHANGELOG.md

@@ -2,6 +2,68 @@
 
 This is the changelog for the current year. Changelogs for previous years can be found [here](#changelog-archives).
 
+## 2023-12-02-fe-bugs | 11 DECEMBER 2023
+
+`IMPROVEMENTS`
+
+- Organization Homepage
+    - Sorting environments in Project cards based on status - moved “non-ready” environments to the bottom
+- Applications
+    - IDE no longer scrolls to the top after committing changes to a file
+- Deployments
+    - Improved “skipped” message in *Messages* tab - (we made it sound like we threw your topic messages in the bin)
+- Code Samples
+    - If searching with a filter applied yields no results: empty state message and CTA changed to *clear* applied filters
+    - Enabled “+ Add new” button in topic input field
+    - Various loading spinners on CTAs to improve click-action feedback
+- YAML
+    - Improved supplementary message on syncing with 0 changes to inform user that no changes are made during sync
+    - Editing YAML retains carat position (if you click on the YAML section you want to edit before you click edit, then we take you there)
+
+`BUG FIXES`
+
+- Organization Homepage
+    - Prevent “undefined” repository issue when switching in and out of projects too quickly
+    - Prevent “login required” error in ungated experience
+- Data Explorer
+    - Waveform was disappearing if you came from *Live data*
+- “Topic created” notifications weren’t taking the user to the *Topics* page
+- Deployments
+    - Deployment dialogue sliders for *CPU* and *Memory* were using the wrong increments
+    - *CPU* and *Memory* metrics weren’t cleared when switching to a stopped deployment
+    - Destinations were appearing as Transformations in *Lineage* views
+- Pipeline
+    - Changing topic on a deployment wasn’t updating the pipeline view
+    - Adding replays from placeholders didn’t use the correct topic
+    - Link for *Public URL* on deployment cards weren’t pointing to the *Public URL*
+- Applications
+    - Uploading and replacing file wasn’t working
+    - Progress bars on *replays* in the *Lineage* tab weren’t moving
+    - Heartbeat connection was not reconnecting after disconnection, and it was calling a V1 endpoint
+    - Topics being created when user was adding variables
+- YAML
+    - *YAML* was appearing in edit mode when *YAML* was loading
+    - Switching environments when viewing the *YAML* was not updating the environment variables in the *variables* tab
+    - Error in sync dialogue was clipping code
+- Various component-interaction console errors
+- Error messages in various dialogues were persisted
+- Updated tab names related to domain changes
+- Various UI width fixes
+
+## 2023-12-01-f1 | 7 DECEMBER 2023
+
+`IMPROVEMENTS`
+
+- Deleting old trial workspaces 7 days after disabling
+
+## 2023-12-01-freetier | 6 DECEMBER 2023
+
+`IMPROVEMENTS`
+
+- Increase quotas for free and base tier
+- Update trial expired email and delete trials according to that
+- Remove unneeded IDE PVCs possibly costing lot
+
 ## 2023-11-03-promocode | 16 NOVEMBER 2023
 
 `NEW FEATURES`
@@ -83,7 +145,7 @@ This is the changelog for the current year. Changelogs for previous years can be
     - -1 retention in topics was setting as -60000.
 - Platform
     - Workspaces were stuck in “creating”/”updating” status
-    - Topic quota logic caused external topics and topics that failed to create to count towards organisation quotas
+    - Topic quota logic caused external topics and topics that failed to create to count towards organization quotas
     - StreamPackageType changed so icons for data types in messages weren’t being displayed correctly
     - Changing to a locally-created branch was not displaying backend errors
     - Resolved various console errors caused by Front-End component interactions
@@ -151,7 +213,7 @@ This is the changelog for the current year. Changelogs for previous years can be
     - Improved YAML parsing to maintain the order of elements during merging and syncronization.
     - YAML variables definition in the code can now be composed by a combination of text or multiple variables. (ex: “{variable1}-sometext-{variable2}”)
     - Loader on branch dropdown when switching branches for an environment
-    - New organisation homepage Projects/Environments counters
+    - New organization homepage Projects/Environments counters
 - Other
     - Autofocus behavior improvements to input fields on onboarding
     - Improved FE performance by changing the way angular components are interacted with
@@ -373,7 +435,7 @@ Second release under tag release/2023-10-01-deployment-hf-2:
 - Internal:
     - Added a new updater service system that simplifies the release process
     - Increased resources for some of the Workspace services by default to improve the stability for standard workspaces, and Added some Requests configuration for Premium workspaces
-    - New Quota system introducing new quotas per organisation
+    - New Quota system introducing new quotas per organization
     - New payment modal explaining serverless when a user clicks on payment CTAs
 
 `BUG FIXES`
@@ -442,7 +504,7 @@ Second release under tag release/2023-10-01-deployment-hf-2:
     - Refresh button to get latest changes from git
     - Confirmation dialogue when deleting a branch
     - Dependencies are installed upon opening the application
-- Inviting a user to an organisation now displays a “pending” or “error” status
+- Inviting a user to an organization now displays a “pending” or “error” status
 - README files are selected by default in *Code Samples*
 - Deployments are no longer auto-focused after deploying (it was getting annoying)
 - Minor enhancements in dropdown behavior during query selection in the data explorer
@@ -528,7 +590,7 @@ Second release under tag release/2023-10-01-deployment-hf-2:
 - Topic cards in the deployment details now show a “creating” status if the topic isn’t ready yet
 - Clicking “Edit code” in a code sample takes you directly to a newly created application (V2 ONLY)
 - Added “client.id” property to some of our services to track Quix Kafka usage on external providers like Confluent.
-- Added the ability to set special Quotas per Organisation
+- Added the ability to set special Quotas per Organization
 - Improved internal Quix reports with more information
 - Deployment details
     - Replica display is now based on deployment type (job/service). Running a job multiple times no longer displays replicas of previous jobs.

docs/byoc/byoc-vs-cloud.md

@@ -0,0 +1,31 @@
+# When to choose Quix Bring Your Own Cluster (BYOC) Enterprise Edition?
+
+Quix Cloud is suitable for a managed experience. BYOC offers the power of the Quix, along with the ability to control and scale the underlying services, and infrastructure. 
+
+When hosting your own Quix platform, you are in full control of how all its parts operate. Useful defaults are provided, but BYOC can be configured to fit your exact use case.
+
+| | Quix Cloud | Quix BYOC |
+|----|----|----|
+| Analyze data streams | Yes   | Yes |
+| Quickly deploy real-time apps | Yes   | Yes |
+| ISO 27001 certified | Yes   | No[^1] |
+| You store the data | No | Yes[^2] |
+| On-premise cost savings | No | Possible[^3] |
+| Consume cloud reservations | No | Possible[^3] |
+| Bespoke Networking | No | Yes |
+| Bespoke Storage | No | Yes |
+| Private CA certificates | No | Yes |
+| Can be scaled to your needs | Yes | Yes |
+
+[^1]:
+    The process of creating Quix deliverables continues to be ISO 27001 certified. This means that the containers and services inside them that you receive as part of the BYOC offering are built to stringent security standards. You can expect them to follow best industry practices and safe defaults. 
+
+    Once you install them on your environment, they become part of your processes and fall under your data security policies. Therefore these software packages may or may not be ISO (and ISO27001 specifically) compliant when deployed outside of Quix Cloud.
+
+[^2]:
+    Exclusively. Quix BYOC Enterprise Editions are self-contained. _Only_ you store your data.
+
+[^3]:
+    Running your own infrastructure on your premises (or in a co-location) is often more cost-efficient than most cloud offerings. This is particularly true if you have specific hardware requirements that are not easily met in the cloud, such as GPUs, FPGAs, ultra-high-speed storage or networking. However, Quix Cloud remains the best managed experience.
+
+    You may choose to run Quix BYOC in your own cloud environment, consuming reservations or quotas established in prior agreements with cloud providers. This has the potential to lower your operational costs, while maintaining a cloud presence with Quix. 

docs/byoc/installation.md

@@ -0,0 +1,116 @@
+# How to install BYOC
+
+The summary of the deployment procedure is as follows:
+
+1. Create a [Kubernetes cluster](#1-create-a-kubernetes-cluster)
+2. Obtain a Quix Container Registry [API key](#2-obtain-an-api-key-to-pull-quix-platform-containers) to pull Quix Platform containers
+3. Obtain a copy of the Quix Platform [BYOC installer](#3-obtain-a-copy-of-the-quix-platform-byoc-installer-ansible-recipe--docker-image) (Ansible Recipe + Docker Image)
+4. [Prepare Secrets](#4-prepare-secrets-and-platform-configuration) and platform configuration
+5. Run the [installer container](#5-run-the-installer-container)
+6. [Push Secrets](#6-push-secrets-and-platform-configuration-to-the-cluster) and platform configuration to the cluster
+7. Optional: [Initialize ArgoCD](#7-optional-initialize-argocd)
+8. [Install Quix Platform](#8-install-quix-platform) for the first time
+
+This is explained in more detail in the following step-by-step guide.
+
+## 1. Create a Kubernetes cluster
+
+This step is where you have the most freedom of choice. The assumption this guide works with is that you have an operational Kubernetes cluster ready to schedule pods and create the requirement dependencies. Any Kubernetes installation should work as long as it clears the requirements in the [Requirements](requirements.md) section.
+
+In short, if your Kubernetes cluster configuration isn't _particularly_ niche, it should work without any extra configuration.
+
+Quix recommends a production ready Kubernetes cluster, with HA control plane and multiple worker nodes, as this makes maintenance and scaling easier.
+
+## 2. Obtain an API key to pull Quix Platform containers
+
+In this step you will be receiving a username / API token and docker registry URL. These will be provided to you by Quix before you start the installation process.
+
+## 3. Obtain a copy of the Quix Platform BYOC installer (Ansible Recipe + Docker Image)
+
+With the provided API key you can download the installer from our private Container Registry. The installer is a Docker image that contains an Ansible recipe and all the required dependencies to run it. This way you don't need to install Ansible (and its particular Python version dependencies), Helm and all the other programs and libraries required to run the installer. We have packaged it all to offer a turn-key, convenient experience.
+
+## 4. Prepare Secrets and platform configuration
+
+A successful installation of the Quix Platform requires a few secrets and variables to be set. Secrets are used to store sensitive information about your Platform Installation. API keys, usernames, passwords for all the services, dependencies and integrations are stored in Secrets which the Installer will use to configure the Platform. By storing secrets in a Kubernetes native way we ensure that any subsequent successful installations of the Quix Platform do not depend on the machine used for installation. After a successful initialisation of the Secrets and Platform configuration, anyone with the correct permissions should be able to maintain the platform.
+
+If ArgoCD is used -- of which we supply an opinionated installation, if you choose to use it --, it will be able to utilize these secrets and configuration to maintain the platform.
+
+## 5. Run the installer container
+
+The container is built and tested with Docker. On any system capable of running Docker, you can run the installer with the following command:
+
+```bash
+./quixplatform container quix -V 1.1.2
+```
+
+This will run the Quix Platform Installer using the Quix Platform CLI tool provided to you ahead of the installation process. 
+
+![Quixplatform CLI](../images/byoc/using-quixplatform-cli.png){width=80%}
+
+## 6. Push Secrets and platform configuration to the cluster
+
+The Quixplatform CLI tools help you push the Secrets and Platform configuration to the cluster.
+
+1. Ensure you have everything set correctly in `vars/platform-variables.yaml` and `vars/platform-secrets-human.yaml`
+
+Then, from inside the Installer container started in step 4, run the following command:
+
+```bash
+namespace=quix
+./secrets.sh init vars/platform-secrets-human.yaml.template vars/platform-secrets-human.yaml
+# Add your secrets to vars/platform-secrets-human.yaml
+./secrets.sh encode vars/platform-secrets-human.yaml vars/platform-secrets.yaml
+./secrets.sh push ${namespace} vars/platform-secrets.yaml
+./quixplatform config ${namespace} -f vars/platform-variables.yaml
+```
+As a general rule, commands and steps are designed to be idempotent wherever possible. This is also the case when manipulating secrets and platform configuration:
+any subsequent pushes that make no changes will look like this: 
+![Quixplatform CLI Config Push](../images/byoc/push-variables.png){width=80%}
+
+## 7. Optional: Initialize ArgoCD
+
+Run the following commands inside the installer container:
+
+Change values in `init-scripts/application.yaml.template` to meet your requirements.
+The following lines are of particular interest:
+
+```yaml
+    repoURL: ''
+    targetRevision: stable
+    path: releases/
+```
+
+These define what release 'stream' your environment is subscribed to. When running ArgoCD connected to our release branches, any updates we deploy to the repository your environment follows will be automatically applied, based on GitOps principles. There's a [little more to it](release-filtering.md), but generally speaking your environment will deploy the latest version of the platform, unless you specify otherwise.
+
+Any software package we release for the BYOC offering will have been put through our QA process and validated. That said, we operate multiple external branches to facilitate testing leading-edge features on your test environments before we add them to the stable branch.
+
+```bash
+argo_namespace=argo
+quix_namespace=quix
+init-scripts/init.sh ${argo_namespace} ${quix_namespace}
+```
+
+This will initialize ArgoCD and create the Quix application in the namespace you specify. If you do not specify a namespace, it will default to `argocd` and `quix`.
+
+!!! tip
+    You may host your own release repository to subscribe to with ArgoCD. This allows you to be in ultimate control of the entire release process.
+
+## 8. Install Quix Platform
+
+Inside the installer container, run the following command:
+
+```bash
+./quixplatform install
+```
+
+or if ArgoCD is installed, but you want to manually trigger the installation:
+
+```bash
+./quixplatform install --context=<your_kubectl_context_name>
+```
+
+This installs Quix on your Kubernetes cluster. The installation process will take three to five minutes. 
+
+The progress of the installation is displayed as Ansible roles initialize and set up the various components and then the Quix Platform itself, as shown in the following screenshot:
+
+![Quixplatform Successful Installation](../images/byoc/byoc-successful-install.png){width=80%}

docs/byoc/overview.md

@@ -0,0 +1,17 @@
+# Bring Your Own Cluster (BYOC)
+
+BYOC is Quix, packaged to run on your own Kubernetes cluster. Bring Your Own Cluster, control its resources and make them work efficiently by deploying the Quix Platform to it.
+
+!!! Info "Glossary"
+
+    **Kubernetes** is a container orchestration platform tailored to offer great flexibility and power. You can run Kubernetes on a variety of different computers ranging from your laptop to hundreds of Virtual Machine nodes in data centres distributed around the world.
+
+The driving force behind the design of **Quix BYOC Enterprise Edition** was to enable the installation of the Quix Platform in as many different configurations of Kubernetes as technology allows. This enables us to offer Quix on a range of platforms, from minimal-viable clusters functioning as pilot projects on spare bare-metal hardware, to extensive production clusters managed within AKS, EKS, GCP, Proxmox and similar environments. These advanced setups can include hundreds of CPU cores and terabytes of RAM, utilize container engines off the beaten path and provide storage through a multitude of means.
+
+Quix has developed Quix BYOC to deliver a safe, opinionated default configuration, designed to ensure our platform operates effectively across a diverse range of Kubernetes cluster setups. Additionally, it is crafted for easy integration with existing components and technologies you currently employ and wish to continue using.
+
+Quix have also made a conscious effort to ensure Quix works well with clusters that already run workloads. We do not require a dedicated empty cluster for Quix to run on, although you may want to consider operating BYOC in its own environment for a variety of reasons.
+
+## Next steps
+
+See the requirements of the [Quix platform](requirements.md)