How task containers give AI agents real infrastructure without idle cost

Infrastructure for AI agents usually forces a choice between two bad options. A sandbox is safe but blind, cut off from the data and services that would make the agent's output useful. Full access means paying to keep a container idle between runs, waiting on a prompt that might not arrive for hours. 

Task containers, which Upsun released on August 12, 2026, are built to avoid that choice.

A task container is a single-purpose container defined in a project's .upsun/config.yaml file. It runs exactly one command, and when that command exits, the container is gone. There is no daemon to keep alive and no idle container to pay for. 

The documentation describes the lifecycle: a task is "injected into your environment's cluster, runs a single command, and is removed when the command exits." Billing covers only the seconds the command runs.

That covers more ground than AI work alone. The documentation lists three kinds of job a task is meant for:

• A background AI agent session: an agent that reads a codebase, calls tools such as shell commands or database queries, and writes the results back to the project
• A one-time job that needs service access: database maintenance, a data export, a report
• A batch job triggered from an application rather than on a schedule

Why AI agents made the case for tasks

Nicolas Gommenginger, director of product at Upsun, says his team had been thinking about task containers for some time before this year's wave of agent activity. What moved the idea into implementation was AI agents.

"That's something we've been thinking about adding for quite some time, because it can be seen a bit like a serverless function where you call it and it runs something. And when it's done, there are no idle resources," Nicolas said. “But what really triggered us to go ahead and implement it is the rise of AI agents, because tasks are something ideal for running AI agents.”

An agent's workload has the shape of a task. It starts, does a defined piece of work, and stops. Keeping a container warm between prompts does buy lower startup latency, but for work that arrives in bursts it means paying for the gaps. Nicolas was careful to note that the feature is not agent-specific. A task suits a large export or a one-off migration just as well. Anything that runs once and then stops fits.

What task containers do that sandboxes don't

A sandbox's job is isolation, keeping an agent from reaching the internet or the rest of the filesystem. It is a case Upsun has made in its own writing on zero-trust sandboxes for AI agents. A task container does not give you that shape of isolation out of the box, though it is far from unprotected: tasks run with the same namespace isolation, capability dropping, seccomp profile, cgroup limits and network isolation as application containers. Nicolas said Upsun Cloud's container security primitives “are already at a very high level.”

Turning a task into a true sandbox means adding a bit of configuration on top. Firewall rules to limit outbound connections, and mount and variable configuration to limit what the process can read. For untrusted code, the documentation suggests considering bubblewrap inside the task container, to restrict the filesystem, environment variables and syscalls visible to the agent process.

What a task does have by default is access to the rest of the project. That access is the part Nicolas kept returning to.

"The big advantage of a task is that it has access to all your services on Upsun Cloud," he said. “You can create a preview environment, run your tasks on this preview environment with access to production-like data, since we clone the data from your parent environment.”

Combine the two and an agent gets something a sandbox alone cannot give it: a closed, disposable environment that still holds a working copy of production. Upsun has argued that point at length in its case for stateful AI sandboxes, and preview environments are what make it practical, cloning a parent environment's data, files and services in under a minute.

"An agent running in a sandbox is usually quite constrained," Nicolas said. “But if you add the preview environment as an environment sandbox, you can run the agent in a closed environment, but still with access to a replication of your production services, which is very valuable for agents: to have access to logs, to see data, to be able to loop and reach a real working state, not just based on the code.”

The demo: a prompt becomes a pull request

In the recorded demo, Nicolas showed a small admin application that triggers task containers. A plain-language request typed into it, such as adding a gradient background to a front end's hero section, fires a task. The task calls the Anthropic API, clones the front end repository, applies the change and opens a pull request. Upsun Cloud then builds a preview environment for the new branch automatically, and the gradient appeared on the preview URL a few minutes later.

The task stops there. It does not deploy anything, and merging the pull request is what would ship the change to production, with a human deciding whether that happens. In the demo it did not happen: GitHub was failing throughout the recording, so the merge stayed theoretical. "I can just merge a pull request, which is not possible today with GitHub," Nicolas said. “But theoretically, you just merge, and it would deploy this on your main production front end.”

The same project uses a second task, with no AI involved, to export every prompt sent to the admin tool along with the model's output as a JSON file. Anyone wanting to run evaluations against past sessions can replay it later. A task container does not care whether the command it runs touches a model.

In configuration, a task needs a runtime type and a run.command. Optional fields cover source.root, authorizations, build hooks, relationships to other services, mounts and variables. So does run.timeout, which defaults to one hour and can be raised to 86,400 seconds, one day, after which the platform sends SIGTERM and then SIGKILL. Relationships run one way. A task can reach an application or a database, but nothing can address a task, because a task exists only while it runs and Upsun Cloud does not route inbound traffic to it.

A task that needs to hand off results has to push them out itself, for example to an app over an HTTP relationship, or into a shared service or mount. Parallel runs are capped at three by default, with further triggers queued rather than dropped, and the limit is lower during a trial.

The performance agent comes next

Upsun is building its own agents on this same infrastructure, starting with one aimed at performance.

"The first one coming soon is the performance agent that you will be able to use to have detailed reports and performance recommendations for your application," Nicolas said.

It runs as a task against a project's observability data and returns recommendations for improving performance. The pattern is the same as the demo: trigger a job, let it run with access to the project's services, take the result, and stop paying for the container.

Task containers are available on every Upsun Cloud project now, alongside the rest of Upsun Cloud's platform capabilities. Configuration details, including authorization scopes and API triggering, are in Upsun's task documentation. 

The full conversation with Nicolas, including the demo, can be viewed here.