How It Works

Aquanode splits one thing most GPU clouds treat as inseparable: the machine you rent and the environment you built on it.

The machine is a GPU card at a provider. It is billed by the second, only while it runs, and it is disposable. The setup is your disk, your image, and everything you installed on that machine. It is not disposable, and it is not tied to the card it started on.

Everything below follows from that split.

Launching

You pick a GPU and an image, and Aquanode rents the machine on your behalf. Providers differ in their APIs, their request formats and their lifecycle rules, so a launch is not a single call to a single vendor: Aquanode holds one request shape and translates it per provider, which is why the same setup can land on very different hardware.

The first time a setup boots, its state is captured for you. You will see that first save in the setup's Versions tab as Captured on first deploy. There is no separate "turn this box into a template" step.

Saving

A save writes the setup's state to object storage as a numbered, immutable version.

Saves happen three ways, and each is labelled in the version list so you can tell them apart:

• Captured on first deploy, automatically, when the setup first boots
• Saved on pause, when you pause the machine yourself
• Auto-paused: saved, machine released, when auto-pause decides the box is idle

You can also save at any time from a running setup with Save a version, in the header of the setup page or from the row menu on the Setups list. Saves are incremental, so a repeat save of the same machine only moves what changed.

Pausing

Pausing is not a suspend. Aquanode captures the setup, then releases the machine back to the provider, which is what stops the GPU charge. Storage keeps billing, because your version has to live somewhere.

This is why pause and resume work on every provider we support, including ones with no native suspend: it is a save and a terminate, then a fresh box restored from that save.

Resuming, anywhere

Resuming rents a new machine and restores a version onto it. The card, the region and the provider can all differ from where the version was made. That is the same mechanism whether you are coming back from a pause, moving to cheaper capacity, or leaving a provider that ran dry, which is why there is no separate migration feature to learn.

Aquanode keeps a small agent on each running box. It reports health and metrics, and it does the work of capturing and restoring your setup. That agent is why a save is a real capture of the disk rather than a provider snapshot you cannot move.

Serving a version

A service job (entrypoint http or comfyui) puts a stable, callable address in front of one saved version. This is what used to be called an endpoint: same address, same tokens, now filed under Jobs. Calls queue, and the number of running instances follows the queue depth up to a limit you set. When the queue empties, the job scales back down, to zero by default, so an idle one is not holding a GPU.

Because a cold call has to rent and restore a box rather than start a container, the first call after an idle period takes minutes, not milliseconds. Service jobs are built for work where that is acceptable. There is no per-run dollar cap: the bound that always applies is wall-clock (time limit times attempts times machines), and an optional monthly budget can sit on top of that.

See Jobs for the full flow.

What this buys you

One account, one bill, and one set of keys across every provider we support, with the environment you built surviving each machine it runs on.

See which providers and GPUs this covers on the Aquanode Marketplace.