Aquanode LogoAquanode Docs

aq import

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

aq import runs ON a box you already rent somewhere else and captures its /workspace into a new Aquanode Volume, which you can then attach to any pod. 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 volume: 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 Volume exists as soon as capture starts - even if you stop partway through, it's billed, visible in aq volume ls, 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 volume:

aq import --resume <volume-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 volume.

Once the volume exists, attach it to a pod from the console's New pod screen. Attaching a volume to a pod is currently console-only; there is no aq subcommand for it.

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 volume's manifest for reference, but it is never replayed onto a pod that attaches this volume later - 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. A Volume carries no app/template at all; attaching it to a pod is a data-only restore, and any app comes from that pod's own Environment.

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 Stop, start, and move 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 volume (default: derived from the box's hostname); --yes skips the interactive confirmation; --dry-run surveys and prints the plan without capturing or uploading anything; and --resume <volume-id> resumes a previously started import into the same volume, re-minting write credentials and picking up from what already landed instead of re-uploading from zero.