@@ -699,9 +699,9 @@ deletion owns a separate hold until artifact cleanup returns.
 
 The services are scheduler-agnostic binaries and containers; the supported way to run them is the
 Kubernetes-based distribution. The roles below hold regardless of how the nodes are provisioned.
-E2B Embed (`embed/`) runs the same containers on one machine, the web dashboard included, in three
-shapes (Compose, Terraform for GCP, Kubernetes); its ports, start order and images are in
-`embed/docs/REFERENCE.md`.
+E2B Embed (`embed/`) runs the same containers on one machine, the web dashboard included — with
+Compose, with Terraform on GCP, AWS or Azure, or on Kubernetes; its ports, start order and images
+are in `embed/docs/REFERENCE.md`.
 
 ```mermaid
 flowchart TB
 
@@ -21,7 +21,7 @@ lint: config vector-validate otel-validate kubernetes-render terraform-validate
 kubernetes-render:
 	kubectl kustomize kubernetes >/dev/null
 
-# All four roots share one plugin cache, so each provider is downloaded once.
+# All six roots share one plugin cache, so each provider is downloaded once.
 # Terraform reads that cache only for providers a lock file already lists
 # unless told otherwise, and none of these roots tracks a lock file
 # (.gitignore), so there is none to keep. The examples are validated too: a
@@ -39,6 +39,11 @@ terraform-validate:
 	terraform -chdir=terraform/aws validate
 	$(TF_CACHE) terraform -chdir=terraform/aws/examples/basic init -backend=false -input=false >/dev/null
 	terraform -chdir=terraform/aws/examples/basic validate
+	$(TF_CACHE) terraform -chdir=terraform/azure init -backend=false -input=false >/dev/null
+	terraform -chdir=terraform/azure fmt -check -recursive
+	terraform -chdir=terraform/azure validate
+	$(TF_CACHE) terraform -chdir=terraform/azure/examples/basic init -backend=false -input=false >/dev/null
+	terraform -chdir=terraform/azure/examples/basic validate
 
 # Vector parses the config and compiles its VRL without connecting to sinks.
 # Catches a broken remap or a misspelled sink option before a host does.
 
@@ -15,6 +15,7 @@ Open source, Apache-2.0.
 [Docker Compose](#docker-compose)
 | [Terraform on GCP](#terraform-on-gcp)
 | [Terraform on AWS](#terraform-on-aws)
+| [Terraform on Azure](#terraform-on-azure)
 | [Kubernetes](#kubernetes)
 | [Reference](docs/REFERENCE.md)
 
@@ -27,6 +28,7 @@ Choose the setup that fits what you already have.
 | Docker Compose | a Linux host you own | `docker compose up -d --wait` | [Docker Compose](#docker-compose) |
 | Terraform on GCP | a Google Cloud project | `terraform apply` | [Terraform on GCP](#terraform-on-gcp) |
 | Terraform on AWS | an AWS account | `terraform apply` | [Terraform on AWS](#terraform-on-aws) |
+| Terraform on Azure | an Azure subscription | `terraform apply` | [Terraform on Azure](#terraform-on-azure) |
 | Kubernetes | one node in your cluster | `kubectl apply -k` | [Kubernetes](#kubernetes) |
 
 Every guide ends with your first sandbox, a few minutes after you start. If
@@ -45,9 +47,8 @@ through the SDK, your team through the dashboard. The control plane is the
 same API as E2B Cloud, the data plane runs the same E2B sandboxes, storage
 keeps your templates and snapshots, and telemetry keeps your logs and
 metrics. Nothing leaves the node. It is the same node wherever you run it,
-on a Linux host you own with Docker Compose, on one VM on Google Cloud or
-one instance on AWS with Terraform, or on one node in your Kubernetes
-cluster.
+on a Linux host you own with Docker Compose, on one VM on Google Cloud,
+AWS or Azure with Terraform, or on one node in your Kubernetes cluster.
 
 ## What you get
 
@@ -110,6 +111,26 @@ module "e2b" {
 terraform init && terraform apply
 ```
 
+### Terraform on Azure
+
+Create the machine in your Azure subscription. [Full guide](terraform/azure/README.md#install).
+
+```hcl
+provider "azurerm" {
+  features {}
+  storage_use_azuread = true
+}
+
+module "e2b" {
+  source       = "github.com/e2b-dev/runtime//embed/terraform/azure?ref=main"
+  client_cidrs = ["203.0.113.0/24"]   # where your SDK clients connect from
+}
+```
+
+```bash
+terraform init && terraform apply
+```
+
 ### Kubernetes
 
 Run it on a node in your existing cluster. [Full guide](kubernetes/README.md#install).
 
@@ -3,7 +3,7 @@
 The [hub README](../README.md) says what E2B Embed is and how to run it.
 This page holds the rest: what runs where and on which ports, logs and
 telemetry, the secrets, how images and pins are released, building templates,
-and the developer tooling. The 4 guides cover what differs on Compose,
+and the developer tooling. The 5 guides cover what differs on Compose,
 Terraform and Kubernetes.
 
 ## What runs where
@@ -181,8 +181,9 @@ commented patch line in the kustomization; the
 [Kubernetes guide](../kubernetes/README.md#telemetry) has both, and where the
 collector sits in the pod. Terraform has the `otel_collector_grpc_endpoint` and
 `otel_collector` variables, which the startup script writes into the
-instance's `.env`; the [GCP](../terraform/gcp/README.md#variables) and
-[AWS](../terraform/aws/README.md#variables) guides list them.
+instance's `.env`; the [GCP](../terraform/gcp/README.md#variables),
+[AWS](../terraform/aws/README.md#variables) and
+[Azure](../terraform/azure/README.md#variables) guides list them.
 
 ## Secrets
 
@@ -316,20 +317,20 @@ without a tunnel.
 | Target | What it does |
 |--------|--------------|
 | `make images` | build the 3 stack images locally under their pinned tags |
-| `make lint` | render the compose file and the kustomization, validate the Vector config and the 2 Terraform modules, shellcheck the scripts and the tests |
+| `make lint` | render the compose file and the kustomization, validate the Vector config and the 3 Terraform modules, shellcheck the scripts and the tests |
 | `make test` | run the bats suite in `tests/` |
 | `make stores-check` | the store-level integration check |
 | `make sync-configs` | re-inline the 3 configs into the compose file |
 
 ### What the targets need
 
 `make lint` wants `shellcheck`, `terraform` (1.7.5 or newer) and `kubectl`,
-for `kubectl kustomize`. `terraform init` downloads the google, aws, random
-and time providers, once each into a shared cache, so it needs network; the
-aws provider alone is about 180 MB to download and about 800 MB unpacked in
-the cache. `make test` wants `bats` plus `kubectl`, which
+for `kubectl kustomize`. `terraform init` downloads the google, aws, azurerm,
+random and time providers, once each into a shared cache, so it needs network;
+the aws provider alone is about 180 MB to download and about 800 MB unpacked
+in the cache. `make test` wants `bats` plus `kubectl`, which
 `tests/kubernetes.bats` renders the manifest with.
-`tests/terraform.bats` reads both modules' files as text and needs no
+`tests/terraform.bats` reads every module's files as text and needs no
 terraform.
 
 Both also need a working Docker daemon with the compose plugin, and `jq` on