diff --git a/2.0/docs/services/workloads.md b/2.0/docs/services/workloads.md
index cca3dddd..35ec2b28 100644
--- a/2.0/docs/services/workloads.md
+++ b/2.0/docs/services/workloads.md
@@ -285,3 +285,10 @@ Service import validates workloads strictly.
 - When the chart can be rendered during validation, each selector must resolve to exactly one rendered workload of the declared kind.
 - Workload references used by endpoints, cron jobs, backups, imports, actions, and database actions must point to existing workloads.
 - In inherited services, overridden workloads and containers must already exist in the base service.
+
+### Fixed component image tags
+
+A service containing several components can specify an explicit tag in each container's `image`, for example
+`supabase/gotrue:v2.196.0`. That tag takes precedence over the selected service option's image tag. Untagged image
+repositories continue to use the option tag, or the option version when no tag is set. This allows one service option
+to identify a tested bundle whose components have different versions. Registry ports are not image tags.
diff --git a/2.0/docs/stacks/catalog/index.md b/2.0/docs/stacks/catalog/index.md
index e5677cc9..890c407e 100644
--- a/2.0/docs/stacks/catalog/index.md
+++ b/2.0/docs/stacks/catalog/index.md
@@ -14,6 +14,8 @@ storage, and defaults. Browse all available stacks in the [Wodby stack catalog](
 - [WordPress](wordpress/index.md): build, runtime configuration, shared content, and cron behavior
 - [Matomo](matomo/index.md): installer database values, geolocation, mail, and archiving cron
 
+- [Supabase](supabase/index.md): credentials, storage, recovery and self-hosting limits
+
 ## Service stack guides
 
 - [Gotenberg](gotenberg/index.md): private endpoint usage and migration from AthenaPDF
diff --git a/2.0/docs/stacks/catalog/supabase/index.md b/2.0/docs/stacks/catalog/supabase/index.md
new file mode 100644
index 00000000..b6192aae
--- /dev/null
+++ b/2.0/docs/stacks/catalog/supabase/index.md
@@ -0,0 +1,41 @@
+# Supabase
+
+The Supabase stack runs one self-hosted Supabase project per app environment, with a dedicated database and the Auth,
+REST, Realtime, Storage and Studio components. The [stack source](https://github.com/wodby/stack-supabase) and its service
+manifests define the supported component bundle and current defaults.
+
+## Initial setup
+
+Set the application site URL, allowed authentication redirects and sender email address. Connect an SMTP integration
+for confirmation and recovery emails. Wodby routes the public Supabase URL to the API gateway. Studio uses username
+`supabase` and the generated `dashboard_password` service token.
+
+Client applications use the public URL and the `publishable_key` token. Trusted server applications may use
+`secret_key`; it bypasses ordinary user row-level security and must not be included in browser code.
+
+## Storage
+
+The default filesystem backend keeps Storage objects on a persistent volume, shared with image processing in the
+same pod. Studio snippets have separate persistence. Optional S3 storage uses an existing bucket and a variable
+integration providing `AWS_ACCESS_KEY_ID`, secret `AWS_SECRET_ACCESS_KEY`, and `AWS_REGION`. Set the service's bucket
+and optional custom endpoint settings before connecting it. Existing filesystem objects are not migrated automatically.
+
+## Backup, restore and copies
+
+The PostgreSQL service uses `wodby/supabase-postgres`. Its database backup includes non-template database dumps, roles and the pgsodium root encryption key in one checksummed archive. Database files and the key share one persistent volume.
+
+Use the service's **Supabase database import** operation with a `.tar.gz` or `.tgz` backup from the same supported bundle. Import restores into a fresh replacement volume and finishes before PostgreSQL accepts connections. Invalid bundles and imports into a running database are rejected. Supabase-owned database passwords follow the target environment's database token; custom role passwords are preserved.
+
+Establish a coordinated recovery point with application writers stopped. Preserve database backups, matching application signing/encryption tokens and the corresponding stored objects. The filesystem backup does not include objects stored in an external S3 bucket. Database import does not restore application tokens or stored objects.
+
+Restore the corresponding objects and application tokens before resuming application writers. Copies retain token values; rotate client-facing credentials deliberately when the copy needs separate access, while preserving encryption tokens needed to read copied data.
+
+## Upgrades and limitations
+
+Upgrade the tested component bundle together. Changing a PostgreSQL major image tag against an existing data directory
+is not a supported upgrade procedure. A Helm rollback does not undo database migrations.
+
+The initial stack uses single-replica components. Edge Functions, connection pooling, Supabase analytics, MCP and
+high-availability PostgreSQL are not included. Supabase Cloud organization management, branching and managed PITR are
+separate capabilities. See the [Supabase self-hosting documentation](https://supabase.com/docs/guides/self-hosting)
+for the distinction from the hosted platform.
diff --git a/2.0/mkdocs.yml b/2.0/mkdocs.yml
index e00dd62a..edbb9a53 100644
--- a/2.0/mkdocs.yml
+++ b/2.0/mkdocs.yml
@@ -260,6 +260,7 @@ nav:
               - Connect to Solr: stacks/catalog/drupal/solr.md
           - WordPress: stacks/catalog/wordpress/index.md
           - Matomo: stacks/catalog/matomo/index.md
+          - Supabase: stacks/catalog/supabase/index.md
           - Gotenberg: stacks/catalog/gotenberg/index.md
           - Solr: stacks/catalog/solr/index.md
           - OpenSMTPD: stacks/catalog/opensmtpd/index.md