> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sailresearch.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Migrate to Sailboxes

> Move an app, an agent, or a dev environment onto Sailboxes

Sailboxes are just Linux VMs. Anything that runs on a Linux machine runs in a
Sailbox, so most migrations are a matter of getting your code and your data
onto one and exposing the ports you need.

## Let your agent do it

The fastest way to migrate is to hand the job to your coding agent. Give it
three things:

1. **A way in.** Install the [Sail CLI](/reference/cli) on the machine the
   agent runs on and sign in with `sail auth login`. The agent can then create
   Sailboxes, run commands with `sail box exec`, and copy files with
   `sail box cp`. If the agent prefers SSH, run `sail box ssh enable <id>` and
   it can use `ssh <name>.sail`, `scp`, and `rsync` as usual.
2. **The docs.** Point it at
   [https://docs.sailresearch.com/llms.txt](https://docs.sailresearch.com/llms.txt),
   or connect it to the docs MCP server at `https://docs.sailresearch.com/mcp`.
   See the [AI Quickstart](/ai-quickstart) for the setup in Claude Code,
   Codex, Cursor, and other tools.
3. **A goal.** Say what should be true when it is done.

A prompt like this is enough to start:

```text theme={null}
Migrate this project to run in a Sailbox on Sail (https://sailresearch.com).
Read https://docs.sailresearch.com/llms.txt first. Use the sail CLI to create
a Sailbox, get the code and dependencies onto it, run the app, and expose the
port it listens on. Report the public URL and anything you could not move.
```

<Note>
  Using Claude Code or Codex? Install the [Sail skills](/ai-quickstart) and ask
  your agent to "Migrate this app to Sail". The `sail-migrate` skill walks
  through the whole migration, including moving sandboxed execution onto
  Sailboxes.
</Note>

## Migrating a web app

Expose the port your app listens on when you create the Sailbox, and Sail gives
it a public HTTPS URL. Nothing inside the Sailbox needs to know about TLS or
hostnames.

<div className="sail-prompt-cli">
  <CodeGroup>
    ```bash CLI theme={null}
    sail box create --app my-app --name web --port 8000
    sail box address <id> 8000
    ```

    ```python Python theme={null}
    import sail

    app = sail.App.find(name="my-app", mint_if_missing=True)
    sb = sail.Sailbox.create(app=app, name="web", ingress_ports=[8000])
    listener = sb.wait_for_listener(8000, timeout=60)
    print(listener.endpoint.url)
    ```
  </CodeGroup>
</div>

If your app is containerized, `docker` and `docker compose` work inside a
Sailbox. To bake your container into the Sailbox itself instead of running
Docker inside it, build the Dockerfile into a Sailbox image with
[`Image.from_dockerfile`](/sailboxes-images#build-one-from-a-dockerfile). The
Sailbox then boots straight into your environment.

To serve the app on your own hostname, see [Custom Domains](/sailboxes-custom-domains).

## Migrating a dev environment

Enable SSH on the Sailbox and use it like any remote machine: your editor's
remote mode, `scp`, `rsync`, and port forwarding all work.

<div className="sail-prompt-shell">
  ```bash theme={null}
  sail box ssh enable <id>
  ssh <name>.sail
  ```
</div>

SSH is organization-scoped. Anyone in your org can connect to an org-visible
Sailbox with a short-lived certificate for their own key, so there are no
per-machine keys to hand out. Create the Sailbox with `--visibility private`
when only you should be able to reach it.

For a quick shell without SSH, `sail box shell` opens a terminal over the same
channel the CLI uses for commands and needs no open port.

## Things that work differently

* **You pay for what the Sailbox uses, not what it could use.** Billing follows
  actual CPU, memory, and disk usage. An idle Sailbox sleeps on its own and
  wakes the moment something needs it, with its processes and memory intact. See [Autosleep](/sailboxes-autosleep) and
  [Billing](/sailboxes-billing). There is no need to tear environments down to
  save money.
* **Secrets can stay outside the Sailbox.** Instead of copying API keys into
  the environment, [Credential injection](/sailboxes-credentials) adds them to
  outbound HTTPS requests on the way out, so code running in the Sailbox never
  sees them.
* **A working environment can be cloned.** Once the migration is done, take a
  checkpoint and start as many copies as you need from it. See
  [Forking](/sailboxes-forking).
* **Sailboxes are persistent.** There is no fixed runtime limit. A Sailbox keeps
  its disk for its whole life, so long-running agents and stateful services do
  not need to be rebuilt between sessions.

Stuck on something? See [Getting Help](/sailboxes-getting-help).