---
title: "import.http | Grafana Alloy documentation"
description: "Learn about the import.http configuration block"
---

# `import.http`

`import.http` retrieves a module from an HTTP server.

Use `import.http` to load Alloy configuration from a remote HTTP server. The remote file must define configuration inside a `declare` block. Alloy evaluates imported modules as reusable components, so the remote file must not include top-level global configuration blocks such as `logging` or `remotecfg`. Global configuration belongs in the local configuration file that imports the module. You must configure command-line flags outside the module. Alloy periodically polls the URL to detect and apply configuration changes.

Refer to [Load configuration from remote sources](../../configure/load-remote-configuration/) for more information.

## Usage

Alloy ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy

```alloy
import.http "<LABEL>" {
  url = <URL>
}
```

## Arguments

You can use the following arguments with `import.http`:

Expand table

| Name             | Type          | Description                     | Default | Required |
|------------------|---------------|---------------------------------|---------|----------|
| `url`            | `string`      | URL to poll.                    |         | yes      |
| `headers`        | `map(string)` | Custom headers for the request. | `{}`    | no       |
| `method`         | `string`      | HTTP method for the request.    | `"GET"` | no       |
| `poll_frequency` | `duration`    | Frequency to poll the URL.      | `"1m"`  | no       |
| `poll_timeout`   | `duration`    | Timeout when polling the URL.   | `"10s"` | no       |

## Blocks

You can use the following blocks with `import.http`:

Expand table

| Block                                                   | Description                                                | Required |
|---------------------------------------------------------|------------------------------------------------------------|----------|
| [`client`](#client)                                     | HTTP client settings when connecting to the endpoint.      | no       |
| `client` &gt; [`authorization`](#authorization)         | Configure generic authorization to the endpoint.           | no       |
| `client` &gt; [`basic_auth`](#basic_auth)               | Configure `basic_auth` for authenticating to the endpoint. | no       |
| `client` &gt; [`oauth2`](#oauth2)                       | Configure OAuth 2.0 for authenticating to the endpoint.    | no       |
| `client` &gt; `oauth2` &gt; [`tls_config`](#tls_config) | Configure TLS settings for connecting to the endpoint.     | no       |
| `client` &gt; [`tls_config`](#tls_config)               | Configure TLS settings for connecting to the endpoint.     | no       |

The &gt; symbol indicates deeper levels of nesting. For example, `client` &gt; `basic_auth` refers to a `basic_auth` block defined inside a `client` block.

### `client`

The `client` block configures settings for connecting to the HTTP server.

Expand table

| Name                     | Type                | Description                                                                                      | Default | Required |
|--------------------------|---------------------|--------------------------------------------------------------------------------------------------|---------|----------|
| `bearer_token_file`      | `string`            | File containing a bearer token to authenticate with.                                             |         | no       |
| `bearer_token`           | `secret`            | Bearer token to authenticate with.                                                               |         | no       |
| `enable_http2`           | `bool`              | Whether HTTP2 is supported for requests.                                                         | `true`  | no       |
| `follow_redirects`       | `bool`              | Whether redirects returned by the server should be followed.                                     | `true`  | no       |
| `http_headers`           | `map(list(secret))` | Custom HTTP headers to be sent along with each request. The map key is the header name.          |         | no       |
| `proxy_url`              | `string`            | HTTP proxy to send requests through.                                                             |         | no       |
| `no_proxy`               | `string`            | Comma-separated list of IP addresses, CIDR notations, and domain names to exclude from proxying. |         | no       |
| `proxy_from_environment` | `bool`              | Use the proxy URL indicated by environment variables.                                            | `false` | no       |
| `proxy_connect_header`   | `map(list(secret))` | Specifies headers to send to proxies during CONNECT requests.                                    |         | no       |

`bearer_token`, `bearer_token_file`, `basic_auth`, `authorization`, and `oauth2` are mutually exclusive, and only one can be provided inside of a `http_client_config` block.

`no_proxy` can contain IPs, CIDR notations, and domain names. IP and domain names can contain port numbers. `proxy_url` must be configured if `no_proxy` is configured.

`proxy_from_environment` uses the environment variables HTTP\_PROXY, HTTPS\_PROXY, and NO\_PROXY (or the lowercase versions thereof). Requests use the proxy from the environment variable matching their scheme, unless excluded by NO\_PROXY. `proxy_url` and `no_proxy` must not be configured if `proxy_from_environment` is configured.

`proxy_connect_header` should only be configured if `proxy_url` or `proxy_from_environment` are configured.

### `authorization`

The `authorization` block configures custom authorization for polling the configured URL.

Expand table

| Name               | Type     | Description                                | Default | Required |
|--------------------|----------|--------------------------------------------|---------|----------|
| `credentials_file` | `string` | File containing the secret value.          |         | no       |
| `credentials`      | `secret` | Secret value.                              |         | no       |
| `type`             | `string` | Authorization type, for example, “Bearer”. |         | no       |

`credential` and `credentials_file` are mutually exclusive, and only one can be provided inside an `authorization` block.

> Warning
> 
> Using `credentials_file` causes the file to be read on every outgoing request. Use the `local.file` component with the `credentials` attribute instead to avoid unnecessary reads.

### `basic_auth`

The `basic_auth` block configures basic authentication for polling the configured URL.

Expand table

| Name            | Type     | Description                              | Default | Required |
|-----------------|----------|------------------------------------------|---------|----------|
| `password_file` | `string` | File containing the basic auth password. |         | no       |
| `password`      | `secret` | Basic auth password.                     |         | no       |
| `username`      | `string` | Basic auth username.                     |         | no       |

`password` and `password_file` are mutually exclusive, and only one can be provided inside a `basic_auth` block.

> Warning
> 
> Using `password_file` causes the file to be read on every outgoing request. Use the `local.file` component with the `password` attribute instead to avoid unnecessary reads.

### `oauth2`

The `oauth2` block configures OAuth 2.0 authorization for polling the configured URL.

Expand table

| Name                     | Type                | Description                                                                                      | Default | Required |
|--------------------------|---------------------|--------------------------------------------------------------------------------------------------|---------|----------|
| `client_id`              | `string`            | OAuth2 client ID.                                                                                |         | no       |
| `client_secret_file`     | `string`            | File containing the OAuth2 client secret.                                                        |         | no       |
| `client_secret`          | `secret`            | OAuth2 client secret.                                                                            |         | no       |
| `endpoint_params`        | `map(string)`       | Optional parameters to append to the token URL.                                                  |         | no       |
| `no_proxy`               | `string`            | Comma-separated list of IP addresses, CIDR notations, and domain names to exclude from proxying. |         | no       |
| `proxy_connect_header`   | `map(list(secret))` | Specifies headers to send to proxies during CONNECT requests.                                    |         | no       |
| `proxy_from_environment` | `bool`              | Use the proxy URL indicated by environment variables.                                            | `false` | no       |
| `proxy_url`              | `string`            | HTTP proxy to send requests through.                                                             |         | no       |
| `scopes`                 | `list(string)`      | List of scopes to authenticate with.                                                             |         | no       |
| `token_url`              | `string`            | URL to fetch the token from.                                                                     |         | no       |

`client_secret` and `client_secret_file` are mutually exclusive, and only one can be provided inside an `oauth2` block.

> Warning
> 
> Using `client_secret_file` causes the file to be read on every outgoing request. Use the `local.file` component with the `client_secret` attribute instead to avoid unnecessary reads.

The `oauth2` block may also contain a separate `tls_config` sub-block.

`no_proxy` can contain IPs, CIDR notations, and domain names. IP and domain names can contain port numbers. `proxy_url` must be configured if `no_proxy` is configured.

`proxy_from_environment` uses the environment variables HTTP\_PROXY, HTTPS\_PROXY, and NO\_PROXY (or the lowercase versions thereof). Requests use the proxy from the environment variable matching their scheme, unless excluded by NO\_PROXY. `proxy_url` and `no_proxy` must not be configured if `proxy_from_environment` is configured.

`proxy_connect_header` should only be configured if `proxy_url` or `proxy_from_environment` are configured.

### `tls_config`

The `tls_config` block configures TLS settings for connecting to HTTPS servers.

Expand table

| Name                   | Type     | Description                                              | Default | Required |
|------------------------|----------|----------------------------------------------------------|---------|----------|
| `ca_pem`               | `string` | CA PEM-encoded text to validate the server with.         |         | no       |
| `ca_file`              | `string` | CA certificate to validate the server with.              |         | no       |
| `cert_pem`             | `string` | Certificate PEM-encoded text for client authentication.  |         | no       |
| `cert_file`            | `string` | Certificate file for client authentication.              |         | no       |
| `insecure_skip_verify` | `bool`   | Disables validation of the server certificate.           |         | no       |
| `key_file`             | `string` | Key file for client authentication.                      |         | no       |
| `key_pem`              | `secret` | Key PEM-encoded text for client authentication.          |         | no       |
| `min_version`          | `string` | Minimum acceptable TLS version.                          |         | no       |
| `server_name`          | `string` | ServerName extension to indicate the name of the server. |         | no       |

The following pairs of arguments are mutually exclusive and can’t both be set simultaneously:

- `ca_pem` and `ca_file`
- `cert_pem` and `cert_file`
- `key_pem` and `key_file`

When configuring client authentication, both the client certificate (using `cert_pem` or `cert_file`) and the client key (using `key_pem` or `key_file`) must be provided.

When `min_version` isn’t provided, the minimum acceptable TLS version is inherited from Go’s default minimum version, TLS 1.2. If `min_version` is provided, it must be set to one of the following strings:

- `"TLS10"` (TLS 1.0)
- `"TLS11"` (TLS 1.1)
- `"TLS12"` (TLS 1.2)
- `"TLS13"` (TLS 1.3)

## Behavior when the remote server is unavailable

- **Initial evaluation in this process:** A failed fetch means the configuration that imports the remote module fails to evaluate, so nothing that only the remote module would define runs.
- **After at least one successful fetch in this process:** A failed poll keeps the running configuration on the last successfully loaded module in memory; Alloy retries at each `poll_frequency` interval.

The first evaluation happens when Alloy evaluates `import.http` during startup or when it reapplies configuration after a change. If that fetch fails, there’s no remote module content from this process to fall back on.

Remote module contents aren’t persisted across process restarts. On a cold start or restart, Alloy must again successfully complete the initial fetch. If the remote server is unavailable at that time, evaluation of the configuration that uses `import.http` fails.

Alloy writes configuration retrieval errors to the logs in all of these cases, which you can use for troubleshooting and alerting.

## Monitor configuration fetch failures

To detect configuration update problems early, monitor for repeated fetch failures:

- Check collector logs for repeated HTTP errors when retrieving remote modules.
- Investigate persistent `4xx` errors, which indicate authentication or URL configuration issues.
- Investigate persistent `5xx` errors, which indicate remote server problems.
- Verify network connectivity and proxy configuration if requests time out.

If configuration updates are critical for your deployment, consider adding alerting based on log monitoring or collector health checks.

## Example

This example imports custom components from an HTTP response and instantiates a custom component for adding two numbers.

Create a module file and host it on your HTTP server:

Alloy ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy

```alloy
declare "add" {
  argument "a" {}
  argument "b" {}

  export "sum" {
    value = argument.a.value + argument.b.value
  }
}
```

In your local configuration file, import the remote module and use the declared component:

Alloy ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy

```alloy
import.http "math" {
  url = <SERVER_URL>
}

math.add "default" {
  a = 15
  b = 45
}
```

### Load configuration from a remote HTTP server

You can use `import.http` to load an Alloy configuration containing standard components from a remote HTTP server.

The following example shows how to load a Prometheus scrape configuration from a remote server.

Create a module file and host it on your HTTP server:

Alloy ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy

```alloy
declare "scrape" {
  argument "targets" {}
  argument "forward_to" {}

  prometheus.scrape "default" {
    targets    = argument.targets.value
    forward_to = argument.forward_to.value
  }
}
```

In your local configuration file, import the remote module and use the declared component:

Alloy ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy

```alloy
import.http "remote" {
  url            = "http://config-server.example.com/prometheus_scrape.alloy"
  poll_frequency = "5m"
}

prometheus.remote_write "default" {
  endpoint {
    url = "http://mimir:9009/api/v1/push"
  }
}

remote.scrape "app" {
  targets    = [{"__address__" = "localhost:8080"}]
  forward_to = [prometheus.remote_write.default.receiver]
}
```