Migrate between devices

For an application’s data to follow it between devices you own, that data has to live in platform-managed storage declared as mobility: movable. A raw host bind-mount is tied to the machine it was created on; the platform can’t quiesce, snapshot, and restore it elsewhere. This guide takes an app whose data starts as a host bind-mount and makes it movable: declare the volume, promote it to platform-managed movable storage, and push local data into it.

The whole flow runs through the edgible application storage subcommand group. Have the application’s ID handy:

edgible application list

What needs to be true

For a volume to be movable:

1. It is a platform-managed storage record, not a raw host bind-mount. That’s what storage promote produces.
2. It is declared with mobility: movable in spec.storage[]. Volumes default to immovable — set movable explicitly.
3. The serving device is online and registered in your organization.

A movable-storage application

Declare the volume in spec.storage[] and reference it from the workload. Save as app.yml:

app.yml

apiVersion: v3
kind: Application
metadata:
  name: migration-app
  organization: <your-org-id>
spec:
  storage:
    - name: data
      type: persistent
      size: 1Gi
      mobility: movable
  workloads:
    - name: web
      type: compose
      composeFile: ./docker-compose.yml
      ports:
        - { name: http, containerPort: 8080, protocol: tcp }
      storage:
        - name: data
          mountPath: /mnt/edgible/data
  access:
    - name: public
      type: https
      target: { workload: web, port: http }
      hostname: { generated: true }
      tls: { managedBy: edgible }
      policies: { auth: { modes: [none] } }

Deploy:

edgible stack deploy -f app.yml

The mobility: movable field is the declaration that this volume is allowed to move. See the Application YAML reference for the other mobility values.

Step 1 — Declare any undeclared host-bind volumes

If your workload writes to a bind-mount that isn’t yet in spec.storage[], storage declare inspects the running app and proposes the matching spec.storage[] entries so the platform knows the volume exists:

edgible application storage declare --app-id <app-id>

It prompts you to accept each proposal. For a scripted run, accept them all without prompting:

edgible application storage declare --app-id <app-id> --auto-declare-yes --non-interactive

If your storage is already declared in the YAML (as above), you can skip this step.

Step 2 — Promote the volume to platform-managed movable storage

storage promote converts a host-bind storage record into platform-managed storage on its serving device, and sets its final mobility. Promote it to movable and wait for the job to finish:

edgible application storage promote --app-id <app-id> --storage-name data --mobility movable --watch

--watch blocks until the promote job completes and reports its final status. Without it the command returns as soon as the job is submitted.

Once promoted, the volume is a platform-managed, movable record — the platform can quiesce, snapshot, transfer, and restore it.

Step 3 — Push data into the volume

Use storage push to ship local data into the volume on the app’s device — for example, to seed the promoted volume from a backup, or to load a dataset:

edgible application storage push --app-id <app-id> --storage-name data --path ./seed-data

By default the CLI packs --path with tar before shipping. Useful options:

Option	What it does
-p, --path <path>	Local file or directory to push.
--no-pack	Treat --path as a pre-built tarball; don’t pack it.
--quiesce	Stop the workload across the apply step. Recommended for stateful apps so nothing writes mid-copy.
--apply-mode <mode>	replace (default) swaps the volume contents; merge overlays the pushed data on top of what’s there.
--device-id <id>	Target a specific device (defaults to the application’s first device).

For a stateful app, quiesce and replace:

edgible application storage push --app-id <app-id> --storage-name data --path ./seed-data --quiesce --apply-mode replace

Verify

List the application’s storage records to confirm the volume is now platform-managed and movable:

edgible application storage list --app-id <app-id>

Add --json for machine-readable output.

Once the workload is running against the promoted volume, confirm the app itself is healthy: read its live output with edgible application logs and check that its hostname’s certificate is still issued with edgible certs.

Limits

• VM workloads need a storage-mounted disk. Inline diskImage paths can’t move; declare the disk via spec.storage[] and reference it from the workload’s storage[].
• Host bind-mounts move best-effort until promoted. UID, symlink, and sparse-file caveats apply to raw bind-mounts; promote to platform-managed storage first for a high-fidelity move.
• The serving device must be online for declare, promote, and push.