Environments are sub-divisons of workspaces, allowing you to deploy the same app
(or set of apps) in multiple instances for different purposes without changing
your code. Typical use cases for environments include having one
environment and one
prod environment, preventing overwriting production apps
when developing new features, while still being able to deploy changes to a
“live” and potentially complex structure of apps.
Each environment has its own set of Secrets and any object lookups 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:
modal environment create dev
(You can run
modal environment --help for more info)
Once created, environments show up as a dropdown menu in the navbar of the [/home](Modal dashboard), letting you set browse all Modal apps and Secrets 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.:
modal run --env=dev app.py modal nfs create --env=dev storage
Note that if you have multiple environments in your workspace and try to interact with it without specifying an environment, an error will be raised.
To set a default environment for your current CLI profile you can use
modal config set-environment, e.g.:
modal config set-environment dev
Alternatively, you can set the
MODAL_ENVIRONMENT environment variable.
Cross environment lookups
It’s possible to explicitly look up objects from other environments than your app runs in:
production_secret = modal.Secret.from_name( "my-secret", environment_name="main" ) modal.Function.lookup( "my_app", "some_function", environment_name="dev" )
environment_name argument is optional and omitting it will use
the environment from the object’s associated app or calling context.