Modal logo
IntroductionCustom container images Defining ImagesUsing existing container imagesNamed imagesFast pull from registryGPUs and other resources GPU accelerationUsing CUDA on ModalConfiguring CPU, memory, and diskScaling out Scaling outInput concurrencyBatch processingJob queuesDynamic batchingMulti-node clusters (Beta)Deployment Apps, Functions, and entrypointsManaging deploymentsInvoking deployed functionsContinuous deploymentRunning untrusted code in FunctionsModal Sandboxes SandboxesRunning commandsNetworking and securityFile accessSnapshotsPricing and resourcesVM Sandboxes (Beta)Modal NotebooksSecrets and environment variables SecretsEnvironment variablesScheduling and cron jobsHTTP Applications ServersWeb FunctionsStreaming endpointsWeb Function URLsRequest timeoutsProxy TokensModal Auto Endpoints EndpointsEndpoint metricsBenchmark an endpointEndpoint integrationsNetworking TunnelsProxies (Beta)Cluster networkingData sharing and storage Passing local dataVolumesStoring model weightsCloud bucket mountsDictsQueuesDataset ingestionPerformance Cold start performanceMemory SnapshotsHigh-performance LLM inferenceReliability and robustness Failures and retriesPreemptionTimeoutsGPU healthTroubleshootingSecurity and privacy Security and privacyCustomer-supplied encryption keysAudit logsIntegrations 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 usersRole-Based Access Control (RBAC)BillingOther topics Feature maturityJavaScript/Go SDKsModal 1.0 migration guideFile and project structureDeveloping and debuggingJupyter notebooksAsynchronous API usageGlobal variablesRegion selectionContainer lifecycle hooksParametrized functionsDynamic function configurationS3 Gateway endpointsGPU Metrics

Service Users

Service users are programmatic accounts that allow automated systems to interact with Modal. They’re ideal for CI/CD pipelines, automated deployments, and other workflows that need to authenticate.

Create a Service User 

Service users are only available for shared workspaces. You will need workspace owner or manager privileges to create service users.

To create a service user:

  1. Go to your workspace tokens settings page
  2. Click New Service User
  3. Enter a name for your service user (must be lowercase alphanumeric, can contain hyphens or underscores)
  4. Click Create
  5. Copy the MODAL_TOKEN_ID and MODAL_TOKEN_SECRET. This is the only time you can view the token secret for security reasons.
  6. Click Configure environments to grant the service user access. A new service user has No Access to every Environment, so it can’t be used until you assign it the Viewer or Contributor role on at least one Environment.

Use Service User Tokens 

Set the service user credentials as environment variables in your automated environment:

export MODAL_TOKEN_ID=your-token-id
export MODAL_TOKEN_SECRET=your-token-secret

Once configured, you can use Modal’s CLI and Python SDK as usual:

modal deploy your_app.py

Delete a Service User 

To remove a service user:

  1. Go to the tokens settings page
  2. Find the service user in the table
  3. Click Delete when you hover over the row

Permissions 

Service users default to No Access on every Environment — they cannot read or write to an Environment until you grant them a Role. This differs from Workspace Members, who default to Contributor.

Grant a service user the Viewer or Contributor role on the specific Environments it needs, either:

  • from the service user: on the tokens settings page, open the ⋯ menu on the service user’s row and select Manage environments, or
  • from an Environment: on the Environment settings page, click Manage on the Environment, then open the Access Restrictions tab.

See Role-Based Access Control for what each Environment Role allows.

Securing Service Users 

Because service user tokens are long-lived and used in automated environments, it’s important to limit their access to only what’s necessary:

  • Store tokens securely. Use a secrets manager or your CI/CD platform’s built-in secrets storage rather than hardcoding tokens in source code or configuration files.
  • Grant least-privilege access. Because service users start with No Access, assign the Viewer or Contributor role only on the Environments they actually need, keeping production isolated from development and staging.