Modal logo
IntroductionCustom container images Defining ImagesUsing existing container imagesFast pull from registryGPUs and other resources GPU accelerationUsing CUDA on ModalReserving CPU and memoryScaling out Scaling outInput concurrencyBatch processingJob queuesDynamic batching (beta)Multi-node clusters (beta)Deployment Apps, Functions, and entrypointsManaging deploymentsInvoking deployed functionsContinuous deploymentRunning untrusted code in FunctionsModal Sandboxes SandboxesRunning commandsNetworking and securityFile accessSnapshotsModal NotebooksSecrets and environment variables SecretsEnvironment variablesScheduling and cron jobsWeb endpoints Web endpointsStreaming endpointsWeb endpoint URLsRequest timeoutsProxy Auth TokensNetworking TunnelsProxies (beta)Cluster networkingData sharing and storage Passing local dataVolumesStoring model weightsCloud bucket mountsDictsQueuesDataset ingestionPerformance Cold start performanceMemory SnapshotHigh-performance LLM inferenceGeographic latencyReliability and robustness Failures and retriesPreemptionTimeoutsGPU healthTroubleshootingSecurity and privacyIntegrations Using OIDC to authenticate with external servicesConnecting Modal to your Datadog accountConnecting Modal to your OpenTelemetry providerOkta SSOCustom SAML SSOSlack notifications (beta)Workspace & account settings WorkspacesEnvironmentsModal user account setupService usersBillingOther topics Feature maturityJavaScript/Go SDKsModal 1.0 migration guideFile and project structureDeveloping and debuggingDeveloping Modal code with LLMsJupyter notebooksAsynchronous API usageGlobal variablesRegion selectionContainer lifecycle hooksParametrized functionsS3 Gateway endpointsGPU Metrics

Environments

Modal Environments isolate Modal applications and resources from one another.

Environments are sub-divisions of Workspaces, allowing you to deploy the same App (or set of Apps) in multiple instances for different purposes without changing code.

Typical use cases for Environments include having one dev Environment and one prod Environment. Production Apps are protected from overwriting when developing new features, but you can still deploy and test changes with a “live” and potentially complex structure of Apps.

Each Environment has its own set of Secrets and any object lookups, say for Dicts or Volumes, performed from an App in an Environment will by default look for objects in the same Environment.

By default, every Workspace has a single Environment called “main”. New Environments can be created on the CLI:

Run modal environment --help for more info.

Workspaces can have up to 1500 Environments.

Once created, Environments show up as a dropdown menu in the navbar of the Modal dashboard, letting you set browse all Modal Apps, Secrets, and Storage filtered by which Environment they were deployed to.

Most CLI commands also support an --env flag letting you specify which Environment you intend to interact with, e.g.:

To set a default Environment for your current CLI profile you can use modal config set-environment, e.g.:

Alternatively, you can set the MODAL_ENVIRONMENT environment variable.

Environment web suffixes 

Environments have a ‘web suffix’ which is used to make web endpoint URLs unique across your workspace. One Environment is allowed to have no suffix ("").

Cross environment lookups 

It’s possible to explicitly look up objects in Environments other than the Environment your App runs within:

However, the environment_name argument is optional and omitting it will use the Environment from the object’s associated App or calling context.