Add Reverse Proxy documentation and update self-hosted quickstart

src/components/NavigationDocs.jsx

@@ -150,6 +150,16 @@ export const docsNavigation = [
                     },
                 ]
             },
+            {
+                title: 'Reverse Proxy',
+                isOpen: false,
+                links: [
+                    { title: 'Overview', href: '/manage/reverse-proxy' },
+                    { title: 'Custom Domains', href: '/manage/reverse-proxy/custom-domains' },
+                    { title: 'Authentication', href: '/manage/reverse-proxy/authentication' },
+                    { title: 'Access Logs', href: '/manage/reverse-proxy/access-logs' },
+                ]
+            },
             {
                 title: 'Network Routes',
                 isOpen: false,
@@ -291,6 +301,15 @@ export const docsNavigation = [
                 isOpen: false,
                 links: [
                     { title: 'Configuration Files', href: '/selfhosted/configuration-files' },
+                    {
+                        title: 'Scaling Your Deployment', href: '/selfhosted/maintenance/scaling/scaling-your-self-hosted-deployment',
+                        isOpen: false,
+                        links: [
+                            { title: 'Set Up External Relays', href: '/selfhosted/maintenance/scaling/set-up-external-relays' },
+                            { title: 'Migrate SQLite to PostgreSQL', href: '/selfhosted/maintenance/scaling/migrate-sqlite-to-postgresql' },
+                            { title: 'Set Up External Signal', href: '/selfhosted/maintenance/scaling/set-up-external-signal' },
+                        ]
+                    },
                     { title: 'Backup', href: '/selfhosted/maintenance/backup' },
                     { title: 'Upgrade', href: '/selfhosted/maintenance/upgrade' },
                     { title: 'Remove', href: '/selfhosted/maintenance/remove' },
@@ -340,7 +359,7 @@ export const docsNavigation = [
                 isOpen: false,
                 links: [
                     { title: 'Coturn to Embedded STUN', href: '/selfhosted/migration/coturn-to-stun-migration' },
-
+                    { title: 'Enable Reverse Proxy', href: '/selfhosted/migration/enable-reverse-proxy' },
                 ]
             },
         ],

src/pages/manage/reverse-proxy/access-logs.mdx

@@ -0,0 +1,64 @@
+import {Note} from "@/components/mdx"
+
+export const description =
+    'Monitor and audit HTTP requests flowing through your NetBird reverse proxy services with detailed access logs.'
+
+# Reverse Proxy Access Logs
+
+NetBird logs every request that passes through your reverse proxy services. Access logs provide visibility into who is accessing your services, from where, and whether requests were allowed or denied. This is useful for auditing, debugging, and monitoring traffic to your publicly exposed services.
+
+## Viewing access logs
+
+Access logs are available in the NetBird dashboard under **Activity** > **Proxy Events**. This view displays a table of all HTTP requests that have passed through your reverse proxy services, with filters to narrow down results by time range, status, or other fields.
+
+<p>
+    <img src="/docs-static/img/manage/reverse-proxy/access-logs-table.png" alt="Proxy Events table showing reverse proxy access log entries" className="imagewrapper"/>
+</p>
+
+You can also retrieve access logs programmatically using the API:
+
+```bash
+GET /api/events/proxy
+```
+
+## What access logs capture
+
+Each log entry records the following information about an HTTP request:
+
+| Field | Description |
+|-------|-------------|
+| **Timestamp** | When the request occurred |
+| **Method** | HTTP method (GET, POST, PUT, DELETE, etc.) |
+| **Host** | The domain the request was made to |
+| **Path** | The URL path requested |
+| **Status Code** | HTTP status code returned (200, 401, 403, 500, etc.) |
+| **Duration** | How long the request took (in milliseconds) |
+| **Source IP** | The client's IP address |
+| **Auth Method** | Which authentication method was used (SSO, password, PIN, or none) |
+| **User ID** | The authenticated user's ID (if SSO was used) |
+| **Country** | Country of origin based on source IP geolocation |
+| **City** | City of origin based on source IP geolocation |
+| **Reason** | Reason for denial (if applicable) |
+
+## Understanding log entries
+
+Log entries fall into three categories based on the HTTP status code returned:
+
+- **Allowed requests** - Successful requests show a `2xx` status code along with the authentication method used to access the service.
+- **Denied requests** - Failed authentication attempts show `401` or `403` status codes with a reason explaining why the request was denied, such as an invalid password or missing SSO session.
+- **Errors** - Backend errors or proxy issues show `5xx` status codes. These typically indicate that the target service is unreachable or returned an error.
+
+## Use cases
+
+Access logs support several operational and security workflows:
+
+- **Security auditing** - Review who accessed sensitive services, which authentication method they used, and from which geographic locations. This helps identify unauthorized access attempts and verify that authentication policies are working as expected.
+- **Debugging** - Trace failed requests to understand authentication or routing issues. The status code, duration, and reason fields help pinpoint whether problems originate from authentication configuration, target availability, or network connectivity.
+- **Monitoring** - Track usage patterns across your services. Identify which services receive the most traffic, peak usage times, and unusual access patterns that may warrant investigation.
+- **Compliance** - Maintain records of service access for regulatory requirements. Access logs provide an auditable trail of who accessed what, when, and from where.
+
+## Related pages
+
+- [Reverse Proxy Overview](/manage/reverse-proxy) - learn how to create and manage reverse proxy services
+- [Audit Events Logging](/manage/activity) - view management-level events such as configuration changes and user activity
+- [Traffic Events Logging](/manage/activity/traffic-events-logging) - monitor network-level traffic events across your NetBird mesh

src/pages/manage/reverse-proxy/authentication.mdx

@@ -0,0 +1,163 @@
+import {Note} from "@/components/mdx"
+
+export const description =
+    'Configure SSO, password, and PIN authentication methods for NetBird Reverse Proxy services to control who can access your exposed applications.'
+
+# Reverse Proxy Authentication
+
+NetBird Reverse Proxy supports multiple authentication methods to control who can access your exposed services. You can enable one or more methods on each service, or leave a service completely public. Authentication is configured per service in the **Authentication** tab when creating or editing a service.
+
+<p>
+    <img src="/docs-static/img/manage/reverse-proxy/reverse-proxy-add-service-auth.png" alt="Authentication tab showing all available authentication methods" className="imagewrapper"/>
+</p>
+
+## Authentication methods
+
+NetBird offers three authentication methods, each suited to different access patterns. You can enable any combination of them on a single service.
+
+### SSO (Single Sign-On)
+
+SSO authentication requires users to authenticate through your identity provider (IdP) using OIDC before they can access the service. When a user visits the service URL, they are redirected to your IdP login page. After successful authentication, they are granted access to the service.
+
+You can optionally restrict access to specific **distribution groups** from your IdP. When groups are configured, only users who belong to at least one of the selected groups are allowed through after authenticating.
+
+<p>
+    <img src="/docs-static/img/manage/reverse-proxy/auth-sso-modal.png" alt="SSO configuration modal with group selection" className="imagewrapper"/>
+</p>
+
+**Key details:**
+
+- Users authenticate via your existing identity provider (OIDC)
+- Sessions last **24 hours** before re-authentication is required
+- Optionally restrict access to specific distribution groups synced from your IdP
+- When no groups are selected, any authenticated user in your organization can access the service
+
+<Note>
+    **Self-hosted deployments:** SSO authentication uses whichever OIDC provider is configured in your management server. If you use the built-in embedded IdP, SSO works automatically. If you use an external identity provider (Auth0, Okta, Keycloak, etc.) without the embedded IdP, you must register the reverse proxy callback URL with your IdP before SSO will work. See the [Enable Reverse Proxy migration guide](/selfhosted/migration/enable-reverse-proxy#configure-sso-for-external-identity-providers) for step-by-step instructions.
+</Note>
+
+**Best for:** Team services where you want to leverage existing identity management, internal tools that require user-level accountability, and services where you need group-based access control.
+
+### Password
+
+Password authentication protects a service with a shared password that you define. When a user visits the service URL, they are prompted to enter the password before they can proceed. Passwords are securely hashed using **Argon2id** on the backend - the plaintext password is never stored.
+
+<p>
+    <img src="/docs-static/img/manage/reverse-proxy/auth-password-modal.png" alt="Password configuration modal" className="imagewrapper"/>
+</p>
+
+**Key details:**
+
+- Set a shared password when configuring the service
+- Users must enter the correct password to access the service
+- Passwords are hashed with Argon2id before being stored
+- Sessions last **24 hours** before re-authentication is required
+
+**Best for:** Simple shared access to internal tools, staging environments, or services shared with external partners who do not have accounts in your identity provider.
+
+### PIN Code
+
+PIN code authentication works similarly to password authentication but is limited to numeric input. When a user visits the service URL, they are prompted to enter the PIN code. PINs are securely hashed using **Argon2id** on the backend, just like passwords.
+
+<p>
+    <img src="/docs-static/img/manage/reverse-proxy/auth-pin-modal.png" alt="PIN Code configuration modal" className="imagewrapper"/>
+</p>
+
+**Key details:**
+
+- Set a numeric PIN code when configuring the service
+- Users must enter the correct PIN to access the service
+- PINs are hashed with Argon2id before being stored
+- Sessions last **24 hours** before re-authentication is required
+
+**Best for:** Quick access scenarios, kiosk-style interfaces, or situations where a simple numeric code is easier to share than a full password.
+
+### No authentication (public access)
+
+Services can also be configured without any authentication. When no authentication method is enabled, anyone with the service URL can access it without any restrictions.
+
+<Note>
+    When you save a service with no authentication configured, the dashboard displays a warning: **"This service will be publicly accessible to everyone on the internet without any restrictions."** You must confirm before the service is saved. Make sure this is intentional before proceeding.
+</Note>
+
+<p>
+    <img src="/docs-static/img/manage/reverse-proxy/auth-no-auth-warning.png" alt="Warning dialog displayed when saving a service without authentication" className="imagewrapper"/>
+</p>
+
+**Best for:** Public-facing websites, APIs that handle their own authentication internally, or services that are intentionally open to the internet.
+
+## Combining authentication methods
+
+You can enable multiple authentication methods on a single service simultaneously. When more than one method is active, users can authenticate using **any** of the enabled methods - they choose which one to use when accessing the service.
+
+For example, you could enable both **SSO** and **Password** on the same service. Team members who have accounts in your identity provider can authenticate with SSO, while external partners or contractors can use a shared password. This gives you flexibility without requiring everyone to be in your IdP.
+
+Common combinations include:
+
+| Combination | Use case |
+|-------------|----------|
+| **SSO + Password** | Team members use SSO; external collaborators use a shared password |
+| **SSO + PIN Code** | Team members use SSO; quick access via PIN for specific scenarios |
+| **Password + PIN Code** | Different shared credentials for different groups of users |
+| **SSO + Password + PIN Code** | Maximum flexibility with all methods available |
+
+## Configuring authentication
+
+All authentication settings are managed in the **Authentication** tab of the service creation or edit modal. Navigate to **Reverse Proxy** > **Services**, then either click **Add Service** to create a new service or click an existing service to edit it.
+
+### Setting up SSO
+
+1. Open the service modal (create or edit).
+2. Switch to the **Authentication** tab.
+3. Click **SSO (Single Sign-On)**.
+4. Enable SSO using the toggle.
+5. Optionally, select one or more **distribution groups** to restrict access to specific users. If no groups are selected, all authenticated users in your organization can access the service.
+6. Click **Save** (or **Save Changes** when editing).
+
+<Note>
+    Distribution groups are synced from your identity provider. If you do not see the groups you expect, check your [IdP sync configuration](/manage/team/idp-sync) or [Single Sign-On setup](/manage/team/single-sign-on).
+</Note>
+
+### Setting up a password
+
+1. Open the service modal (create or edit).
+2. Switch to the **Authentication** tab.
+3. Click **Password**.
+4. Enter a password in the input field.
+5. Click **Save** (or **Save Changes** when editing).
+
+### Setting up a PIN code
+
+1. Open the service modal (create or edit).
+2. Switch to the **Authentication** tab.
+3. Click **PIN Code**.
+4. Enter a numeric PIN in the input field.
+5. Click **Save** (or **Save Changes** when editing).
+
+### Removing authentication
+
+To remove an authentication method from a service:
+
+1. Open the service modal by clicking the service in the services list.
+2. Switch to the **Authentication** tab.
+3. Click on the authentication method you want to remove.
+4. Use the **Remove** option to disable it.
+5. Click **Save Changes**.
+
+If you remove all authentication methods, the service becomes publicly accessible. The dashboard will display a warning before saving, as described in the [No authentication](#no-authentication-public-access) section above.
+
+## Session management
+
+Authenticated sessions for reverse proxy services are managed using JWT (JSON Web Token) technology. Here is how sessions work:
+
+- **Token signing:** Sessions use JWT tokens signed with **Ed25519** key pairs. Each service has its own unique key pair, ensuring that tokens for one service cannot be used to access another.
+- **Session duration:** Authenticated sessions expire after **24 hours**. After expiry, users must re-authenticate using whichever method they originally used.
+- **Scope:** Sessions are scoped to individual services. Authenticating with one service does not grant access to other services, even if they use the same authentication method.
+
+## Related pages
+
+- [Reverse Proxy Overview](/manage/reverse-proxy) - learn how the reverse proxy feature works and create your first service
+- [Custom Domains](/manage/reverse-proxy/custom-domains) - configure your own domain names for reverse proxy services
+- [Access Logs](/manage/reverse-proxy/access-logs) - monitor and audit traffic to your reverse proxy services
+- [Single Sign-On](/manage/team/single-sign-on) - configure your identity provider for SSO across NetBird
+- [Provision Users and Groups](/manage/team/idp-sync) - sync users and groups from your identity provider