docs: initial CI setup

docs/components/overview.md

@@ -0,0 +1,19 @@
+# Overview
+
+## Architecture
+
+The following diagram explains the overall architecture of Supabase as it is deployed from this operator:
+
+```kroki-excalidraw
+@from_file:./images/overview.excalidraw
+```
+
+The dashed parts on the left are not managed by this operator but illustrate how traffic can be routed to the Supabase instance.
+
+## Core
+
+The `Core` custom resource (CR) is the basic resource that - if not in an 'edge case' (pun intended) - configures all basic aspects of a Supabase instance:
+
+- PostgREST API
+- Supabase Auth
+- initial database migrations

docs/getting_started.md

@@ -0,0 +1,14 @@
+# Getting Started
+
+## Deploying the operator
+
+The easiest way to deploy the operator is to fetch the manifest from the [releases](https://code.icb4dc0.de/prskr/supabase-operator/releases) and apply it like this:
+
+```bash
+kubectl apply --server-side -f manifest.yaml
+```
+
+The manifest is rendered as part of the release workflow and based on [kustomize](https://kustomize.io/).
+If you want to customize the deployment, you can start from the [release/default](https://code.icb4dc0.de/prskr/supabase-operator/src/branch/main/config/release/default) layer and build your own manifest.
+
+## Deploying a basic Supabase instance

docs/index.md

@@ -1,17 +1,36 @@
-# Welcome to MkDocs
+# About
 
-For full documentation visit [mkdocs.org](https://www.mkdocs.org).
+This is a Kubernetes operator for managing self-hosted [Supabase](https://supabase.com/) instances.
+It is built using the [Kubebuilder](https://book.kubebuilder.io/) framework.
+This project is not affiliated with the Supabase project or company in any way.
 
-## Commands
+## Description
 
-* `mkdocs new [dir-name]` - Create a new project.
-* `mkdocs serve` - Start the live-reloading docs server.
-* `mkdocs build` - Build the documentation site.
-* `mkdocs -h` - Print help message and exit.
+This is currently a work-in-progress experiment to replace existing Helm charts for Supabase as they tend to be hard to deploy and to manage and the default Supabase stack - although working great as a single instance or in their SaaS instances - isn't a perfect fit for Kubernetes.
+This operator replaces tedious Helm values files with a small set of custom resources that allow an user to quickly deploy a Supabase instance without having to know much (if anything) of the Supabase internals.
 
-## Project layout
+## Targets
 
-    mkdocs.yml    # The configuration file.
-    docs/
-        index.md  # The documentation homepage.
-        ...       # Other markdown pages, images and other files.
+- Make it as easy as possible to deploy Supabase on a Kubernetes cluster
+- Manage updates of components
+- Run Supabase specific migrations on the database (those managed in the supabase/postgres repository)
+- Make Supabase as resource effective as possible (e.g. replaced Kong with Envoy)
+- Keep it as secure as possible (e.g. adding OAuth2/Basic auth to studio if desired)
+- Manage **all** aspects of the Kubernetes resources, this operator manages everything where a user would need deeper insights into Supabase like:
+  - Deployments
+  - Services
+  - Secrets (although you can ship your own if you want to)
+  - ConfigMaps
+  - *soon*: NetworkPolicies
+
+## Non-Targets
+
+- Manage **all** Kubernetes aspects, it does **not** create:
+  - PodDisruptionBudgets
+  - HorizontalPodAutoscalers
+  - Ingress or HTTPRoutes
+- Replace existing Postgres operators like cloudnative-pg, CrunchyData, Zalando Postgres Operator, ...
+- Manage the database instance e.g. making backups, ... that should be done by the Postgres operator or by the user
+- Manage your application e.g. run app specific migrations, host your frontend, ...
+
+This operator tries to be as un-opionionated as possible and thereofore does not make assumptions on how you expose APIs to your users (Ingress, GatewayAPI, LoadBalancer service (coming soon))...