Customizable Deployment server settings (#4064)

* Implement deployment settings

* Separated code into base abstraction and implementation classes

* Finalize implementation of the app runner and associated extensions

* Use constants for URL paths

* Small fixes and better docstrings

* Reorganize the build logic to allow the app to be built last (for e.g. Django).

* Apply code review suggestions and fix docstrings

* Implement deployment app runner flavor

* Upgrade secure, remove deprecated XSSP and rework middleware adapter

* Fix linter errors

* Fix secure headers and dashboard static files support

* Reimplemented source or object class

* Fix circular dependency

* Remove outdated unit tests

* Add custom UI to the weather agent example

* Fix unit tests remove outdated unit tests

* Refactor builder config to store extra requirements instead of the full deployment settings

* Fix new linter errors after merge with develop

* Add documentation and a few minor tweaks

* Linter fixes

* Doc updates

* More doc updates

* More doc updates

* Small fixes and documentation updates

* Final doc updates and code modifications

Author: stefannica

docs/book/getting-started/deploying-zenml/deploy-with-docker.md

@@ -256,7 +256,6 @@ The following secure headers environment variables are supported:
 * **ZENML\_SERVER\_SECURE\_HEADERS\_SERVER**: The `Server` HTTP header value used to identify the server. The default value is the ZenML server ID.
 * **ZENML\_SERVER\_SECURE\_HEADERS\_HSTS**: The `Strict-Transport-Security` HTTP header value. The default value is `max-age=63072000; includeSubDomains`.
 * **ZENML\_SERVER\_SECURE\_HEADERS\_XFO**: The `X-Frame-Options` HTTP header value. The default value is `SAMEORIGIN`.
-* **ZENML\_SERVER\_SECURE\_HEADERS\_XXP**: The `X-XSS-Protection` HTTP header value. The default value is `0`. NOTE: this header is deprecated and should not be customized anymore. The `Content-Security-Policy` header should be used instead.
 * **ZENML\_SERVER\_SECURE\_HEADERS\_CONTENT**: The `X-Content-Type-Options` HTTP header value. The default value is `nosniff`.
 * **ZENML\_SERVER\_SECURE\_HEADERS\_CSP**: The `Content-Security-Policy` HTTP header value. This is by default set to a strict CSP policy that only allows content from the origins required by the ZenML dashboard. NOTE: customizing this header is discouraged, as it may cause the ZenML dashboard to malfunction.
 * **ZENML\_SERVER\_SECURE\_HEADERS\_REFERRER**: The `Referrer-Policy` HTTP header value. The default value is `no-referrer-when-downgrade`.

docs/book/how-to/containerization/containerization.md

@@ -354,7 +354,16 @@ you already want this automatic detection in current versions of ZenML, set `dis
     docker_settings = DockerSettings(install_stack_requirements=False)
     ```
 
-7.  **Install Local Projects**:
+7.  **Control Deployment Requirements**:
+    By default, if you have a Deployer stack component in your active stack, ZenML installs the requirements needed by the deployment application configured in your deployment settings. You can disable this behavior if needed:
+
+    ```python
+    from zenml.config import DockerSettings
+    
+    docker_settings = DockerSettings(install_deployment_requirements=False)
+    ```
+
+8.  **Install Local Projects**:
     If your code requires the installation of some local code files as a python package, you can specify a command
     that installs it as follows:
     ```python

docs/book/how-to/deployment/deployment.md

@@ -25,6 +25,41 @@ Pipeline deployments are ideal for scenarios requiring real-time, on-demand exec
 
 **Multi-step Business Workflows**: Orchestrate complex processes involving multiple AI/ML components, like document processing pipelines that combine OCR, entity extraction, sentiment analysis, and classification into a single deployable service.
 
+## Traditional Model Serving vs. Deployed Pipelines
+
+If you're reaching for tools like Seldon or KServe, consider this: deployed
+pipelines give you all the core serving primitives, plus the power of a full
+application runtime.
+
+- Equivalent functionality: A pipeline handles the end-to-end inference path
+  out of the box — request validation, feature pre-processing, model loading
+  and inference, post-processing, and response shaping.
+- More flexible: Deployed pipelines are unopinionated, so you can layer in
+  retrieval, guardrails, rules, A/B routing, canary logic, human-in-the-loop,
+  or any custom orchestration. You're not constrained by a model-server template.
+- More customizable: The deployment is a real ASGI app. Tailor endpoints,
+  authentication, authorization, rate limiting, structured logging, tracing,
+  correlation IDs, or SSO/OIDC — all with first-class middleware and
+  framework-level hooks.
+- More features: Serve single-page apps alongside the API. Ship admin/ops
+  dashboards, experiment playgrounds, model cards, or customer-facing UIs
+  from the very same deployment for tighter operational feedback loops.
+
+This approach aligns better with production realities: inference is rarely
+"just call a model." There are policies, data dependencies, and integrations
+that need a programmable, evolvable surface. Deployed pipelines give you that
+without sacrificing the convenience of a managed deployer and a clean HTTP
+contract.
+
+{% hint style="info" %}
+Deprecation notice: ZenML is phasing out the Model Deployer stack components
+in favor of pipeline deployments. Pipeline deployments are the strategic
+direction for real-time serving: they are more dynamic, more extensible, and
+offer deeper integration points with your security, observability, and product
+requirements. Existing model deployers will continue to function during the
+transition period, but new investments will focus on pipeline deployments.
+{% endhint %}
+
 ## How Deployments Work
 
 To deploy a pipeline or snapshot, a **Deployer** stack component needs to be in your active stack:
@@ -420,6 +455,48 @@ The following happens when the pipeline is deployed and then later invoked:
 
 This mechanism can be used to initialize and share global state between all the HTTP requests made to the deployment or to execute long-running initialization or cleanup operations when the deployment is started or stopped rather than on each HTTP request.
 
+## Deployment Configuration
+
+The deployer settings cover aspects of the pipeline deployment process and specific back-end infrastructure used to provision and manage the resources required to run the deployment servers. Independently of that, `DeploymentSettings` can be used to fully customize all aspects pertaining to the deployment ASGI application itself, including:
+
+* HTTP endpoints
+* middleware
+* secure headers
+* CORS settings
+* mounting and serving static files to support deploying single-page applications alongside the pipeline
+* for more advanced cases, even the ASGI framework (e.g. FastAPI, Django, Flask, Falcon, Quart, BlackSheep, etc.) and its configuration can be customized
+
+Example:
+
+```python
+from zenml.config import DeploymentSettings, EndpointSpec, EndpointMethod
+from zenml import pipeline
+
+async def custom_health_check() -> Dict[str, Any]:
+    from zenml.client import Client
+
+    client = Client()
+    return {
+        "status": "healthy",
+        "info": client.zen_store.get_store_info().model_dump(),
+    }
+
+@pipeline(settings={"deployment": DeploymentSettings(
+    custom_endpoints=[
+        EndpointSpec(
+            path="/health",
+            method=EndpointMethod.GET,
+            handler=custom_health_check,
+            auth_required=False,
+        ),
+    ],
+)})
+def my_pipeline():
+    ...
+```
+
+For more detailed information on deployment options, see the [deployment settings guide](./deployment_settings.md).
+
 ## Best Practices
 
 1. **Design for Parameters**: Structure your pipelines to accept meaningful parameters that control behavior