diff --git a/docs/kratos/guides/multi-tenancy-multitenant.md b/docs/kratos/guides/multi-tenancy-multitenant.md
index 9f4a5f4eb..07b7e29b9 100644
--- a/docs/kratos/guides/multi-tenancy-multitenant.md
+++ b/docs/kratos/guides/multi-tenancy-multitenant.md
@@ -3,19 +3,6 @@ id: multi-tenancy-multitenant
 title: Multitenancy
 ---
 
-Ory Kratos doesn't implement multi-tenancy in its application logic, but it's possible to implement multi-tenancy with Ory Kratos!
-
-The recommended approach is to run one or more (depending on your scale) SQL databases and create one database schema per tenant
-in these database instances. So one PostgreSQL database instance could, for example, host 15000 tenants who each have access to
-one schema.
-
-Ory Kratos itself should run as one instance per tenant with a configuration tailored for that specific tenant. The minimum
-required change is using different secrets and the tenant's DSN (`postgresql://user:pass@.../tenant-123`). Because Ory Kratos is
-very lightweight, the deployment overhead becomes negligible.
-
-Deployment complexity increases but is addressable with container orchestration systems such as
-[Kubernetes](https://kubernetes.io/). This approach has several advantages:
-
-- Absolute isolation of tenants which implies: better security, better privacy, more control.
-- Easy sharding and partitioning because database schemas isolate tenants.
-- No complexity in Ory Kratos business logic and security defenses.
+[Ory Network](https://console.ory.sh) is the only available option to have a multi-tenant Ory Kratos set up. It is not possible to
+self-host Ory Kratos as a multi-tenant service as its data model does not support this due to data, scalability, and operational
+complexity.