Modal logo
IntroductionCustom container images Custom containersPrivate registriesFast pull from registryGPUs and other resources GPU accelerationUsing CUDA on ModalReserving CPU and memoryScaling out Scaling outDicts and queuesJob processingConcurrent inputs on a single container (beta)Dynamic batching (beta)Scheduling and cron jobsDeployment Apps, Stubs, and entrypointsManaging deploymentsInvoke deployed functionsContinuous deploymentSecrets and environment variables SecretsEnvironment variablesWeb endpoints Web endpointsStreaming endpointsWeb endpoint URLsRequest timeoutsNetworking Tunnels (beta)Proxies (beta)Data sharing and storage Passing local dataVolumesMounting local files and directoriesStoring model weightsDataset ingestionCloud bucket mountsNetwork file systems (superseded)Sandboxes SandboxesRunning commandsNetworking and securityFile accessPerformance Cold start performanceMemory Snapshot (beta)Geographic latencyReliability and robustness Failures and retriesPreemptionTimeoutsTroubleshootingSecurity and privacyIntegrations Using OIDC to authenticate with external servicesConnecting Modal to your Vercel accountConnecting Modal to your Datadog accountConnecting Modal to your OpenTelemetry providerOkta SSOSlack notifications (beta)Other topics File and project structureDeveloping and debuggingModal user account setupWorkspacesEnvironmentsJupyter notebooksAsynchronous API usageGlobal variablesRegion selectionContainer lifecycle hooksParameterized functionsS3 Gateway endpoints

Managing deployments

Once you’ve finished using modal run or modal serve to iterate on your Modal code, it’s time to deploy. A Modal deployment creates and then persists an application and its objects, providing the following benefits:

  • Repeated application function executions will be grouped under the deployment, aiding observability and usage tracking. Programmatically triggering lots of ephemeral App runs can clutter your web and CLI interfaces.
  • Function calls are much faster because deployed functions are persistent and reused, not created on-demand by calls. Learn how to trigger deployed functions in Invoking deployed functions.
  • Scheduled functions will continue scheduling separate from any local iteration you do, and will notify you on failure.
  • Web endpoints keep running when you close your laptop, and their URL address matches the deployment name.

Creating deployments

Deployments are created using the modal deploy command.

 % modal deploy whisper_pod_transcriber.main
✓ Initialized. View app page at https://modal.com/apps/ap-PYc2Tb7JrkskFUI8U5w0KG.
✓ Created objects.
├── 🔨 Created populate_podcast_metadata.
├── 🔨 Mounted /home/ubuntu/whisper_pod_transcriber at /root/whisper_pod_transcriber
├── 🔨 Created fastapi_app => https://modal-labs-whisper-pod-transcriber-fastapi-app.modal.run
├── 🔨 Mounted /home/ubuntu/whisper_pod_transcriber/whisper_frontend/dist at /assets
├── 🔨 Created search_podcast.
├── 🔨 Created refresh_index.
├── 🔨 Created transcribe_segment.
├── 🔨 Created transcribe_episode..
└── 🔨 Created fetch_episodes.
✓ App deployed! 🎉

View Deployment: https://modal.com/apps/modal-labs/whisper-pod-transcriber

Running this command on an existing deployment will redeploy the App, incrementing its version. For detail on how live deployed apps transition between versions, see the Updating deployments section.

Deployments can also be created using Modal’s client library.

Viewing deployments

Deployments can be viewed either on the apps web page or by using the modal app list command.

viewing deployments in the web interface

Updating deployments

A deployment can deploy a new App or redeploy a new version of an existing deployed App. It’s useful to understand how Modal handles the transition between versions of running deployment. Modal deployments only take a few seconds, but we still ensure things run smoothly in this short deployment period.

A deployed App will continue running and accepting requests while a new deployment is happening. Existing function executions will also keep running. They will not be terminated by the deployment because they’re outdated.

However, any existing container running the old version of the App will be marked by Modal as outdated and will become ineligible to serve new requests. These outdated containers will become idle and gracefully terminate.

Any warm pool containers will also be cycled during a deployment, as the previous version’s warm pool are now outdated.

Deployment rollbacks

To quickly reset an App back to a previous version, you can perform a deployment rollback. Rollbacks can be triggered from either the App dashboard or the CLI. Rollback deployments look like new deployments: they increment the version number and are attributed to the user who triggered the rollback. But the App’s functions and metadata will be reset to their previous state independently of your current App codebase.

Note that deployment rollbacks are supported only on the Team and Enterprise plans.

Stopping deployments

Deployed apps can be stopped in the web UI by clicking the red delete button on the deployment’s App page, or alternatively by using the modal app stop command.

Stopped deployments are eventually garbage collected.