docs: extend docs

docs/auth/email.md

@@ -0,0 +1 @@
+# Email

docs/auth/overview.md

@@ -0,0 +1 @@
+# Overview

docs/auth/providers/azure.md

@@ -0,0 +1 @@
+# Providers

docs/components/apigateway.md

@@ -0,0 +1 @@
+# APIGateway

docs/components/core.md

@@ -0,0 +1,14 @@
+# Core
+
+The `Core` resource configures the essential Supabase services:
+
+- PostgREST
+- Auth
+
+and it manages the initial DB migrations that are not done by the services themselves and are part of the [supabase/postgres](https://github.com/supabase/postgres) repository.
+
+To deploy a basic `Core` instance, you can use the following snippet as a 'template':
+
+```yaml title="Basic 'Core' example" linenums="1"
+--8<-- "config/samples/supabase_v1alpha1_core.yaml"
+```

docs/development/tools.md

@@ -0,0 +1,19 @@
+# Tools
+
+## Essentials
+
+- Current Go version (see `go.mod`)
+- Any Docker daemon[^1]
+- kubectl (v1.30.0+.)
+- Access to a Kubernetes v1.30.+ cluster[^2]
+
+[^1]: Docker Desktop, Orbstack, Podman, ...
+[^2]: kind, Orbstack, Docker Desktop, Rancher Desktop, k3s, microk8s, ...
+
+## Recommended
+
+- [husky](https://github.com/go-courier/husky)
+- [tilt](https://tilt.dev/)
+- [ctlptl](https://github.com/tilt-dev/ctlptl)
+- [goreleaser](https://goreleaser.com/)
+- [ko](https://ko.build/)

docs/getting_started.md

@@ -1,5 +1,11 @@
 # Getting Started
 
+## Dependencies
+
+The operator has the following dependencies:
+
+- [cert-manager](https://cert-manager.io/) (to issue webhook certificates)
+
 ## 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:
@@ -12,3 +18,12 @@ The manifest is rendered as part of the release workflow and based on [kustomize
 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
+
+As described in the [overview](./components/overview.md) the custom resources are 'grouping' the Supabase services into 'modules'.
+A common basic instance requires:
+
+- a [`Core`](./components/core.md) instance (PostgREST, Auth & DB migrations)
+- an [`APIGateway`](./components/apigateway.md) instance (gateway to handle JWT auth and routing)
+
+it is perfectly possible to deploy for instance only an `APIGateway` and a `Storage` instance as well if you don't need the API or you can also manage your own API gateway if you prefer it that way.
+The operator setup tries to be as 'unopinionated' as possible.

docs/index.md

@@ -9,7 +9,7 @@ This project is not affiliated with the Supabase project or company in any way.
 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.
 
-## Targets
+## Goals
 
 - Make it as easy as possible to deploy Supabase on a Kubernetes cluster
 - Manage updates of components
@@ -23,7 +23,7 @@ This operator replaces tedious Helm values files with a small set of custom reso
   - ConfigMaps
   - *soon*: NetworkPolicies
 
-## Non-Targets
+## Non-Goals
 
 - Manage **all** Kubernetes aspects, it does **not** create:
   - PodDisruptionBudgets