> ## Documentation Index
> Fetch the complete documentation index at: https://modal-devin.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Operate a deployed worker

> Check health, follow sessions, redeploy changes, and preserve resumability.

The generated Modal application is the operational unit for one outpost.

## Check local prerequisites

```bash theme={null}
uv run modal-devin doctor
```

Run this before the first deployment and after changing local credentials, the Modal
SDK, or the configured Secret.

## Follow a session

Use the Modal dashboard or the
[`modal app logs`](https://modal.com/docs/cli/latest/app#modal-app-logs) command. A
healthy session follows this observable path:

1. A session assigned to the outpost starts a Modal invocation.
2. The invocation logs show the Devin worker starting.
3. Worker output is prefixed with the Devin session ID.
4. The invocation finishes, or preserves the workspace when the session suspends.

Common outcomes:

| What you see                                  | What it usually means                                                       |
| --------------------------------------------- | --------------------------------------------------------------------------- |
| No invocation starts                          | The outpost, credential, deployment, or queue needs attention               |
| An invocation exits immediately with no error | Another worker already accepted that session                                |
| `WorkerExitedError`                           | The Devin worker returned a nonzero status; inspect preceding output        |
| `SessionStatusUnknownError`                   | Final state remained unconfirmed; recovery data was preserved when possible |

## Deploy configuration changes

Edit the generated outpost file and redeploy it:

```bash theme={null}
uv run modal-devin deploy outposts/my_outpost.py
```

`modal-devin deploy` always uses Modal's rolling deployment strategy. Session
invocations that are already serving work remain on the previous application version
until their input finishes, while new work shifts to the replacement version. The
durable dispatch lease prevents the old and new schedulers from starting the same
pending session during that overlap.

Independent schedulers may target the same Devin outpost. They can discover and
dispatch the same pending session, but the Outposts atomic claim permits only one
session invocation to serve it. Local dispatch leases reduce duplicate Modal work
during rolling deployment overlap.

Keep the Modal application running before redeploying it. `modal app stop` permanently
terminates running containers, including active session invocations; a subsequent deployment
creates a new application instead of performing a rolling update.

Run `init` only for a new file; it preserves existing application code.

## Retire an outpost

After every active or resumable session is no longer needed, destroy one deployment:

```bash theme={null}
uv run modal-devin destroy outposts/my_outpost.py
```

The command confirms interactively, stops the Modal app, and then deletes the Devin
outpost. Use `--yes` for non-interactive operation. It retains the generated file and
shared Modal Secret for deliberate cleanup or auditing.

## Rotate the Devin service user key

Update the [Modal Secret](https://modal.com/docs/guide/secrets) referenced by the
generated application, then run:

```bash theme={null}
uv run modal-devin doctor --secret-name devin-outposts-token
```

Avoid putting the token in command arguments, checked-in files, or shell history.

## Preserve resumability

Keep the deployment active while sessions may remain suspended. A resumed session
uses its preserved filesystem when available; if that snapshot has expired, it starts
from the current base image.

<Card title="Troubleshoot failures" icon="stethoscope" href="/guides/troubleshooting" horizontal>
  Match an observable symptom to its likely cause and corrective action.
</Card>