Export & Import Cubes: Portable Infrastructure

You should be able to walk away from any cloud provider with your entire infrastructure intact. Most hosting platforms lock you in: your data stays behind their walls, your configuration is proprietary, and moving means starting from scratch. The ability to export import cubes changes that equation.

TL;DR: Export any cube as a single portable .cube file and download it over a private link. Import that same file into a different space or account to boot it as a running cube with identical disk, configuration, vCPU, RAM, and disk size. The round trip is the entire point: your machine is a file you own, not a database entry locked inside a platform.

What Cube Portability Is and Why Export Import Cubes Matter

A cube is a lightweight virtual machine running on dedicated cloud infrastructure. You get full root access, no shared kernel, and a real Linux environment that boots in seconds. Cube portability means you can take that entire machine as a file and move it anywhere: to a different space, a different account, or off the platform entirely.

This matters because infrastructure lock-in is real. When your configuration, data, and environment are trapped inside a platform's proprietary format, moving costs time, money, and risk. You rewrite deployment scripts, lose historical state, and rebuild from documentation that is always out of step. Portable infrastructure means you own the actual machine, not a lease on someone else's abstraction.

The .cube file format is a single compressed, checksummed archive containing your entire disk and everything running inside the cube at export time. Same format on the way out and the way back in. No conversion, no translation layer, no surprises.

How to Export and Import

Exporting a cube is straightforward. Pick any snapshot from your cube's Snapshots tab, request an export, and get a private download link when the archive is ready. That link is presigned and expires in 15 minutes. Anyone holding the URL can download the archive during that window with no further authentication. Treat the link as a credential and do not paste it into shared channels. Once downloaded, it is an ordinary file. Store it wherever you keep your own backups: your own object storage, a Git-sealed vault, an encrypted external drive. The ability to export import cubes means your machine is never locked to one place.

Importing is the reverse of the export import cubes flow. In the destination space, go to the Cubes page and choose Import Cube. Upload the .cube file. The manifest inside fills in the disk size, vCPU, and RAM settings automatically. The same rule applies as on redeploy: you can raise the disk but not lower it. If the archive's disk is larger than your plan allows, the import is blocked until you upgrade. No partial state, no data loss.

The disk cannot shrink on import because the filesystem would corrupt. RAM and vCPU move freely within your plan, but disk is permanent and only grows.

One detail that catches people when they export import cubes: the hostname comes from the disk. When you import a cube, the hostname command inside it still returns whatever the original was, because that lives on the restored disk. If anything you run keys off the hostname, set it explicitly after the first boot with hostnamectl set-hostname new-name. Otherwise you end up with a cube named web-prod-1 in the dashboard but answering as old-staging-box inside the VM.

The .Cube File Format Explained

A .cube archive is a tar archive. The first entry is a manifest.json describing the cube's resources and image. The manifest tells the import system exactly what to recreate: vCPU count, RAM in GB, disk in GB, the base image, region preference, and any port mappings or custom domains stored in the backup.

The rest of the archive is the compressed disk. Because it is compressed, the file size is often much smaller than the disk itself. A 10 GB cube whose disk is mostly empty produces a few hundred MB archive. The Backups page shows both the size and the monthly cost before you commit to keeping it.

The file is checksummed. That checksum protects against corruption in transit or storage. When you import, the system verifies the archive integrity before extracting. A corrupted or truncated file fails import immediately instead of booting a broken cube.

Backups are stored separately from the cube they came from. When you delete a cube, the backup survives. That separation is deliberate, and it follows the same principle that lets you export import cubes freely. It means you can delete a cube, keep its backup indefinitely, and recreate it months later. But backups are billed per GB-month for as long as they exist. Keep what you need, delete what you don't, and check the cost estimate on the Backups page before committing.

Common Use Cases for Moving Cubes

CI/CD and ephemeral environments. Set a cube up exactly how you want it, snapshot it, and clone that snapshot every time you need the same environment again. Export the base snapshot as a .cube file and check it into a private repository. Being able to export import cubes means a fresh box per CI job, per test run, per agent starts from a known-good machine instead of a provisioning script you hope still works. When the script fails at 2 AM, you restore from the file and keep moving.

Customer demos and multi-tenant staging. Build a demo cube once. Snapshot it. Clone that snapshot before each customer call so each demo gets a pristine, isolated copy. Import the same .cube file into a different account for a prospect in a different organization. No cross-contamination, no leftover test data, no collisions on ports or domains.

Migrating between spaces. Redeploy works within the same space. To move a cube to a different space or account, download the backup and import it there. Useful when you reorganize teams, split a project into its own billing space, or onboard a cube managed by someone else. The entire machine moves: disk, configuration, services, everything.

Off-platform archival. Export a cube as a .cube file and store it in your own object storage, on your own servers, in your own cold-storage vault. Because you can export import cubes at will, if the platform disappears tomorrow the machine is still yours, a portable, checksummed file that boots on compatible infrastructure. This is not backup strategy on its own (everything lives in the same platform), but it is the foundation of owning your data.

Limitations and What You Should Know

Export and import work only with snapshots, not live cubes. Snapshots run automatically on your tier's schedule against a running cube. There is no downtime, and filesystem buffers are flushed inside the VM first so the captured disk is clean. But you must have at least one snapshot to export.

Backups are not a backup strategy on their own. Everything lives in the same platform as the cube. Backups cover the cases you will actually hit: a bad deploy, a deleted file, a cube you removed too eagerly. But if the data truly matters, keep something of your own as well. Export a database dump to your own object storage, push a Git remote you control, or use export import cubes to check a .cube file into your vault. Backups are insurance, not archival.

Mappings are re-attempted on import, and conflicts are skipped. Domains and TCP port mappings stored in the backup are re-applied on boot, but if the original cube still holds one, the new cube simply boots without it. Nothing is stolen and nothing errors. The mapping is just absent, and you add it manually if you meant to move it. This behavior when you export import cubes is exactly right for a staging copy and exactly wrong if you expected a failover.

The presigned download link expires in 15 minutes. Plan ahead. If it expires, request a new export. The archive is cached, so a fresh link is ready in seconds. But do not rely on the link persisting.

FAQ

Can I Export a Cube While It Is Still Running?

Yes. Snapshots are taken against a running cube, and nothing you are serving goes offline. Filesystem buffers inside the VM are flushed first so the captured disk is clean. The export uses that snapshot, not the live cube.

What Happens to Custom Domains and Port Mappings When I Import a .Cube File?

Domains and TCP mappings stored in the backup are re-applied on boot, but if the original cube still holds one, the new cube boots without it. You must add those mappings manually in the destination space if you want them. This prevents collisions and makes it safe to clone alongside a live original.

Can I Shrink the Disk When I Import a .Cube File?

No. Disk size can only grow or stay the same. Shrinking the filesystem would corrupt it. If you need a smaller cube, create a new one and copy the data you need manually, or use a fresh snapshot with fewer resources from the start.

Is There a Size Limit on .Cube Files I Can Import?

The limit is your plan's disk allocation. If the archive's disk is larger than your plan allows, the import is blocked until you upgrade. There is no other file-size limit. The archive is downloaded and extracted in streaming, so a very large machine still imports successfully as long as you have space.

You now know why portable infrastructure matters and how to export import cubes to own your data. Start with a snapshot, export it, and store the .cube file somewhere safe. When you need to move, redeploy into a new space, or archive the machine, the file is ready. Create your first cube today with $5 in free credit and test the export workflow yourself, no credit card required.