diff --git a/apps/docs/content/docs/core/cloud.mdx b/apps/docs/content/docs/core/cloud.mdx
index b6cb2d5..839905b 100644
--- a/apps/docs/content/docs/core/cloud.mdx
+++ b/apps/docs/content/docs/core/cloud.mdx
@@ -3,18 +3,85 @@ title: Dokploy Cloud
description: "Deploy your apps to multiple servers remotely without worrying about the underlying infrastructure."
---
+import { Callout } from 'fumadocs-ui/components/callout';
-Dokploy Cloud allows you to deploy your apps to a cloud provider of your choice. This means that you can deploy your apps to any cloud provider, such as AWS, GCP, Azure, or DigitalOcean, without having to worry about the underlying infrastructure.
+Dokploy Cloud is the managed version of Dokploy. Instead of installing and maintaining Dokploy on your own server, the **control plane** (UI, database, and management layer) is hosted by us — you just connect your own servers and deploy.
+## How it works
-By default when you install Dokploy in a Self Hosted version, if you deploy all your applications by default they will be deployed on the same server where Dokploy UI is installed. This means that you will need to build and run your applications where Dokploy
-UI is installed, which can be a challenge if you don't have the resources to do so, also self hosted support for remote instances.
+With **Self-Hosted** Dokploy, everything runs on a single server: the UI, the database (PostgreSQL), Redis, Traefik, and your applications — all on the same machine. This works well for small setups, but as you scale, your management layer competes for resources with your actual workloads.
+**Dokploy Cloud** separates these concerns:
-Dokploy cloud starts from $4.50 per month per server, the next is 3.50$, and you can deploy as many applications you want to your remote server connected to a dokploy cloud, multi server feature is recommended for HA and scalability projects.
+```
+┌──────────────────────────────┐ ┌─────────────────────────┐
+│ Dokploy Cloud │ │ Your Server(s) │
+│ (managed by Dokploy) │ │ (any cloud provider) │
+│ │ │ │
+│ ┌────────────┐ │ │ ┌───────────────────┐ │
+│ │ Dashboard │─── deploy ──┼──────►│ │ Your apps │ │
+│ │ (UI) │ │ │ │ Your databases │ │
+│ ├────────────┤ │ │ │ Your compose │ │
+│ │ PostgreSQL │ │ │ │ Traefik (proxy) │ │
+│ ├────────────┤ │ │ └───────────────────┘ │
+│ │ Redis │ │ │ │
+│ └────────────┘ │ │ ┌───────────────────┐ │
+│ │ │ │ Monitoring agent │ │
+│ ┌────────────┐ │◄──────┤ │ (metrics → cloud) │ │
+│ │ Monitoring │ │ │ └───────────────────┘ │
+│ └────────────┘ │ │ │
+└──────────────────────────────┘ └─────────────────────────┘
+```
-You can start by registering on the [Dokploy Cloud](https://app.dokploy.com) website and follow the steps to deploy your apps, see the [Pricing](https://dokploy.com/pricing) page for more information.
+- **Control plane** (Cloud): Dashboard, user management, deployment orchestration, monitoring dashboard, and notifications.
+- **Data plane** (Your servers): Your actual applications, databases, Traefik, and a lightweight monitoring agent.
+Your code and data **never leave your servers**. Dokploy Cloud only manages the orchestration.
+## Key benefits
+| Benefit | Description |
+|---------|-------------|
+| **No management overhead** | No need to maintain the Dokploy instance itself — updates, backups, and uptime are handled for you |
+| **100% server resources for your apps** | The UI and management database don't compete with your workloads |
+| **Multi-server from day one** | Connect as many servers as you need from any provider (AWS, GCP, Azure, DigitalOcean, Hetzner, etc.) |
+| **Automatic updates** | Always on the latest version of Dokploy without manual upgrades |
+| **Support** | Direct support via email/chat (Startup) or priority SLA (Enterprise) |
+## Getting started
+
+1. Register on [Dokploy Cloud](https://app.dokploy.com).
+2. Add a server by providing the SSH connection details (IP, port, SSH key).
+3. Dokploy Cloud will set up the server automatically (Docker, Traefik, monitoring agent).
+4. Start deploying your applications, databases, and compose stacks.
+
+
+You can connect servers from **any provider** — they just need to be reachable via SSH. You can even mix providers (e.g., Hetzner for production, DigitalOcean for staging).
+
+
+## Pricing
+
+Dokploy Cloud offers several plans:
+
+| Plan | Price | Servers included | Additional servers |
+|------|-------|------------------|--------------------|
+| **Hobby** | $4.50/month per server | 1 | $4.50/month each |
+| **Startup** | $15/month | 3 | $4.50/month each |
+| **Enterprise** | Custom | Custom | Contact sales |
+| **Agency** | Custom | Custom | Contact partner team |
+
+All plans include **unlimited deployments, databases, and applications** per server. Annual billing saves 20%.
+
+See the [Pricing](https://dokploy.com/pricing) page for full plan details and feature limits.
+
+## When to use Cloud vs Self-Hosted
+
+| Use Cloud when... | Use Self-Hosted when... |
+|-------------------|------------------------|
+| You don't want to maintain the Dokploy instance | You want full control over everything |
+| You need multi-server from the start | You have a single server and want to keep it simple |
+| You want built-in monitoring without extra config | You already have your own monitoring stack |
+| You prefer automatic updates | You want to control when updates happen |
+| You need HA for the management layer | Budget is the top priority |
+
+For a full feature comparison, see [Cloud vs Self-Hosted Differences](/docs/core/differences).
diff --git a/apps/docs/content/docs/core/differences.mdx b/apps/docs/content/docs/core/differences.mdx
new file mode 100644
index 0000000..9bc98d0
--- /dev/null
+++ b/apps/docs/content/docs/core/differences.mdx
@@ -0,0 +1,129 @@
+---
+title: Cloud vs Self-Hosted
+description: "Detailed comparison between Dokploy Cloud and the Self-Hosted version."
+---
+
+import { Callout } from 'fumadocs-ui/components/callout';
+
+Both versions of Dokploy are **functionally identical** — same deployment engine, same features, same Docker/Traefik integration, same API. The difference is purely operational: **who manages the Dokploy instance itself**.
+
+## Same features, different operations
+
+Every feature available in Self-Hosted is also available in Cloud, and vice versa. This includes:
+
+- Application, Database, and Docker Compose deployments
+- Git integration (GitHub, GitLab, Bitbucket, Gitea)
+- Traefik reverse proxy with custom domains & SSL
+- Remote servers and multi-server management
+- Monitoring, notifications, backups, rollbacks
+- Preview deployments, environments, templates
+- API & CLI, schedule jobs, watch paths
+- User permissions and all Enterprise features (SSO, custom roles, audit logs, whitelabeling)
+
+There are **no feature gates** between Cloud and Self-Hosted. The core product is the same.
+
+## What's actually different
+
+The differences come down to three things:
+
+### 1. Managed uptime
+
+With **Self-Hosted**, you are responsible for keeping the Dokploy instance running. If your server goes down, restarts, or runs out of disk — you need to fix it yourself.
+
+With **Cloud**, the Dokploy team manages the uptime of the control plane (the UI, database, and management layer). Your applications still run on your own servers, but the management dashboard is maintained by us.
+
+### 2. Automatic updates
+
+With **Self-Hosted**, you update Dokploy manually when new versions are released.
+
+With **Cloud**, updates are applied automatically — you're always on the latest version without doing anything.
+
+### 3. Support
+
+With **Self-Hosted**, support is community-based (Discord, GitHub issues).
+
+With **Cloud**, you get direct support depending on your plan:
+
+| Plan | Support level |
+|------|--------------|
+| **Hobby** | Community (Discord) |
+| **Startup** | Email & Chat |
+| **Enterprise** | Priority support with SLA |
+
+## Architecture
+
+Both versions use the same architecture. The only difference is **where** the control plane runs.
+
+### Self-Hosted
+
+The Dokploy UI, PostgreSQL, Redis, and your applications all run on the same server(s) that you manage.
+
+```
+┌─────────────────────────────────┐
+│ Your Server (you manage) │
+│ │
+│ Dokploy UI + PostgreSQL + Redis│
+│ Traefik (reverse proxy) │
+│ ───────────────────────────── │
+│ Your Apps & Databases │
+└─────────────────────────────────┘
+```
+
+### Cloud
+
+The control plane runs on Dokploy's infrastructure. Your servers only run your workloads.
+
+```
+┌─────────────────┐ ┌──────────────────────┐
+│ Dokploy Cloud │ SSH │ Your Server(s) │
+│ (managed by us) │────────►│ Apps + Databases │
+│ │ │ Traefik │
+│ UI, DB, Redis │ └──────────────────────┘
+└─────────────────┘
+```
+
+
+Your **applications keep running independently** even if the Cloud control plane is temporarily unavailable. The control plane is only needed for management operations (deploys, config changes, monitoring dashboard, etc.).
+
+
+## When to choose what
+
+| Choose Self-Hosted if... | Choose Cloud if... |
+|--------------------------|-------------------|
+| You want zero cost | You don't want to maintain Dokploy itself |
+| You want full control over everything | You want automatic updates |
+| You prefer air-gapped or private networks | You want managed uptime for the control plane |
+| You're comfortable managing servers | You want direct support (Startup/Enterprise) |
+
+## Cloud Plans
+
+If you choose Dokploy Cloud, there are several plans depending on your needs:
+
+### Plan comparison
+
+| | Hobby | Startup | Enterprise | Agency |
+|---|:---:|:---:|:---:|:---:|
+| **Price** | $4.50/mo per server | $15/mo (3 servers included) | Custom | Custom |
+| **Additional servers** | $4.50/mo each | $4.50/mo each | Custom | Custom |
+| **Organizations** | 1 | 3 | Custom | Custom |
+| **Users** | 1 | Unlimited | Unlimited | Unlimited |
+| **Environments** | 2 | Unlimited | Unlimited | Unlimited |
+| **Backups** | 1 per app/database | Unlimited | Unlimited | Unlimited |
+| **Scheduled jobs** | 1 | Unlimited | Unlimited | Unlimited |
+| **RBAC** | Basic (Owner, Admin, Member) | Basic (Admin/Developer roles) | Fine-grained + custom roles | Fine-grained + custom roles |
+| **2FA** | ❌ | ✅ | ✅ | ✅ |
+| **SSO / SAML** | ❌ | ❌ | ✅ | ✅ |
+| **Audit logs** | ❌ | ❌ | ✅ | ✅ |
+| **White labeling** | ❌ | ❌ | ✅ | ✅ |
+| **Support** | Community (Discord) | Email & Chat | Priority with SLA | Partner team |
+
+
+Annual billing saves **20%** on all plans. See the [Pricing](https://dokploy.com/pricing) page for the latest details.
+
+
+### Which plan do I need?
+
+- **Hobby** — You're a solo developer deploying personal projects or small client sites on a single server.
+- **Startup** — You have a team, need multiple environments (production, staging, dev), and want unlimited backups and scheduled jobs.
+- **Enterprise** — You need SSO/SAML, audit logs, white labeling, custom roles with fine-grained permissions, and priority support with SLA.
+- **Agency** — You manage infrastructure for multiple clients and need a tailored partnership.
diff --git a/apps/docs/content/docs/core/meta.json b/apps/docs/content/docs/core/meta.json
index ec84982..82ba002 100644
--- a/apps/docs/content/docs/core/meta.json
+++ b/apps/docs/content/docs/core/meta.json
@@ -15,6 +15,7 @@
"uninstall",
"videos",
"goodies",
+ "multi-tenancy",
"troubleshooting",
"---Cloud---",
"cloud",
diff --git a/apps/docs/content/docs/core/multi-tenancy.mdx b/apps/docs/content/docs/core/multi-tenancy.mdx
new file mode 100644
index 0000000..47caa14
--- /dev/null
+++ b/apps/docs/content/docs/core/multi-tenancy.mdx
@@ -0,0 +1,239 @@
+---
+title: Multi-Tenancy
+description: "Understand how Dokploy organizes resources using Organizations, Projects, Environments, and Services for team collaboration and resource isolation."
+---
+
+import { Callout } from 'fumadocs-ui/components/callout';
+
+Dokploy provides a hierarchical multi-tenancy model that lets you organize your infrastructure cleanly — whether you're a solo developer or managing multiple teams. This guide explains how Organizations, Projects, Environments, and Services work together.
+
+## Resource Hierarchy
+
+Dokploy organizes all resources in a four-level hierarchy:
+
+```
+┌─────────────────────────────────────────────────────────────┐
+│ ORGANIZATION │
+│ The top-level tenant. All users, billing, and settings │
+│ belong to an organization. │
+│ │
+│ ┌────────────────────────┐ ┌────────────────────────┐ │
+│ │ PROJECT A │ │ PROJECT B │ │
+│ │ │ │ │ │
+│ │ ┌──────────────────┐ │ │ ┌──────────────────┐ │ │
+│ │ │ Environment: │ │ │ │ Environment: │ │ │
+│ │ │ Production │ │ │ │ Production │ │ │
+│ │ │ │ │ │ │ │ │ │
+│ │ │ ┌────────────┐ │ │ │ │ ┌────────────┐ │ │ │
+│ │ │ │ App (Next) │ │ │ │ │ │ App (Go) │ │ │ │
+│ │ │ ├────────────┤ │ │ │ │ ├────────────┤ │ │ │
+│ │ │ │ PostgreSQL │ │ │ │ │ │ Redis │ │ │ │
+│ │ │ ├────────────┤ │ │ │ │ │ │ │ │ │
+│ │ │ │ Redis │ │ │ │ │ └────────────┘ │ │ │
+│ │ │ └────────────┘ │ │ │ └──────────────────┘ │ │
+│ │ └──────────────────┘ │ │ │ │
+│ │ │ │ ┌──────────────────┐ │ │
+│ │ ┌──────────────────┐ │ │ │ Environment: │ │ │
+│ │ │ Environment: │ │ │ │ Staging │ │ │
+│ │ │ Staging │ │ │ │ │ │ │
+│ │ │ │ │ │ │ ┌────────────┐ │ │ │
+│ │ │ ┌────────────┐ │ │ │ │ │ App (Go) │ │ │ │
+│ │ │ │ App (Next) │ │ │ │ │ │ │ │ │ │
+│ │ │ ├────────────┤ │ │ │ │ └────────────┘ │ │ │
+│ │ │ │ PostgreSQL │ │ │ │ └──────────────────┘ │ │
+│ │ │ └────────────┘ │ │ │ │ │
+│ │ └──────────────────┘ │ │ │ │
+│ └────────────────────────┘ └────────────────────────┘ │
+│ │
+└─────────────────────────────────────────────────────────────┘
+```
+
+### How it flows
+
+```
+Organization ──► Project ──► Environment ──► Service
+ │ │ │ │
+ Users & Logical Isolation Apps,
+ Billing grouping layer Databases,
+ of work (prod/stg/dev) Compose
+```
+
+## Organization
+
+The **Organization** is the top-level container in Dokploy. Everything — users, projects, servers, settings — belongs to an organization.
+
+- Each Dokploy instance starts with **one default organization** created during setup.
+- The user who installs Dokploy becomes the **Owner** of that organization.
+- All billing, SSO configuration, and global settings are scoped to the organization.
+
+### Key capabilities
+
+| Feature | Description |
+|---------|-------------|
+| **User Management** | Invite members, assign roles (Owner, Admin, Member, or custom roles) |
+| **SSO Integration** | Connect Auth0, Azure AD, Keycloak, Okta, or Zitadel (Enterprise) |
+| **Global Settings** | Manage servers, registries, SSH keys, certificates, and S3 destinations |
+| **Audit Logs** | Track all actions performed by organization members (Enterprise) |
+
+## Projects
+
+A **Project** is a logical grouping of related services. Think of it as a workspace for a specific product, client, or initiative.
+
+- Projects live inside an organization.
+- Each project can contain **multiple environments**.
+- Projects have their own **shared environment variables** that are inherited by all services within.
+
+### Common project structures
+
+```
+# By product
+├── Project: "Marketing Website"
+├── Project: "Mobile API"
+└── Project: "Internal Tools"
+
+# By client (agencies)
+├── Project: "Client: Acme Corp"
+├── Project: "Client: Globex Inc"
+└── Project: "Internal Projects"
+
+# By team
+├── Project: "Frontend Team"
+├── Project: "Backend Team"
+└── Project: "Data Pipeline"
+```
+
+### Creating a project
+
+1. Go to the **Dashboard**.
+2. Click **Create Project**.
+3. Enter a name and optional description.
+
+
+Projects are the primary unit for **access control**. You can grant members access to specific projects without exposing the rest of your infrastructure.
+
+
+## Environments
+
+**Environments** provide isolation within a project. They allow you to run the same services in different configurations (production, staging, development) without interference.
+
+- Each project starts with a **default environment**.
+- You can create additional environments as needed.
+- Environments have their own **shared environment variables** that override project-level variables.
+- Services in different environments are **completely isolated** from each other.
+
+### Environment use cases
+
+| Pattern | Environments | Purpose |
+|---------|-------------|---------|
+| **Standard** | `production`, `staging` | Classic deploy pipeline |
+| **Feature branches** | `production`, `staging`, `feature-x` | Test features in isolation |
+| **Regional** | `us-east`, `eu-west`, `ap-south` | Multi-region deployments |
+| **Per-client** | `client-a`, `client-b` | Client-specific configurations |
+
+### Variable inheritance
+
+Environment variables flow downward through the hierarchy with the ability to override at each level:
+
+```
+Organization
+ └── Project (shared variables: DATABASE_HOST=db.internal)
+ ├── Environment: Production (override: DATABASE_HOST=db-prod.internal)
+ │ └── Service: API (uses DATABASE_HOST=db-prod.internal)
+ │
+ └── Environment: Staging (no override)
+ └── Service: API (uses DATABASE_HOST=db.internal)
+```
+
+
+Environment-level variables take precedence over project-level variables. Service-level variables take precedence over both.
+
+
+## Services
+
+**Services** are the actual workloads running inside an environment. Dokploy supports three types of services:
+
+### Service types
+
+| Type | Description | Examples |
+|------|-------------|---------|
+| **Application** | Your custom app deployed from Git or Docker | Next.js app, Go API, Python worker |
+| **Database** | Managed database instances | PostgreSQL, MySQL, MongoDB, Redis, MariaDB |
+| **Docker Compose** | Multi-container stacks defined via `docker-compose.yml` | WordPress + MySQL, ELK stack |
+
+Each service gets its own:
+- **Domains** — Custom domains with automatic SSL via Traefik
+- **Environment Variables** — Service-specific configuration
+- **Deployments** — Independent deploy history and rollbacks
+- **Logs & Monitoring** — Per-service resource metrics
+- **Backups** — Automated database backups (for database services)
+
+## Access Control
+
+Dokploy's permission system maps directly to this hierarchy, allowing you to control who can see and do what at every level.
+
+### Role hierarchy
+
+```
+Owner (full control)
+ │
+ ├── Admin (full control, cannot manage other admins/owner)
+ │
+ ├── Member (limited, configurable permissions)
+ │ ├── Can be granted access to specific Projects
+ │ ├── Can be granted access to specific Environments
+ │ └── Permissions are configurable per resource type
+ │
+ └── Custom Role (Enterprise)
+ └── Fine-grained permissions across 25+ categories
+```
+
+### Permission scoping
+
+| Level | What you can control |
+|-------|---------------------|
+| **Organization** | Who can manage users, servers, registries, SSH keys, certificates |
+| **Project** | Who can view/create/delete projects and their services |
+| **Environment** | Who can access specific environments (e.g., only production) |
+| **Service** | Who can deploy, view logs, manage environment variables |
+
+
+For detailed permission configuration, see [Permissions](/docs/core/permissions). For enterprise custom roles, see [Custom Roles](/docs/core/enterprise/custom-roles).
+
+
+## Best Practices
+
+### Naming conventions
+
+Use consistent, descriptive names across your hierarchy:
+
+```
+Organization: "Acme Corp"
+ └── Project: "acme-ecommerce"
+ ├── Environment: "production"
+ │ ├── Service: "storefront" (Application)
+ │ ├── Service: "api" (Application)
+ │ ├── Service: "postgres-main" (Database)
+ │ └── Service: "redis-cache" (Database)
+ │
+ └── Environment: "staging"
+ ├── Service: "storefront"
+ ├── Service: "api"
+ └── Service: "postgres-main"
+```
+
+### Separation strategies
+
+| Strategy | When to use | Example |
+|----------|-------------|---------|
+| **One project per product** | You have distinct products with separate teams | `website`, `mobile-api`, `admin-panel` |
+| **One project per client** | You're an agency or MSP managing multiple clients | `client-acme`, `client-globex` |
+| **One environment per stage** | Standard dev → staging → production workflow | `development`, `staging`, `production` |
+| **One environment per feature** | You want isolated testing of features before merge | `feature-auth-v2`, `feature-payments` |
+
+### Security recommendations
+
+1. **Principle of least privilege** — Only grant the minimum permissions each user needs.
+2. **Use environments for isolation** — Never run staging and production services in the same environment.
+3. **Scope variables properly** — Put shared secrets at the project level, environment-specific values at the environment level.
+4. **Audit regularly** — Review user access and permissions periodically, especially when team members change roles. Use [Audit Logs](/docs/core/enterprise/audit-logs) (Enterprise) to track changes.
+5. **Use custom roles** — If the default roles don't fit your needs, create [Custom Roles](/docs/core/enterprise/custom-roles) (Enterprise) with exactly the permissions required.