Aquanode LogoAquanode Docs

aq import

Capture a box you rent elsewhere - RunPod, Vast, your own hardware - into a portable Aquanode setup.

aq import runs ON a box you already rent somewhere else and captures its environment into a new Aquanode setup, so it can be launched on any provider we support. It is survey-first: nothing is captured or uploaded until you have seen exactly what will and won't be, and confirmed.

Haven't installed aq on that box yet? See Install the CLI.

Bring your box in

See what will be captured, without uploading anything

aq import --dry-run

This runs a bounded, read-only survey of the box - two levels deep under a handful of common data roots (/, /mnt, /data, /scratch, /srv, /workspace) - and prints exactly what it found before touching the network. Nothing is captured, uploaded, or billed by --dry-run.

Read the survey

The survey always reports three separate things, and they mean different things:

  • Capturing - what's going into the setup: your detected app/data directories, plus anything you named with --include.
  • Not capturing - a directory outside the capture set that's at least 1 GiB (smaller ones aren't worth a line, and the survey says so - see below). This is the actionable one: if it should be in, add it with --include <path>.
  • Unreadable - a path the survey couldn't even open, distinct from "not capturing." A directory you don't have permission to read is reported here, never silently folded into "not capturing" (which would claim we looked and chose to skip it) and never silently dropped - and never counted as captured, even if it was a candidate aq import expected to pick up.

Below is real output from ogre capture --survey-only - the same survey aq import runs on the box - against a test machine with a 40 GiB dataset at /mnt/data, a non-standard virtualenv at /srv/env, a Hugging Face cache under the importing user's home, and a root-owned directory the importing user can't read:

ogre capture — survey

  Capturing (1)
    /home/mluser/.cache/huggingface           200.0 MiB  (detected)

  Not capturing (2)
    /mnt/data                                  40.0 GiB  add with --include /mnt/data
    /srv/env                                    1.5 GiB  add with --include /srv/env
    (directories under 1.0 GiB are not listed)

  Unreadable (3)
    /root                                    permission_denied
    /var/cache/apt/archives/partial          permission_denied
    /var/cache/ldconfig                      permission_denied
    not captured — re-run under sudo to include them

  App       none detected — the import restores data only
  GPU       unknown · no GPU visible × 0 · skew unknown
  Manifest  0 python env(s), 101 dpkg package(s) — recorded, not replayed

Two things worth reading closely here:

  • /mnt/data never appears under --include by accident - a 40 GiB dataset outside your app/venv directories is exactly the kind of thing the survey exists to surface before it gets left behind silently.
  • /root is a common app home, so the survey expected to capture it - but the importing user couldn't read it, so it's reported under Unreadable only, never counted toward Capturing. Nothing the survey couldn't read is ever reported as captured. Re-run as a user (or with sudo) that can read it, or drop it with --exclude.

The (directories under 1.0 GiB are not listed) line is a disclosure, not decoration: the survey only walks two levels deep and only names an uncaptured directory once it clears that floor, so "Not capturing" is a list of the big things you'd actually want to add with --include, not an exhaustive map of the filesystem. The floor is also in the machine-readable output as survey.min_report_bytes.

A GPU is reported as skew: unknown (not none) when none is visible - on a CPU box, or a container without device passthrough, absence of a GPU is never reported as a driver match.

Capture and upload

aq import

Without --dry-run, aq import shows you the same survey, prints the held-storage cost for what it's about to capture, asks you to confirm, then uploads. A real Setup exists as soon as capture starts - even if you stop partway through, it's billed, visible in aq setups, and deletable, never a silent leak. --yes skips the confirmation for scripting; a non-interactive shell without --yes refuses rather than guessing.

If the upload is interrupted - credentials expired mid-capture, the network dropped - re-run against the same setup:

aq import --resume <setup-id>

Capture is backed by restic, so resuming re-mints write credentials and picks up from what already landed instead of re-uploading from zero or starting a second, parallel setup.

Launch it on a GPU (optional, billable)

aq import --launch

--launch rents a GPU and restores the capture onto it in the same command - this is a real, billable deployment. It defaults the GPU to the model observed on the source box, and prints the install verdict - template, suggested hardware, compatibility warnings - before anything is rented. --gpu, --max-price, and --provider override the pick, same as aq up and aq deploy.

What isn't captured

aq import captures directories, not the machine. It does not produce a full machine image: no apt/dpkg state, no systemd units, no kernel modules, no driver install. The installed-package list (dpkg/pip freeze) is recorded in the setup's manifest for reference, but it is never replayed onto the restore target - a package pinned to the source box's driver tier can be wrong on a different one, so nothing re-installs it for you automatically.

If no runnable app is detected on the source box, aq import says so (template: null) rather than guessing one, and restores data only.

This isn't provider failover

aq import is a capture you run yourself, while the box is still up. It doesn't survive the source provider killing the box out from under you - see Migrating Workloads for what does and doesn't survive a provider-initiated stop.

Flags

--include <path> and --exclude <path> are repeatable and adjust the detected capture set before anything is surveyed again; --name <name> names the resulting setup (default: derived from the box's hostname); --yes skips the interactive confirmation; --dry-run surveys and prints the plan without capturing or uploading anything; --resume <setup-id> resumes a previously started import into the same storage location; and --launch (with --gpu, --max-price, --provider) rents a GPU and restores onto it immediately after capture completes.