GPU provider capabilities
Pause/resume, auto-pause, and snapshot/restore all use the same mechanism: snapshot the environment, terminate the box, and (for resume) redeploy a fresh one and restore onto it, so they work the same way on every provider Aquanode supports. What genuinely varies is what each provider's own API offers: persistent volumes, whether the browser terminal can reach the box, how your SSH key gets there, and whether a startup script runs at first boot. That's the comparison below: everything above it is a platform guarantee, not a per-provider capability.
The same on every provider
- Pause / resume. Your environment is captured and can be restored onto a fresh box on any provider: pause snapshots it and terminates the box; resume rents a fresh one and restores that snapshot onto it.
- Auto-pause. The identical snapshot-then-terminate mechanism, on a timer instead of a click.
- Snapshot / restore. The underlying mechanism behind both of the above: Aquanode's own agent plus Aquanode-managed storage, so it never depends on a provider's own API.
The real precondition for all three is the deployment having automated backups turned on (a storage bucket selected), never which provider it's on. A prior version of this page scoped pause/resume and auto-pause down to 3 of 10 providers based on adapter methods that turned out to be dead code, never called by the real pause/resume path; verified against the orchestrator source and by running the round trip on a real box, 2026-08-16.
| Provider | Persistent volumes | Browser terminal | SSH keys on account | SSH key at deploy | Startup scripts |
|---|---|---|---|---|---|
| Verda | Yes | Yes | Yes | Yes | Yes |
| HyperStack | Yes | Yes | Yes | Yes | Yes |
| Voltage Park | Yes | Yes | Yes | Yes | No |
| RunPod | No | Yes | No | No | No |
| Vast.ai | No | Not verified | Yes | Yes | No |
| SimplePod | No | Not verified | No | No | No |
| Akash | No | No | No | No | No |
| Hot Aisle | No | Yes | Yes | Yes | No |
| Vultr | No | Yes | Yes | Yes | Yes |
| Massed Compute | No | Yes | No | Yes | Yes |
Persistent volumes are a real, separately-managed block-storage resource that some provider APIs don't expose at all: where they don't, a workspace is still preserved through snapshot and restore, just not as an attachable volume. Verified against each provider's adapter in Aquanode's orchestrator as of 2026-08-16.
“Not verified” does not mean “no.” The browser terminal needs one specific port to reach the box, and on Vast.ai and SimplePod nobody has established whether that port is forwarded. We won't promise the terminal there, and we won't claim it's broken either: we'd be stating something we haven't measured. Only Akash reads a real “no”: its deployments expose port 80 and nothing else, so there is no port for the terminal to arrive on. Everything else on this page (SSH, pause/resume, snapshots) is unaffected either way.
What each guarantee means
- Pause / resume
- Pause stops billing and tears the box down after snapshotting it; resume is not un-pausing the same machine: it rents a fresh one, possibly on a different provider, and restores your snapshot onto it.
- Auto-pause
- Aquanode saves your setup and pauses a box you left idle, so you stop paying for a GPU nobody's using. It's the same mechanism as pause, running on a timer.
- Persistent volumes
- Block storage you can attach, detach, and re-attach to a later deployment, independent of any one box's lifecycle. This is a genuinely per-provider capability, not a mechanism Aquanode built on top of every adapter.
- Browser terminal
- A shell on your box from the Aquanode console, with no SSH client and no key setup. It reaches the box over one fixed port, so it only works where that port is actually forwarded, which is why this column has a “not verified” state rather than a plain yes/no.
- SSH keys on account
- Whether the provider's own API can hold and manage SSH keys independently of any one box. Mostly an implementation detail: where Aquanode uses it, it uses its own account, and on shared-account providers it deliberately avoids registering your key there at all, because those providers copy account keys onto every box on the account.
- SSH key at deploy
- Whether your public key is on the box from its very first boot, as part of the create request. Where it isn't, Aquanode's on-box agent installs it once the box is running, so you get SSH either way, just slightly later in the sequence.
- Startup scripts
- Whether you can hand the provider a script to run at first boot. Independent of Aquanode's own agent, which is installed on every provider regardless of how the box boots.
- Snapshot / restore
- Save your whole environment and restore it onto a new box, on the same provider or a different one. This is Aquanode's own mechanism and the one pause/resume and auto-pause are both built from. Automated snapshots are opt-in (15–30 min intervals in the console, as low as 1 min via the API/CLI); nothing schedules one for you automatically. Taking a snapshot is free; holding one in Aquanode Storage is billed at $0.02 per GiB per 30-day month.
Per-provider notes
- Browser terminal: Verda names no port set anywhere in the create request, so a declared-only policy is structurally impossible. A real deploy (2026-08-16, deployment 3288) reached ogre's proxy on 8443 with a genuine 401 and a working interactive shell despite 8443 never being named. Verda forwards the box's ports without requiring them to be declared.
- Persistent volumes: Real block volumes: create, list, delete.
- SSH keys on account: Verda's API manages SSH keys on the account independently of any instance (get, add, delete).
- SSH key at deploy: Your public key is passed straight through on the create request, so it's on the box from first boot.
- Startup scripts: Real startup-script API: a script is created and attached to every deploy (that's how the on-box agent installs itself).
- Browser terminal: Works, but for a reason outside the provider's own API: after a Hyperstack box is deployed, Aquanode's orchestrator opens ports 22 and 3000-9000 on it, and that range covers the port the terminal proxy listens on (8443). Hyperstack's own adapter declares nothing about ports, so this is the orchestrator's doing, not the provider's.
- Persistent volumes: Real block volumes: create, list, delete.
- SSH keys on account: Hyperstack's keypair API manages SSH keys on the account independently of any instance (list, create, delete).
- SSH key at deploy: The create request names a keypair, which Hyperstack injects into the box at boot.
- Startup scripts: Not through a scripts-management API (Hyperstack has none) but through cloud-init: a supplied script is layered into the instance's user-data and runs at first boot.
- Browser terminal: Voltage Park boxes sit behind NAT and forward only the ports we ask for, and 8443, the terminal proxy port, is in that set on every instant-VM deploy. A regression test pins the port list so a future trim can't silently drop it.
- Persistent volumes: Real persistent storage, but through Voltage Park's own separate storage API rather than the generic volume API most other adapters use (its CreateVolume method is intentionally unused).
- SSH keys on account: Real account-level SSH key endpoints (list, add, delete), independent of any instance.
- SSH key at deploy: Your key is set directly on the create request, on both the instant-VM and bare-metal paths.
- Startup scripts: No startup-script API: every script-management method returns not-supported.
- Browser terminal: RunPod forwards only the ports named when the pod is created, and 8443 (the terminal proxy port) is one of them.
- Persistent volumes: No volume API.
- SSH keys on account: Deliberately not used: RunPod injects account-level keys into every pod on the account, and Aquanode's RunPod account is shared across customers, so registering a key there would put it on other people's boxes. Your key reaches the box through Aquanode's own agent instead.
- SSH key at deploy: The create request carries no SSH key. Access is set up by Aquanode's on-box agent once the pod is running.
- Startup scripts: No startup-script API.
- Browser terminal: Nobody has established whether this provider forwards ogre's proxy port (8443) to the box, so mjolnir's adapter declares its port policy unknown rather than guessing. That means we can't promise the browser terminal here, and equally can't claim it doesn't work. SSH is unaffected.
- Persistent volumes: No volume API.
- SSH keys on account: Vast.ai's API manages keys on the account (list, create, delete), though Aquanode deliberately doesn't route your key through it, because account keys land on every new box.
- SSH key at deploy: Your key is attached to the instance during the deploy sequence, before the deploy returns. That's what makes SSH through Vast.ai's proxy work.
- Startup scripts: No managed startup-script resource. Boot commands are embedded inline in the create request instead.
- Browser terminal: SimplePod's two pools genuinely differ and mjolnir's Capabilities() can't express a per-pool answer, so this can't honestly be a flat yes or no. The instant/VPS pool was measured reaching ogre's proxy on 8443 (deployment 3290, 2026-08-16) despite naming no port in its create request. The docker pool takes a different route: it declares 8443 in its own template's port list, so this isn't the same unmeasured gap as a provider nobody has checked; it's a fact the adapter-wide type can't carry. See /features/browser-terminal for the pool-scoped breakdown.
- Persistent volumes: No volume API.
- SSH keys on account: Keys on the account can be listed but never registered or removed through the API, which isn't key management in any useful sense.
- SSH key at deploy: Neither pool puts your key on the box at create time. Access is set up afterwards by Aquanode's on-box agent.
- Startup scripts: The container pool does run a boot script, but the VPS pool can't, so this isn't true of every box SimplePod rents.
- Browser terminal: Akash deployments only expose port 80, and the terminal proxy needs 8443. That isn't a missing feature we could ship: no port is forwarded for it to reach, so the terminal can't work on Akash at all.
- Persistent volumes: No volume API.
- SSH keys on account: No account-level SSH key API: Akash is a decentralised marketplace with no account to hold keys on.
- SSH key at deploy: The deployment manifest carries no SSH key; access is set up by Aquanode's on-box agent.
- Startup scripts: No startup-script API.
- Browser terminal: Hot Aisle names no port set anywhere in the create request, so a declared-only policy is structurally impossible. A real deploy (2026-08-16, deployment 3287) reached ogre's proxy on 8443 with a genuine 401 and a working interactive shell despite 8443 never being named. Hot Aisle forwards the box's ports without requiring them to be declared.
- Persistent volumes: No volume API.
- SSH keys on account: Real account-level SSH key endpoints (list, add, delete), independent of any instance.
- SSH key at deploy: The create request names no key, but every account-registered key is on the box at first boot. Aquanode SSHes into a freshly deployed Hot Aisle VM with no attach step in between.
- Startup scripts: No startup-script API.
- Browser terminal: Vultr instances are created with no firewall group attached, so the box gets a public IP with nothing filtering ports, including 8443, which the terminal proxy needs.
- Persistent volumes: No volume API.
- SSH keys on account: Real account-level SSH key endpoints (list, create, delete), independent of any instance.
- SSH key at deploy: Your key is registered and its ID passed on the create request, so Vultr injects it at boot.
- Startup scripts: Real startup-script API: a script is created and attached on every deploy, and a script you supply is combined into it.
- Browser terminal: Massed Compute names no port set anywhere in the create request, so a declared-only policy is structurally impossible. A real deploy (2026-08-16, deployment 3289) reached ogre's proxy on 8443 with a genuine 401 and a working interactive shell despite 8443 never being named. Massed Compute forwards the box's ports without requiring them to be declared.
- Persistent volumes: No volume API.
- SSH keys on account: No account-level key management at all: every key method is a stub that makes no API call.
- SSH key at deploy: Your key is a real field on the launch request, so it's injected into the box at create time. This provider has deploy-time keys without account-level ones.
- Startup scripts: Not through a scripts-management API, but a script supplied at deploy time is appended to the boot command and does run at first boot.
Frequently asked questions
Which GPU providers support pause and resume on Aquanode?
All of them: Verda, HyperStack, Voltage Park, RunPod, Vast.ai, SimplePod, Akash, Hot Aisle, Vultr and Massed Compute. The durable guarantee is that your environment is captured and can be restored onto a fresh box on any provider; that's true regardless of which provider you paused on, since pause needs only a create call and a terminate call, which every provider we support implements. The real requirement is having automated backups turned on for the deployment (a storage bucket selected), not which provider you're on.
Does auto-pause work on every GPU provider?
Yes. Auto-pause uses the identical snapshot-then-terminate mechanism as pause, just on a timer instead of a click, so it works on every provider Aquanode supports. Like pause, it saves your setup before releasing the box.
Which GPU providers offer real persistent volumes on Aquanode?
Persistent block storage that survives independently of any one deployment is available on Verda, HyperStack and Voltage Park. Other providers have no volume API at all. A workspace on them is preserved through snapshot and restore instead of an attached volume. This is the one capability that genuinely varies by provider on this page.
Which GPU providers support the browser terminal on Aquanode?
The in-browser terminal works on Verda, HyperStack, Voltage Park, RunPod, Hot Aisle, Vultr and Massed Compute. On Akash it cannot work at all. Those deployments only expose port 80, and the terminal proxy needs a different port, so there's nothing for it to connect to. On Vast.ai and SimplePod we haven't established whether the required port reaches the box, so we don't claim it either way. SSH access is separate and unaffected on all of them.
Can I add my SSH key when I deploy a GPU box, on any provider?
Your key is put on the box as part of the deploy itself on Verda, HyperStack, Voltage Park, Vast.ai, Hot Aisle, Vultr and Massed Compute. On the rest, the key is installed by Aquanode's on-box agent once the box is running instead. You still get SSH, it just arrives a moment later in the sequence rather than being baked in by the provider at boot.
Which providers run a startup script at first boot?
A script you supply runs at first boot on Verda, HyperStack, Vultr and Massed Compute. On the others there's no way to hand the provider a script for the initial boot. You run your setup after the box is up instead. This is separate from Aquanode's own agent, which is installed on every provider regardless.
Is resume the same as un-pausing the same machine?
No, and that's true on every provider. The original box is gone once paused. Resume rents a new one, possibly on a different provider, and restores your snapshot onto it. That's also what makes cross-provider resume possible: it was never restarting the same hardware to begin with, so there's nothing tying it to the provider you paused on.
Related pages
See live pricing per provider on the provider index, read more about auto-pause, network volumes, and workspace backups & migration, or browse every feature Aquanode ships.
