# Modal Labs Workflow: Costs, Limits and Setup (2026)
By Tessa Bergmann · 2026-11-12 · Source: https://www.activepieces.com/blog/modal-labs-workflow-costs-limits-and-setup-2026
---
There's no drag-and-drop builder, which sets it apart from visual tools like [Activepieces](https://www.activepieces.com), and a Python engineer can **finish a Modal workflow in about 30 minutes**, so there's no engineering moat.
It is Python functions decorated with `@app.function`, chained with `.remote()` and `.map()`, scheduled with `modal.Cron` or `modal.Period`, and shipped with `modal deploy`.
A Modal workflow is a set of Python functions that run as a job on Modal's serverless cloud, chained together in code, triggered on a schedule or on demand, and deployed with a single command.
## Modal Labs workflow: the fastest path and prerequisites
### What you will have working at the end
You'll have a deployed Modal app that runs on a schedule without your laptop. The classic 2am failure's a job that only ever ran from a terminal session, so the schedule never existed. Deploying fixes that, because the schedule lives with the app.
### Modal Labs prerequisites for Python teams
You need a Python engineer comfortable reading a stack trace, Python installed locally, a [Modal](https://modal.com/pricing) account, and the `modal` package with the command line authenticated.
If nobody on your team writes Python, this path costs more than it returns, and hiring for it is the wrong fix, since you don't hire for this, you describe it.
[Activepieces](https://www.activepieces.com) builds and publishes the automation from a process you describe in its built-in chat, and what lands in your account is the same live flow a builder would have assembled by hand, under the same RBAC and audit logs as every other flow.
Every run leaves a trace anyone can read, no stack trace required, and MoneyGram and Moneypenny run it in production.
### Modal pricing and documentation sources checked
As of 2026-11-12, the function, scheduling and deploy behavior here match Modal's documentation and its pricing page. Limits and billing rules change, so treat anything older as suspect.
Treat the revenue figures with care: they come from [Sacra](https://sacra.com/c/modal-labs/), which publishes estimates, not audited numbers. They show a company growing fast:
- June 2025: $90 million annualized.
- December 2025: $160 million, so **run rate nearly doubled in six months**.
- May 2026: $330 million.
- July 2026: $545 million.
- September 2026: $825 million.
- October 2026: $1,000 million, or $1 billion annualized.
Read that as a signal that the platform is heavily used and actively changing, not as proof it fits your team.
## Modal plans by team size and usage
As of 2026-11-12, a solo user fits Starter at $0 a month, so adoption isn't gated by cost for individuals.
A team that hits Starter's concurrency ceiling needs Team at $250, and anyone who needs more than 50 GPUs running at once is into Enterprise's custom pricing, which means growing teams inevitably enter paid tiers.
| Plan | Monthly fee | Included credits | Concurrent containers / GPUs | Catch that pushes you up |
|---|---|---|---|---|
| Starter | $0 | $30 | 100 / 10 | The 10-GPU ceiling stalls parallel jobs |
| Team | $250 | $100 | 5,000 / 50 | Past 50 GPUs at once, you negotiate |
| Enterprise | Custom | Quoted per contract | Quoted per contract | No listed price, so you go through sales |
### Which plan fits which team
If you're a solo engineer running a nightly job, stay on Starter. The $30 of credits covers experiments, and 10 concurrent GPUs is more than one person's chained workflow normally needs, so researchers won't be GPU-constrained for typical workflows.
A team of 5 can usually stay there too, until two people fan out GPU jobs at once and the queue silently serializes them.
When the load gets heavier, Team is the next step. The $250 fee buys $100 of credits and a jump to 5,000 containers and 50 GPUs.
I couldn't verify seat counts or which tier unlocks SSO and admin controls. A team of 25 with those requirements should check the [Modal pricing page](https://modal.com/pricing) before budgeting, not assume Team covers it.
### Modal GPU pricing per second
Because **Modal bills usage per second**, the GPU you pick matters more than the plan. A [T4](https://modal.com/pricing) costs $0.000164 a second, about $0.59 an hour. An L4 is $0.000222, about $0.80 an hour, and an A10 is $0.000306, about $1.10.
Further up the list, the L40S is $0.000542 (about $1.95), the A100 40GB is $0.000583 (about $2.10), and the A100 80GB is $0.000694 (about $2.50).
Using an A100 80GB for a job a T4 could handle costs roughly four times as much, and per-second billing makes that mistake add up quickly in a scheduled job that runs every hour.
For GPUs above the A100 80GB, up to the B300, prices are listed on Modal's pricing page. Read them from the pricing page, not from an older tutorial.
## Six workflow stages that work
Test after every stage rather than writing all six and debugging them together at 2am, because each stage adds one capability and fails in one predictable way.
### Stages 1-2: install, authenticate, run one function
Install the client with `pip install modal`, then run `modal setup`. It opens a browser, ties your machine to a workspace and writes a token to your home directory.
If the command isn't found, your virtualenv isn't the one on your PATH.
Next, write one function and run it. Decorate it with `@app.function()`, attach it to a `modal.App`, and add a `@app.local_entrypoint()` that calls it:
```python
import modal
app = modal.App("report-pipeline")
@app.function()
def fetch(n):
return n * 2
@app.local_entrypoint()
def main():
print(fetch.remote(21))
```
Run it with `modal run script.py`. The function executes in Modal's cloud, not on your laptop. So a missing package fails remotely even though it imports fine locally, which is why you declare dependencies in the image, not in your own environment.
### Stage 3: deploy and find it in the dashboard
Close the laptop and `modal run` stops, because it lasts only as long as your terminal session. `modal deploy script.py` publishes the app so it keeps existing without you.
After deploying, open the dashboard and find the app by the name you gave `modal.App`.
Deploying again under the same name replaces the old version, so a typo in the app name quietly creates a second app, and the one you meant to update stays unchanged.
### Stages 4-5: chain functions and attach a Secret
To chain functions, you write plain Python. Inside one Modal function, call another with `.remote()` to run it and wait for the result.
Use `.map()` to fan out across a list, with each item running as its own container call. A failure in one item can abort the whole map unless you handle it, so decide up front whether one bad record should stop the batch.
For credentials, create a Secret in the dashboard or with `modal secret create`, then attach it:
```python
@app.function(secrets=[modal.Secret.from_name("my-api-keys")])
def call_service():
import os
key = os.environ
```
If you hardcode the key in the file instead, it ships with your source. Secrets arrive as environment variables inside the container only. If you misspell the Secret name, the function fails at startup, before any of your code runs.
### Stage 6: schedule it with Cron or Period
Add a schedule to the function's decorator. `modal.Cron("0 8 * * *")` takes a standard cron string, and `modal.Period(hours=6)` runs at a fixed interval:
```python
@app.function(schedule=modal.Cron("0 8 * * *"))
def nightly():
...
```
**Redeploy with `modal deploy` for the schedule to take effect, because `modal run` ignores it.**
If a job must land at a specific hour, use Cron. Cron fires at clock times, while Period counts from the last deploy, so a redeploy shifts a Period job's timing.
## Modal limits and errors people hit, with fixes
Schedule a job for 9 a.m. local time and it fires at the wrong hour, because Cron schedules run in UTC. That's one of a few limits behind most Modal failures.
| Symptom | Cause | Fix | Documented limit |
|---|---|---|---|
| Run killed mid-job | Function exceeded its timeout | Raise `timeout` or split the job | Default 300 seconds |
| Job reruns or fails repeatedly | Retries on a non-idempotent step | Set `modal.Retries` and make the step safe to repeat | Retries are opt-in, per function |
| Job fires at the wrong hour | Cron read as UTC | Convert to UTC | Cron is UTC |
| Sixth schedule won't deploy | Schedule cap reached | Merge jobs into one scheduled function | 5 schedules |
| Calls queue; GPU unavailable | Workspace concurrency or GPU cap | Lower fan-out or upgrade | Varies by plan |
| First call is slow | Cold start | Keep a container warm | See benchmark below |
| Function fails at startup | Secret missing from workspace | Create it and attach it to the function | Per workspace |
| Old code keeps running | Changes never redeployed | Run `modal deploy` again | Deploys are explicit |
| Deploy fails at image step | Bad package pin or build command | Fix the pin and rebuild | Build logs show the failing line |
Unless you raise the 300-second default, a long batch job **dies silently at five minutes**. Retries then rerun the whole function, so a step that sends an email or charges a card will do it twice. Make writes idempotent before enabling retries.
The cap of five schedules means Modal refuses a sixth deploy, so fold small jobs into one scheduled function that dispatches the rest. A forgotten redeploy hides here too: edit the code, skip `modal deploy`, and the schedule keeps running the old version.
### Modal plan, concurrency and GPU limits
Check your workspace's limits before sizing a batch, because a fan-out that works in testing can queue in production: concurrency and GPU availability depend on your plan.
Cold starts matter next. A [2026 benchmark on dev.to](https://dev.to/mrzitoun/benchmarking-serverless-gpus-modal-vs-runpod-vs-replicate-cold-starts-2026-a5c) measured a median GPU cold start of 1.8 seconds on Modal, 4.2 on RunPod and 6.5 on Replicate.
Under two seconds is tolerable for a user-facing call, while 6.5 seconds feels like a hang. This is one author's test, so measure your own model.
Set the scaledown window as short as your latency tolerance allows, since keeping containers warm removes the cold start but bills for idle time.
## Production deployment and external triggering
Unattended is where defaults bite. Pin versions, set timeout and retries, add alerts and check the bill before anything outside Python triggers the job.
### Modal production deployment checklist
Usually the first failure is silent. A dependency floats to a new release overnight, the job starts throwing, and nobody finds out until someone asks why the report is empty.
- Pin dependency versions in the image definition, so a rebuild next week installs what you tested today.
- Set an explicit timeout and retry count on every function, so Modal kills a hung call and a flaky one gets another attempt instead of running up billed compute indefinitely.
- Add a failure alert that reaches a person, because a scheduled job that errors on its own produces no output and no complaint.
- Review the bill against your plan credit after the first few runs, so a retry loop shows up as a line item before it becomes a surprise.
- Expose a web endpoint for an HTTP step in an automation tool only if something outside Python has to start the job.
The last item is optional, and the next two subsections cover it.
### Expose a Modal function as a web endpoint
If a scheduled run is enough, skip this part.
Wrap the function in Modal's web endpoint decorator, accept POST, and read a JSON body. This is for when a form submission, a CRM record change or an incoming email has to start the job. Then deploy it so it has a stable URL.
Check an auth token in the handler against a value stored as a Modal secret. An endpoint with no check lets anyone who finds the URL start billable compute, and the first sign's usually your own invoice.
Return quickly. If the work is long, have the endpoint accept the request and hand back an identifier, rather than holding the connection open until a caller's own timeout cuts it off.
### Trigger a Modal job with an HTTP request
Nothing in this step needs Python. Activepieces watches the form, CRM or inbox, calls your URL and routes whatever comes back. The Python stays in Modal.
Configure an HTTP step with method POST, the deployed URL, a JSON body holding the fields your function expects, and the auth token in a request header.
Test it with a deliberately wrong token and confirm the call is rejected. A step that succeeds with bad credentials means the check you wrote isn't running.
## What Activepieces does about this
The problem in this article is a split: Modal works well when someone on the team writes Python, and it stops working the moment that person is the only one who can read or change the flow. Activepieces covers the other side of that split.
Modal works well when someone on the team writes Python, and it stops working the moment that person is the only one who can read or change the flow.
You describe the process in plain language in its built-in chat, and it builds and publishes the automation for you.
What lands in your account is the same live flow a builder would have assembled by hand, so a teammate who has never opened a terminal can open it, read each step and change it.
It also answers the failure the article keeps returning to, a job that reports success while doing nothing.
Every run of an Activepieces flow leaves a trace you can read step by step, with no stack trace and no dashboard hunt for a schedule that was never registered.
Flows run under the same RBAC and audit logs as every other flow in the workspace, so a change has an owner and a history, which is the property the article credits to code you can review and version.
The two tools also fit together rather than compete.
If your team already has a Modal function doing the heavy Python work, an Activepieces HTTP step can call its deployed URL with a token in a header, and the form, CRM or inbox trigger stays on the Activepieces side.
The Python stays in Modal, and the people who don't write it still own the flow around it.
MoneyGram and Moneypenny run Activepieces in production, which is the clearest evidence we can point to that this holds up outside a demo.
To try it, describe one process you would otherwise hand to an engineer, such as the report that fires every morning, and read the flow it builds before you publish it.
## Frequently asked questions
These four questions keep circling one failure: **a workflow that reports success while doing nothing**. Each answer below is about where Modal will quietly do what you told it rather than what you meant.
### Does Modal Labs have a visual workflow builder?
No. Modal is a Python library and a cloud runtime, so a workflow is functions in a file that you chain with ordinary code and deploy from the command line. There's no canvas to drag steps onto.
A teammate who doesn't write Python can't read or change the flow, which is the point where a plain-language tool becomes the better fit. Everything lives in code you can review and version, so changes leave a history.
### Is Modal free to try in 2026?
Yes, Modal's pricing page describes a free plan with a monthly credit allowance, enough to build and test a small workflow before you add a card.
The catch is that the credit is spent by compute time, so a function stuck in a retry loop uses it up like any real job. Check the current allowance and limits on Modal's pricing page before you plan around them, since plans change.
### Can Modal run a scheduled job without a server?
Yes. You attach a schedule to a function, either a fixed interval or a cron expression, and Modal starts a container when the time comes. You don't keep a machine running between runs.
Skip the deploy and the schedule never exists. Running the file once from your terminal executes the function but doesn't register the schedule.
The job then never fires, and nothing errors, because nothing was ever asked to run. After deploying, confirm the next run shows up in the dashboard.
### How do I stop a Modal workflow from running up my bill?
Cap every place a function can run without anyone watching:
- Set an explicit timeout on each function, so a hung call ends instead of billing until it hits the default.
- Limit how many containers can run at once, so a burst of inputs can't fan out into dozens of parallel jobs.
- Keep retries small and finite, because an unbounded retry on a failing step's the quietest way to burn credit.
- Leave warm containers off unless you need low latency, since Modal bills a container kept alive whether or not it's doing work.
Then look at the usage page after the first scheduled week, not the first day.
A job that's cheap once and runs on a schedule is a different cost than the one you tested, and the timeout and concurrency settings are what make that cost predictable.
## Related reading
- [Modal Labs Pricing 2026: GPU Rates, Plans and Credits](https://www.activepieces.com/blog/modal-labs-pricing-2026-gpu-rates-plans-and-credits)
- [SAP S/4HANA Purchase Order Workflow for MS Teams](https://www.activepieces.com/blog/sap-s-4hana-purchase-order-workflow-for-ms-teams)
- [Content Creation Workflow: How Successful Teams Do It](https://www.activepieces.com/blog/content-creation-workflow)
## References
- [dev.to (mrzitoun)](https://dev.to/mrzitoun/benchmarking-serverless-gpus-modal-vs-runpod-vs-replicate-cold-starts-2026-a5c)
- [Sacra](https://sacra.com/c/modal-labs/)
- [Modal](https://modal.com/pricing)