You can now mount your own S3 bucket into an environment, keep its keys in your secrets, and have everything an agent writes there uploaded before the machine is torn down.
The mounts block. Mounts are declared in the environment manifest, alongside services, env and secrets, with up to four per environment. Each one names a bucket, a mountpoint, and a region, or an HTTPS endpoint if you run S3-compatible storage somewhere else. A prefix scopes the mount to part of the bucket, and read_only gives an agent a reference copy it cannot write back to.
Keys in secrets. Reference the keys as ${secrets.NAME} and the value never appears in the manifest. A reference to a secret you do not have is refused when you save, and a secret a mount depends on cannot be deleted.
Checked at save time. Mounts are Linux only: the macOS image ships no FUSE runtime, and a macOS environment that declares a mount is rejected when you save it. The mountpoint and the mount's name are checked on save too, and each error names the mount it came from.
Flush before teardown. Destroying a machine flushes the mount first and waits up to sixteen minutes for a large write to finish, whether the machine belonged to a session or was booted straight from the API. Deleting one through the API answers 202 and finishes in the background: poll the machine until destroyed_at is set. Deactivating an account flushes its machines the same way.
Off-machine snapshots. Environment snapshots are now stored off the machine that captured them, so they survive if that machine goes away.
Start here
Under Computers, open the environment, add the bucket's access key and secret under Secrets, then add a mounts entry to its manifest under Build, naming the bucket, the mountpoint and the region. Agents are told about the mount in their session context, as a place to copy finished work to.
Read the mounted storage docs for the full field reference, the mountpoint and name rules, and what a teardown flush does.