Modal Team plan: how do I enable rollbacks and the static IP proxy, and does it include $100/month free credits?

Most teams hit the same questions as soon as they move from the Free plan to Modal’s Team plan: how do I turn on rollbacks, how do I get a static IP for outbound traffic, and do I still get any “free” credits each month? This guide walks through how those pieces actually work in practice, and what you should expect when you upgrade.

Quick Answer: On the Team plan, rollbacks and the static IP proxy are paid, team-level features that are managed via Modal’s dashboard and your app configuration. The Team plan does not include a recurring $100/month of free credits; instead, you pay for usage with finer-grained controls, team governance, and access to higher-throughput workloads on CPUs and GPUs.

Why This Matters

If you’re running real AI workloads—LLM endpoints, eval infra, agents calling out to third-party APIs—you care about two things: not breaking production every time you deploy, and not having your outbound traffic suddenly blocked by vendors or firewalls. Rollbacks give you a safety net for deploys; the static IP proxy gives your outbound calls a predictable egress address for allowlists and compliance.

On the cost side, you want a plan that scales with actual usage instead of relying on small, fixed monthly credits. Understanding how the Team plan handles all three—rollbacks, static IP, and credits—lets you design your Modal setup once and stop thinking about infra every time you ship a change.

Key Benefits:

• Safer deploys with rollbacks: Quickly revert to a previously working deployment when a new version misbehaves, instead of scrambling to hotfix production.
• Predictable outbound networking via static IP proxy: Present a stable, known IP to third-party APIs, VPNs, or firewalled databases without building custom NAT gateways.
• Production-ready cost model: Move beyond tiny “free” buckets and get a pay-as-you-go platform with team controls, credits programs, and access to serious CPU/GPU capacity.

Core Concepts & Key Points

Concept	Definition	Why it's important
Rollbacks	Reverting a deployed Modal app or endpoint to a previous version of its code and image configuration.	Lets you undo bad deploys in seconds, minimizing downtime and regressions for production inference, batch jobs, and agents.
Static IP proxy	A Modal-managed outbound egress service that routes your app’s external traffic through one or more fixed IP addresses.	Enables IP allowlisting with vendors, databases, or corporate firewalls without managing your own NAT infra.
Team plan credits & billing	The cost model for Team workspaces: usage-based billing, optional startup/academic credits, and no recurring $100/month “free” allowance.	Determines how you budget CPU/GPU usage and how you think about scaling from dev experiments to production loads.

How It Works (Step-by-Step)

From a developer’s perspective, rollbacks and static IP are just configuration and a couple of clicks. Under the hood, Modal is tracking versions of your code and routing outbound traffic through a managed egress layer.

1. Enabling and using rollbacks

Conceptually, you can think of each modal deploy as creating a new, versioned snapshot of your app: its Images, functions, classes, and endpoint definitions.

At a high level, the workflow looks like this:

1. Define your app in code

   You express everything—environment, hardware, endpoints—in Python:

   import modal
   
   image = (
       modal.Image.debian_slim()
       .pip_install("fastapi", "uvicorn", "transformers==4.39.0")
   )
   
   app = modal.App("my-llm-api", image=image)
   
   @app.cls(gpu="A10G", concurrency_limit=8)
   class LLMServer:
       @modal.enter()
       def load_model(self):
           from transformers import AutoModelForCausalLM, AutoTokenizer
   
           self.tokenizer = AutoTokenizer.from_pretrained("gpt2")
           self.model = AutoModelForCausalLM.from_pretrained("gpt2")
   
       @modal.method()
       def generate(self, prompt: str) -> str:
           inputs = self.tokenizer(prompt, return_tensors="pt")
           outputs = self.model.generate(**inputs, max_new_tokens=64)
           return self.tokenizer.decode(outputs[0], skip_special_tokens=True)
   
   @app.fastapi_endpoint()
   def fastapi_app():
       from fastapi import FastAPI
       api = FastAPI()
   
       @api.post("/generate")
       async def generate(prompt: str):
           return {"text": await LLMServer.generate.remote(prompt)}
   
       return api
   

   To deploy:

   modal deploy my_llm_app.py
   

2. Each deploy becomes a rollback point

   Every time you run modal deploy, Modal creates a new revision of the app. In the Team plan, those revisions are addressable in the dashboard so you can:

   • Inspect which commit or code version is live.
   • See the Image configuration (pinned Python version, packages, GPU type).
   • Roll back to a prior revision if the latest one starts failing.

3. Performing a rollback via the dashboard

   The exact UI varies over time, but the pattern is:

   • Go to the Apps page in the Modal dashboard.
   • Open your app (e.g., “my-llm-api”).
   • Find the Deployments or Revisions section.
   • Select a previous version and choose Roll back or Promote.

   Modal updates routing so that the previous revision serves new traffic. Existing containers for the bad revision will be drained according to the app’s scaling behavior.

4. Best practices when relying on rollbacks

   • Pin dependencies. Use exact versions in pip_install or requirements.txt. If you roll back code but your dependencies have drifted, behavior can still change.
   • Separate staging vs. production apps. Use different app names (e.g., my-llm-api-staging vs. my-llm-api) so you can test deploys in staging before shipping to production.
   • Use modal.Retries and timeouts. Rollbacks are for bad deploys, not for handling transient failures. Configure retries and sane timeouts on your functions.

2. Enabling and using the static IP proxy

The static IP proxy is about outbound traffic. You still define your endpoints the same way, but when your code calls out to an external service, that call is routed through a fixed egress IP that you can share with vendors.

A typical pattern:

1. Identify workloads that need fixed IPs

   Common cases:

   • Calling third-party APIs that require IP allowlisting.
   • Connecting to a database behind a corporate firewall.
   • Integrating with internal services via VPN where you want a single, predictable source IP.

2. Enable the static IP proxy in your Team workspace

   Operationally, you do this in the Modal dashboard for your Team workspace. The pattern usually looks like:

   • Go to Settings → Networking (or similar).
   • Enable Static IP / Egress proxy for the workspace or a specific region.
   • Note the published IP(s) that Modal exposes; you’ll share these with your vendors.

   Once enabled at the workspace level, traffic from your Team’s apps can be routed through that egress layer. You don’t have to change your Python code just to get a fixed IP; you keep calling requests, httpx, or your client library as usual.

3. Configure vendor allowlists

   With the static IP(s) in hand:

   • Provide the IP addresses to your vendor or network team.
   • Ask them to allowlist those addresses for ingress on their side.
   • Test from a Modal app by hitting their API and verifying access.

   A simple test function:

   import modal
   import requests
   
   app = modal.App("egress-test")
   
   @app.function()
   def call_vendor():
       resp = requests.get("https://api.vendor.com/health")
       resp.raise_for_status()
       return resp.json()
   

   Run locally against Modal:

   modal run egress_test.py::call_vendor
   

   Inspect logs in the Apps page if anything fails.

4. Operational notes

   • Region awareness: Keep your egress region and your upstream endpoints aligned to avoid unnecessary cross-region latency and egress charges.
   • Scaling behavior: The static IP proxy is built to handle spiky workloads—thousands of concurrent requests from @modal.fastapi_endpoint or .spawn() fan-out—without you worrying about NAT caps.
   • Security posture: Outbound traffic still runs in gVisor-isolated containers, and you can pair static IP with Proxy Auth Tokens (requires_proxy_auth=True) on inbound endpoints for a fully locked-down surface.

3. Understanding Team plan credits vs. “$100/month free”

The Team plan is designed for production usage. That means:

• No recurring $100/month “always free” bucket. Once you’re on Team, you’re on a usage-based model that assumes you’re running real workloads.
• Startup / Academic credits are separate. Modal does offer credits programs—“$500–$25k credits available”—for eligible startups and academic teams. Those are one-time or time-bounded grants, not a permanent monthly stipend.
• Free plan is where small recurring free usage lives. The Free plan offers a “Healthy Free Plan” (e.g., $30 of free compute/month) designed for experimentation. The Team plan trades that for more features, capacity, and governance.

So, if your mental model is “I’ll get $100 of fresh credits every month on Team,” that’s not how it works. Instead, you:

• Apply for credits if you’re a startup or academic project.
• Run on Team with usage-based billing, with better controls and higher limits.
• Use the Free plan only for low-intensity personal experiments where the monthly free quota is enough.

If you’re unsure what you qualify for, you can apply through the Modal for Startups or Academics programs. Those can unlock “thousands of free GPU credits to supercharge your startup,” plus access to Modal’s engineering team and community, but again: that’s distinct from the Team plan billing model.

Common Mistakes to Avoid

• Assuming rollbacks replace proper testing: Rollbacks are a parachute, not your primary deployment strategy. Still use staging apps, smoke tests, and incremental rollout where possible.
• Relying on static IP without sharing it with vendors: Enabling the static IP proxy in your workspace is only half the story—you must also update allowlists on vendor APIs, VPNs, or firewalls.
• Planning budgets around non-existent monthly free credits: The Team plan doesn’t ship with a recurring $100/month buffer. Budget based on your actual CPU/GPU hours, and treat any startup/academic credits as a runway extension, not a permanent discount.

Real-World Example

Imagine you’re running a coding agent service that fans out to thousands of containers to evaluate model changes. Each eval run:

• Hits a third-party code execution API that requires an IP allowlist.
• Runs on A10G GPUs for a few minutes to simulate realistic workloads.
• Exposes a @modal.fastapi_endpoint to orchestrate eval batches and collect metrics.

You:

1. Enable the static IP proxy on your Team workspace.
2. Give that IP to the code execution vendor to allowlist.
3. Deploy your eval orchestrator with modal deploy and run your first batch.
4. A week later, you ship a new version that accidentally increases GPU memory usage, causing OOMs and timeouts.
5. You go into the Modal dashboard, roll back to the last known-good deployment, and your evals recover immediately while you debug the regression in a separate branch.

You’re not spending time wiring NAT gateways or manually resizing GPU clusters; you’re just writing Python and using rollbacks + static egress as guardrails.

Pro Tip: Treat each modal deploy as a release candidate: tag your Git commits, pin your dependency versions, and use Modal’s rollbacks as a safe way to revert to a tagged version when production telemetry tells you something went wrong.

Summary

On the Modal Team plan, rollbacks and the static IP proxy are core tools for running serious AI workloads: rollbacks let you unwind bad deploys quickly; the static IP proxy gives you predictable outbound networking for vendors and firewalls. The trade-off is that the Team plan doesn’t include a recurring $100/month of free credits—you move to usage-based billing, with the option to add one-time startup or academic credits if you qualify.

If you’re upgrading from the Free plan, the model shift is simple: keep defining everything in Python, wire in rollbacks via the dashboard, turn on static IP egress where you need it, and budget based on real usage instead of assuming a permanent free tier.

Next Step

Get Started