Skip to main content
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 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, or connect it to the docs MCP server at https://docs.sailresearch.com/mcp. See the 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:
Using Claude Code or Codex? Install the Sail skills 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.

​
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.
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. The Sailbox then boots straight into your environment. To serve the app on your own hostname, see 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.
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 and 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 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 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.