nomad/website/content/docs/reference/runtime-environment-settings.mdx

---
layout: docs
page_title: Runtime environment settings
description: Nomad provides runtime environment variables that you can use in your workloads. Learn about task identifiers, CPU and memory resources, IP addresses, task directories, and host variables. Review job, network, and Consul variables. Supply arbitrary configuration to a job task.
---

# Runtime Environment Settings

This page provides reference information for runtime environment settings in
your Nomad job specification. Learn about task identifiers, CPU and memory
resources, IP addresses, task directories, and host variables. Review job,
network, and Consul variables. Supply arbitrary configuration to a job task.

## Introduction

Some settings you specify in your [job specification][jobspec] are passed
to tasks when they start. Other settings are dynamically allocated when your job
is scheduled. Both types of values are made available to your job through
environment variables.

## Variables Summary

@include 'envvars.mdx'

## Task Identifiers

Nomad will pass both the allocation ID and name, the deployment ID that created
the allocation, the job ID and name, the parent job ID as well as
the task and group's names. These are given as `NOMAD_ALLOC_ID`, `NOMAD_ALLOC_NAME`,
`NOMAD_ALLOC_INDEX`, `NOMAD_JOB_NAME`, `NOMAD_JOB_ID`,
`NOMAD_JOB_PARENT_ID`, `NOMAD_GROUP_NAME` and `NOMAD_TASK_NAME`. The allocation ID
and index can be useful when the task being run needs a unique identifier or to
know its instance count.

## Resources

When you request resources for a job, Nomad creates a resource offer. The final
resources for your job are not determined until it is scheduled. Nomad will
tell you which resources have been allocated after evaluation and placement.

### CPU and Memory

Nomad will pass CPU and memory limits to your job as `NOMAD_CPU_LIMIT`,
`NOMAD_MEMORY_LIMIT`, and `NOMAD_MEMORY_MAX_LIMIT`. Your task should use these
values to adapt its behavior to fit inside the resource allocation that Nomad
provides. For example, you can use the memory limit to inform how large your
in-process cache should be, or to decide when to flush buffers to disk.

Both CPU and memory are presented as integers. The unit for CPU limit is
`1024 = 1GHz`. The unit for memory is `1 = 1 megabyte`.

Writing your applications to adjust to these values at runtime provides greater
scheduling flexibility since you can adjust the resource allocations in your
job specification without needing to change your code. You can also schedule workloads
that accept dynamic resource allocations so they can scale up or down as your
cluster gets more or less busy.

### Networking

Nomad assigns IP addresses and ports to your jobs and exposes them via environment
variables. See the [Networking](/nomad/docs/job-specification/network) page for more
details.

### Task Directories

Nomad creates a working directory for each allocation on a client. The
allocation working directory contains a task working directory for each task
in the allocation.

Nomad makes the following directories available to tasks, relative to the task
working directory:

- `alloc/`: This directory is shared across all tasks in a task group and can be
  used to store data that needs to be used by multiple tasks, such as a log
  shipper.
- `local/`: This directory is private to each task. It can be used to store
  arbitrary data that should not be shared by tasks in the task group.
- `secrets/`: This directory is private to each task, not accessible via the
  `nomad alloc fs` command or filesystem APIs. Where possible it is backed by an
  in-memory filesystem and mounted `noexec`. It can be used to store secret data
  that should not be visible outside the task.

These directories are persisted until the allocation is removed, which occurs
hours after all the tasks in the task group enter terminal states. This gives
time to view the data produced by tasks.

Depending on the driver and operating system being targeted, the directories
are made available in various ways. For example, on `docker` the directories
are bound to the container, while on `exec` on Linux the chroot is built in
the task working directory, and the directories are mounted into that
chroot. Regardless of how the directories are made available, the path to the
directories can be read through the `NOMAD_ALLOC_DIR`, `NOMAD_TASK_DIR`, and
`NOMAD_SECRETS_DIR` environment variables.

For more details on the task directories, see the [Filesystem internals][].

## Meta block for arbitrary configuration

The job specification also allows you to specify a `meta` block to supply
arbitrary configuration to a task. This allows you to easily provide
job-specific configuration even if you use the same executable unit in multiple
jobs. These key-value pairs are passed through to the job as
`NOMAD_META_<key>=<value>` environment variables. Any character in a key other
than `[A-Za-z0-9_.]` will be converted to `_`. Both the original case and an uppercased
version are injected. The uppercased version will be deprecated in a future release.

Currently there is no enforcement that the meta keys be lowercase, but using
multiple keys with the same uppercased representation will lead to undefined
behavior.

## Host environment variables

Nomad passes the environment variables defined in the client host to tasks
when using the `exec`, `raw_exec`, and `java` task drivers. Nomad also modifies
`HOME` and `USER` variables for tasks that have the `user` parameter set, to
reflect the set username. The variables that are passed to the tasks can be
controlled using the client configuration [`env.denylist`][].

[jobspec]: /nomad/docs/job-specification 'Nomad Job Specification'
[filesystem internals]: /nomad/docs/concepts/filesystem
[`env.denylist`]: /nomad/docs/configuration/client#env-denylist