Task containers turn idle jobs into on-demand compute

Somewhere in most production setups there is a container that stays awake all week to do one job on Friday.

Maybe it re-indexes a database. Maybe it runs a batch report, or a data migration that only matters at month end. Either way, the resources are billed for seven days.

Task containers close that gap. They are ephemeral, API-triggered containers that spin up inside an Upsun Cloud environment, run exactly one command, and remove themselves when that command exits. Nothing sits idle between runs. They went generally available on August 12, 2026, after a prerelease that opened on Upsun Flex in June.

Corey Dockendorf, senior solutions architect at Upsun, hears the same complaint over and over. A service is provisioned for a job that runs once a week, and then it waits. The question customers land on, in his telling: “Why am I paying for this all week when it does one thing on Friday?”

What task containers actually are

A task is declared in .upsun/config.yaml at the same level as your applications and services. Two fields are required: a runtime image, using the same syntax applications use, and the command to run. When the task is triggered, Upsun Cloud injects a container into the environment's cluster, runs the command to completion, and removes the container.

"It's basically an ephemeral, on-demand compute piece," Corey says. "They spin up when they're triggered directly by an API call. They run exactly one command, and then automatically shut themselves down once they're done."

The mechanics are deliberately narrow. You can trigger a task three ways:

• From the Console
• From the CLI, with upsun task:run
• With a POST request to https://api.upsun.com/projects/{project}/environments/{env}/tasks/{taskname}/run, optionally passing variables in the request body

Every invocation creates an activity with its own ID, live status, streamed logs, and the ability to cancel it. The default timeout is one hour and the maximum is 24 hours. Billing is per second of each run, at the same CPU and memory rates as your applications.

What tasks are not: they are not daemons, they are not scheduled, and they are not routable. Long-running background processing still belongs in a worker, and anything that needs to fire on a fixed schedule still belongs in a cron. The difference between crons and workers is worth understanding before you reach for a task, because tasks solve the third case: work that needs to happen now, once, and then stop existing. 

The schedule itself lives outside the task. A cron, a CI job, or your own application makes the API call, so the cadence stays scheduled while the compute stays on demand.

The jobs you already run once a week

Corey's experience is that the concept lands fastest when it is attached to something mundane.

"Everybody re-indexes the database," he says. "It's just one of the things you have to do. It's standard database cleanup."

It is also the example that changes minds. "That's the one that gets customers really hooked, because they're like, oh yeah, I do that. I have that. I do trigger that. Maybe once a week, every two weeks, every month," Corey says.

He sees the same pattern in SMB, mid-market and enterprise accounts, which makes sense once you list the candidates. Database maintenance. Data exports. Month-end reports. Migrations that run once during a release and never again.

Tasks can reach the rest of the environment while they run. Declared relationships give a task access to services and applications, so a re-index actually has a database to talk to, and the credentials appear in PLATFORM_RELATIONSHIPS inside the task container. Relationships only run one way. Neither applications nor other tasks can declare a relationship to a task, because a task only exists while it runs. If your app needs the result, the task pushes it somewhere.

Applications can still start tasks. Grant the app an authorization to operate a specific task, and it requests a short-lived token at runtime from the local token endpoint at localhost:8200 rather than holding a long-lived credential. Those tokens expire after 60 seconds by default, and you can stretch them to 900 seconds with the x-token-ttl header if you want fewer round trips.

Agents need production context, not production access

The second use case is newer, and it is where Corey takes the conversation next in the latest Product Highlights episode.

An AI agent doing real work "actually needs production context," he says. "Logs, metrics, deploy history." What it should not get is the live application. "You also really don't want to give an agent free rein over the live app," Corey says. Handing one the keys and stepping back is, in his words, "a terrifying thought."

This is the problem most teams hit at the same point. An agent that cannot see production is useless for anything operational. An agent with credentials to production is a liability nobody wants to sign off on. Upsun has written about the zero-trust version of this argument before: the question is less about trusting the model and more about whether the platform around it can hold the boundary.

A task container is one place to put that boundary. The agent session runs in its own container with the relationships and API permissions you granted it and nothing else. Tasks run in Linux Containers with the same isolation as applications: dropped capabilities, a seccomp profile, cgroup limits, network isolation. For code you genuinely do not trust, the docs suggest pairing a task with bubblewrap to narrow filesystem and syscall access further.

"With a task container, you can give that agent real context, but also with proper container level isolation," Corey says. "And then that agent can spin up a preview environment, validate their own changes before anything gets merged to production."

That last step matters more than the isolation on its own. An agent proposing a change is cheap. An agent granted the permissions to branch an environment can prove the change works against production-like data first, with a human still holding the merge, and that is the part that makes the output usable.

Cost control that holds up when agents multiply

Per-second billing reads like a pricing detail until agents enter the picture. Agent workloads are bursty by nature, and the risk is not one expensive run. It is hundreds of cheap ones nobody is counting.

Task resources are configured like any other container's, so a small job gets a small allocation. And parallel runs are capped, by default at three and lower during a trial, with further triggers queued rather than executed. That cap is a cost guardrail as much as a scheduling one.

What Upsun is building on it

Upsun has built its own agents on top of the same primitive. As host Jack Creighton said on the episode, the first agent out the door will be a performance agent, with more after it.

The pattern is the useful takeaway even if you never run an agent. Compute that exists only while it works removes a category of decision you used to make in advance: how much to provision for something that mostly does nothing. You stop sizing for idle.

Start with the tasks documentation and the one job in your stack you already know you run once a week.