Docker Sandboxes Beyond the Laptop: Running AI Agents in the Cloud

In my previous article, I walked through running coding agents inside Docker Sandboxes on a local machine. We installed the sbx CLI, started with a small project, and covered the commands needed to run, stop, and remove a sandbox.

This time, I want to take that same workflow off the laptop.

Docker added cloud sandboxes in version 0.42.0. You can now use sbx --cloud to run an agent on Docker-managed infrastructure instead of using your machine for the sandbox’s compute.

The command is simple to use. The part that is worth understanding is how you get your code into that environment, work with the agent, and bring the changes back locally. That is what we will do here. Nothing complicated; we will start with a small Python project, one coding task, and a cloud sandbox. We will remove the sandbox when we are done with the work.

What Changes With a Cloud Sandbox?

The sbx CLI still runs in your terminal. With --cloud, supported commands target Docker’s cloud service rather than your local sandbox environment.

For example:

sbx ls

Lists your local sandboxes.

sbx --cloud ls

Lists your cloud sandboxes.

That distinction matters throughout this walkthrough. If you forget --cloud, you are not asking about the same environment.

Cloud sandboxes also have separate credentials and network policies. Do not assume that an agent login or network policy you configured locally is already available in the cloud.

For this example, we will copy individual files explicitly. That keeps it easy to see what we send to the sandbox and what we bring back.

Before You Start

You will need:

• An updated sbx CLI with cloud support, introduced in version 0.42.0.
• A Docker account with an active Docker Agentic Platform plan for cloud compute.
• Authentication for the coding agent you want to use. This walkthrough uses Claude.
• Python 3 available in the sandbox image for the example.

Note: The free sbx CLI does not mean cloud compute is free. Docker bills cloud compute based on usage, and your model provider bills inference separately. Check your account’s pricing before starting.

Also, use a small sample project first. Running remotely means sending code off your machine. For company repositories, make sure that is allowed before uploading anything.

The host-side commands below use PowerShell. Paths inside the cloud sandbox use Linux-style paths.

Step 1: Sign In and Configure the Agent

First, check your installed version:

sbx version

If you are still using an older version from the previous walkthrough, update it before continuing.

Sign in to Docker:

sbx login

For Claude, Docker documents a cloud OAuth flow:

sbx --cloud secret set anthropic --oauth

Complete the provider sign-in with an account that has the required access.

Notice the --cloud flag here, too. These credentials are stored for cloud use, separately from your local sandbox credentials.

There is no reason to put a token in our Python files or paste it into an agent prompt.

Step 2: Create a Small Project

Let us give the agent something specific to fix.

Create a project folder:

New-Item -ItemType Directory -Path .\cloud-sandbox-demo Set-Location .\cloud-sandbox-demo

Inside it, create a file named slug.py:

def make_slug(text):    
  	return text.lower().replace(" ", "-")

This converts "Docker Sandboxes" into "docker-sandboxes".

It works for that input, but it does not handle whitespace very well. Leading spaces become leading hyphens. Repeated spaces become repeated hyphens. Tabs are not handled at all.

Now create test_slug.py:

import unittest 
from slug import make_slug 

class SlugTests(unittest.TestCase):  
  	def test_two_words(self):    
        self.assertEqual(make_slug("Docker Sandboxes"),"docker-sandboxes") 

if __name__ == "__main__":  
   unittest.main()

We have one passing case and a clear improvement to make.

The point is not that this function needs cloud compute. It is small enough that we can focus on the sandbox workflow without spending half the article explaining an application.

Step 3: Start a Cloud Sandbox

Run the following command:

sbx --cloud run --detached --name cloud-demo --ttl 1h claude

This creates a cloud sandbox and starts the agent without attaching your terminal to it.

The flags in the above command are for doing useful things:

• --cloud selects the cloud environment.
• --detached returns control to your terminal.
• --name cloud-demo gives the sandbox a recognizable name.
• --ttl 1h requests a one-hour lifetime.

Important: The documented default action when the TTL expires is deletion. Treat this as a disposable environment, and copy your work out before the deadline.

The command prints a sandbox ID. You can also find it with:

sbx --cloud ls

Copy that ID into a PowerShell variable:

$sandbox = "PASTE_YOUR_SANDBOX_ID_HERE"

Use the real ID returned by Docker, not the placeholder above. Keep using this terminal for the remaining commands.

One detail to remember is a detached cloud run creates a new sandbox. It is not the command to run repeatedly when you want to reconnect to the same one.

Step 4: Copy the Project Into the Sandbox

Create a directory for our example:

sbx --cloud exec $sandbox mkdir -p /workspace/demo

The mkdir command runs inside the Linux sandbox, not on Windows.

Now copy the two files:

sbx --cloud cp .\slug.py "${sandbox}:/workspace/demo/slug.py" sbx --cloud cp .\test_slug.py "${sandbox}:/workspace/demo/test_slug.py"

The ${sandbox} syntax is intentional. In PowerShell, it separates the variable name from the colon used in Docker’s SANDBOX:PATH format.

This is also why I am copying individual files rather than uploading the entire folder. We do not need a virtual environment, local configuration, or an accidentally included .env file for this task.

Run the existing test inside the sandbox:

sbx --cloud exec --workdir /workspace/demo $sandbox python3 -m unittest discover -v

If your selected image does not include Python 3, add it inside the sandbox before continuing.

The existing test only covers two words separated by one space. Passing it does not mean the whitespace handling is correct yet.

Step 5: Give the Agent a Narrow Task

Attach to the running cloud sandbox:

sbx --cloud attach $sandbox

Now give Claude a concrete task:

Work on the Python project in /workspace/demo. 
Update make_slug so that: - The output remains lowercase. - Leading and trailing whitespace is removed. - Consecutive whitespace becomes a single hyphen. - Spaces, tabs, and newlines are handled consistently. - Empty input returns an empty string. 
Add unit tests for these cases using unittest. Keep the existing test. Do not add third-party dependencies or modify files outside this project. 
Run the tests and summarize which files you changed.

This is much more useful than asking the agent to “improve the project.”

We have told it what the function should do, which edge cases matter, and how much freedom it has. There is no reason for it to introduce a framework or reorganize the project.

The prompt is task guidance, though — not a security policy. File access, network access, and credentials still need the appropriate sandbox controls.

Once the agent finishes, use Ctrl + backslash to detach and return to your local terminal. Detaching does not stop the cloud sandbox.

Step 6: Run the Tests and Bring the Changes Back

Run the test command again from your terminal:

sbx --cloud exec --workdir /workspace/demo $sandbox python3 -m unittest discover -v

This executes inside the cloud sandbox. It is not running against your original local files.

For this task, a straightforward implementation could look like:

def make_slug(text):  
  	return "-".join(text.lower().split())

Calling split() without a separator handles consecutive whitespace and removes leading and trailing whitespace. Joining those words with a hyphen gives us the requested behavior.

The agent may arrive at a different implementation. Read it rather than assuming that passing tests makes every change worth keeping.

Create a separate folder for the returned files:

New-Item -ItemType Directory -Path .\review

Copy the modified files into it:

sbx --cloud cp "${sandbox}:/workspace/demo/slug.py" .\review\slug.py sbx --cloud cp "${sandbox}:/workspace/demo/test_slug.py" .\review\test_slug.py

Your original files are still untouched.

If you have Git installed, compare the versions:

git diff --no-index -- .\slug.py .\review\slug.py git diff --no-index -- .\test_slug.py .\review\test_slug.py

You can also compare them in your editor.

Look at the tests as closely as the implementation. Did the agent actually add cases for tabs and newlines? Did it keep the original test? Did it add anything unrelated?

For a real repository, I would bring the changes into a working branch and use the normal review process. The sandbox changes where the agent works. It does not replace code review.

What About Web Applications?

Our Python example does not start a server. If you use a web project instead, cloud sandboxes can expose an application through a public HTTPS URL.

For an application already listening on sandbox port 3000:

sbx --cloud ports $sandbox --publish 3000 sbx --cloud ports $sandbox

Use the URL returned by Docker.

This is different from publishing a local port such as localhost:3000. In cloud mode, the command accepts the sandbox port, and Docker assigns the public URL.

Note: Publicly reachable is not the same as private. Do not expose an unauthenticated admin page, secrets, or sensitive test data.

Remove the exposure when you no longer need it:

sbx --cloud ports $sandbox --unpublish 3000

Step 7: Clean Up the Cloud Sandbox

Before cleanup, make sure the files you want to keep are on your machine.

If you want to pause rather than delete, Docker documents cloud stop as preserving the sandbox’s memory and disk state:

sbx --cloud stop $sandbox

Do not assume that preserved resources have no cost. Check your plan’s billing terms.

For this small exercise, we have already copied the results out, so we can remove the sandbox:

sbx --cloud rm $sandbox

Confirm the removal when prompted, then list your cloud sandboxes:

sbx --cloud ls

There is an important difference from my earlier article: sbx --cloud rm --all is intentionally disabled. Cloud cleanup requires explicit sandbox identifiers.

That is a useful safeguard. A cloud credential may have access to more than the one environment you were experimenting with.

A Few Things That Can Slow You Down

If the agent cannot authenticate, check its cloud credentials. A successful local session does not prove that cloud authentication is configured.

If it cannot reach a service, check the cloud network policy. Do not immediately open access to everything just to make an error disappear.

If your local files have not changed, remember the workflow we used: we copied files into the cloud and copied the results back. Those copies are not a live synchronization mechanism.

And if you are coming back to a running sandbox, use attach. Repeating the detached creation command gives you another sandbox, not another connection to the original one.

Conclusion

What I like about this addition is that it keeps the workflow familiar. We are still using sbx, still giving the agent a specific project, and still deciding what work to keep.

The difference is where that work happens.

Start small. Send only the files the agent needs, give it one clear task, and bring the results back into your normal development process. Once that feels comfortable, move on to a larger repository or a task that actually benefits from remote compute.

And copy the changes back before the sandbox expires. A useful fix is not very useful if the only copy disappears with the environment.