Repository: PrefectHQ/prefect
Pull request: Refactor and reorganize the 3.0 docs in the Deploy section
This PR is an attempt to refactor and reorganize all of the 3.0 deploy docs to minimize the amount of overlap between docs and to make the relationships between pages clearer at a glance.

* Establish two main categories of infra docs: concepts and examples.
* Create an umbrella **Deployments overview** page with an overview of what deployments are and why they're useful.
* Merge content that is overly similar so that there's a single source of truth for major topics (e.g. how to use `deploy()` with Docker work pools).
* Make page titles use the same consistent "&lt;verb&gt; &lt;noun&gt;" format that's used elsewhere.

Closes https://github.com/PrefectHQ/prefect/issues/14094

### Example

Before:

<img width="282" alt="image" src="https://github.com/PrefectHQ/prefect/assets/186715/67cab1a1-fee0-4d89-a1a5-95aff76596c1">

After:

<img width="280" alt="image" src="https://github.com/PrefectHQ/prefect/assets/173499228/7467b6f4-5e18-4a8c-9286-6516e52eeb52">

### Checklist
<!-- These boxes may be checked after opening the pull request. -->

- [x] This pull request includes a label categorizing the change e.g. `maintenance`, `fix`, `feature`, `enhancement`, `docs`.
- [x] This pull request references any related issue by including "closes `<link to issue>`"
  <!-- If you do not have permission to add a label, a maintainer will add one for you -->
  - If no issue exists and your change is not a small fix, please [create an issue](https://github.com/PrefectHQ/prefect/issues/new/choose) first.
- [x] If this pull request adds new functionality, it includes unit tests that cover the changes
- [x] If this pull request removes docs files, it includes redirect settings in `mint.json`.
- [x] If this pull request adds functions or classes, it includes helpful docstrings.


Problem statement:
Reduce the content on some Deploy section docs pages
### First check

- [X] I added a descriptive title to this issue.
- [X] I used GitHub search to find a similar request and didn't find it 😇

### Describe the issue

Two docs pages that feel quite onerous in length:

Work pools and workers: 3.0rc/deploy/work-pools/control-runs
Deploy flows to work pools and workers: 3.0rc/deploy/work-pools/prefect-deploy


### Describe the proposed change

Shorten, break up, and/or simplify.

### Additional context

_No response_

Hints from issue discussion:
As mentioned in Slack, I think **Work pools and workers** could be broken up into two pages: **Work pools** and **Workers**.

**Deploy flows to work pools and workers** doesn't seem quite as clear-cut, but one thought is to use a tabbed component when showing equivalent instructions for different deploy providers (e.g. Docker vs. Git vs. AWS et. al.).

Commit message: Remove warning to not use flow.serve in production deployments

Patch to review:
diff --git a/docs/3.0rc/automate/add-schedules.mdx b/docs/3.0rc/automate/add-schedules.mdx
index 0961c38554b3..b58bda8f5679 100644
--- a/docs/3.0rc/automate/add-schedules.mdx
+++ b/docs/3.0rc/automate/add-schedules.mdx
@@ -4,7 +4,7 @@ description: Prefect can schedule when to automatically create new flow runs.
 ---
 
 Prefect allows you to specify schedules on which your flows run.
-You can add one or more schedules to any [served or deployed](/3.0rc/deploy/serve-flows/) flow.
+You can add one or more schedules to any [served or deployed](/3.0rc/deploy/run-flows-in-local-processes) flow.
 Schedules tell Prefect when and how to create new flow runs.
 You can add a schedule to a deployed flow in the Prefect UI, in the CLI through the `prefect deployment schedule` command, or the `prefect.yaml` configuration file.
 
@@ -16,7 +16,7 @@ There are several ways to create a schedule for a deployment:
 - With the `cron`, `interval`, or `rrule` parameters if building your deployment with the 
 [`serve` method](/3.0rc/develop/write-flows/#serving-a-flow) of the `Flow` object or 
 [the `serve` utility](/3.0rc/develop/write-flows/#serving-multiple-flows-at-once) for managing multiple flows simultaneously
-- If using [worker-based deployments](/3.0rc/deploy/control-runs/workers/)
+- If using [worker-based deployments](/3.0rc/deploy/infrastructure-concepts/workers/)
   - When you define a deployment with `flow.serve` or `flow.deploy`
   - Through the interactive `prefect deploy` command
   - With the `deployments` -> `schedules` section of the `prefect.yaml` file
@@ -166,9 +166,7 @@ Longer schedules, such as one that fires at 9am every morning, adjust for DST au
   
 ### Interval
 
-An `Interval` schedule creates new flow runs on a regular interval measured in seconds. Intervals are computed using an optional 
-`anchor_date`. For example, this is how you create a schedule for every 10 minutes in a 
-[block-based deployment](/3.0rc/deploy/serve-flows/#block-based-deployments) YAML file:
+An `Interval` schedule creates new flow runs on a regular interval measured in seconds. Intervals are computed using an optional `anchor_date`.
 
 ```yaml
 schedule:
@@ -229,9 +227,6 @@ week day or day-of-month adjustments, and more. RRules can represent complex log
 
 You may find it useful to use an RRule string generator such as the [iCalendar.org RRule Tool](https://icalendar.org/rrule-tool.html) to help create valid RRules.
 
-For example, the following RRule schedule in a [block-based deployment](/3.0rc/deploy/serve-flows/#block-based-deployments) 
-YAML file creates flow runs on Monday, Wednesday, and Friday until July 30, 2024.
-
 ```yaml
 schedule:
   rrule: 'FREQ=WEEKLY;BYDAY=MO,WE,FR;UNTIL=20240730T040000Z'
diff --git a/docs/3.0rc/automate/events/automations-triggers.mdx b/docs/3.0rc/automate/events/automations-triggers.mdx
index 4cae71294041..ccc031661043 100644
--- a/docs/3.0rc/automate/events/automations-triggers.mdx
+++ b/docs/3.0rc/automate/events/automations-triggers.mdx
@@ -17,7 +17,7 @@ Actions include starting flow runs, pausing schedules, and sending custom notifi
 - Python installed
 - Prefect [installed](/3.0rc/get-started/install/)
 - Authenticated to a [Prefect Cloud workspace](/3.0rc/get-started/quickstart/#step-2-connect-to-prefects-api/)
-- A [work pool](/3.0rc/deploy/control-runs/work-pools/) set up to handle the deployments
+- A [work pool](/3.0rc/deploy/infrastructure-concepts/work-pools/) set up to handle the deployments
 
 ## Create an automation
 
diff --git a/docs/3.0rc/deploy/dynamic-infra/deploy-docker.mdx b/docs/3.0rc/deploy/dynamic-infra/deploy-docker.mdx
deleted file mode 100644
index 1138688520a0..000000000000
--- a/docs/3.0rc/deploy/dynamic-infra/deploy-docker.mdx
+++ /dev/null
@@ -1,439 +0,0 @@
----
-title: Run Flows with Docker
-description: Learn how to store your flow code in a Docker image and serve your flow on any docker-compatible infrastructure.
----
-
-The [Deployments](/3.0rc/deploy/serve-flows/) guide showed how to serve a flow on a schedule.
-
-With a Python script, you can build a Docker image for that script, allowing you to serve your flow 
-This guide demonstrates running a flow in Kubernetes, but you can use any Docker-compatible 
-infrastructure.
-
-This guide covers how to:
-
-- Write a Dockerfile to build an image that stores your Prefect flow code.
-- Build a Docker image for your flow.
-- Deploy and run your Docker image on a Kubernetes cluster.
-- Look at the Prefect-maintained Docker images and discuss options for use.
-
-In this guide you will create a Dockerfile from scratch. Alternatively, Prefect makes it convenient 
-to build a Docker image as part of deployment creation. You can even include environment variables 
-and specify additional Python packages to install at runtime.
-
-If creating a deployment with a `prefect.yaml` file, the build step makes it easy to customize your 
-Docker image and push it to the registry of your choice. See an [example](/3.0rc/deploy/dynamic-infra/deploy-kubernetes/#define-a-deployment).
-
-<Note>
-Deployment creation with a Python script that includes `flow.deploy` similarly allows you to customize 
-your Docker image with keyword arguments as shown below.
-
-```python
-...
-
-if __name__ == "__main__":
-    hello_world.deploy(
-        name="my-first-deployment",
-        work_pool_name="above-ground",
-        image='my_registry/hello_world:demo',
-        job_variables={"env": { "EXTRA_PIP_PACKAGES": "boto3" } }
-    )
-```
-</Note>
-
-## Prerequisites
-
-- A Python script that defines and serves a flow. This guide uses the flow script and 
-deployment from the [Deployments](/3.0rc/deploy/serve-flows/) guide.
-- Access to a running Prefect API server. Sign up for a forever free 
-[Prefect Cloud account](https://docs.prefect.io/cloud/), or run a Prefect API server 
-locally with `prefect server start`.
-- [Docker Desktop](https://docs.docker.com/desktop/) installed on your machine.
-
-## Write a Dockerfile
-
-Make a clean directory to work from, called `prefect-docker-guide`.
-
-```bash
-mkdir prefect-docker-guide
-cd prefect-docker-guide
-```
-
-In this directory, create a sub-directory named `flows` and put your flow script 
-from the [Deployments](/3.0rc/deploy/serve-flows/) guide in it.
-
-```bash
-mkdir flows
-cd flows
-touch prefect-docker-guide-flow.py
-```
-
-Here's the flow code for reference:
-
-```python prefect-docker-guide-flow.py
-import httpx
-from prefect import flow
-
-
-@flow(log_prints=True)
-def get_repo_info(repo_name: str = "PrefectHQ/prefect"):
-    url = f"https://api.github.com/repos/{repo_name}"
-    response = httpx.get(url)
-    response.raise_for_status()
-    repo = response.json()
-    print(f"{repo_name} repository statistics 🤓:")
-    print(f"Stars 🌠 : {repo['stargazers_count']}")
-    print(f"Forks 🍴 : {repo['forks_count']}")
-
-
-if __name__ == "__main__":
-    get_repo_info.serve(name="prefect-docker-guide")
-```
-
-Next, add a `requirements.txt` to the `prefect-docker-guide` directory. 
-Include all dependencies required for your `prefect-docker-guide-flow.py` script in the 
-Docker image to build.
-
-```bash
-# ensure you run this line from the top level of the `prefect-docker-guide` directory
-touch requirements.txt
-```
-
-Put the following in your `requirements.txt` file:
-
-```txt requirements.txt
-prefect>=3.0.0
-httpx
-```
-
-Create a `Dockerfile` to create a Docker image that also stores the flow code:
-
-```bash
-touch Dockerfile
-```
-
-Add the following content to your `Dockerfile`:
-
-```dockerfile Dockerfile
-# Using the latest version of Prefect with Python 3.10
-FROM prefecthq/prefect:2-python3.10
-
-# Add your requirements.txt file to the image and install dependencies
-COPY requirements.txt .
-RUN pip install -r requirements.txt --trusted-host pypi.python.org --no-cache-dir
-
-# Add your flow code to the image
-COPY flows /opt/prefect/flows
-
-# Run your flow script when the container starts
-CMD ["python", "flows/prefect-docker-guide-flow.py"]
-```
-
-## Build a Docker image
-
-Now that you have a Dockerfile, build your image by running:
-
-```bash
-docker build -t prefect-docker-guide-image .
-```
-
-Check that your build worked by running a container from your new image.
-
-<Tabs>
-  <Tab title="Cloud">
-
-    Your container needs an API URL and an API key to communicate with Prefect Cloud. 
-    
-    - You can get an API key from the [API Keys](https://docs.prefect.io/2.12.0/cloud/manage-users/api-keys/) section of the user settings in the Prefect UI. 
-
-    - You can get your API URL by running `prefect config view` and copying the `PREFECT_API_URL` value.
-
-    Provide both these values to your container by passing them as environment variables with the `-e` flag.
-
-    ```bash
-    docker run -e PREFECT_API_URL=YOUR_PREFECT_API_URL -e PREFECT_API_KEY=YOUR_API_KEY prefect-docker-guide-image
-    ```
-
-    After running the above command, the container should start up and serve the flow within the container.
-  </Tab>
-  <Tab title="Self-hosted">
-
-    Your container needs an API URL and network access to communicate with the Prefect API. 
-    
-    For this guide, assume the Prefect API is running on the same machine that you will run your container on and the Prefect API was started with `prefect server start`. If you're running a different setup, check out the [Hosting a Prefect server guide](/3.0rc/manage/self-host/) for information on how to connect to your Prefect API instance.
-    
-    To ensure that your flow container can communicate with the Prefect API, set your `PREFECT_API_URL` to `http://host.docker.internal:4200/api`. If you're running Linux, set your `PREFECT_API_URL` to `http://localhost:4200/api` and use the `--network="host"` option instead.
-
-    ```bash
-    docker run --network="host" -e PREFECT_API_URL=http://host.docker.internal:4200/api prefect-docker-guide-image
-    ```
-
-    After running the above command, the container should start and the flow should run within the container.
-  </Tab>
-</Tabs>
-
-## Deploy to a remote environment
-
-Now that you have a Docker image with your flow code embedded, you can deploy it to a remote environment.
-
-This guide simulates a remote environment by using Kubernetes locally with Docker Desktop. 
-Use the instructions provided by Docker to 
-[set up Kubernetes locally.](https://docs.docker.com/desktop/kubernetes/)
-
-### Create a Kubernetes deployment manifest
-
-To ensure the process serving your flow is always running, 
-create a [Kubernetes deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/). 
-If your flow's container crashes, Kubernetes automatically restarts it, 
-ensuring you don't miss any scheduled runs.
-
-First, create a `deployment-manifest.yaml` file in your `prefect-docker-guide` directory:
-
-```bash
-touch deployment-manifest.yaml
-```
-
-Add the following content to your `deployment-manifest.yaml` file:
-
-<Tabs>
-  <Tab title="Cloud">
-
-    ```yaml deployment-manifest.yaml
-    apiVersion: apps/v1
-    kind: Deployment
-    metadata:
-      name: prefect-docker-guide
-    spec:
-      replicas: 1
-      selector:
-        matchLabels:
-          flow: get-repo-info
-      template:
-        metadata:
-          labels:
-            flow: get-repo-info
-        spec:
-          containers:
-          - name: flow-container
-            image: prefect-docker-guide-image:latest
-            env:
-            - name: PREFECT_API_URL
-              value: YOUR_PREFECT_API_URL
-            - name: PREFECT_API_KEY
-              value: YOUR_API_KEY
-            # Never pull the image because we're using a local image
-            imagePullPolicy: Never
-    ```
-<Tip>
-**Keep your API key secret**
-
-In the above manifest, you are passing the Prefect API URL and API key as environment variables. 
-This approach is simple, but not secure. If you are deploying your flow to a remote cluster, use a 
-[Kubernetes secret](https://kubernetes.io/docs/concepts/configuration/secret/)
-to store your API key.
-</Tip>
-  </Tab>
-  <Tab title="Self-hosted">
-
-    ```yaml deployment-manifest.yaml
-    apiVersion: apps/v1
-    kind: Deployment
-    metadata:
-      name: prefect-docker-guide
-    spec:
-      replicas: 1
-      selector:
-        matchLabels:
-          flow: get-repo-info
-      template:
-        metadata:
-          labels:
-            flow: get-repo-info
-        spec:
-          containers:
-          - name: flow-container
-            image: prefect-docker-guide-image:latest
-            env:
-            - name: PREFECT_API_URL
-              value: <http://host.docker.internal:4200/api>
-            # Never pull the image because we're using a local image
-            imagePullPolicy: Never
-    ```
-<Tip>
-**Linux users**
-
-If you're running Linux, set your `PREFECT_API_URL` to use the IP address of your 
-machine instead of `host.docker.internal`.
-</Tip>
-  </Tab>
-</Tabs>
-
-This manifest defines how your image runs when deployed in your Kubernetes cluster. 
-Note that you will run a single replica of your flow container. 
-If you want to run multiple replicas of your flow container to keep up with an active schedule, 
-or because your flow is resource-intensive, you can increase the `replicas` value.
-
-### Deploy your flow to the cluster
-
-You now have a deployment manifest. To deploy your flow to the cluster, use:
-
-```bash
-kubectl apply -f deployment-manifest.yaml
-```
-
-To monitor the status of your Kubernetes deployment, use:
-
-```bash
-kubectl get deployments
-```
-
-Once the deployment successfully starts, check the logs of your flow container 
-by running the following:
-
-```bash
-kubectl logs -l flow=get-repo-info
-```
-
-You're now serving your flow in your cluster. To trigger a flow run, use:
-
-```bash
-prefect deployment run get-repo-info/prefect-docker-guide
-```
-
-Navigate to the URL provided by the `prefect deployment run` command and follow the flow run 
-through the logs in the Prefect UI.
-
-## Prefect-maintained Docker images
-
-Every release of Prefect results in several new Docker images.
-These images are all named [prefecthq/prefect](https://hub.docker.com/r/prefecthq/prefect) and their
-**tags** identify their differences.
-
-### Image tags
-
-When a release is published, images are built for all of Prefect's supported Python versions.
-These images are tagged to identify the combination of Prefect and Python versions contained.
-Additionally, we have "convenience" tags which are updated with each release to facilitate automatic updates.
-
-For example, when release `3.1.1` is published:
-
-1. Images with the release packaged are built for each supported Python version 
-(3.9, 3.10, 3.11, 3.12) with both standard Python and Conda.
-2. These images are tagged with the full description. For example, `prefect:3.1.1-python3.10` 
-and `prefect:3.1.1-python3.10-conda`.
-3. For users that want more specific pins, these images are also tagged with the SHA of the 
-git commit of the release. For example, `sha-88a7ff17a3435ec33c95c0323b8f05d7b9f3f6d2-python3.10`.
-4. To be on the latest `3.1.x` release and receiving patch updates, 
-we update a tag without the patch version to this release. For example, `prefect.3.1-python3.10`.
-5. To be on the latest `3.x.y` release and receiving minor version updates, 
-we update a tag without the minor or patch version to this release. 
-For example, `prefect.3-python3.10`.
-6. For users who want the latest `3.x.y` release without specifying a Python version, 
-we update `3-latest` to the image for our highest supported Python version, 
-which in this case is equivalent to `prefect:3.1.1-python3.10`.
-
-<Tip>
-**Choose image versions carefully**
-
-It's a good practice to use Docker images with specific Prefect versions in production.
-
-Be careful when employing images that automatically update to new versions 
-(such as `prefecthq/prefect:2-python3.11` or `prefecthq/prefect:3-latest`).
-</Tip>
-
-### Standard Python
-
-Standard Python images are based on the official Python `slim` images, such as `python:3.10-slim`.
-
-| Tag                         |       Prefect Version       | Python Version |
-| --------------------------- | :-------------------------: | -------------: |
-| 3-latest                    | most recent v2 PyPi version |           3.10 |
-| 3-python3.12                | most recent v2 PyPi version |           3.12 |
-| 3-python3.11                | most recent v2 PyPi version |           3.11 |
-| 3-python3.10                | most recent v2 PyPi version |           3.10 |
-| 3-python3.9                 | most recent v2 PyPi version |            3.9 |
-| 3.X-python3.12              |             2.X             |           3.12 |
-| 3.X-python3.11              |             2.X             |           3.11 |
-| 3.X-python3.10              |             2.X             |           3.10 |
-| 3.X-python3.9               |             2.X             |            3.9 |
-| sha-&lt;hash&gt;-python3.12 |        &lt;hash&gt;         |           3.12 |
-| sha-&lt;hash&gt;-python3.11 |        &lt;hash&gt;         |           3.11 |
-| sha-&lt;hash&gt;-python3.10 |        &lt;hash&gt;         |           3.10 |
-| sha-&lt;hash&gt;-python3.9  |        &lt;hash&gt;         |            3.9 |
-
-### Conda-flavored Python
-
-Conda-flavored images are based on `continuumio/miniconda3`.
-Prefect is installed into a conda environment named `prefect`.
-
-| Tag                               |       Prefect Version       | Python Version |
-| --------------------------------- | :-------------------------: | -------------: |
-| 3-latest-conda                    | most recent v3 PyPi version |           3.10 |
-| 3-python3.12-conda                | most recent v3 PyPi version |           3.12 |
-| 3-python3.11-conda                | most recent v3 PyPi version |           3.11 |
-| 3-python3.10-conda                | most recent v3 PyPi version |           3.10 |
-| 3-python3.9-conda                 | most recent v3 PyPi version |            3.9 |
-| 3.X-python3.12-conda              |             3.X             |           3.12 |
-| 3.X-python3.11-conda              |             3.X             |           3.11 |
-| 3.X-python3.10-conda              |             3.X             |           3.10 |
-| 3.X-python3.9-conda               |             3.X             |            3.9 |
-| sha-&lt;hash&gt;-python3.12-conda |        &lt;hash&gt;         |           3.12 |
-| sha-&lt;hash&gt;-python3.11-conda |        &lt;hash&gt;         |           3.11 |
-| sha-&lt;hash&gt;-python3.10-conda |        &lt;hash&gt;         |           3.10 |
-| sha-&lt;hash&gt;-python3.9-conda  |        &lt;hash&gt;         |            3.9 |
-
-## Build your own image
-
-If your flow relies on dependencies not found in the default `prefecthq/prefect` images, 
-you may want to build your own image. You can either
-base it off of one of the provided `prefecthq/prefect` images, or build your own image.
-See the [Work pool deployment guide](/3.0rc/deploy/control-runs/prefect-deploy) 
-to build custom images with dependencies specified in a `requirements.txt` file.
-
-By default, Prefect [work pools](/3.0rc/deploy/control-runs/work-pools) 
-that use containers refer to the `3-latest` image.
-You can specify another image at work pool creation.
-You can override the work pool image choice in individual deployments.
-
-### Extend the `prefecthq/prefect` image manually
-
-Here is an example `Dockerfile` for building an image based on
-`prefecthq/prefect:2-latest`, but with `scikit-learn` installed:
-
-```dockerfile
-FROM prefecthq/prefect:3-latest
-
-RUN pip install scikit-learn
-```
-
-### Choose an image strategy
-
-The options described above have different complexity and performance characteristics. 
-We recommend the following when choosing a strategy:
-
-- If your flow only makes use of tasks defined in the same file as the flow, 
-or tasks that are part of `prefect` itself, you can rely on the default provided 
-`prefecthq/prefect` image.
-
-- If your flow requires a few extra dependencies found on PyPI, you can use the default 
-`prefecthq/prefect` image and specify additional packages to install at runtime when you create a deployment or a work pool.
-
-- If the installation process requires compiling code or other expensive operations, 
-consider building a custom image instead.
-
-- If your flow requires extra dependencies or shared libraries, 
-we recommend building a shared custom image with all the extra dependencies 
-and shared task definitions you need. Your flows can all rely on the same image, 
-but have their source stored externally. This option eases development, since 
-the shared image only needs to be rebuilt when dependencies change, 
-not when a flow's code changes.
-
-## Next steps
-
-- You can extend this setup to serve 
-multiple flows in a single Docker image by updating your Python script to use 
-`flow.to_deployment` and `serve` to [serve multiple flows or the same flow with 
-different configuration](/3.0rc/develop/write-flows#serving-multiple-flows-at-once).
-- To learn more about deploying flows, check out the [Deployments](/3.0rc/deploy/serve-flows/) 
-concept doc.
-- For advanced infrastructure requirements, such as executing each flow run within its own dedicated 
-Docker container, learn more in the [Work pool deployment guide](/3.0rc/deploy/control-runs/prefect-deploy).
diff --git a/docs/3.0rc/deploy/dynamic-infra/push-runs-remote.mdx b/docs/3.0rc/deploy/dynamic-infra/push-runs-remote.mdx
deleted file mode 100644
index 830c1c8771a0..000000000000
--- a/docs/3.0rc/deploy/dynamic-infra/push-runs-remote.mdx
+++ /dev/null
@@ -1,355 +0,0 @@
----
-title: Workers
-description: Learn how flow deployments enable configuring flows for scheduled and remote execution with workers.
----
-
-## Prerequisites
-
-[Docker](https://docs.docker.com/engine/install/) installed and running on your machine.
-
-## About workers
-
-Work pools that rely on client-side workers enable you to run work flows in your own Docker containers, Kubernetes clusters, 
-and serverless environments such as AWS ECS, Azure Container Instances, and GCP Cloud Run.
-
-The following diagram summarizes the architecture of a worker-based work pool deployment:
-
-```mermaid
-graph TD
-    subgraph your_infra["Your Execution Environment"]
-        worker["Worker"]
-    subgraph flow_run_infra[Flow Run Infra]
-     flow_run_a(("Flow Run A"))
-    end
-    subgraph flow_run_infra_2[Flow Run Infra]
-     flow_run_b(("Flow Run B"))
-    end      
-    end
-
-    subgraph api["Prefect API"]
-    Deployment --> |assigned to| work_pool
-        work_pool(["Work Pool"])
-    end
-
-    worker --> |polls| work_pool
-    worker --> |creates| flow_run_infra
-    worker --> |creates| flow_run_infra_2
-```
-
-<Tip>
-Notice above that the worker is in charge of provisioning the _flow run infrastructure_.
-In the context of this tutorial, that flow run infrastructure is an ephemeral Docker container to host each flow run.
-Different [worker types](/3.0rc/deploy/control-runs/workers/#worker-types) create different types of flow run 
-infrastructure.
-</Tip>
-
-Next, create a work pool and worker to deploy your tutorial flow. You will execute it later with the Prefect API.
-
-## Set up a work pool and worker
-
-In this guide you will create a **Docker** type work pool through the CLI.
-
-When you set the work pool type to **Docker**, the worker uses an available Docker 
-client to execute all work sent to this pool inside a dedicated Docker container.
-
-<Tip>
-**Other work pool types**
-
-There are [work pool types](/3.0rc/deploy/control-runs/work-pools/#work-pool-types) for serverless computing 
-environments such as AWS ECS, Azure Container Instances, Google Cloud Run, and Vertex AI.
-Kubernetes is also a popular work pool type.
-</Tip>
-
-### Create a work pool
-
-To set up a **Docker** type work pool, run:
-
-
-```bash
-prefect work-pool create --type docker my-docker-pool
-```
-
-
-To confirm the work pool creation was successful, run:
-
-
-```bash
-prefect work-pool ls
-```
-
-You should see your new `my-docker-pool` listed in the output.
-
-Next, check that you can see this work pool in your Prefect UI.
-
-Navigate to the **Work Pools** tab and verify that you see `my-docker-pool` listed.
-
-When you click into `my-docker-pool`, you should see a red status icon signifying that this work pool is not ready.
-
-To make the work pool ready, start a worker.
-
-### Start a worker
-
-Workers are a lightweight polling process that kick off scheduled flow runs on a specific type of infrastructure (such as Docker).
-To start a worker on your local machine, open a new terminal and confirm that your virtual environment has `prefect` installed.
-
-Run the following command in this new terminal to start the worker:
-
-
-```bash
-prefect worker start --pool my-docker-pool
-
-```
-
-You should see the worker start.
-It's now polling the Prefect API to check for any scheduled flow runs it should pick up and then submit for execution.
-You’ll see your new worker listed in the UI under the **Workers** tab of the Work Pools page with a recent last polled date.
-
-You should now see a `Ready` status indicator on your work pool.
-
-Keep this terminal session active for the worker to continue to pick up jobs.
-Since you are running this worker locally, the worker will terminate if you close the terminal.
-In a production setting this worker should run as a [daemonized or managed process](/3.0rc/deploy/dynamic-infra/push-runs-remote/).
-
-Next, deploy your tutorial flow to `my-docker-pool`.
-
-## Create the deployment
-
-From the previous steps, you now have:
-
-1. [A flow](/3.0rc/develop/write-flows/)
-2. A work pool
-3. A worker
-
-Update your `repo_info.py` file to build a Docker image, and update your deployment so your worker can execute it.
-
-Make the following updates in `repo_info.py`:
-
-1. Change `flow.serve` to `flow.deploy`.
-2. Tell `flow.deploy` which work pool to deploy to.
-3. Tell `flow.deploy` the name for the Docker image to build.
-
-The updated `repo_info.py` looks like this:
-
-```python repo_info.py
-import httpx
-from prefect import flow
-
-
-@flow(log_prints=True)
-def get_repo_info(repo_name: str = "PrefectHQ/prefect"):
-    url = f"https://api.github.com/repos/{repo_name}"
-    response = httpx.get(url)
-    response.raise_for_status()
-    repo = response.json()
-    print(f"{repo_name} repository statistics 🤓:")
-    print(f"Stars 🌠 : {repo['stargazers_count']}")
-    print(f"Forks 🍴 : {repo['forks_count']}")
-
-
-if __name__ == "__main__":
-    get_repo_info.deploy(
-        name="my-first-deployment", 
-        work_pool_name="my-docker-pool", 
-        image="my-first-deployment-image:tutorial",
-        push=False
-    )
-```
-
-<Note>
-**Why the `push=False`?**
-
-For this tutorial, your Docker worker is running on your machine, so you don't need to push the image built by 
-`flow.deploy` to a registry. When your worker is running on a remote machine, you must push the image to a registry 
-that the worker can access.
-
-Remove the `push=False` argument, include your registry name, and ensure you've 
-[authenticated with the Docker CLI](https://docs.docker.com/engine/reference/commandline/login/) to push the image to a registry.
-
-</Note>
-
-Now that you've updated your script, run it to deploy your flow to the work pool:
-
-```bash
-python repo_info.py
-```
-    
-Prefect builds a custom Docker image containing your flow code. The worker can use it to dynamically spawn Docker 
-containers whenever this workflow needs to run.
-
-<Note>
-    **Dockerfile**
-    
-    In this example, Prefect generates a Dockerfile that builds an image based on one of Prefect's published images. 
-    The generated Dockerfile copies the current directory into the Docker image and installs any dependencies listed in a 
-    `requirements.txt` file.
-
-    To use a custom Dockerfile, specify the path to the Dockerfile using the `DockerImage` class:
-
-    ```python repo_info.py
-    import httpx
-    from prefect import flow
-    from prefect.docker import DockerImage
-
-
-    @flow(log_prints=True)
-    def get_repo_info(repo_name: str = "PrefectHQ/prefect"):
-        url = f"https://api.github.com/repos/{repo_name}"
-        response = httpx.get(url)
-        response.raise_for_status()
-        repo = response.json()
-        print(f"{repo_name} repository statistics 🤓:")
-        print(f"Stars 🌠 : {repo['stargazers_count']}")
-        print(f"Forks 🍴 : {repo['forks_count']}")
-
-
-    if __name__ == "__main__":
-        get_repo_info.deploy(
-            name="my-first-deployment", 
-            work_pool_name="my-docker-pool", 
-            image=DockerImage(
-                name="my-first-deployment-image",
-                tag="tutorial",
-                dockerfile="Dockerfile"
-            ),
-            push=False
-        )
-    ```
-</Note>
-
-### Modify the deployment
-
-To update your deployment, modify your script and rerun it. Specify a value for `job_variables` 
-so your Docker worker can successfully execute scheduled runs for this flow. See the example below.
-
-The `job_variables` section allows you to fine-tune the infrastructure settings for a specific deployment. These values override 
-default values in the specified work pool's [base job template](/3.0rc/deploy/control-runs/work-pools/#base-job-template).
-
-When testing images locally without pushing them to a registry (to avoid potential errors like docker.errors.NotFound), 
-we recommend including an `image_pull_policy` job_variable set to `Never`. However, for production workflows, push images to a 
-remote registry for more reliability and accessibility.
-
-Set the `image_pull_policy` as `Never` for this test deployment without affecting the default value set on your work pool:
-
-```python repo_info.py
-import httpx
-from prefect import flow
-
-
-@flow(log_prints=True)
-def get_repo_info(repo_name: str = "PrefectHQ/prefect"):
-    url = f"https://api.github.com/repos/{repo_name}"
-    response = httpx.get(url)
-    response.raise_for_status()
-    repo = response.json()
-    print(f"{repo_name} repository statistics 🤓:")
-    print(f"Stars 🌠 : {repo['stargazers_count']}")
-    print(f"Forks 🍴 : {repo['forks_count']}")
-
-
-if __name__ == "__main__":
-    get_repo_info.deploy(
-        name="my-first-deployment", 
-        work_pool_name="my-docker-pool", 
-        job_variables={"image_pull_policy": "Never"},
-        image="my-first-deployment-image:tutorial",
-        push=False
-    )
-```
-
-To register this update to your deployment's parameters with Prefect's API, run:
-
-
-```bash
-python repo_info.py
-```
-
-
-Submit a flow-run to the work pool:
-
-
-```bash
-prefect deployment run 'get_repo_info/my-deployment'
-```
-
-
-<Warning>
-    **Common Pitfall**
-    
-    Store and run your deploy scripts at the **root of your repo**, otherwise the built Docker file may be missing files that 
-    it needs to execute.
-</Warning>
-
-<Tip>
-    **Multiple deployments**
-    
-    A Prefect flow can have more than one deployment. 
-    This pattern is useful for a flow to run in different execution environments.
-</Tip>
-
-## Learn more
-
-- Learn how to configure deployments in YAML with [`prefect.yaml`](/3.0rc/deploy/control-runs/prefect-deploy/).
-- [Deploy flows on Kubernetes](/3.0rc/deploy/dynamic-infra/deploy-kubernetes/)
-- [Deploy flows in Docker](/3.0rc/deploy/dynamic-infra/deploy-docker/)
-- [Deploy flows on serverless infrastructure](/3.0rc/deploy/dynamic-infra/push-runs-remote/)
-- [Daemonize workers](/3.0rc/deploy/dynamic-infra/push-runs-remote/)
-
-# Run deployments on serverless infrastructure with Prefect workers
-
-Prefect provides hybrid work pools for workers to run flows on the serverless platforms of major cloud providers.
-The following options are available:
-
-- AWS Elastic Container Service (ECS)
-- Azure Container Instances (ACI)
-- Google Cloud Run
-- Google Cloud Run V2
-- Google Vertex AI
-
-![Work pool options](/3.0rc/img/ui/work-pools.png)
-
-- Create a work pool that sends work to your chosen serverless infrastructure
-- Deploy a flow to that work pool
-- Start a worker in your serverless cloud provider that polls its matched work pool for scheduled runs
-- Schedule a deployment run that a worker picks up from the work pool and runs on your serverless infrastructure
-
-<Note>
-**Push work pools don't require a worker**
-
-Options for push work pool versions of AWS ECS, Azure Container Instances, and Google Cloud Run that do not require a 
-worker are available with Prefect Cloud.
-These push work pool options require connection configuration information to be stored on Prefect Cloud.
-Read more in the [Serverless push work pool guide](/3.0rc/deploy/dynamic-infra/push-runs-serverless/).
-</Note>
-
-This is a brief overview of the options to run workflows on serverless infrastructure.
-For in-depth guides, see the Prefect integration libraries:
-
-- [AWS ECS guide in the `prefect-aws` docs](https://prefecthq.github.io/prefect-aws/ecs_guide/)
-- [Azure Container Instances guide](/integrations/prefect-azure/aci_worker/)
-- [Google Cloud Run guide in the `prefect-gcp` docs](https://prefecthq.github.io/prefect-gcp/gcp-worker-guide/).
-- For Google Vertex AI, follow the Cloud Run guide, substituting *Google Vertex AI* where *Google Cloud Run* is mentioned.
-
-<Note>
-**Choosing between Google Cloud Run and Google Vertex AI**
-
-Google Vertex AI is well-suited for machine learning model training applications with GPUs or TPUs and high resource 
-levels.
-</Note>
-
-## Steps
-
-1. Make sure you have a user or service account on your chosen cloud provider with the necessary permissions to run serverless jobs
-1. Create the appropriate serverless work pool that uses a worker in the Prefect UI
-1. Create a deployment that references the work pool
-1. Start a worker in your chose serverless cloud provider infrastructure
-1. Run the deployment
-
-## Next steps
-
-Learn more about [work pools](/3.0rc/deploy/control-runs/work-pools/) and [workers](/3.0rc/deploy/control-runs/workers/).
-
-Learn about installing dependencies at runtime or baking them into your Docker image in the 
-[work pools and workers guide](/3.0rc/deploy/control-runs/prefect-deploy/#creating-work-pool-based-deployments-with-deploy).
-
-To set up a long-lived process on a Windows machine the pattern is similar.
-Instead of systemd, you can use [NSSM](https://nssm.cc/).
\ No newline at end of file
diff --git a/docs/3.0rc/deploy/serve-flows/deploy-a-flow.mdx b/docs/3.0rc/deploy/index.mdx
similarity index 54%
rename from docs/3.0rc/deploy/serve-flows/deploy-a-flow.mdx
rename to docs/3.0rc/deploy/index.mdx
index 0716101b6a23..f8f785d06734 100644
--- a/docs/3.0rc/deploy/serve-flows/deploy-a-flow.mdx
+++ b/docs/3.0rc/deploy/index.mdx
@@ -1,6 +1,6 @@
 ---
-title: Deploy flows
-description: Learn how to configure flows for scheduled and remote execution.
+title: Deployment overview
+description: Learn what deployments are and how to use them in Prefect.
 tags:
     - orchestration
     - flow runs
@@ -12,7 +12,9 @@ search:
   boost: 2
 ---
 
-[Deployments](/3.0rc/deploy/serve-flows/) are server-side representations of flows. 
+## What is a deployment?
+
+[Deployments](/3.0rc/deploy/infrastructure-examples/docker/) are server-side representations of flows. 
 They store the crucial metadata for remote orchestration including when, where, and 
 how a workflow should run.
 
@@ -30,155 +32,7 @@ UI that allow you to:
 - trigger new runs, [cancel active runs](/3.0rc/develop/write-flows/#cancel-a-flow-run), 
 pause scheduled runs, customize parameters, and more
 - remotely configure schedules and automation rules for your deployments
-- dynamically provision infrastructure using [workers](/3.0rc/deploy/dynamic-infra/push-runs-remote)
-
-<Note>
-**Connect to Prefect Cloud or a self-hosted Prefect server instance**
-
-Some features in this tutorial, such as scheduling, require you to connect to a Prefect server.
-If using a self-hosted setup, run `prefect server start` to run both the webserver and UI.
-If using Prefect Cloud, make sure you have 
-[successfully authenticated your local environment](/3.0rc/manage/cloud/connect-to-cloud).
-
-</Note>
-
-## Create a deployment
-
-Here's an example of creating a deployment by calling a 
-single method on the flow object: `flow.serve`.
-
-```python repo_info.py
-import httpx
-from prefect import flow
-
-
-@flow(log_prints=True)
-def get_repo_info(repo_name: str = "PrefectHQ/prefect"):
-    url = f"https://api.github.com/repos/{repo_name}"
-    response = httpx.get(url)
-    response.raise_for_status()
-    repo = response.json()
-    print(f"{repo_name} repository statistics 🤓:")
-    print(f"Stars 🌠 : {repo['stargazers_count']}")
-    print(f"Forks 🍴 : {repo['forks_count']}")
-
-
-if __name__ == "__main__":
-    get_repo_info.serve(name="my-first-deployment")
-```
-
-Running this script will:
-
-- create a deployment called ```my-first-deployment``` for your flow in the Prefect API
-- continue running to listen for flow runs for this deployment; when a run is found, it  
-*asynchronously executes within a subprocess*
-
-<Warning>
-**You must define deployments in static files**
-
-You can define and run flows interactively, within REPLs or Notebooks.
-However, deployments require that your flow definition exist in a known file.  
-</Warning>
-
-Because this deployment doesn't have a schedule or triggering automation, you must use the UI or API to create 
-runs for it.
-Use the CLI (in a separate terminal window) to create a run for this deployment:
-
-```bash
-prefect deployment run 'get-repo-info/my-first-deployment'
-```
-
-In your terminal or UI, you should see the newly created run execute successfully.  
-
-### Additional options
-
-The `serve` method on flows exposes many options for the deployment. For more information, see 
-[Serve a flow](3.0rc/deploy/serve-flows/serve-a-flow)
-Here's how to use some of those options:
-
-- `cron`: a keyword that allows you to set a cron string schedule for the deployment; see 
-[schedules](/3.0rc/automate/add-schedules/) for more advanced scheduling options
-- `tags`: a keyword that allows you to tag this deployment and its runs for bookkeeping and filtering purposes
-- `description`: a keyword that allows you to document what this deployment does; by default the 
-description is set from the docstring of the flow function (if documented)
-- `version`: a keyword that allows you to track changes to your deployment; uses a hash of the 
-file containing the flow by default; popular options include semver tags or git commit hashes
-
-Next, add these options to your deployment:
-
-```python
-if __name__ == "__main__":
-    get_repo_info.serve(
-        name="my-first-deployment",
-        cron="* * * * *",
-        tags=["testing", "tutorial"],
-        description="Given a GitHub repository, logs repository statistics for that repo.",
-        version="tutorial/deployments",
-    )
-```
-
-When you rerun this script, you will find an updated deployment in the UI that is actively scheduling work.  
-Stop the script in the CLI using `CTRL+C` and your schedule automatically pauses.
-
-<Note>
-**`.serve` is a long-running process**
-
-To execute remotely triggered or scheduled runs, your script with `flow.serve` must be actively running.
-</Note>
-
-## Run multiple deployments at once
-
-This method is useful for creating deployments for single flows. For two or more flows, you must provide a 
-few additional method calls and imports:
-
-```python multi_flow_deployment.py
-import time
-from prefect import flow, serve
-
-
-@flow
-def slow_flow(sleep: int = 60):
-    "Sleepy flow - sleeps the provided amount of time (in seconds)."
-    time.sleep(sleep)
-
-
-@flow
-def fast_flow():
-    "Fastest flow this side of the Mississippi."
-    return
-
-
-if __name__ == "__main__":
-    slow_deploy = slow_flow.to_deployment(name="sleeper", interval=45)
-    fast_deploy = fast_flow.to_deployment(name="fast")
-    serve(slow_deploy, fast_deploy)
-```
-
-A few things to note:
-
-- the `flow.to_deployment` interface exposes the *exact same* options as `flow.serve`; this method 
-produces a deployment object
-- the deployments are only registered with the API once `serve(...)` is called
-- when serving multiple deployments, the only requirement is that they share a Python environment; 
-they can be executed and scheduled independently of each other
-
-A few optional steps for exploration include:
-
-- pause and unpause the schedule for the "sleeper" deployment
-- use the UI to submit ad-hoc runs for the "sleeper" deployment with different values for `sleep`
-- cancel an active run for the "sleeper" deployment from the UI
-
-<Tip>
-**Hybrid execution option**
-
-Prefect's deployment interface allows you to choose a hybrid execution model.
-Whether you use Prefect Cloud or host a Prefect server instance, you can run workflows in the 
-environments best suited to their execution.
-This model enables efficient use of your infrastructure resources while maintaining the privacy 
-of your code and data.
-There is no ingress required.
-Read more about our [hybrid model](https://www.prefect.io/security/overview/#hybrid-model).
-</Tip>
+- dynamically provision infrastructure using [workers](/3.0rc/deploy/infrastructure-examples/docker)
 
 ## Deployment schema
 
@@ -218,7 +72,7 @@ class Deployment:
 All methods for creating Prefect deployments are interfaces for populating this schema. 
 The following sections explain each component in more detail.
 
-### Required data
+### Required defining data
 
 Deployments universally require a `name` and a reference to an underlying `Flow`.
 
@@ -261,7 +115,7 @@ This is key to the Prefect hybrid model: there's a boundary between your proprie
 such as your flow code, and the Prefect backend (including [Prefect Cloud](/3.0rc/manage/cloud/)). 
 </Note>
 
-### Scheduling and parametrization
+### Workflow scheduling and parametrization
 
 One of the primary motivations for creating deployments of flows is to remotely _schedule_ and _trigger_ them.
 Just as you can call flows as functions with different input values, deployments can be triggered or 
@@ -289,73 +143,7 @@ passed to a flow run against the schema defined by `parameter_openapi_schema`.
 Pausing a schedule, updating your deployment, and other actions reset your auto-scheduled runs.
 </Tip>
 
-#### Run a deployed flow from within Python flow code
-
-Prefect provides a [`run_deployment` function](https://prefect-python-sdk-docs.netlify.app/prefect/deployments/deployments/#prefect.deployments.deployments.run_deployment) 
-to schedule the run of an existing deployment when your Python code executes.
-
-```python
-from prefect.deployments import run_deployment
-
-def main():
-    run_deployment(name="my_flow_name/my_deployment_name")
-```
-
-<Tip>
-**Run a deployment without blocking**
-
-By default, `run_deployment` blocks until the scheduled flow run finishes
-executing. Pass `timeout=0` to return immediately and not block.
-</Tip>
-    
-If you call `run_deployment` from within a flow or task, the scheduled flow
-run is linked to the calling flow run (or the calling task's flow run)
-as a nested flow run by default.
-
-Nested flow runs have different behavior than regular flow runs. For example, you can't suspend a 
-nested flow run independently of its parent flow run. 
-To prevent the flow run triggered by `run_deployment` from being linked to the flow run from which the method was called,
-pass `as_subflow=False` to disable it:
-
-```python
-from prefect import flow
-from prefect.deployments import run_deployment
-
-
-@flow
-def my_flow():
-    # This flow run will not be linked to `my_flow` run as a child 
-    run_deployment(name="my_other_flow/my_deployment_name", as_subflow=False)
-```
-
-The return value of `run_deployment` is a [FlowRun](https://prefect-python-sdk-docs.netlify.app/prefect/client/schemas/#prefect.client.schemas.objects.FlowRun) 
-object containing metadata about the scheduled run. Use this object to retrieve information 
-about the run after calling
-`run_deployment`:
-
-```python
-from prefect import get_client
-from prefect.deployments import run_deployment
-
-def main():
-    flow_run = run_deployment(name="my_flow_name/my_deployment_name")
-    flow_run_id = flow_run.id
-
-    # If you save the flow run's ID, you can use it later to retrieve
-    # flow run metadata again, e.g. to check if it's completed.
-    async with get_client() as client:
-        flow_run = client.read_flow_run(flow_run_id)
-        print(f"Current state of the flow run: {flow_run.state}")
-```
-
-<Tip>
-**Using the Prefect client**
-
-For more information on using the Prefect client to interact with Prefect's
-REST API, see [Interact with the API](/3.0rc/manage/interact-with-api/).
-</Tip>
-
-## Versioning and bookkeeping
+### Metadata for bookkeeping
 
 Here is important information on the versions, descriptions, and tags fields:
 
@@ -377,9 +165,9 @@ versions set through their respective decorators. These versions are sent to the
 anytime the flow or task runs, allowing you to audit changes.
 </Tip>
 
-### Workers and work pools
+### Worker-specific fields
 
-[Work pools](/3.0rc/deploy/control-runs/work-pools/) and [workers](/3.0rc/deploy/control-runs/workers/) are an advanced deployment pattern that 
+[Work pools](/3.0rc/deploy/infrastructure-concepts/work-pools/) and [workers](/3.0rc/deploy/infrastructure-concepts/workers/) are an advanced deployment pattern that 
 allow you to dynamically provision infrastructure for each flow run.
 The work pool job template interface allows users to create and govern opinionated interfaces 
 to their workflow infrastructure.
@@ -401,7 +189,12 @@ Pull steps allow users to highly decouple their workflow architecture.
 For example, a common use of pull steps is to dynamically pull code from remote filesystems such as 
 GitHub with each run of their deployment.
 
-### Serving flows on long-lived infrastructure
+## Static vs. dynamic infrastructure
+
+You can deploy your flows on long-lived static infrastructure or on dynamic infrastructure that is able to scale horizontally.
+The right choice depends on your use case.
+
+### Static infrastructure
 
 When you have several flows running regularly, [the `serve` method](/3.0rc/develop/write-flows/#serving-a-flow) 
 of the `Flow` object or [the `serve` utility](/3.0rc/develop/write-flows/#serving-multiple-flows-at-once) 
@@ -422,10 +215,9 @@ run is a suitable deployment environment.
 - Creating deployments requires a minimal set of decisions.
 - Iteration speed is fast.
 
-### Dynamically provisioning infrastructure with work pools
+### Dynamic infrastructure
 
-Consider running flows on dynamically provisioned 
-infrastructure with work pools under these circumstances:
+Consider running flows on dynamically provisioned infrastructure with work pools under these circumstances:
 
 - Flows that have expensive infrastructure due to the long-running process.
 - Flows with heterogeneous infrastructure needs across runs.
@@ -433,12 +225,12 @@ infrastructure with work pools under these circumstances:
 - If your internal team structure requires that deployment authors be members of a different team 
 than the team managing infrastructure.
 
-[Work pools](/3.0rc/deploy/control-runs/work-pools/) allow Prefect to exercise greater control 
+[Work pools](/3.0rc/deploy/infrastructure-concepts/work-pools/) allow Prefect to exercise greater control 
 of the infrastructure on which flows run.
-Options for [serverless work pools](/3.0rc/deploy/dynamic-infra/push-runs-remote/) allow you to 
+Options for [serverless work pools](/3.0rc/deploy/infrastructure-examples/serverless/) allow you to 
 scale to zero when workflows aren't running.
 Prefect even provides you with the ability to 
-[provision cloud infrastructure via a single CLI command](/3.0rc/deploy/dynamic-infra/push-runs-serverless/#automatically-creating-a-new-push-work-pool-and-provisioning-infrastructure), 
+[provision cloud infrastructure via a single CLI command](/3.0rc/deploy/infrastructure-examples/serverless/#automatically-create-a-new-push-work-pool-and-provision-infrastructure), 
 if you use a Prefect Cloud push work pool option.
 
 With work pools:
@@ -455,4 +247,4 @@ You can mix and match approaches based on the needs of each flow. You can also c
 deployment approach for a particular flow as its needs evolve.
 For example, you might use workers for your expensive machine learning pipelines, 
 but use the serve mechanics for smaller, more frequent file-processing pipelines.
-</Note>
+</Note>
\ No newline at end of file
diff --git a/docs/3.0rc/deploy/dynamic-infra/customize.mdx b/docs/3.0rc/deploy/infrastructure-concepts/customize.mdx
similarity index 99%
rename from docs/3.0rc/deploy/dynamic-infra/customize.mdx
rename to docs/3.0rc/deploy/infrastructure-concepts/customize.mdx
index 2e301c592b89..c489dc18c400 100644
--- a/docs/3.0rc/deploy/dynamic-infra/customize.mdx
+++ b/docs/3.0rc/deploy/infrastructure-concepts/customize.mdx
@@ -1,5 +1,5 @@
 ---
-title: Override work pool job variables
+title: Override job variables
 description: Learn how to override job variables on a work pool for a given deployment.
 ---
 
diff --git a/docs/3.0rc/deploy/dynamic-infra/deploy-ci-cd.mdx b/docs/3.0rc/deploy/infrastructure-concepts/deploy-ci-cd.mdx
similarity index 99%
rename from docs/3.0rc/deploy/dynamic-infra/deploy-ci-cd.mdx
rename to docs/3.0rc/deploy/infrastructure-concepts/deploy-ci-cd.mdx
index da3cc24e0c3f..4205a43aceb7 100644
--- a/docs/3.0rc/deploy/dynamic-infra/deploy-ci-cd.mdx
+++ b/docs/3.0rc/deploy/infrastructure-concepts/deploy-ci-cd.mdx
@@ -1,5 +1,5 @@
 ---
-title: CI/CD with Prefect
+title: Build deployments via CI/CD
 description: CI/CD resources for working with Prefect.
 tags:
   - CI/CD
@@ -11,7 +11,7 @@ search:
 
 Many organizations deploy Prefect workflows through their CI/CD process.
 Each organization has their own unique CI/CD setup, but a common pattern is to use CI/CD to manage
-Prefect [deployments](/3.0rc/deploy/serve-flows).
+Prefect [deployments](/3.0rc/deploy/infrastructure-examples/docker).
 Combining Prefect's deployment features with CI/CD tools enables efficient management of flow code
 updates, scheduling changes, and container builds.
 This guide uses [GitHub Actions](https://docs.github.com/en/actions) to implement a CI/CD process,
diff --git a/docs/3.0rc/deploy/control-runs/prefect-deploy.mdx b/docs/3.0rc/deploy/infrastructure-concepts/prefect-yaml.mdx
similarity index 59%
rename from docs/3.0rc/deploy/control-runs/prefect-deploy.mdx
rename to docs/3.0rc/deploy/infrastructure-concepts/prefect-yaml.mdx
index a6d850478be2..eb2a33c60bec 100644
--- a/docs/3.0rc/deploy/control-runs/prefect-deploy.mdx
+++ b/docs/3.0rc/deploy/infrastructure-concepts/prefect-yaml.mdx
@@ -1,562 +1,8 @@
 ---
-title: Deploy flows to work pools and workers
-description: Learn how to schedule and trigger flow runs through the API and easily manage your code and deployments.
+title: Define deployments with YAML
+description: Use YAML to schedule and trigger flow runs and manage your code and deployments.
 ---
 
-In this guide, you will configure a deployment that uses a work pool for dynamically provisioned infrastructure.
-Work pools and workers bridge the Prefect _orchestration environment_ with your _execution environment_. 
-When a [deployment](/3.0rc/deploy/serve-flows/) creates a flow run, it is submitted to a specific work pool for scheduling. 
-A worker running in the execution environment polls its respective work pool for new runs to execute; or the work pool submits flow runs to serverless infrastructure directly, depending on the type of work pool.
-
-All Prefect flow runs are tracked by the API. The API does not require prior registration of flows.
-You can call a flow locally or on a remote environment and it will be trackable.
-
-A deployment turns your workflow into an application you can manage through the Prefect API.
-A deployment enables you to:
-
-- Schedule flow runs.
-- Specify event triggers for flow runs.
-- Assign one or more tags to organize your deployments and flow runs. You can use those tags as filters in the Prefect UI.
-- Assign custom parameter values for flow runs based on the deployment.
-- Create ad-hoc flow runs from the API or Prefect UI.
-- Upload flow files to a defined storage location for retrieval at run time.
-
-<Note>
-**Deployments created with `.serve`**
-
-    A deployment created with the Python `flow.serve` method or the `serve` function runs flows in a subprocess on the same 
-    machine where the deployment is created. It does not use a work pool or worker.
-</Note>
-
-## Work pool-based deployments
-
-A work pool-based deployment is useful to dynamically scale the infrastructure where your flow code runs.
-Work pool-based deployments contain information about the infrastructure type and configuration for your workflow execution.
-
-Work pool-based deployment infrastructure options include the following:
-
-- **Process**: runs flow in a subprocess. In most cases, you're better off using `.serve`.
-- **[Docker](/3.0rc/deploy/dynamic-infra/deploy-docker/)**: - runs flows in an ephemeral Docker container.
-- **[Kubernetes](/3.0rc/deploy/dynamic-infra/deploy-kubernetes/)**: - runs flows as a Kubernetes Job.
-- **[Serverless Cloud Provider options](/3.0rc/deploy/dynamic-infra/push-runs-remote/)**: runs flows in a 
-Docker container in a serverless cloud provider environment, 
-such as AWS ECS, Azure Container Instance, Google Cloud Run, or Vertex AI.
-
-The following diagram provides a high-level overview of the conceptual elements involved in defining a work-pool based 
-deployment that is polled by a worker and executes a flow run based on that deployment.
-
-```mermaid
-%%{
-  init: {
-    'theme': 'base',
-    'themeVariables': {
-      'fontSize': '19px'
-    }
-  }
-}%%
-
-flowchart LR
-    F("<div style='margin: 5px 10px 5px 5px;'>Flow Code</div>"):::yellow -.-> A("<div style='margin: 5px 10px 5px 5px;'>Deployment Definition</div>"):::gold
-    subgraph Server ["<div style='width: 150px; text-align: center; margin-top: 5px;'>Prefect API</div>"]
-        D("<div style='margin: 5px 10px 5px 5px;'>Deployment</div>"):::green
-    end
-    subgraph Remote Storage ["<div style='width: 160px; text-align: center; margin-top: 5px;'>Remote Storage</div>"]
-        B("<div style='margin: 5px 6px 5px 5px;'>Flow</div>"):::yellow
-    end
-    subgraph Infrastructure ["<div style='width: 150px; text-align: center; margin-top: 5px;'>Infrastructure</div>"]
-        G("<div style='margin: 5px 10px 5px 5px;'>Flow Run</div>"):::blue
-    end
-
-    A --> D
-    D --> E("<div style='margin: 5px 10px 5px 5px;'>Worker</div>"):::red
-    B -.-> E
-    A -.-> B
-    E -.-> G
-
-    classDef gold fill:goldenrod,stroke:goldenrod,stroke-width:4px,color:black
-    classDef yellow fill:gold,stroke:gold,stroke-width:4px,color:black
-    classDef gray fill:lightgray,stroke:lightgray,stroke-width:4px
-    classDef blue fill:blue,stroke:blue,stroke-width:4px,color:white
-    classDef green fill:green,stroke:green,stroke-width:4px,color:white
-    classDef red fill:red,stroke:red,stroke-width:4px,color:white
-    classDef dkgray fill:darkgray,stroke:darkgray,stroke-width:4px,color:white
-```
-
-These work pool types require a worker running on your infrastructure to poll a work pool for scheduled flow runs.
-
-<Note>
-**Additional work pool options available with Prefect Cloud**
-
-    Prefect Cloud offers other flavors of work pools that don't require a worker:
-
-    - **[Push Work Pools](/3.0rc/deploy/dynamic-infra/push-runs-serverless)**: serverless cloud options that don't require 
-    a worker because Prefect Cloud submits them to your serverless cloud infrastructure on your behalf. 
-    Prefect can auto-provision your cloud infrastructure for you and set it up to use your work pool.
-    - **[Managed Execution](/3.0rc/deploy/control-runs/managed-execution/)**: Prefect Cloud submits and runs your 
-    deployment on serverless infrastructure. No cloud provider account required.
-</Note>
-
-This guide focuses on deployments that require a worker.
-
-Work pool-based deployments that use a worker also allow you to assign a work queue name to prioritize work 
-and allow you to limit concurrent runs at the work pool level.
-
-When creating a deployment that uses a work pool and worker, there are two important considerations:
-
-- What instructions does a [worker](/3.0rc/deploy/control-runs/workers/) require to set up an execution environment for your flow? 
-For example, a flow may have Python package requirements, unique Kubernetes settings, or Docker networking configuration.
-- How should the flow code be accessed?
-
-[Serve flows](/3.0rc/deploy/serve-flows/) shows how to create a deployment with a long-running process using `.serve`, 
-and how to move to a [work-pool-based deployment](/3.0rc/deploy/dynamic-infra/push-runs-remote/) setup with `.deploy`.
-Learn more about when to move to [work-pool-based deployments](/3.0rc/deploy/dynamic-infra/push-runs-remote/#why-workers-and-work-pools).
-
-Next, you'll learn how to use `.deploy` to create deployments with Python code.
-If you prefer to learn about using a YAML-based alternative for managing deployment configuration, skip to the 
-[`prefect.yaml` section](#creating-work-pool-based-deployments-with-prefectyaml).
-
-## Create work pool-based deployments with `.deploy`
-
-### Automatically bake your code into a Docker image
-
-Create a deployment from Python code by calling the `.deploy` method on a flow:
-
-```python buy.py
-from prefect import flow
-
-
-@flow(log_prints=True)
-def buy():
-    print("Buying securities")
-
-
-if __name__ == "__main__":
-    buy.deploy(
-        name="my-code-baked-into-an-image-deployment", 
-        work_pool_name="my-docker-pool", 
-        image="my_registry/my_image:my_image_tag"
-    )
-```
-
-Ensure the [work pool](/3.0rc/deploy/control-runs/work-pools/) exists in the Prefect Cloud workspace you are 
-authenticated to, or on your running self-hosted server instance.  
-Then run the script to create a deployment (in future examples this step is omitted for brevity):
-
-```bash
-python buy.py
-```
-
-You should see messages in your terminal that Docker is building your image.
-When the deployment build succeeds, you will see information in your terminal showing you how to start a worker for your 
-deployment, and how to run your deployment.
-Your deployment is visible on the `Deployments` page in the UI.
-
-By default, `.deploy` builds a Docker image with your flow code baked into it and pushes the image to the 
-[Docker Hub](https://hub.docker.com/) registry specified in the `image` argument`.
-
-<Note>
-**Authentication to Docker Hub**
-
-    Your environment must be authenticated to your Docker registry to push an image to it.
-</Note>
-
-You can specify a registry other than Docker Hub by providing the full registry path in the `image` argument.
-
-<Warning>
-    If building a Docker image, your environment with your deployment needs Docker installed and running.
-</Warning>
-
-To avoid pushing to a registry, set `push=False` in the `.deploy` method:
-
-```python
-
-if __name__ == "__main__":
-    buy.deploy(
-        name="my-code-baked-into-an-image-deployment", 
-        work_pool_name="my-docker-pool", 
-        image="my_registry/my_image:my_image_tag",
-        push=False
-    )
-```
-
-To avoid building an image, set `build=False` in the `.deploy` method:
-
-```python
-
-if __name__ == "__main__":
-    buy.deploy(
-        name="my-code-baked-into-an-image-deployment", 
-        work_pool_name="my-docker-pool", 
-        image="my_registry/no-build-image:1.0",
-        build=False
-    )
-```
-
-The specified image must be available in your deployment's execution environment for accessible flow code.
-
-Prefect generates a Dockerfile for you that builds an image based off of one of Prefect's published images. 
-The generated Dockerfile copies the current directory into the Docker image and installs any dependencies listed 
-in a `requirements.txt` file.
-
-### Automatically build a custom Docker image with a local Dockerfile
-
-If you want to use a custom Dockerfile, specify the path to the Dockerfile with the `DockerImage` class:
-
-```python custom_dockerfile.py
-from prefect import flow
-from prefect.docker import DockerImage
-
-
-@flow(log_prints=True)
-def buy():
-    print("Selling securities")
-
-
-if __name__ == "__main__":
-    buy.deploy(
-        name="my-custom-dockerfile-deployment", 
-        work_pool_name="my-docker-pool", 
-        image=DockerImage(
-            name="my_image",
-            tag="deploy-guide",
-            dockerfile="Dockerfile"
-    ),
-    push=False
-)
-
-```
-
-The `DockerImage` object enables image customization.
-
-For example, you can install a private Python package from GCP's artifact registry like this:
-
-Create a custom base Dockerfile.
-
-```
-FROM python:3.10
-
-ARG AUTHED_ARTIFACT_REG_URL
-COPY ./requirements.txt /requirements.txt
-
-RUN pip install --extra-index-url ${AUTHED_ARTIFACT_REG_URL} -r /requirements.txt
-```
-
-Create your deployment with the DockerImage class:
-
-```python private-package.py
-from prefect import flow
-from prefect.deployments.runner import DockerImage
-from prefect.blocks.system import Secret
-from my_private_package import do_something_cool
-
-
-@flow(log_prints=True)
-def my_flow():
-    do_something_cool()
-
-
-if __name__ == "__main__":
-    artifact_reg_url: Secret = Secret.load("artifact-reg-url")
-    
-    my_flow.deploy(
-        name="my-deployment",
-        work_pool_name="k8s-demo",
-        image=DockerImage(
-            name="my-image",
-            tag="test",
-            dockerfile="Dockerfile",
-            buildargs={"AUTHED_ARTIFACT_REG_URL": artifact_reg_url.get()},
-        ),
-    )
-```
-
-Note that you used a [Prefect Secret block](/3.0rc/develop/blocks/) to load the URL configuration for 
-the artifact registry above.
-
-See all the optional keyword arguments for the [DockerImage class](https://docker-py.readthedocs.io/en/stable/images.html#docker.models.images.ImageCollection.build).
-
-<Tip>
-**Default Docker namespace**
-
-    You can set the `PREFECT_DEFAULT_DOCKER_BUILD_NAMESPACE` setting to append a default Docker namespace to all images 
-    you build with `.deploy`. This is helpful if you use a private registry to store your images.
-
-    To set a default Docker namespace for your current profile run:
-
-    ```bash
-    prefect config set PREFECT_DEFAULT_DOCKER_BUILD_NAMESPACE=<docker-registry-url>/<organization-or-username>
-    ```
-
-    Once set, you can omit the namespace from your image name when creating a deployment:
-
-    ```python with_default_docker_namespace.py
-    if __name__ == "__main__":
-        buy.deploy(
-            name="my-code-baked-into-an-image-deployment", 
-            work_pool_name="my-docker-pool", 
-            image="my_image:my_image_tag"
-        )
-    ```
-
-    The above code builds an image with the format `<docker-registry-url>/<organization-or-username>/my_image:my_image_tag` 
-    when `PREFECT_DEFAULT_DOCKER_BUILD_NAMESPACE` is set.
-</Tip>
-
-### Store your code in git-based cloud storage
-
-While baking code into Docker images is a popular deployment option, many teams store their workflow code in git-based 
-storage, such as GitHub, Bitbucket, or Gitlab.
-
-If you don't specify an `image` argument for `.deploy`, you must specify where to pull the flow code from at runtime 
-with the `from_source` method.
-
-Here's how to pull your flow code from a GitHub repository:
-
-```python git_storage.py
-from prefect import flow
-
-if __name__ == "__main__":
-    flow.from_source(
-        "https://github.com/my_github_account/my_repo/my_file.git",
-        entrypoint="flows/no-image.py:hello_world",
-    ).deploy(
-        name="no-image-deployment",
-        work_pool_name="my_pool",
-        build=False
-    )
-```
-
-The `entrypoint` is the path to the file the flow is located in and the function name, separated by a colon.
-
-Alternatively, you could specify a git-based cloud storage URL for a Bitbucket or Gitlab repository.
-
-<Note>
-    If you don't specify an image as part of your deployment creation, the image specified in the work pool 
-    runs your flow.
-</Note>
-
-After creating a deployment, you may need to change your flow code.
-Generally, you can just push your code to GitHub, without rebuilding your deployment.
-The exception is if there is something the server needs to know about changes, such as the flow entrypoint parameters.
-Rerunning the Python script with `.deploy` updates your deployment on the server with the new flow code.
-
-If you need to provide additional configuration, such as specifying a private repository, you can provide a 
-[`GitRepository`](https://prefect-python-sdk-docs.netlify.app/prefect/flows/#prefect.runner.storage.GitRepository) object instead of a URL:
-
-```python private_git_storage.py
-from prefect import flow
-from prefect.runner.storage import GitRepository
-from prefect.blocks.system import Secret
-
-if __name__ == "__main__":
-    flow.from_source(
-        source=GitRepository(
-        url="https://github.com/org/private-repo.git",
-        branch="dev",
-        credentials={
-            "access_token": Secret.load("github-access-token")
-        }
-    ),
-    entrypoint="flows/no-image.py:hello_world",
-    ).deploy(
-        name="private-git-storage-deployment",
-        work_pool_name="my_pool",
-        build=False
-    )
-```
-
-Note the use of the Secret block to load the GitHub access token.
-Alternatively, you could provide a username and password to the `username` and `password` fields of the `credentials` argument.
-
-### Store your code in cloud provider storage
-
-Another option for flow code storage is any [fsspec](https://filesystem-spec.readthedocs.io/en/latest/)-supported 
-storage location, such as AWS S3, GCP GCS, or Azure Blob Storage.
-
-For example, you can pass the S3 bucket path to `source`.
-
-```python s3_storage.py
-from prefect import flow
-
-if __name__ == "__main__":
-    flow.from_source(
-        source="s3://my-bucket/my-folder",
-        entrypoint="flows.py:my_flow",
-    ).deploy(
-        name="deployment-from-aws-flow",
-        work_pool_name="my_pool",
-    )
-```
-
-In the example above, your credentials are auto-discovered from your deployment creation environment. Your credentials 
-must be available in your runtime environment.
-
-If you need additional configuration for your cloud-based storage (for example, with a private S3 Bucket), we recommend using a 
-[storage block](/3.0rc/develop/blocks/).
-A storage block also ensures your credentials are available in both your deployment creation environment and your execution 
-environment.
-
-Here's an example that uses an `S3Bucket` block from the [prefect-aws library](https://prefecthq.github.io/prefect-aws/):
-
-```python s3_storage_auth.py
-from prefect import flow
-from prefect_aws.s3 import S3Bucket
-
-if __name__ == "__main__":
-    flow.from_source(
-        source=S3Bucket.load("my-code-storage"), entrypoint="my_file.py:my_flow"
-    ).deploy(name="test-s3", work_pool_name="my_pool")
-```
-
-The deployment creation mechanics or `.serve` are similar to `.deploy`. `.deploy` 
-just requires a work pool name and has a number of parameters dealing with flow code storage for Docker images.
-
-Unlike `.serve`, if you don't specify an image to use for your flow, you must to specify where to pull the flow code from at runtime  
-with the `from_source` method; `from_source` is optional with `.serve`.
-
-### Additional configuration with `.deploy`
-
-The examples so far have explored options for where to store flow code.
-Next, see deployment configuration options.
-
-To pass parameters to your flow, you can use the `parameters` argument in the `.deploy` method. Just pass in a dictionary of 
-key-value pairs.
-
-```python pass_params.py
-from prefect import flow
-
-@flow
-def hello_world(name: str):
-    print(f"Hello, {name}!")
-
-if __name__ == "__main__":
-    hello_world.deploy(
-        name="pass-params-deployment",
-        work_pool_name="my_pool",
-        parameters=dict(name="Prefect"),
-        image="my_registry/my_image:my_image_tag",
-    )
-```
-
-The `job_variables` parameter allows you to fine-tune the infrastructure settings for a deployment.
-The values passed in override default values in the specified work pool's 
-[base job template](/3.0rc/deploy/control-runs/work-pools/#base-job-template).
-
-You can override environment variables, such as `image_pull_policy` and `image`, for a specific deployment with the `job_variables` 
-argument.
-
-```python job_var_image_pull.py
-if __name__ == "__main__":
-    get_repo_info.deploy(
-        name="my-deployment-never-pull", 
-        work_pool_name="my-docker-pool", 
-        job_variables={"image_pull_policy": "Never"},
-        image="my-image:my-tag"",
-        push=False
-    )
-```
-
-Similarly, you can override the environment variables specified in a work pool through the `job_variables` parameter:
-
-```python job_var_env_vars.py
-if __name__ == "__main__":
-    get_repo_info.deploy(
-        name="my-deployment-never-pull", 
-        work_pool_name="my-docker-pool", 
-        job_variables={"env": {"EXTRA_PIP_PACKAGES": "boto3"} },
-        image="my-image:my-tag"",
-        push=False
-    )
-```
-
-The dictionary key "EXTRA_PIP_PACKAGES" denotes a special environment variable that Prefect uses to install additional 
-Python packages at runtime.
-This approach is an alternative to building an image with a custom `requirements.txt` copied into it.
-
-For more information on [overriding job variables](/3.0rc/deploy/dynamic-infra/customize).
-
-### Work with multiple deployments with `deploy`
-
-Create multiple deployments from one or more Python files that use `.deploy`.
-You can manage these deployments independently of one another to deploy the same flow with different configurations 
-in the same codebase.
-
-To create multiple work pool-based deployments at once, use the `deploy` function, which is analogous to the `serve` function:
-
-```python
-from prefect import deploy, flow
-
-@flow(log_prints=True)
-def buy():
-    print("Buying securities")
-
-
-if __name__ == "__main__":
-    deploy(
-        buy.to_deployment(name="dev-deploy", work_pool_name="my-dev-work-pool"),
-        buy.to_deployment(name="prod-deploy", work_pool_name="my-prod-work-pool"),
-        image="my-registry/my-image:dev",
-        push=False,
-    )
-```
-
-In the example above you created two deployments from the same flow, but with different work pools.
-Alternatively, you can create two deployments from different flows:
-
-```python
-from prefect import deploy, flow
-
-@flow(log_prints=True)
-def buy():
-    print("Buying securities.")
-
-@flow(log_prints=True)
-def sell():
-    print("Selling securities.")
-
-
-if __name__ == "__main__":
-    deploy(
-        buy.to_deployment(name="buy-deploy"),
-        sell.to_deployment(name="sell-deploy"),
-        work_pool_name="my-dev-work-pool"
-        image="my-registry/my-image:dev",
-        push=False,
-    )
-```
-
-In the example above, the code for both flows is baked into the same image.
-
-You can specify one or more flows to pull from a remote location at runtime with the `from_source` method.
-Here's an example of deploying two flows, one defined locally and one defined in a remote repository:
-
-```python
-from prefect import deploy, flow
-
-
-@flow(log_prints=True)
-def local_flow():
-    print("I'm a flow!")
-
-if __name__ == "__main__":
-    deploy(
-        local_flow.to_deployment(name="example-deploy-local-flow"),
-        flow.from_source(
-            source="https://github.com/org/repo.git",
-            entrypoint="flows.py:my_flow",
-        ).to_deployment(
-            name="example-deploy-remote-flow",
-        ),
-        work_pool_name="my-work-pool",
-        image="my-registry/my-image:dev",
-    )
-```
-
-You could pass any number of flows to the `deploy` function.
-This is useful if using a monorepo approach to your workflows.
-
-## Create work pool-based deployments with prefect.yaml
-
 The `prefect.yaml` file is a YAML file describing base settings for your deployments, procedural steps for preparing deployments, 
 and instructions for preparing the execution environment for a deployment run.
 
@@ -975,11 +421,7 @@ the `{{ build-image.image }}` variable is dynamically populated with the relevan
 <Note>
 **Docker step**
 
-    The most commonly used build step is 
-    [`prefect_docker.deployments.steps.build_docker_image`](/3.0rc/deploy/dynamic-infra/deploy-docker/) 
-    which produces both the `image_name` and `tag` fields.
-
-    For an example, check out [Deploy Docker](/3.0rc/deploy/dynamic-infra/deploy-docker/).
+The most commonly used build step is `prefect_docker.deployments.steps.build_docker_image` which produces both the `image_name` and `tag` fields.
 </Note>
 
 A `prefect.yaml` file can have multiple deployment configurations that control the behavior of several deployments.
@@ -1166,7 +608,7 @@ These are fields you can add to each deployment declaration.
 | `tags`                                     | A list of strings to assign to the deployment as tags.                                                                                                                                                                                                                                   |
 | <span class="no-wrap">`description`</span> | An optional description for the deployment.                                                                                                                                                                                                                                              |
 | `schedule`                                 | An optional [schedule](/3.0rc/automate/add-schedules) to assign to the deployment. Fields for this section are documented in the [Schedule Fields](#schedule-fields) section.                                                                                                                      |
-| `triggers`                                  | An optional array of [triggers](/3.0rc/deploy/serve-flows/#create-a-flow-run-with-an-event-trigger) to assign to the deployment |
+| `triggers`                                  | An optional array of [triggers](/3.0rc/automate/events/automations-triggers/#custom-triggers) to assign to the deployment |
 | `entrypoint`                               | Required path to the `.py` file containing the flow you want to deploy (relative to the root directory of your development folder) combined with the name of the flow function. In the format `path/to/file.py:flow_function_name`. |
 | `parameters`                               | Optional default values to provide for the parameters of the deployed flow. Should be an object with key/value pairs.                                                                                                                                                                    |
 | <span class="no-wrap">`enforce_parameter_schema`</span>                              | Boolean flag that determines whether the API should validate the parameters passed to a flow run against the parameter schema generated for the deployed flow.                                                                                                                                                                    |
@@ -1194,7 +636,7 @@ These are fields you can add to a deployment declaration's `work_pool` section.
 | ---------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | `name`                                         | The name of the work pool to schedule flow runs in for the deployment.                                                                                                                                    |
 | <span class="no-wrap">`work_queue_name`</span> | The name of the work queue within the specified work pool to schedule flow runs in for the deployment. If not provided, the default queue for the specified work pool is used.                       |
-| `job_variables`                                | Values used to override the default values in the specified work pool's [base job template](/3.0rc/deploy/control-runs/work-pools/#base-job-template). Maps directly to a created deployments `infra_overrides` attribute. |
+| `job_variables`                                | Values used to override the default values in the specified work pool's [base job template](/3.0rc/deploy/infrastructure-concepts/work-pools/#base-job-template). Maps directly to a created deployments `infra_overrides` attribute. |
 
 #### Deployment mechanics
 
@@ -1224,7 +666,7 @@ Each time a step runs, the following actions take place in order:
 
 Now that you are familiar with creating deployments, you can explore infrastructure options for running your deployments:
 
-- [Managed work pools](/3.0rc/deploy/control-runs/managed-execution/)
-- [Push work pools](/3.0rc/deploy/dynamic-infra/push-runs-serverless/)
-- [Kubernetes work pools](/3.0rc/deploy/dynamic-infra/deploy-kubernetes/)
-- [Serverless hybrid work pools](/3.0rc/deploy/dynamic-infra/push-runs-remote/)
+- [Managed work pools](/3.0rc/deploy/infrastructure-examples/managed/)
+- [Push work pools](/3.0rc/deploy/infrastructure-examples/serverless/)
+- [Kubernetes work pools](/3.0rc/deploy/infrastructure-examples/kubernetes/)
+- [Serverless hybrid work pools](/3.0rc/deploy/infrastructure-examples/docker/)
diff --git a/docs/3.0rc/deploy/dynamic-infra/retrieve-flow-code.mdx b/docs/3.0rc/deploy/infrastructure-concepts/store-flow-code.mdx
similarity index 96%
rename from docs/3.0rc/deploy/dynamic-infra/retrieve-flow-code.mdx
rename to docs/3.0rc/deploy/infrastructure-concepts/store-flow-code.mdx
index 4a41c70b8865..b868adb11964 100644
--- a/docs/3.0rc/deploy/dynamic-infra/retrieve-flow-code.mdx
+++ b/docs/3.0rc/deploy/infrastructure-concepts/store-flow-code.mdx
@@ -1,5 +1,5 @@
 ---
-title: Store flow code
+title: Retrieve code from storage
 description: Learn about where to store your flow code.
 ---
 
@@ -9,10 +9,9 @@ Flow code is not stored in a Prefect server instance or in Prefect Cloud.
 You have several flow code storage options.
 
 This guide focuses on deployments created with the interactive CLI experience or a prefect.yaml file. 
-To create deployments with Python code, see the [work pools and workers guide](/3.0rc/deploy/control-runs/prefect-deploy/#creating-work-pool-based-deployments-with-deploy).
+To create deployments with Python code, see the [work pools guide](/3.0rc/deploy/infrastructure-concepts/work-pools).
 
-
-## Option 1: Git-based storage
+## Git-based storage
 
 Git-based version control platforms provide redundancy, version control, and easier collaboration. Prefect supports:
 
@@ -20,7 +19,7 @@ Git-based version control platforms provide redundancy, version control, and eas
 - [GitLab](https://www.gitlab.com)
 - [Bitbucket](https://bitbucket.org/)
 
-### Create a deployment with git-based storage
+To create a deployment with git-based storage:
 
 1. Run `prefect deploy` from the root directory of the git repository
 1. Create a new deployment
@@ -151,14 +150,14 @@ You need to push your code manually or as part of your CI/CD pipeline.
 This is intentional to avoid confusion about the git history and push process.
 </Warning>
 
-## Option 2: Docker-based storage
+## Docker-based storage
 
 Another way to store your flow code is to include it in a Docker image. 
 All work pool options except Process and Prefect Managed work pools allow you to bake your code into a Docker image.
 
 1. Run `prefect init` in the root of your repository and choose `docker` for the project name. Answer the prompts to 
 create a `prefect.yaml` file with a build step that creates a Docker image with the flow code built in. 
-See the [Workers and Work Pools page of the tutorial](/3.0rc/deploy/dynamic-infra/push-runs-remote/) for more info.
+See the [Workers and Work Pools page of the tutorial](/3.0rc/deploy/infrastructure-examples/docker/) for more info.
 1. Run `prefect deploy` from the root of your repository to create a deployment.
 1. When a deployment runs, the worker pulls the Docker image and spins up a container.
 1. The flow code baked into the image runs inside the container.
@@ -170,7 +169,7 @@ You don't need push or pull steps in the `prefect.yaml` file if using CI/CD to b
 Instead, the work pool can reference the image directly.
 </Tip>
 
-## Option 3: Cloud-provider storage
+## Cloud-provider storage
 
 You can store your code in an AWS S3 bucket, Azure Blob Storage container, or GCP GCS bucket and specify the destination 
 directly in the `push` and `pull` steps of your `prefect.yaml` file.
@@ -290,7 +289,7 @@ Below are the recipe options and the relevant portions of the `prefect.yaml` fil
     </Tab>
 </Tabs>
 
-Another authentication option is to give the [worker](/3.0rc/deploy/control-runs/workers/) access 
+Another authentication option is to give the [worker](/3.0rc/deploy/infrastructure-concepts/workers/) access 
 to the storage location at runtime through SSH keys.
 
 Alternatively, you can inject environment variables into your deployment. See this example that uses an environment variable named 
diff --git a/docs/3.0rc/deploy/control-runs/work-pools.mdx b/docs/3.0rc/deploy/infrastructure-concepts/work-pools.mdx
similarity index 90%
rename from docs/3.0rc/deploy/control-runs/work-pools.mdx
rename to docs/3.0rc/deploy/infrastructure-concepts/work-pools.mdx
index b257c3d75644..cb77661fe737 100644
--- a/docs/3.0rc/deploy/control-runs/work-pools.mdx
+++ b/docs/3.0rc/deploy/infrastructure-concepts/work-pools.mdx
@@ -1,13 +1,13 @@
 ---
-title: Work pools
+title: Manage infrastructure with work pools
 description: Prefect work pools route deployment flow runs to workers.
 ---
 
 Work pools organize work for execution. Work pools have types corresponding to the infrastructure to execute the flow code, 
 as well as the delivery method of work to that environment. Pull work pools require workers to poll the work 
-pool for flow runs to execute. [Push work pools](/3.0rc/deploy/dynamic-infra/push-runs-serverless) submit runs directly to your 
+pool for flow runs to execute. [Push work pools](/3.0rc/deploy/infrastructure-examples/serverless) submit runs directly to your 
 serverless infrastructure providers such as Google Cloud Run, Azure Container Instances, and AWS ECS without the need for an agent or worker. 
-[Managed work pools](/3.0rc/deploy/control-runs/managed-execution) are administered by Prefect and handle the submission and execution of code on your behalf.
+[Managed work pools](/3.0rc/deploy/infrastructure-examples/managed) are administered by Prefect and handle the submission and execution of code on your behalf.
 
 <Tip>
 **Work pools are like pub/sub topics**
@@ -21,6 +21,62 @@ serverless infrastructure providers such as Google Cloud Run, Azure Container In
 Users can control aspects of work pool behavior, such as how many runs the pool allows to run concurrently. You can modify these options 
 at any time, and any workers requesting work for a specific pool only see matching flow runs.
 
+The following diagram provides a high-level overview of the conceptual elements involved in defining a work-pool based 
+deployment that is polled by a worker and executes a flow run based on that deployment.
+
+```mermaid
+%%{
+  init: {
+    'theme': 'base',
+    'themeVariables': {
+      'fontSize': '19px'
+    }
+  }
+}%%
+
+flowchart LR
+    F("<div style='margin: 5px 10px 5px 5px;'>Flow Code</div>"):::yellow -.-> A("<div style='margin: 5px 10px 5px 5px;'>Deployment Definition</div>"):::gold
+    subgraph Server ["<div style='width: 150px; text-align: center; margin-top: 5px;'>Prefect API</div>"]
+        D("<div style='margin: 5px 10px 5px 5px;'>Deployment</div>"):::green
+    end
+    subgraph Remote Storage ["<div style='width: 160px; text-align: center; margin-top: 5px;'>Remote Storage</div>"]
+        B("<div style='margin: 5px 6px 5px 5px;'>Flow</div>"):::yellow
+    end
+    subgraph Infrastructure ["<div style='width: 150px; text-align: center; margin-top: 5px;'>Infrastructure</div>"]
+        G("<div style='margin: 5px 10px 5px 5px;'>Flow Run</div>"):::blue
+    end
+
+    A --> D
+    D --> E("<div style='margin: 5px 10px 5px 5px;'>Worker</div>"):::red
+    B -.-> E
+    A -.-> B
+    E -.-> G
+
+    classDef gold fill:goldenrod,stroke:goldenrod,stroke-width:4px,color:black
+    classDef yellow fill:gold,stroke:gold,stroke-width:4px,color:black
+    classDef gray fill:lightgray,stroke:lightgray,stroke-width:4px
+    classDef blue fill:blue,stroke:blue,stroke-width:4px,color:white
+    classDef green fill:green,stroke:green,stroke-width:4px,color:white
+    classDef red fill:red,stroke:red,stroke-width:4px,color:white
+    classDef dkgray fill:darkgray,stroke:darkgray,stroke-width:4px,color:white
+```
+
+Work pool-based deployments that use a worker also allow you to assign a work queue name to prioritize work 
+and allow you to limit concurrent runs at the work pool level.
+
+When creating a deployment that uses a work pool and worker, there are two important considerations:
+
+- What instructions does a [worker](/3.0rc/deploy/infrastructure-concepts/workers/) require to set up an execution environment for your flow? 
+For example, a flow may have Python package requirements, unique Kubernetes settings, or Docker networking configuration.
+- How should the flow code be accessed?
+
+[Serve flows](/3.0rc/deploy/run-flows-in-local-processes/) shows how to create a deployment with a long-running process using `.serve`, 
+and how to move to a [work pool deployment](/3.0rc/deploy/infrastructure-examples/docker/) setup with `.deploy`.
+Learn more about when to move to [work pool deployments](#benefits-of-work-pools).
+
+Next, you'll learn how to use `.deploy` to create deployments with Python code.
+If you prefer to learn about using a YAML-based alternative for managing deployment configuration, skip to [Create deployments with YAML](/3.0rc/deploy/infrastructure-concepts/prefect-yaml).
+
 ### Work pool configuration
 
 You can configure work pools by using any of the following:
@@ -269,7 +325,7 @@ deployments:
         stream_output: false
 ```
 
-Learn more about [overriding job variables](/3.0rc/deploy/dynamic-infra/customize).
+Learn more about [overriding job variables](/3.0rc/deploy/infrastructure-concepts/customize).
 
 <Tip>
 **Advanced customization of the base job template**
@@ -286,7 +342,7 @@ Learn more about [overriding job variables](/3.0rc/deploy/dynamic-infra/customiz
     For more information and advanced configuration examples, see the [Kubernetes Worker](https://prefecthq.github.io/prefect-kubernetes/worker/) 
     documentation.
 
-    See more information about [overriding a work pool's job variables](/3.0rc/deploy/dynamic-infra/customize).
+    See more information about [overriding a work pool's job variables](/3.0rc/deploy/infrastructure-concepts/customize).
 </Tip>
 
 ### View work pools
@@ -457,7 +513,7 @@ Work pools are a bridge between the Prefect orchestration layer and infrastructu
 To transition from persistent infrastructure to dynamic infrastructure, use `flow.deploy` instead of `flow.serve`.
 
 <Tip>
-    **[Choosing Between `flow.deploy()` and `flow.serve()`](/3.0rc/deploy/serve-flows/#two-approaches-to-deployments)**
+    **Choosing Between `flow.deploy()` and `flow.serve()`**
 
     For many use cases, `serve` is sufficient for scheduling and orchestration.
     Work pools are great for complex infrastructure requirements. But they are optional.
@@ -480,9 +536,9 @@ Other advantages of work pools:
 
 - Configure default infrastructure configurations on your work pools that all jobs inherit and can override.
 - Allow platform teams to use work pools to expose opinionated (and enforced) interfaces to the infrastructure that they oversee.
-- Allow work pools to prioritize (or limit) flow runs through the use of [work queues](/3.0rc/deploy/control-runs/work-pools/#work-queues).
+- Allow work pools to prioritize (or limit) flow runs through the use of [work queues](/3.0rc/deploy/infrastructure-concepts/work-pools/#work-queues).
 
-Prefect provides several [types of work pools](/3.0rc/deploy/control-runs/work-pools/#work-pool-types).
+Prefect provides several [types of work pools](/3.0rc/deploy/infrastructure-concepts/work-pools/#work-pool-types).
 Prefect Cloud provides a Prefect Managed work pool option that is the simplest way to run workflows remotely.
 A cloud-provider account, such as AWS, is not required with a Prefect Managed work pool.
 
@@ -624,7 +680,7 @@ prefect deployment run 'get_repo_info/my-deployment'
 ```
 
 Prefect Managed work pools are a great way to get started with Prefect.  
-See the [Managed Execution guide](/3.0rc/deploy/control-runs/managed-execution) for more details.
+See the [Managed Execution guide](/3.0rc/deploy/infrastructure-examples/managed) for more details.
 
 For more control over the infrastructure that your flows run on, we recommend Prefect Cloud's push work pools.
 
@@ -747,9 +803,9 @@ Otherwise, you can pass `image="my-image:latest"` to `deploy`.
 The `cron` argument schedules the deployment to run at 1:00 AM every day.
 See the [schedules](/3.0rc/automate/add-schedules/) guide for more information on scheduling options.
 
-See the [Push Work Pool guide](/3.0rc/deploy/dynamic-infra/push-runs-serverless/) for more details and example commands for each 
+See the [Push Work Pool guide](/3.0rc/deploy/infrastructure-examples/serverless/) for more details and example commands for each 
 cloud provider.
 
 If you need more control over your infrastructure, want to run your workflows in Kubernetes, or are running a self-hosted Prefect 
-server instance, see the Workers [guide](/3.0rc/deploy/dynamic-infra/push-runs-remote/). You will learn how 
+server instance, see the Workers [guide](/3.0rc/deploy/infrastructure-examples/docker/). You will learn how 
 to use work pools that rely on a worker and customize Docker images for container-based infrastructure.
diff --git a/docs/3.0rc/deploy/control-runs/workers.mdx b/docs/3.0rc/deploy/infrastructure-concepts/workers.mdx
similarity index 84%
rename from docs/3.0rc/deploy/control-runs/workers.mdx
rename to docs/3.0rc/deploy/infrastructure-concepts/workers.mdx
index ac0db4744d45..827d8ade967e 100644
--- a/docs/3.0rc/deploy/control-runs/workers.mdx
+++ b/docs/3.0rc/deploy/infrastructure-concepts/workers.mdx
@@ -1,13 +1,41 @@
 ---
-title: Workers
+title: Learn about workers
 description: Prefect workers poll work pools for new runs to execute.
 ---
 
 Workers are lightweight polling services that retrieve scheduled runs from a work pool and execute them.
 
-Workers each have a type corresponding to the execution environment to submit flow runs to. Workers can only poll 
-work pools that match their type. As a result, when deployments are assigned to a work pool, you know in which execution environment 
-scheduled flow runs for that deployment will run.
+Workers each have a type corresponding to the execution environment to submit flow runs to.
+Workers can only poll work pools that match their type.
+As a result, when deployments are assigned to a work pool, you know in which execution environment scheduled flow runs for that deployment will run.
+
+The following diagram summarizes the architecture of a worker-based work pool deployment:
+
+```mermaid
+graph TD
+    subgraph your_infra["Your Execution Environment"]
+        worker["Worker"]
+    subgraph flow_run_infra[Flow Run Infra]
+     flow_run_a(("Flow Run A"))
+    end
+    subgraph flow_run_infra_2[Flow Run Infra]
+     flow_run_b(("Flow Run B"))
+    end      
+    end
+
+    subgraph api["Prefect API"]
+    Deployment --> |assigned to| work_pool
+        work_pool(["Work Pool"])
+    end
+
+    worker --> |polls| work_pool
+    worker --> |creates| flow_run_infra
+    worker --> |creates| flow_run_infra_2
+```
+
+<Tip>
+Notice above that the worker is in charge of provisioning the _flow run infrastructure_.
+</Tip>
 
 ### Worker types
 
@@ -28,10 +56,10 @@ If you don’t see a worker type that meets your needs, consider
 
 ### Worker options
 
-Workers poll for work from one or more queues within a work pool. If the worker references a work queue that doesn't exist, 
-it is created automatically. The worker CLI infers the worker type from the work pool. Alternatively, you can  
-specify the worker type explicitly. If you supply the worker type to the worker CLI, a work pool is created automatically 
-if it doesn't exist (using default job settings).
+Workers poll for work from one or more queues within a work pool. If the worker references a work queue that doesn't exist, it is created automatically.
+The worker CLI infers the worker type from the work pool.
+Alternatively, you can specify the worker type explicitly.
+If you supply the worker type to the worker CLI, a work pool is created automatically if it doesn't exist (using default job settings).
 
 Configuration parameters you can specify when starting a worker include:
 
@@ -140,8 +168,8 @@ If `prefect worker start` is run non-interactively, the `prompt` install policy
 
 ### Additional resources
 
-See how to [daemonize a Prefect worker](/3.0rc/deploy/dynamic-infra/push-runs-remote/).
+See how to [daemonize a Prefect worker](/3.0rc/resources/daemonize-processes/).
 
-See more information on [overriding a work pool's job variables](/3.0rc/deploy/dynamic-infra/customize).
+See more information on [overriding a work pool's job variables](/3.0rc/deploy/infrastructure-concepts/customize).
 
 ---------
diff --git a/docs/3.0rc/deploy/infrastructure-examples/docker.mdx b/docs/3.0rc/deploy/infrastructure-examples/docker.mdx
new file mode 100644
index 000000000000..ba1062b0d352
--- /dev/null
+++ b/docs/3.0rc/deploy/infrastructure-examples/docker.mdx
@@ -0,0 +1,500 @@
+---
+title: Run flows in Docker containers
+description: Learn how to deploy a flow to a Docker work pool with workers
+---
+
+In this tutorial, you will create a work pool and worker to deploy your tutorial flow, and then execute it with the Prefect API.
+You must have [Docker](https://docs.docker.com/engine/install/) installed and running on your machine.
+
+### Create a work pool
+
+To set up a **Docker** type work pool, run:
+
+```bash
+prefect work-pool create --type docker my-docker-pool
+```
+
+To confirm the work pool creation was successful, run:
+
+```bash
+prefect work-pool ls
+```
+
+You should see your new `my-docker-pool` listed in the output.
+
+Next, check that you can see this work pool in your Prefect UI.
+Navigate to the **Work Pools** tab and verify that you see `my-docker-pool` listed.
+When you click into `my-docker-pool`, you should see a red status icon signifying that this work pool is not ready.
+
+To make the work pool ready, you'll need to start a worker.
+We'll show how to do this next.
+
+### Start a worker
+
+Workers are a lightweight polling process that kick off scheduled flow runs on a specific type of infrastructure (such as Docker).
+To start a worker on your local machine, open a new terminal and confirm that your virtual environment has `prefect` installed.
+
+Run the following command in this new terminal to start the worker:
+
+
+```bash
+prefect worker start --pool my-docker-pool
+```
+
+You should see the worker start.
+It's now polling the Prefect API to check for any scheduled flow runs it should pick up and then submit for execution.
+You’ll see your new worker listed in the UI under the **Workers** tab of the Work Pools page with a recent last polled date.
+The work pool should have a `Ready` status indicator.
+
+Keep this terminal session active for the worker to continue to pick up jobs.
+Since you are running this worker locally, the worker will terminate if you close the terminal.
+In a production setting this worker should run as a [daemonized or managed process](/3.0rc/resources/daemonize-processes/).
+
+## Create the deployment
+
+From the previous steps, you now have:
+
+- A work pool
+- A worker
+
+Next, you'll create a deployment from your flow code.
+
+### Automatically bake your code into a Docker image
+
+Create a deployment from Python code by calling the `.deploy` method on a flow:
+
+```python buy.py
+from prefect import flow
+
+@flow(log_prints=True)
+def buy():
+    print("Buying securities")
+
+if __name__ == "__main__":
+    buy.deploy(
+        name="my-code-baked-into-an-image-deployment", 
+        work_pool_name="my-docker-pool", 
+        image="my_registry/my_image:my_image_tag"
+    )
+```
+
+Now, run the script to create a deployment (in future examples this step is omitted for brevity):
+
+```bash
+python buy.py
+```
+
+You should see messages in your terminal that Docker is building your image.
+When the deployment build succeeds, you will see information in your terminal showing you how to start a worker for your 
+deployment, and how to run your deployment.
+Your deployment is visible on the `Deployments` page in the UI.
+
+By default, `.deploy` builds a Docker image with your flow code baked into it and pushes the image to the 
+[Docker Hub](https://hub.docker.com/) registry specified in the `image` argument`.
+
+<Note>
+**Authentication to Docker Hub**
+
+    Your environment must be authenticated to your Docker registry to push an image to it.
+</Note>
+
+You can specify a registry other than Docker Hub by providing the full registry path in the `image` argument.
+
+<Warning>
+    If building a Docker image, your environment with your deployment needs Docker installed and running.
+</Warning>
+
+To avoid pushing to a registry, set `push=False` in the `.deploy` method:
+
+```python
+
+if __name__ == "__main__":
+    buy.deploy(
+        name="my-code-baked-into-an-image-deployment", 
+        work_pool_name="my-docker-pool", 
+        image="my_registry/my_image:my_image_tag",
+        push=False
+    )
+```
+
+To avoid building an image, set `build=False` in the `.deploy` method:
+
+```python
+
+if __name__ == "__main__":
+    buy.deploy(
+        name="my-code-baked-into-an-image-deployment", 
+        work_pool_name="my-docker-pool", 
+        image="my_registry/no-build-image:1.0",
+        build=False
+    )
+```
+
+The specified image must be available in your deployment's execution environment for accessible flow code.
+
+Prefect generates a Dockerfile for you that builds an image based off of one of Prefect's published images. 
+The generated Dockerfile copies the current directory into the Docker image and installs any dependencies listed 
+in a `requirements.txt` file.
+
+### Automatically build a custom Docker image with a local Dockerfile
+
+If you want to use a custom Dockerfile, specify the path to the Dockerfile with the `DockerImage` class:
+
+```python custom_dockerfile.py
+from prefect import flow
+from prefect.docker import DockerImage
+
+
+@flow(log_prints=True)
+def buy():
+    print("Selling securities")
+
+
+if __name__ == "__main__":
+    buy.deploy(
+        name="my-custom-dockerfile-deployment", 
+        work_pool_name="my-docker-pool", 
+        image=DockerImage(
+            name="my_image",
+            tag="deploy-guide",
+            dockerfile="Dockerfile"
+    ),
+    push=False
+)
+
+```
+
+The `DockerImage` object enables image customization.
+
+For example, you can install a private Python package from GCP's artifact registry like this:
+
+1. Create a custom base Dockerfile.
+
+   ```
+   FROM python:3.10
+
+   ARG AUTHED_ARTIFACT_REG_URL
+   COPY ./requirements.txt /requirements.txt
+
+   RUN pip install --extra-index-url ${AUTHED_ARTIFACT_REG_URL} -r /requirements.txt
+   ```
+
+1. Create your deployment with the DockerImage class:
+
+   ```python private-package.py
+   from prefect import flow
+   from prefect.deployments.runner import DockerImage
+   from prefect.blocks.system import Secret
+   from my_private_package import do_something_cool
+
+
+   @flow(log_prints=True)
+   def my_flow():
+       do_something_cool()
+
+
+   if __name__ == "__main__":
+       artifact_reg_url: Secret = Secret.load("artifact-reg-url")
+    
+       my_flow.deploy(
+           name="my-deployment",
+           work_pool_name="my-docker-pool",
+           image=DockerImage(
+               name="my-image",
+               tag="test",
+               dockerfile="Dockerfile",
+               buildargs={"AUTHED_ARTIFACT_REG_URL": artifact_reg_url.get()},
+           ),
+       )
+   ```
+
+Note that you used a [Prefect Secret block](/3.0rc/develop/blocks/) to load the URL configuration for 
+the artifact registry above.
+
+See all the optional keyword arguments for the [DockerImage class](https://docker-py.readthedocs.io/en/stable/images.html#docker.models.images.ImageCollection.build).
+
+<Tip>
+**Default Docker namespace**
+
+    You can set the `PREFECT_DEFAULT_DOCKER_BUILD_NAMESPACE` setting to append a default Docker namespace to all images 
+    you build with `.deploy`. This is helpful if you use a private registry to store your images.
+
+    To set a default Docker namespace for your current profile run:
+
+    ```bash
+    prefect config set PREFECT_DEFAULT_DOCKER_BUILD_NAMESPACE=<docker-registry-url>/<organization-or-username>
+    ```
+
+    Once set, you can omit the namespace from your image name when creating a deployment:
+
+    ```python with_default_docker_namespace.py
+    if __name__ == "__main__":
+        buy.deploy(
+            name="my-code-baked-into-an-image-deployment", 
+            work_pool_name="my-docker-pool", 
+            image="my_image:my_image_tag"
+        )
+    ```
+
+    The above code builds an image with the format `<docker-registry-url>/<organization-or-username>/my_image:my_image_tag` 
+    when `PREFECT_DEFAULT_DOCKER_BUILD_NAMESPACE` is set.
+</Tip>
+
+### Store your code in git-based cloud storage
+
+While baking code into Docker images is a popular deployment option, many teams store their workflow code in git-based 
+storage, such as GitHub, Bitbucket, or GitLab.
+
+If you don't specify an `image` argument for `.deploy`, you must specify where to pull the flow code from at runtime 
+with the `from_source` method.
+
+Here's how to pull your flow code from a GitHub repository:
+
+```python git_storage.py
+from prefect import flow
+
+if __name__ == "__main__":
+    flow.from_source(
+        "https://github.com/my_github_account/my_repo/my_file.git",
+        entrypoint="flows/no-image.py:hello_world",
+    ).deploy(
+        name="no-image-deployment",
+        work_pool_name="my-docker-pool",
+        build=False
+    )
+```
+
+The `entrypoint` is the path to the file the flow is located in and the function name, separated by a colon.
+
+Alternatively, you could specify a git-based cloud storage URL for a Bitbucket or GitLab repository.
+
+<Note>
+    If you don't specify an image as part of your deployment creation, the image specified in the work pool 
+    runs your flow.
+</Note>
+
+After creating a deployment, you may need to change your flow code.
+Generally, you can just push your code to GitHub, without rebuilding your deployment.
+The exception is if there is something the server needs to know about changes, such as the flow entrypoint parameters.
+Rerunning the Python script with `.deploy` updates your deployment on the server with the new flow code.
+
+If you need to provide additional configuration, such as specifying a private repository, you can provide a 
+[`GitRepository`](https://prefect-python-sdk-docs.netlify.app/prefect/flows/#prefect.runner.storage.GitRepository) object instead of a URL:
+
+```python private_git_storage.py
+from prefect import flow
+from prefect.runner.storage import GitRepository
+from prefect.blocks.system import Secret
+
+if __name__ == "__main__":
+    flow.from_source(
+        source=GitRepository(
+            url="https://github.com/org/private-repo.git",
+            branch="dev",
+            credentials={
+                "access_token": Secret.load("github-access-token")
+            }
+        ),
+        entrypoint="flows/no-image.py:hello_world",
+    ).deploy(
+        name="private-git-storage-deployment",
+        work_pool_name="my-docker-pool",
+        build=False
+    )
+```
+
+Note the use of the Secret block to load the GitHub access token.
+Alternatively, you could provide a username and password to the `username` and `password` fields of the `credentials` argument.
+
+### Store your code in cloud provider storage
+
+Another option for flow code storage is any [fsspec](https://filesystem-spec.readthedocs.io/en/latest/)-supported 
+storage location, such as AWS S3, GCP GCS, or Azure Blob Storage.
+
+For example, you can pass the S3 bucket path to `source`.
+
+```python s3_storage.py
+from prefect import flow
+
+if __name__ == "__main__":
+    flow.from_source(
+        source="s3://my-bucket/my-folder",
+        entrypoint="flows.py:my_flow",
+    ).deploy(
+        name="deployment-from-aws-flow",
+        work_pool_name="my-docker-pool",
+    )
+```
+
+In the example above, your credentials are auto-discovered from your deployment creation environment. Your credentials 
+must be available in your runtime environment.
+
+If you need additional configuration for your cloud-based storage (for example, with a private S3 Bucket), we recommend using a 
+[storage block](/3.0rc/develop/blocks/).
+A storage block also ensures your credentials are available in both your deployment creation environment and your execution 
+environment.
+
+Here's an example that uses an `S3Bucket` block from the [prefect-aws library](https://prefecthq.github.io/prefect-aws/):
+
+```python s3_storage_auth.py
+from prefect import flow
+from prefect_aws.s3 import S3Bucket
+
+if __name__ == "__main__":
+    flow.from_source(
+        source=S3Bucket.load("my-code-storage"), entrypoint="my_file.py:my_flow"
+    ).deploy(name="test-s3", work_pool_name="my-docker-pool")
+```
+
+The deployment creation mechanics or `.serve` are similar to `.deploy`. `.deploy` 
+just requires a work pool name and has a number of parameters dealing with flow code storage for Docker images.
+
+Unlike `.serve`, if you don't specify an image to use for your flow, you must to specify where to pull the flow code from at runtime with the `from_source` method; `from_source` is optional with `.serve`.
+
+### Additional configuration with `.deploy`
+
+The examples so far have explored options for where to store flow code.
+Next, see deployment configuration options.
+
+To pass parameters to your flow, you can use the `parameters` argument in the `.deploy` method. Just pass in a dictionary of 
+key-value pairs.
+
+```python pass_params.py
+from prefect import flow
+
+@flow
+def hello_world(name: str):
+    print(f"Hello, {name}!")
+
+if __name__ == "__main__":
+    hello_world.deploy(
+        name="pass-params-deployment",
+        work_pool_name="my-docker-pool",
+        parameters=dict(name="Prefect"),
+        image="my_registry/my_image:my_image_tag",
+    )
+```
+
+The `job_variables` parameter allows you to fine-tune the infrastructure settings for a deployment.
+The values passed in override default values in the specified work pool's 
+[base job template](/3.0rc/deploy/infrastructure-concepts/work-pools/#base-job-template).
+
+You can override environment variables, such as `image_pull_policy` and `image`, for a specific deployment with the `job_variables` 
+argument.
+
+```python job_var_image_pull.py
+if __name__ == "__main__":
+    get_repo_info.deploy(
+        name="my-deployment-never-pull", 
+        work_pool_name="my-docker-pool", 
+        job_variables={"image_pull_policy": "Never"},
+        image="my-image:my-tag"",
+        push=False
+    )
+```
+
+Similarly, you can override the environment variables specified in a work pool through the `job_variables` parameter:
+
+```python job_var_env_vars.py
+if __name__ == "__main__":
+    get_repo_info.deploy(
+        name="my-deployment-never-pull", 
+        work_pool_name="my-docker-pool", 
+        job_variables={"env": {"EXTRA_PIP_PACKAGES": "boto3"} },
+        image="my-image:my-tag"",
+        push=False
+    )
+```
+
+The dictionary key "EXTRA_PIP_PACKAGES" denotes a special environment variable that Prefect uses to install additional 
+Python packages at runtime.
+This approach is an alternative to building an image with a custom `requirements.txt` copied into it.
+
+See [Override work pool job variables](/3.0rc/deploy/infrastructure-concepts/customize) for more information about how to customize these variables.
+
+### Work with multiple deployments with `deploy`
+
+Create multiple deployments from one or more Python files that use `.deploy`.
+You can manage these deployments independently of one another to deploy the same flow with different configurations 
+in the same codebase.
+
+To create multiple work pool-based deployments at once, use the `deploy` function, which is analogous to the `serve` function:
+
+```python
+from prefect import deploy, flow
+
+@flow(log_prints=True)
+def buy():
+    print("Buying securities")
+
+
+if __name__ == "__main__":
+    deploy(
+        buy.to_deployment(name="dev-deploy", work_pool_name="my-docker-pool"),
+        buy.to_deployment(name="prod-deploy", work_pool_name="my-docker-pool"),
+        image="my-registry/my-image:dev",
+        push=False,
+    )
+```
+
+In the example above you created two deployments from the same flow, but with different work pools.
+Alternatively, you can create two deployments from different flows:
+
+```python
+from prefect import deploy, flow
+
+@flow(log_prints=True)
+def buy():
+    print("Buying securities.")
+
+@flow(log_prints=True)
+def sell():
+    print("Selling securities.")
+
+
+if __name__ == "__main__":
+    deploy(
+        buy.to_deployment(name="buy-deploy"),
+        sell.to_deployment(name="sell-deploy"),
+        work_pool_name="my-docker-pool"
+        image="my-registry/my-image:dev",
+        push=False,
+    )
+```
+
+In the example above, the code for both flows is baked into the same image.
+
+You can specify one or more flows to pull from a remote location at runtime with the `from_source` method.
+Here's an example of deploying two flows, one defined locally and one defined in a remote repository:
+
+```python
+from prefect import deploy, flow
+
+
+@flow(log_prints=True)
+def local_flow():
+    print("I'm a flow!")
+
+if __name__ == "__main__":
+    deploy(
+        local_flow.to_deployment(name="example-deploy-local-flow"),
+        flow.from_source(
+            source="https://github.com/org/repo.git",
+            entrypoint="flows.py:my_flow",
+        ).to_deployment(
+            name="example-deploy-remote-flow",
+        ),
+        work_pool_name="my-docker-pool",
+        image="my-registry/my-image:dev",
+    )
+```
+
+You can pass any number of flows to the `deploy` function.
+This is useful if using a monorepo approach to your workflows.
+
+## Learn more
+
+- [Deploy flows on Kubernetes](/3.0rc/deploy/infrastructure-examples/kubernetes/)
+- [Deploy flows in Docker](/3.0rc/deploy/infrastructure-examples/docker/)
+- [Deploy flows on serverless infrastructure](/3.0rc/deploy/infrastructure-examples/serverless/)
+- [Daemonize workers](/3.0rc/resources/daemonize-processes/)
\ No newline at end of file
diff --git a/docs/3.0rc/deploy/dynamic-infra/deploy-kubernetes.mdx b/docs/3.0rc/deploy/infrastructure-examples/kubernetes.mdx
similarity index 98%
rename from docs/3.0rc/deploy/dynamic-infra/deploy-kubernetes.mdx
rename to docs/3.0rc/deploy/infrastructure-examples/kubernetes.mdx
index 95840782ab8c..3bcd92589b22 100644
--- a/docs/3.0rc/deploy/dynamic-infra/deploy-kubernetes.mdx
+++ b/docs/3.0rc/deploy/infrastructure-examples/kubernetes.mdx
@@ -1,5 +1,5 @@
 ---
-title: Run flows with Kubernetes
+title: Run flows on Kubernetes
 description: Learn how to run flows on Kubernetes using containers.
 ---
 
@@ -183,7 +183,7 @@ If you already have a registry, skip ahead to the next section.
 
 ## Create a Kubernetes work pool
 
-[Work pools](3.0rc/deploy/control-runs/work-pools/) allow you to manage deployment 
+[Work pools](3.0rc/deploy/infrastructure-concepts/work-pools/) allow you to manage deployment 
 infrastructure.
 This section shows you how to configure the default values for your 
 Kubernetes base job template.
@@ -407,9 +407,9 @@ The `prefect.yaml` file currently allows for more customization in terms of push
 steps.
 
 To learn about the Python deployment creation method with `flow.deploy` see 
-[Workers](/3.0rc/deploy/dynamic-infra/push-runs-remote/).
+[Workers](/3.0rc/deploy/infrastructure-examples/docker/).
 
-The [`prefect.yaml`](/3.0rc/deploy/serve-flows/#managing-deployments) file is used 
+The [`prefect.yaml`](/3.0rc/deploy/infrastructure-concepts/prefect-yaml/#managing-deployments) file is used 
 by the `prefect deploy` command to deploy your flows.
 As a part of that process it also builds and pushes your image.
 Create a new file named `prefect.yaml` with the following contents:
diff --git a/docs/3.0rc/deploy/control-runs/managed-execution.mdx b/docs/3.0rc/deploy/infrastructure-examples/managed.mdx
similarity index 64%
rename from docs/3.0rc/deploy/control-runs/managed-execution.mdx
rename to docs/3.0rc/deploy/infrastructure-examples/managed.mdx
index efbaf514cd5e..6e253a5a5f6b 100644
--- a/docs/3.0rc/deploy/control-runs/managed-execution.mdx
+++ b/docs/3.0rc/deploy/infrastructure-examples/managed.mdx
@@ -1,5 +1,5 @@
 ---
-title: Managed execution
+title: Run flows on Prefect Managed infra
 description: Learn how Prefect will run your deployment on our infrastructure.
 ---
 Prefect Cloud can run your flows on your behalf with Prefect Managed work pools.
@@ -8,55 +8,42 @@ account—Prefect handles the infrastructure and code execution for you.
 
 Managed execution is a great option for users who want to get started quickly, with no infrastructure setup.
 
-## Usage guide
+## Create a managed deployment
 
-Run a flow with managed infrastructure in three steps.
+1. Create a new work pool of type Prefect Managed in the UI or the CLI.
+   Use this command to create a new work pool using the CLI:
 
-### Step 1: Create a new work pool
+   ```bash
+   prefect work-pool create my-managed-pool --type prefect:managed
+   ```
 
-Create a new work pool of type Prefect Managed in the UI or the CLI.
-Use this command to create a new work pool using the CLI:
+1. Create a deployment using the flow `deploy` method or `prefect.yaml`.
+   Specify the name of your managed work pool, as shown in this example that uses the `deploy` method:
 
-```bash
-prefect work-pool create my-managed-pool --type prefect:managed
-```
-
-### Step 2: Create a deployment
-
-Create a deployment using the flow `deploy` method or `prefect.yaml`.
-
-Specify the name of your managed work pool, as shown in this example that uses the `deploy` method:
-
-```python managed-execution.py
-from prefect import flow
-
-if __name__ == "__main__":
-    flow.from_source(
-    source="https://github.com/prefecthq/demo.git",
-    entrypoint="flow.py:my_flow",
-    ).deploy(
-        name="test-managed-flow",
-        work_pool_name="my-managed-pool",
-    )
-```
+   ```python managed-execution.py
+   from prefect import flow
 
-With your [CLI authenticated to your Prefect Cloud workspace](/3.0rc/manage/cloud/manage-users/api-keys/), 
-run the script to create your deployment:
-
-```bash
-python managed-execution.py
-```
+   if __name__ == "__main__":
+       flow.from_source(
+           source="https://github.com/prefecthq/demo.git",
+           entrypoint="flow.py:my_flow",
+       ).deploy(
+           name="test-managed-flow",
+           work_pool_name="my-managed-pool",
+       )
+   ```
 
-Note that this deployment uses flow code stored in a GitHub repository.
+1. With your [CLI authenticated to your Prefect Cloud workspace](/3.0rc/manage/cloud/manage-users/api-keys/), run the script to create your deployment:
 
-### Step 3: Run the deployment
+   ```bash
+   python managed-execution.py
+   ```
 
-Run the deployment from the UI or from the CLI.
+1. Run the deployment from the UI or from the CLI.
 
-This process runs a flow on remote infrastructure without any infrastructure setup, starting a worker, 
-or requiring a cloud provider account.
+   This process runs a flow on remote infrastructure without any infrastructure setup, starting a worker, or requiring a cloud provider account.
 
-### Add dependencies
+## Add dependencies
 
 Prefect can install Python packages in the container that runs your flow at runtime.
 Specify these dependencies in the **Pip Packages** field in the UI, or by configuring 
@@ -67,8 +54,8 @@ from prefect import flow
 
 if __name__ == "__main__":
     flow.from_source(
-    source="https://github.com/prefecthq/demo.git",
-    entrypoint="flow.py:my_flow",
+        source="https://github.com/prefecthq/demo.git",
+        entrypoint="flow.py:my_flow",
     ).deploy(
         name="test-managed-flow",
         work_pool_name="my-managed-pool",
@@ -119,8 +106,8 @@ You can view your compute hours quota usage on the **Work Pools** page in the UI
 
 ## Next steps
 
-Read more about creating deployments in the [deployment guide](/3.0rc/deploy/control-runs/prefect-deploy/).
+Read more about creating deployments in the [deployment guide](/3.0rc/deploy/infrastructure-examples/docker/).
 
 For more control over your infrastructure, such as the ability to run 
-custom Docker images, [serverless push work pools](/3.0rc/deploy/dynamic-infra/push-runs-serverless/) 
+custom Docker images, [serverless push work pools](/3.0rc/deploy/infrastructure-examples/serverless/) 
 are also a good option.
\ No newline at end of file
diff --git a/docs/3.0rc/deploy/dynamic-infra/push-runs-serverless.mdx b/docs/3.0rc/deploy/infrastructure-examples/serverless.mdx
similarity index 97%
rename from docs/3.0rc/deploy/dynamic-infra/push-runs-serverless.mdx
rename to docs/3.0rc/deploy/infrastructure-examples/serverless.mdx
index ed2e4d5b132b..668208906ec0 100644
--- a/docs/3.0rc/deploy/dynamic-infra/push-runs-serverless.mdx
+++ b/docs/3.0rc/deploy/infrastructure-examples/serverless.mdx
@@ -1,9 +1,9 @@
 ---
-title: Push work to serverless computing infrastructure
+title: Run flows on serverless infra
 description: Learn how to use Prefect push work pools to schedule work on serverless infrastructure without having to run a worker.
 ---
 
-Push [work pools](/3.0rc/deploy/control-runs/work-pools/) are a special type of work pool. They allow 
+Push [work pools](/3.0rc/deploy/infrastructure-concepts/work-pools/) are a special type of work pool. They allow 
 Prefect Cloud to submit flow runs for execution to serverless computing infrastructure without requiring you to run a worker.
 Push work pools currently support execution in AWS ECS tasks, Azure Container Instances, Google Cloud Run jobs, and Modal.
 
@@ -617,7 +617,7 @@ Click **Create** to configure your push work pool by selecting a push option in
   <Tab title="AWS ECS">
 
     Each step has several optional fields that are detailed in the
-     [work pools documentation](/3.0rc/deploy/control-runs/work-pools/). 
+     [work pools documentation](/3.0rc/deploy/infrastructure-concepts/work-pools/). 
     Select the block you created under the AWS Credentials field. 
     This allows Prefect Cloud to securely interact with your ECS cluster.
  </Tab>
@@ -629,14 +629,14 @@ Click **Create** to configure your push work pool by selecting a push option in
  <Tab title="Google Cloud Run">
 
     Each step has several optional fields that are detailed in the 
-    [work pools guide](/3.0rc/deploy/control-runs/work-pools/). 
+    [work pools guide](/3.0rc/deploy/infrastructure-concepts/work-pools/). 
     Select the block you created under the GCP Credentials field. 
     This allows Prefect Cloud to securely interact with your GCP project.
  </Tab>
  <Tab title="Modal">
 
     Each step has several optional fields that are detailed in the 
-    [work pools documentation](/3.0rc/deploy/control-runs/work-pools/). 
+    [work pools documentation](/3.0rc/deploy/infrastructure-concepts/work-pools/). 
     Select the block you created under the Modal Credentials field. 
     This allows Prefect Cloud to securely interact with your Modal account.
  </Tab>
@@ -645,7 +645,7 @@ Create your pool to be ready to deploy flows to your Push work pool.
 
 ## Deployment
 
-You need to configure your [deployment](/3.0rc/deploy/serve-flows/) to send flow runs to your push work pool.
+You need to configure your [deployment](/3.0rc/deploy/infrastructure-examples/docker/) to send flow runs to your push work pool.
 For example, if you create a deployment through the interactive command line experience, 
 choose the work pool you just created. If you are deploying an existing `prefect.yaml` file, the deployment would contain:
 
@@ -673,7 +673,6 @@ to your serverless infrastructure, created a job, ran the job, and reported on i
 
 ## Next steps
 
-Learn more about [work pools](/3.0rc/deploy/control-runs/work-pools/) and [workers](/3.0rc/deploy/control-runs/workers/).
+Learn more about [work pools](/3.0rc/deploy/infrastructure-concepts/work-pools/) and [workers](/3.0rc/deploy/infrastructure-concepts/workers/).
 
-Learn about installing dependencies at runtime or baking them into your Docker image in the [Deploying flows to work 
-pools and workers](/3.0rc/deploy/control-runs/prefect-deploy/#creating-work-pool-based-deployments-with-deploy) guide.
+Learn about installing dependencies at runtime or baking them into your Docker image in the [Deploy to Docker](/3.0rc/deploy/infrastructure-examples/docker#automatically-build-a-custom-docker-image-with-a-local-dockerfile) guide.
diff --git a/docs/3.0rc/deploy/serve-flows/serve-a-flow.mdx b/docs/3.0rc/deploy/run-flows-in-local-processes.mdx
similarity index 59%
rename from docs/3.0rc/deploy/serve-flows/serve-a-flow.mdx
rename to docs/3.0rc/deploy/run-flows-in-local-processes.mdx
index 1cbb0550bcca..cf765ebab684 100644
--- a/docs/3.0rc/deploy/serve-flows/serve-a-flow.mdx
+++ b/docs/3.0rc/deploy/run-flows-in-local-processes.mdx
@@ -1,11 +1,14 @@
 ---
-title: Serve flows
+title: Run flows in local processes
 description: Create a deployment for a flow by calling the `serve` method.
 ---
 
-The simplest way to create a [deployment](/3.0rc/deploy/serve-flows/) for your 
+The simplest way to create a [deployment](/3.0rc/deploy/infrastructure-examples/docker/) for your 
 flow is by calling its `serve` method.
-This method creates a deployment for the flow and starts a long-running process 
+
+## Serve a flow
+
+The serve method creates a deployment for the flow and starts a long-running process 
 that monitors for work from the Prefect server.
 When work is found, it is executed within its own isolated subprocess.
 
@@ -59,7 +62,42 @@ if __name__ == "__main__":
 ```
 </Tip>
 
-### Serve multiple flows at once
+## Additional serve options
+
+The `serve` method on flows exposes many options for the deployment.
+Here's how to use some of those options:
+
+- `cron`: a keyword that allows you to set a cron string schedule for the deployment; see 
+[schedules](/3.0rc/automate/add-schedules/) for more advanced scheduling options
+- `tags`: a keyword that allows you to tag this deployment and its runs for bookkeeping and filtering purposes
+- `description`: a keyword that allows you to document what this deployment does; by default the 
+description is set from the docstring of the flow function (if documented)
+- `version`: a keyword that allows you to track changes to your deployment; uses a hash of the 
+file containing the flow by default; popular options include semver tags or git commit hashes
+
+Next, add these options to your deployment:
+
+```python
+if __name__ == "__main__":
+    get_repo_info.serve(
+        name="my-first-deployment",
+        cron="* * * * *",
+        tags=["testing", "tutorial"],
+        description="Given a GitHub repository, logs repository statistics for that repo.",
+        version="tutorial/deployments",
+    )
+```
+
+When you rerun this script, you will find an updated deployment in the UI that is actively scheduling work.
+Stop the script in the CLI using `CTRL+C` and your schedule automatically pauses.
+
+<Note>
+**`serve()` is a long-running process**
+
+To execute remotely triggered or scheduled runs, your script with `flow.serve` must be actively running.
+</Note>
+
+## Serve multiple flows at once
 
 Serve multiple flows with the same process using the `serve` utility along with the `to_deployment` method of flows:
 
@@ -87,6 +125,32 @@ if __name__ == "__main__":
 ```
 
 The behavior and interfaces are identical to the single flow case.
+A few things to note:
+
+- the `flow.to_deployment` interface exposes the *exact same* options as `flow.serve`; this method 
+produces a deployment object
+- the deployments are only registered with the API once `serve(...)` is called
+- when serving multiple deployments, the only requirement is that they share a Python environment; 
+they can be executed and scheduled independently of each other
+
+A few optional steps for exploration include:
+
+- pause and unpause the schedule for the "sleeper" deployment
+- use the UI to submit ad-hoc runs for the "sleeper" deployment with different values for `sleep`
+- cancel an active run for the "sleeper" deployment from the UI
+
+<Tip>
+**Hybrid execution option**
+
+Prefect's deployment interface allows you to choose a hybrid execution model.
+Whether you use Prefect Cloud or host a Prefect server instance, you can run workflows in the 
+environments best suited to their execution.
+This model enables efficient use of your infrastructure resources while maintaining the privacy 
+of your code and data.
+There is no ingress required.
+Read more about our [hybrid model](https://www.prefect.io/security/overview/#hybrid-model).
+</Tip>
+
 
 ## Retrieve a flow from remote storage
 
diff --git a/docs/3.0rc/develop/task-run-limits.mdx b/docs/3.0rc/develop/task-run-limits.mdx
index 02e81f09c9e5..7c4ca79987aa 100644
--- a/docs/3.0rc/develop/task-run-limits.mdx
+++ b/docs/3.0rc/develop/task-run-limits.mdx
@@ -30,12 +30,11 @@ and instructs the client to try entering a `Running` state again in 30 seconds
 ### Configure concurrency limits
 
 <Tip>
-
 **Flow run concurrency limits are set at a work pool and/or work queue level**
-While task run concurrency limits are configured through tags (as shown below), 
-[flow run concurrency limits](https://docs.prefect.io/latest/deploy/dynamic-infra/control-runs/#work-pool-concurrency) 
-are configured through work pools and/or work queues.
+
+While task run concurrency limits are configured through tags (as shown below), [flow run concurrency limits](/3.0rc/develop/global-concurrency-limits) are configured through work pools and/or work queues.
 </Tip>
+
 You can set concurrency limits on as few or as many tags as you wish. You can set limits through:
 
 - Prefect [CLI](#cli)
diff --git a/docs/3.0rc/develop/write-flows.mdx b/docs/3.0rc/develop/write-flows.mdx
index 5ced285dea63..36d6a804a54c 100644
--- a/docs/3.0rc/develop/write-flows.mdx
+++ b/docs/3.0rc/develop/write-flows.mdx
@@ -29,7 +29,7 @@ allowing you to observe and act on flow execution.
 - Retries can be performed on failure.
 - Timeouts can be enforced to prevent unintentional, long-running workflows.
 - Metadata about [flow runs](#flow-runs), such as run time and final state, is automatically tracked.
-- A flow can be [deployed](/3.0rc/deploy/serve-flows/), which exposes an API for interacting with it remotely.
+- A flow can be [deployed](/3.0rc/deploy/infrastructure-examples/docker/), which exposes an API for interacting with it remotely.
 
 Flows are uniquely identified by name. 
 You can provide a `name` parameter value for the flow:
@@ -53,7 +53,7 @@ For example, by running a script or importing the function into an interactive s
 You can also create a flow run by:
 
 - Using external schedulers such as `cron` to invoke a flow function
-- Triggering a [deployment](/3.0rc/deploy/serve-flows/) of that flow on Prefect Cloud or a self-hosted Prefect server instance
+- Triggering a [deployment](/3.0rc/deploy/infrastructure-examples/docker/) of that flow on Prefect Cloud or a self-hosted Prefect server instance
 - Starting a flow run for the deployment through a schedule, the Prefect UI, or the Prefect API
 
 However you run your flow, Prefect monitors the flow run, capturing its state for observability.
@@ -153,7 +153,7 @@ When you run this flow, you'll see the following output:
 It was Friday on 2021-01-01T02:00:19.180906
 ```
 
-Note that you can provide parameter values to a flow through the API using a [deployment](/3.0rc/deploy/serve-flows/).
+Note that you can provide parameter values to a flow through the API using a [deployment](/3.0rc/deploy/infrastructure-examples/docker/).
 Flow run parameters sent to the API on flow calls are coerced to the appropriate types.
 
 <Warning>
@@ -227,7 +227,7 @@ The `state_details` feild of the task run representing the child flow run includ
 The `state_details` feild of the nested flow run includes a `parent_task_run_id`.
 
 You can define multiple flows within the same file.
-Whether running locally or through a [deployment](/3.0rc/deploy/serve-flows/), you must indicate which flow is the entrypoint for a flow run.
+Whether running locally or through a [deployment](/3.0rc/deploy/infrastructure-examples/docker/), you must indicate which flow is the entrypoint for a flow run.
 
 <Warning>
 **Cancelling nested flow runs**
@@ -492,7 +492,7 @@ When you run this flow, you'll see the following output:
 It was Friday on 2021-01-01T02:00:19.180906
 ```
 
-Note that you can provide parameter values to a flow through the API using a [deployment](/3.0rc/deploy/serve-flows/).
+Note that you can provide parameter values to a flow through the API using a [deployment](/3.0rc/deploy/infrastructure-examples/docker/).
 Flow run parameters sent to the API on flow calls are coerced to the appropriate types.
 
 <Warning>
@@ -520,7 +520,7 @@ For example, by running a Python script or importing the flow into an interactiv
 You can also create a flow run by:
 
 - Using external schedulers such as `cron` to invoke a flow function
-- Creating a [deployment](/3.0rc/deploy/serve-flows/) on Prefect Cloud or a locally run Prefect server
+- Creating a [deployment](/3.0rc/deploy/infrastructure-examples/docker/) on Prefect Cloud or a locally run Prefect server
 - Creating a flow run for the deployment through a schedule, the Prefect UI, or the Prefect API
 
 However you run the flow, the Prefect API monitors the flow run, capturing flow run state for observability.
diff --git a/docs/3.0rc/get-started/index.mdx b/docs/3.0rc/get-started/index.mdx
index b0e8667674f9..5851b90dca90 100644
--- a/docs/3.0rc/get-started/index.mdx
+++ b/docs/3.0rc/get-started/index.mdx
@@ -41,8 +41,8 @@ if __name__ == "__main__":
   <Card title="Develop" icon="code" href="/3.0rc/develop/write-flows">
     Write and observe workflows, create tasks, and build interactive workflows.
   </Card>
-  <Card title="Deploy" icon="rocket" href="/3.0rc/deploy/serve-flows/deploy-a-flow">
-    Serve workflows on long lived infrastructure or deploy workflows to dynamic infrastructure.
+  <Card title="Deploy" icon="rocket" href="/3.0rc/deploy/index">
+    Serve workflows on long lived infrastructure or deploy workflows to dynamically provisioned infrastructure.
   </Card>
   <Card title="Automate" icon="eyes" href="/3.0rc/automate/events/automations-triggers">
     Enable workflows to react to their environment with events, automations, and webhooks.
diff --git a/docs/3.0rc/get-started/quickstart.mdx b/docs/3.0rc/get-started/quickstart.mdx
index af30e87f000d..2badc2723007 100644
--- a/docs/3.0rc/get-started/quickstart.mdx
+++ b/docs/3.0rc/get-started/quickstart.mdx
@@ -146,13 +146,13 @@ Prefect automatically tracks the state of the flow run and logs the output in th
 ## Create a work pool
 
 Running a flow locally is a good start, but you should use a remote destination for production flows.
-A [work pool](/3.0rc/deploy/control-runs/work-pools/) is the most common way to do this.
+A [work pool](/3.0rc/deploy/infrastructure-concepts/work-pools/) is the most common way to do this.
 
 <Tabs>
   <Tab title="Prefect Cloud">
 Deploy your flow to Cloud using a managed work pool.
 
-1. Create a [managed work pool](/3.0rc/deploy/control-runs/work-pools):
+1. Create a [managed work pool](/3.0rc/deploy/infrastructure-concepts/work-pools):
 
    ```bash
    prefect work-pool create my-work-pool --type prefect:managed
@@ -189,7 +189,7 @@ You can also choose from other [work pool types](https://docs.prefect.io/concept
 
 ## Deploy and schedule your flow
 
-A [deployment](/3.0rc/deploy/serve-flows/) is used to determine when, where, and how a flow function should run.
+A [deployment](/3.0rc/deploy/infrastructure-examples/docker/) is used to determine when, where, and how a flow function should run.
 Deployments elevate flows to remotely configurable entities that have their own API.
 
 1. Create a deployment script:
@@ -213,7 +213,7 @@ Deployments elevate flows to remotely configurable entities that have their own
 
    <Tip>
    You can store your flow code in nearly any location as long as Prefect can access it.
-   See [Where to store your flow code](/3.0rc/deploy/dynamic-infra/retrieve-flow-code) for more details.
+   See [Where to store your flow code](/3.0rc/deploy/infrastructure-concepts/store-flow-code) for more details.
    </Tip>
 
 1. Run the script to create the deployment:
diff --git a/docs/3.0rc/manage/cloud/index.mdx b/docs/3.0rc/manage/cloud/index.mdx
index ccc68904c280..a3e4958ba67c 100644
--- a/docs/3.0rc/manage/cloud/index.mdx
+++ b/docs/3.0rc/manage/cloud/index.mdx
@@ -13,7 +13,7 @@ Prefect Cloud is a hosted workflow application platform with all the capabilitie
 - [Audit Logs](/3.0rc/manage/cloud/manage-users/audit-logs/) &mdash; a record of user activities to monitor security and compliance.
 - Collaboration &mdash; invite other people to your account.
 - Error summaries  &mdash; (enabled by Marvin AI) distill the error logs of `Failed` and `Crashed` flow runs into actionable information.
-- [Push work pools](/3.0rc/deploy/dynamic-infra/push-runs-serverless/) &mdash; run flows on your serverless infrastructure without running a worker.
+- [Push work pools](/3.0rc/deploy/infrastructure-examples/serverless/) &mdash; run flows on your serverless infrastructure without running a worker.
 
 ## User accounts
 
@@ -44,8 +44,8 @@ Enterprise plans have [object-level access control lists](/3.0rc/manage/cloud/ma
 A workspace is an isolated environment within Prefect Cloud for all Prefect activity, including:
 - [Flow runs](/3.0rc/develop/write-flows/) and task runs executed in an environment that is [syncing with the workspace](/3.0rc/manage/cloud/workspaces/)
 - [Flows](/3.0rc/develop/write-flows/) associated with flow runs and deployments observed by the Prefect Cloud API
-- [Deployments](/3.0rc/deploy/serve-flows/)
-- [Work pools](/3.0rc/deploy/control-runs/work-pools/)
+- [Deployments](/3.0rc/deploy/infrastructure-examples/docker/)
+- [Work pools](/3.0rc/deploy/infrastructure-concepts/work-pools/)
 - [Blocks](/3.0rc/develop/blocks/)
 - [Events](/3.0rc/automate/events/)
 - [Automations](/3.0rc/automate/events/automations-triggers/)
diff --git a/docs/3.0rc/manage/cloud/troubleshoot-cloud.mdx b/docs/3.0rc/manage/cloud/troubleshoot-cloud.mdx
index b607c67feb19..631c56215c93 100644
--- a/docs/3.0rc/manage/cloud/troubleshoot-cloud.mdx
+++ b/docs/3.0rc/manage/cloud/troubleshoot-cloud.mdx
@@ -202,7 +202,7 @@ Insufficient permissions result in an error. For example, starting a worker with
 
 The user can execute flows locally, or remotely by a worker. Local execution generally means that you, the user, 
 run your flow directly with a command like `python flow.py`. Remote execution generally means that a worker runs your flow 
-through a [deployment](/3.0rc/deploy/serve-flows/) (optionally on different infrastructure).
+through a [deployment](/3.0rc/deploy/infrastructure-examples/docker/) (optionally on different infrastructure).
 
 With remote execution, the creation of your flow run happens separately from its execution. 
 Flow runs are assigned to a work pool and a work queue. For flow runs to execute, a worker must be subscribed 
diff --git a/docs/3.0rc/resources/cancel.mdx b/docs/3.0rc/resources/cancel.mdx
index 6eb9981a3d58..d4e7cae81c3e 100644
--- a/docs/3.0rc/resources/cancel.mdx
+++ b/docs/3.0rc/resources/cancel.mdx
@@ -20,7 +20,7 @@ A monitoring process must be running to enforce the cancellation.
 
 Inline nested flow runs (those created without `run_deployment`), cannot be cancelled without cancelling the parent flow run.
 To cancel a nested flow run independent of its parent flow run, we recommend deploying it separately 
-and starting it using the [run_deployment](/3.0rc/deploy/serve-flows/deploy-a-flow) 
+and starting it using the [run_deployment](/3.0rc/deploy/index) 
 function.
 </Warning>
 
diff --git a/docs/3.0rc/resources/cli-shell.mdx b/docs/3.0rc/resources/cli-shell.mdx
index 831e32fab732..b8c844820dc5 100644
--- a/docs/3.0rc/resources/cli-shell.mdx
+++ b/docs/3.0rc/resources/cli-shell.mdx
@@ -40,7 +40,7 @@ shell tasks.
 
 ## Deploy with `serve`
 To run shell commands on a schedule, the `serve` command creates a Prefect 
-[deployment](/3.0rc/deploy/serve-flows/) for regular execution. 
+[deployment](/3.0rc/deploy/infrastructure-examples/docker/) for regular execution. 
 This is a quick way to create a deployment served by Prefect.
 
 ### Example usage
diff --git a/docs/3.0rc/resources/daemonize-processes.mdx b/docs/3.0rc/resources/daemonize-processes.mdx
index 39ef50db24ea..e3629f25a0d6 100644
--- a/docs/3.0rc/resources/daemonize-processes.mdx
+++ b/docs/3.0rc/resources/daemonize-processes.mdx
@@ -27,7 +27,7 @@ AWS Linux image, you can install Python and pip with `sudo yum install -y python
 
 A systemd service is ideal for running a long-lived process on a Linux VM or physical Linux server.
 You will use systemd and learn how to automatically start a
-[Prefect worker](/3.0rc/deploy/control-runs/workers/) or
+[Prefect worker](/3.0rc/deploy/infrastructure-concepts/workers/) or
 long-lived [`serve` process](/3.0rc/develop/write-flows/#serving-a-flow) when Linux starts.
 This approach provides resilience by automatically restarting the process if it crashes.
 
diff --git a/docs/3.0rc/resources/secrets.mdx b/docs/3.0rc/resources/secrets.mdx
index adba5071785d..ef9f223f898e 100644
--- a/docs/3.0rc/resources/secrets.mdx
+++ b/docs/3.0rc/resources/secrets.mdx
@@ -178,7 +178,7 @@ See [`prefect-snowflake`](/integrations/prefect-snowflake) for more examples of
 
 ## Next steps
 
-Now you can turn your flow into a [deployment](/3.0rc/deploy/control-runs/prefect-deploy/) so you and your team 
+Now you can turn your flow into a [deployment](/3.0rc/deploy/infrastructure-examples/docker/) so you and your team 
 can run it remotely on a schedule, in response to an event, or manually.  
 
 Make sure to specify the `prefect-aws` and `prefect-snowflake` dependencies in your work pool or deployment 
diff --git a/docs/3.0rc/resources/upgrade-agents-to-workers.mdx b/docs/3.0rc/resources/upgrade-agents-to-workers.mdx
index dc6a77becdc2..3588a82e9214 100644
--- a/docs/3.0rc/resources/upgrade-agents-to-workers.mdx
+++ b/docs/3.0rc/resources/upgrade-agents-to-workers.mdx
@@ -13,7 +13,7 @@ If you are new to Prefect, we recommend starting with the
 </Note>
 
 ## About workers and agents
-A [worker](/3.0rc/deploy/control-runs/workers/) is the fusion of an 
+A [worker](/3.0rc/deploy/infrastructure-concepts/workers/) is the fusion of an 
 agent with an infrastructure block. 
 Like agents, workers poll a work pool for flow runs that are scheduled to start. 
 Like infrastructure blocks, workers are typed. They work with only one kind of infrastructure, 
@@ -22,7 +22,7 @@ and they specify the default configuration for jobs submitted to that infrastruc
 Accordingly, workers are not a drop-in replacement for agents. **Using workers requires 
 deploying flows differently.** In particular, deploying a flow with a worker does not involve 
 specifying an infrastructure block. Instead, infrastructure configuration is specified on the 
-[work pool](/3.0rc/deploy/control-runs/work-pools/) and passed to each worker that polls work 
+[work pool](/3.0rc/deploy/infrastructure-concepts/work-pools/) and passed to each worker that polls work 
 from that pool.
 
 ## Upgrade enhancements
@@ -36,27 +36,27 @@ and when it last polled.
 ### Work pools
 
 - Work pools allow greater customization and governance of infrastructure parameters for deployments 
-through their [base job template](/3.0rc/deploy/control-runs/work-pools/#base-job-template).
-- Prefect Cloud [push work pools](/3.0rc/deploy/dynamic-infra/push-runs-serverless/) enable flow 
+through their [base job template](/3.0rc/deploy/infrastructure-concepts/work-pools/#base-job-template).
+- Prefect Cloud [push work pools](/3.0rc/deploy/infrastructure-examples/serverless/) enable flow 
 execution in your cloud provider environment without the need to host a worker.
-- Prefect Cloud [managed work pools](/3.0rc/deploy/control-runs/managed-execution/) allow you to run flows on 
+- Prefect Cloud [managed work pools](/3.0rc/deploy/infrastructure-examples/managed/) allow you to run flows on 
 Prefect's infrastructure, without the need to host a worker or configure cloud provider infrastructure.
 
 ### Improved deployment interfaces
 
 - The Python deployment experience with `.deploy()` or the alternative deployment experience with 
 `prefect.yaml` are more flexible and easier to use than block and agent-based deployments.
-- Both options allow you to [deploy multiple flows](/3.0rc/deploy/serve-flows/#working-with-multiple-deployments) 
+- Both options allow you to [deploy multiple flows](/3.0rc/deploy/infrastructure-concepts/prefect-yaml/#work-with-multiple-deployments-with-prefect-yaml) 
 with a single command.
 - Both options allow you to build Docker images for your flows to create portable execution environments.
-- The YAML-based API supports [templating](/3.0rc/deploy/serve-flows/#templating-options) 
-to enable [dryer deployment definitions](/3.0rc/deploy/serve-flows/#reusing-configuration-across-deployments).
+- The YAML-based API supports [templating](/3.0rc/deploy/infrastructure-concepts/prefect-yaml/#templating-options) 
+to enable [dryer deployment definitions](/3.0rc/deploy/infrastructure-examples/docker/#reusing-configuration-across-deployments).
 
 ## Upgrade changes
 
 1. **Deployment CLI and Python SDK:**
 
-    `prefect deployment build <entrypoint>`/`prefect deployment apply` --> [`prefect deploy`](/3.0rc/deploy/serve-flows/#deployment-declaration-reference)
+    `prefect deployment build <entrypoint>`/`prefect deployment apply` --> [`prefect deploy`](/3.0rc/deploy/infrastructure-concepts/prefect-yaml/#deployment-declaration-reference)
 
     Prefect now automatically detects flows in your repo and provides a [wizard](/3.0rc/#step-5-deploy-the-flow)  
     to guide you through setting required attributes for your deployments.
@@ -65,18 +65,18 @@ to enable [dryer deployment definitions](/3.0rc/deploy/serve-flows/#reusing-conf
 
 2. **Configuring remote flow code storage:**
 
-    storage blocks --> [pull action](/3.0rc/deploy/serve-flows/#the-pull-action)
+    storage blocks --> [pull action](/3.0rc/deploy/infrastructure-concepts/prefect-yaml/#the-pull-action)
 
     When using the YAML-based deployment API, you can configure a pull action in your `prefect.yaml` 
     file to specify how to retrieve flow code for your deployments. You can use configuration from your 
-    existing storage blocks to define your pull action [through templating](/3.0rc/deploy/control-runs/prefect-deploy/#templating-options).
+    existing storage blocks to define your pull action [through templating](/3.0rc/deploy/infrastructure-concepts/prefect-yaml/#templating-options).
 
     When using the Python deployment API, you can pass any storage block to the `flow.deploy` method to 
     specify how to retrieve flow code for your deployment.
 
 3. **Configuring flow run infrastructure:**
 
-    infrastructure blocks --> [typed work pool](/3.0rc/deploy/control-runs/workers/#worker-types)
+    infrastructure blocks --> [typed work pool](/3.0rc/deploy/infrastructure-concepts/workers/#worker-types)
 
     Default infrastructure config is now set on the typed work pool, and can be overwritten by 
     individual deployments.
@@ -84,8 +84,8 @@ to enable [dryer deployment definitions](/3.0rc/deploy/serve-flows/#reusing-conf
 4. **Managing multiple deployments:**
 
     Create and/or update many deployments at once through a 
-    [`prefect.yaml`](/3.0rc/deploy/serve-flows/#working-with-multiple-deployments) 
-    file or use the [`deploy`](/3.0rc/deploy/dynamic-infra/push-runs-remote) 
+    [`prefect.yaml`](/3.0rc/deploy/infrastructure-concepts/prefect-yaml/#work-with-multiple-deployments-with-prefect-yaml) 
+    file or use the [`deploy`](/3.0rc/deploy/infrastructure-examples/docker) 
     function.
 
 ## What's similar
@@ -94,9 +94,9 @@ to enable [dryer deployment definitions](/3.0rc/deploy/serve-flows/#reusing-conf
 - Infrastructure blocks have configuration fields similar to typed work pools.
 - Deployment-level infrastructure overrides operate in much the same way.
 
-    `infra_override` -> [`job_variable`](/3.0rc/deploy/serve-flows/#work-pool-fields)
+    `infra_override` -> [`job_variable`](/3.0rc/deploy/infrastructure-concepts/prefect-yaml/#work-pool-fields)
 
-- The process for starting an agent and [starting a worker](/3.0rc/deploy/control-runs/workers/#start-a-worker) 
+- The process for starting an agent and [starting a worker](/3.0rc/deploy/infrastructure-concepts/workers/#start-a-worker) 
 in your environment are virtually identical.
 
     `prefect agent start --pool <work pool name>` --> `prefect worker start --pool <work pool name>`
@@ -114,7 +114,7 @@ to host workers in your cluster.
 If you have existing deployments that use infrastructure blocks, you can quickly upgrade them to 
 be compatible with workers by following these steps:
 
-1. **[Create a work pool](/3.0rc/deploy/control-runs/work-pools/#work-pool-configuration)**
+1. **[Create a work pool](/3.0rc/deploy/infrastructure-concepts/work-pools/#work-pool-configuration)**
 
 This new work pool replaces your infrastructure block.
 
@@ -136,18 +136,15 @@ KubernetesJob.load("my-k8s-job").publish_as_work_pool()
 <Tip>
 **Serving flows**
 If you are using a `Process` infrastructure block and a `LocalFilesystem` storage block 
-(or aren't using an infrastructure and storage block at all), you can use [`flow.serve`](/3.0rc/deploy/serve-flows/deploy-a-flow) 
+(or aren't using an infrastructure and storage block at all), you can use [`flow.serve`](/3.0rc/deploy/index) 
 to create a deployment without specifying a work pool name or start a worker.
 
 This is a quick way to create a deployment for a flow and manage your 
 deployments if you don't need the dynamic infrastructure creation or configuration offered 
 by workers.
-
-Check out our [Docker guide](/3.0rc/deploy/dynamic-infra/deploy-docker/) for how to build a 
-served flow into a Docker image and host it in your environment.
 </Tip>
 
-2. **[Start a worker](/3.0rc/deploy/control-runs/workers/#start-a-worker)**
+2. **[Start a worker](/3.0rc/deploy/infrastructure-concepts/workers/#start-a-worker)**
 
 This worker replaces your agent and polls your new work pool for flow runs to execute.
 
@@ -177,7 +174,7 @@ but here are some possible changes you may need:
   - If you've used the `.publish_as_work_pool` method on your infrastructure block, use the 
   name of the created work pool.
 - Replace `infra_overrides` with `job_variables`.
-- Replace `storage` with a call to [`flow.from_source`](/3.0rc/deploy/serve-flows/deploy-a-flow).
+- Replace `storage` with a call to [`flow.from_source`](/3.0rc/deploy/index).
   - `flow.from_source` loads your flow from a remote storage location and makes it deployable. 
   You can pass your existing storage block to the `source` argument of `flow.from_source`.
 
@@ -350,7 +347,7 @@ flow is executed.
 
 With agents, you may have multiple `deployment.yaml` files. But under worker deployment 
 patterns, each repo has a single `prefect.yaml` file located at the **root** of the repo 
-that contains [deployment configuration](/3.0rc/deploy/serve-flows/#working-with-multiple-deployments) 
+that contains [deployment configuration](/3.0rc/deploy/infrastructure-concepts/prefect-yaml/#work-with-multiple-deployments-with-prefect-yaml) 
 for all flows in that repo.
 </Warning>
 
@@ -367,12 +364,12 @@ This starts a wizard that guides you through setting up your deployment.
 **For step 4, select `y` on the last prompt to save the configuration for the deployment.**
 
 Saving the configuration for your deployment results in a `prefect.yaml` file populated 
-with your first deployment. You can use this YAML file to edit and [define multiple deployments](/3.0rc/deploy/serve-flows/#working-with-multiple-deployments) 
+with your first deployment. You can use this YAML file to edit and [define multiple deployments](/3.0rc/deploy/infrastructure-concepts/prefect-yaml/#work-with-multiple-deployments-with-prefect-yaml) 
 for this repo.
 </Note>
 
-You can add more [deployments](/3.0rc/deploy/serve-flows/#deployment-declaration-reference) 
+You can add more [deployments](/3.0rc/deploy/infrastructure-concepts/prefect-yaml/#deployment-declaration-reference) 
 to the `deployments` list in your `prefect.yaml` file and/or by continuing to use the deployment 
 creation wizard.
 
-For more information on deployments, check out our [in-depth guide for deploying flows to work pools](/3.0rc/deploy/control-runs/prefect-deploy/).
\ No newline at end of file
+For more information on deployments, check out our [in-depth guide for deploying flows to work pools](/3.0rc/deploy/infrastructure-examples/docker/).
\ No newline at end of file
diff --git a/docs/contribute/develop-a-new-worker-type.mdx b/docs/contribute/develop-a-new-worker-type.mdx
index 6742d2c94542..38ede969e148 100644
--- a/docs/contribute/develop-a-new-worker-type.mdx
+++ b/docs/contribute/develop-a-new-worker-type.mdx
@@ -9,7 +9,7 @@ Prefect workers set up execution infrastructure and start flow runs.
 **Advanced topic**
 
 Extending the Prefect framework by developing a worker requires deep knowledge of 
-Prefect. For standard needs, we recommend using one of the [available worker types](/3.0rc/deploy/control-runs/workers/).
+Prefect. For standard needs, we recommend using one of the [available worker types](/3.0rc/deploy/infrastructure-concepts/workers/#worker-types).
 </Tip>
 
 This guide walks you through creating a custom worker that can run your flows on your chosen infrastructure.
@@ -23,7 +23,7 @@ The worker uses this configuration to create the execution environment and start
 <Tip>
 **How are the configuration values populated?**
 
-The work pool that a worker polls for flow runs has a [base job template](/3.0rc/deploy/control-runs/work-pools#base-job-template/) 
+The work pool that a worker polls for flow runs has a [base job template](/3.0rc/deploy/infrastructure-concepts/work-pools/#base-job-template) 
 associated with it. 
 The template is the contract for how configuration values populate for each flow run.
 
diff --git a/docs/integrations/prefect-aws/ecs_guide.mdx b/docs/integrations/prefect-aws/ecs_guide.mdx
index bb2e0eada9b5..ed6ba064b925 100644
--- a/docs/integrations/prefect-aws/ecs_guide.mdx
+++ b/docs/integrations/prefect-aws/ecs_guide.mdx
@@ -13,7 +13,7 @@ ECS (Elastic Container Service) tasks are a good option for executing Prefect fl
 
 ## ECS flow run execution
 
-Prefect enables remote flow execution via workers and work pools. To learn more about these concepts please see our [deployment docs](/3.0rc/deploy/control-runs/work-pools/).
+Prefect enables remote flow execution via workers and work pools. To learn more about these concepts please see our [deployment docs](/3.0rc/deploy/infrastructure-concepts/work-pools/).
 
 For details on how workers and work pools are implemented for ECS, see the diagram below.
 
@@ -104,7 +104,7 @@ If you prefer infrastructure as code check out this [Terraform module](https://r
 
 ## Step 1: Set up an ECS work pool
 
-Before setting up the worker, create a [work pool](3.0rc/deploy/control-runs/work-pools/) of type ECS for the worker to pull work from. If doing so from the CLI, be sure to authenticate with Prefect Cloud or run a local Prefect server instance.
+Before setting up the worker, create a [work pool](/3.0rc/deploy/infrastructure-concepts/work-pools/) of type ECS for the worker to pull work from. If doing so from the CLI, be sure to authenticate with Prefect Cloud or run a local Prefect server instance.
 
 Create a work pool from the CLI:
 
@@ -358,4 +358,4 @@ prefect deploy my_flow.py:my_ecs_deployment
     - Do your flow runs require higher `CPU`?
     - Would an EC2 `Launch Type` speed up your flow run execution?
 
-    These infrastructure configuration values can be set on your ECS work pool or they can be overridden on the deployment level through [job_variables](/3.0rc/deploy/serve-flows/#workers-and-work-pools) if desired.
+    These infrastructure configuration values can be set on your ECS work pool or they can be overridden on the deployment level through [job_variables](/3.0rc/deploy/infrastructure-concepts/customize/) if desired.
diff --git a/docs/integrations/prefect-aws/index.mdx b/docs/integrations/prefect-aws/index.mdx
index b35b16cb7b26..9568d2890cd6 100644
--- a/docs/integrations/prefect-aws/index.mdx
+++ b/docs/integrations/prefect-aws/index.mdx
@@ -46,7 +46,7 @@ Run flows on [AWS Elastic Container Service (ECS)](https://aws.amazon.com/ecs/)
 
 See the [ECS work pool docs](/integrations/prefect-aws/ecs_guide) for a walkthrough of using ECS in a hybrid work pool.
 
-If you're using Prefect Cloud, [ECS push work pools](/3.0rc/deploy/dynamic-infra/push-runs-serverless) provide all the benefits of ECS with a quick setup and no worker needed.
+If you're using Prefect Cloud, [ECS push work pools](/3.0rc/deploy/infrastructure-examples/serverless) provide all the benefits of ECS with a quick setup and no worker needed.
 
 In the examples below, you create blocks with Python code.
 Alternatively, each block can be created through the Prefect UI.
diff --git a/docs/integrations/prefect-azure/index.mdx b/docs/integrations/prefect-azure/index.mdx
index ffd1a539dcb9..7e6f2c6422da 100644
--- a/docs/integrations/prefect-azure/index.mdx
+++ b/docs/integrations/prefect-azure/index.mdx
@@ -102,7 +102,7 @@ Run flows on [Azure Container Instances (ACI)](https://learn.microsoft.com/en-us
 
 See the [Azure Container Instances Worker Guide](/integrations/prefect-azure/aci_worker/) for a walkthrough of using ACI in a hybrid work pool.
 
-If you're using Prefect Cloud, [ACI push work pools](/3.0rc/deploy/dynamic-infra/push-runs-serverless/#__tabbed_1_2) provide all the benefits of ACI with a quick setup and no worker needed.
+If you're using Prefect Cloud, [ACI push work pools](/3.0rc/deploy/infrastructure-examples/serverless/#__tabbed_1_2) provide all the benefits of ACI with a quick setup and no worker needed.
 
 ## Resources
 
diff --git a/docs/integrations/prefect-docker/index.mdx b/docs/integrations/prefect-docker/index.mdx
index 945948a83015..5a83abe9b692 100644
--- a/docs/integrations/prefect-docker/index.mdx
+++ b/docs/integrations/prefect-docker/index.mdx
@@ -31,7 +31,7 @@ Install or update to the latest version of the prefect-docker library and depend
 </Tabs>
 
 ### Examples
-See the Prefect [Workers docs](3.0rc/deploy/dynamic-infra/push-runs-remote) to learn how to create and run deployments that use Docker.
+See the Prefect [Workers docs](/3.0rc/deploy/static-infra/push-runs-remote) to learn how to create and run deployments that use Docker.
 
 ## Resources
 
diff --git a/docs/integrations/prefect-gcp/gcp-worker-guide.mdx b/docs/integrations/prefect-gcp/gcp-worker-guide.mdx
index b11fefc53eee..e53a3e9e6924 100644
--- a/docs/integrations/prefect-gcp/gcp-worker-guide.mdx
+++ b/docs/integrations/prefect-gcp/gcp-worker-guide.mdx
@@ -315,6 +315,6 @@ Congratulations on completing this guide! Looking back on our journey, you have:
 4. Deployed a flow
 5. Executed a flow
 
-For next steps, take a look at some of the other [work pools](/3.0rc/deploy/dynamic-infra/push-runs-serverless) Prefect has to offer.
+For next steps, take a look at some of the other [work pools](/3.0rc/deploy/infrastructure-examples/serverless) Prefect has to offer.
 
 The world is your oyster 🦪✨.
diff --git a/docs/integrations/prefect-gcp/index.mdx b/docs/integrations/prefect-gcp/index.mdx
index f8063acc7358..a595687d7094 100644
--- a/docs/integrations/prefect-gcp/index.mdx
+++ b/docs/integrations/prefect-gcp/index.mdx
@@ -97,7 +97,7 @@ Run flows on [Google Cloud Run](https://cloud.google.com/run) or [Vertex AI](htt
 
 See the [Google Cloud Run Worker Guide](integrations/prefect-gcp/gcp-worker-guide/) for a walkthrough of using Google Cloud Run to run workflows with a hybrid work pool.
 
-If you're using Prefect Cloud, [Google Cloud Run push work pools](/3.0rc/deploy/dynamic-infra/push-runs-serverless) provide all the benefits of Google Cloud Run along with a quick setup and no worker needed.
+If you're using Prefect Cloud, [Google Cloud Run push work pools](/3.0rc/deploy/infrastructure-examples/serverless) provide all the benefits of Google Cloud Run along with a quick setup and no worker needed.
 
 ### Use Prefect with Google BigQuery
 
diff --git a/docs/integrations/prefect-kubernetes/index.mdx b/docs/integrations/prefect-kubernetes/index.mdx
index c42cb6d981e2..498077e84405 100644
--- a/docs/integrations/prefect-kubernetes/index.mdx
+++ b/docs/integrations/prefect-kubernetes/index.mdx
@@ -4,7 +4,7 @@ title: prefect-kubernetes
 
 `prefect-kubernetes` contains Prefect tasks, flows, and blocks enabling orchestration, observation and management of Kubernetes resources.
 
-This library is most commonly used for installation with a Kubernetes worker. See the [Prefect docs on deploying with Kubernetes](3.0rc/deploy/dynamic-infra/deploy-kubernetes) to learn how to create and run deployments in Kubernetes.
+This library is most commonly used for installation with a Kubernetes worker. See the [Prefect docs on deploying with Kubernetes](3.0rc/deploy/infrastructure-examples/kubernetes) to learn how to create and run deployments in Kubernetes.
 
 Prefect provides a Helm chart for deploying a worker, a self-hosted server instance, and other resources to a Kubernetes cluster. See the [Prefect Helm chart](https://github.com/PrefectHQ/prefect-helm) for more information.
 
diff --git a/docs/mint.json b/docs/mint.json
index c61d57a07788..745b9f0c0983 100644
--- a/docs/mint.json
+++ b/docs/mint.json
@@ -125,35 +125,28 @@
       "group": "Deploy",
       "version": "3.0rc",
       "pages": [
+        "3.0rc/deploy/index",
+        "3.0rc/deploy/run-flows-in-local-processes",
         {
-          "group": "Serve flows",
+          "group": "Run flows on infrastructure",
           "version": "3.0rc",
           "pages": [
-            "3.0rc/deploy/serve-flows/deploy-a-flow",
-            "3.0rc/deploy/serve-flows/serve-a-flow"
+            "3.0rc/deploy/infrastructure-concepts/work-pools",
+            "3.0rc/deploy/infrastructure-concepts/workers",
+            "3.0rc/deploy/infrastructure-concepts/store-flow-code",
+            "3.0rc/deploy/infrastructure-concepts/prefect-yaml",
+            "3.0rc/deploy/infrastructure-concepts/deploy-ci-cd",
+            "3.0rc/deploy/infrastructure-concepts/customize"
           ]
         },
         {
-          "group": "Dynamic infrastructure",
+          "group": "Infrastructure specific examples",
           "version": "3.0rc",
           "pages": [
-            "3.0rc/deploy/dynamic-infra/push-runs-serverless",
-            "3.0rc/deploy/dynamic-infra/push-runs-remote",
-            "3.0rc/deploy/dynamic-infra/retrieve-flow-code",
-            "3.0rc/deploy/dynamic-infra/customize",
-            "3.0rc/deploy/dynamic-infra/deploy-docker",
-            "3.0rc/deploy/dynamic-infra/deploy-kubernetes",
-            "3.0rc/deploy/dynamic-infra/deploy-ci-cd"
-          ]
-        },
-        {
-          "group": "Control runs",
-          "version": "3.0rc",
-          "pages": [
-            "3.0rc/deploy/control-runs/work-pools",
-            "3.0rc/deploy/control-runs/workers",
-            "3.0rc/deploy/control-runs/prefect-deploy",
-            "3.0rc/deploy/control-runs/managed-execution"
+            "3.0rc/deploy/infrastructure-examples/managed",
+            "3.0rc/deploy/infrastructure-examples/serverless",
+            "3.0rc/deploy/infrastructure-examples/docker",
+            "3.0rc/deploy/infrastructure-examples/kubernetes"
           ]
         }
       ]


Code review comments:
diff_hunk: @@ -12,7 +12,9 @@ search:
   boost: 2
 ---
 
-[Deployments](/3.0rc/deploy/serve-flows/) are server-side representations of flows. 
+## What is a deployment?
path: docs/3.0rc/deploy/index.mdx
text: @user1:
```suggestion
## Deployments
```

@user1:
Stellar was in favor of not leading with a question. Probably good to stick with that for consistency. We should add in our style guide.

diff_hunk: @@ -31,7 +31,7 @@ Install or update to the latest version of the prefect-docker library and depend
 </Tabs>
 
 ### Examples
-See the Prefect [Workers docs](3.0rc/deploy/dynamic-infra/push-runs-remote) to learn how to create and run deployments that use Docker.
+See the Prefect [Workers docs](/3.0rc/deploy/static-infra/push-runs-remote) to learn how to create and run deployments that use Docker.
path: docs/integrations/prefect-docker/index.mdx
text: @user1:
I think this link is no longer accurate

@user2:
Good catch, I missed one. 😅

diff_hunk: @@ -119,8 +106,8 @@ You can view your compute hours quota usage on the **Work Pools** page in the UI
 
 ## Next steps
 
-Read more about creating deployments in the [deployment guide](/3.0rc/deploy/control-runs/prefect-deploy/).
+Read more about creating deployments in the [deployment guide](/3.0rc/deploy/infrastructure-examples/docker/).
path: docs/3.0rc/deploy/infrastructure-examples/managed.mdx
text: @user1:
We probably don't want to call this the deployment guide.

@user2:
```suggestion
Read more about creating deployments in [Run flows in Docker containers](/3.0rc/deploy/infrastructure-examples/docker/).
```

diff_hunk: @@ -422,23 +215,22 @@ run is a suitable deployment environment.
 - Creating deployments requires a minimal set of decisions.
 - Iteration speed is fast.
 
-### Dynamically provisioning infrastructure with work pools
+### Dynamic infrastructure
 
-Consider running flows on dynamically provisioned 
-infrastructure with work pools under these circumstances:
+Consider running flows on dynamically provisioned infrastructure with work pools under these circumstances:
 
 - Flows that have expensive infrastructure due to the long-running process.
 - Flows with heterogeneous infrastructure needs across runs.
 - Large volumes of deployments.
 - If your internal team structure requires that deployment authors be members of a different team 
path: docs/3.0rc/deploy/index.mdx
text: @user1:
```suggestion
- An internal organizational structure in which deployment authors or runners are not members of
```

diff_hunk: @@ -1,6 +1,6 @@
 ---
-title: Deploy flows
-description: Learn how to configure flows for scheduled and remote execution.
+title: Deployment overview
+description: Learn what deployments are and how to use them in Prefect.
 tags:
path: docs/3.0rc/deploy/index.mdx
text: @user1:
```suggestion
```

@user1:
tags and search->boost are left over metadata from mkdocs that we should remove.

diff_hunk: @@ -289,73 +143,7 @@ passed to a flow run against the schema defined by `parameter_openapi_schema`.
 Pausing a schedule, updating your deployment, and other actions reset your auto-scheduled runs.
 </Tip>
 
-#### Run a deployed flow from within Python flow code
-
-Prefect provides a [`run_deployment` function](https://prefect-python-sdk-docs.netlify.app/prefect/deployments/deployments/#prefect.deployments.deployments.run_deployment) 
-to schedule the run of an existing deployment when your Python code executes.
-
-```python
-from prefect.deployments import run_deployment
-
-def main():
-    run_deployment(name="my_flow_name/my_deployment_name")
-```
-
-<Tip>
-**Run a deployment without blocking**
-
-By default, `run_deployment` blocks until the scheduled flow run finishes
-executing. Pass `timeout=0` to return immediately and not block.
-</Tip>
-    
-If you call `run_deployment` from within a flow or task, the scheduled flow
-run is linked to the calling flow run (or the calling task's flow run)
-as a nested flow run by default.
-
-Nested flow runs have different behavior than regular flow runs. For example, you can't suspend a 
-nested flow run independently of its parent flow run. 
-To prevent the flow run triggered by `run_deployment` from being linked to the flow run from which the method was called,
-pass `as_subflow=False` to disable it:
-
-```python
-from prefect import flow
-from prefect.deployments import run_deployment
-
-
-@flow
-def my_flow():
-    # This flow run will not be linked to `my_flow` run as a child 
-    run_deployment(name="my_other_flow/my_deployment_name", as_subflow=False)
-```
-
-The return value of `run_deployment` is a [FlowRun](https://prefect-python-sdk-docs.netlify.app/prefect/client/schemas/#prefect.client.schemas.objects.FlowRun) 
-object containing metadata about the scheduled run. Use this object to retrieve information 
-about the run after calling
-`run_deployment`:
-
-```python
-from prefect import get_client
-from prefect.deployments import run_deployment
-
-def main():
-    flow_run = run_deployment(name="my_flow_name/my_deployment_name")
-    flow_run_id = flow_run.id
-
-    # If you save the flow run's ID, you can use it later to retrieve
-    # flow run metadata again, e.g. to check if it's completed.
-    async with get_client() as client:
-        flow_run = client.read_flow_run(flow_run_id)
-        print(f"Current state of the flow run: {flow_run.state}")
-```
-
-<Tip>
-**Using the Prefect client**
-
-For more information on using the Prefect client to interact with Prefect's
-REST API, see [Interact with the API](/3.0rc/manage/interact-with-api/).
-</Tip>
-
-## Versioning and bookkeeping
+### Metadata for bookkeeping
 
 Here is important information on the versions, descriptions, and tags fields:
path: docs/3.0rc/deploy/index.mdx
text: @user1:
```suggestion
Important information for the versions, descriptions, and tags fields:
```