Tasks (Automations)
A task is a short, ordered pipeline you own: a few steps
that run in order — a vm step (a script in a sandboxed
microVM), a web step (a host-side search or page read), or a
model step (a call into your managed pool) — triggered on a
schedule (cron) or manually, with a delivery for the result.
The three seeded presets on the Tasks page are the named use cases: a daily research briefing (web → model → mail), a spreadsheet check (vm → model → channel), and a quick script (vm → history only). Each starts as a working template you can edit, schedule, and share within your org.
How a task runs
Steps run in order. Each step's output (capped text) is
addressable by its id; a model step can splice in the output of any earlier
step. Once every step succeeds, the final step's output (or
the delivery's named from step) is delivered.
- vm — a script (python3 or sh) in a light, air-gapped
Firecracker microVM, under your chosen tier. Any input
files you name are packed into the guest; files it writes under
/outcome back into the file store as run artifacts. - web — a search or page read, run host-side
by the gateway (Jina:
s.jina.ai/r.jina.ai). The guest never makes the call. - model — a call into your managed pool, metered to the user who triggered the run.
Limits
Every task runs under per-user ceilings so one person
cannot overwhelm the host. All of these are operator config ceilings
(the tasks.* gateway config); a user cannot raise
them — the API never accepts a per-user limit override.
| Bound | Default | What happens at the ceiling |
|---|---|---|
| Concurrent running runs per user | 1 | A second concurrent run is refused → a skipped row. |
| Runs per user per day | 50 | A run over budget is refused → a skipped row. |
| VM-slot wait (shared pool of 4) | 90 s | If a VM slot is still busy after 90 s the run is refused →
skipped:busy, never a hang. |
| Step run timeout | VM 5 min · web 2 min · model 3 min | The run is recorded timeout. |
| Per-run output caps | VM/model step text 256 KiB; web result 20 KiB | Output is truncated (the truncation is recorded). |
A refused or timed-out run is a recorded skipped /
timeout row in the task's run history — visible, never a
silent drop. (Skips do not count against the daily 50-run budget; only real
runs do.)
Metering
Model steps are metered to the user who triggered the run: a cron run meters to the task's owner; a manual run by a share grantee meters to that grantee. A shared task's manual runs therefore never spend the owner's budget.
The VM tiers
The vm step draws from a light Firecracker budget, set by the
task's tier (the tier is stored on the task; the API rejects anything above
the ceiling):
micro(default, 96 MiB, 2 vCPU) — scripts, math, small CSV/JSON work. The everyday tier.spreadsheet(256 MiB) — python3 +openpyxlover real workbooks. This is the cap; both tiers fit the "under 256 MiB" envelope. No pandas — it exceeds the 256 MiB budget.
The VM steps run in a shared pool of 4 slots (the same pool the code
transaction VMs use). If the pool is full, your VM step waits up to 90 s for a
slot; if it still can't get one the run is skipped:busy.
Delivery
Once the pipeline succeeds, the result text (the final step's output, or a named step's) goes to one of:
- mail — a message to your mailbox (or an org addressee).
- channel — a post into a messaging room.
- doc — saved as a file-backed document.
- none — the result is recorded in the run history only.
Security
The guest microVM is air-gapped — it has no network egress, and the sandbox is the point: a script cannot ring home. Web research is the gateway's own host-side Jina call, never a guest egress. A run that would need the network does it on the host; the guest only ever sees the packed files you handed it.