A VPS is rarely the permanent home of an application.

Eventually, I may need a more powerful machine, a region closer to my users, or simply a different provider. Choosing a new server is usually the easy part. Moving a running application onto it is what makes me hesitate.

I need to back up the data, recreate the containers, transfer the environment variables, configure the domain, and verify that everything actually works. If something fails halfway through, the most important question is whether the old server is still in a state from which the application can restart.

This is the problem the Move to another server feature in Nitrobase aims to solve.

Nitrobase has only recently launched and is still in Beta. This feature does not promise to turn a server move into a zero-downtime migration. Its more practical goal is to make the move an ordered process with verification and a rollback path when the destination is not ready.

A typical manual VPS move

When moving a Docker Compose application by hand, my process usually looks like this:

  1. prepare the new VPS;
  2. copy the Compose file and .env;
  3. transfer the database or volumes;
  4. start the containers on the new server;
  5. update DNS;
  6. test the application;
  7. remove the data from the old server.

The list appears reasonable. The risk lies in when each step happens.

If I delete the old copy too early, I lose the way back. If both copies continue accepting writes, their state can diverge. If I update DNS before checking application health, users may be sent directly to a broken deployment.

A move is therefore not only about copying data. It is about handing responsibility from the source server to the destination at the correct moment.

The most important rule: do not switch before it is healthy

When designing the move flow in Nitrobase, I chose a simple rule:

The application is considered moved only after the copy on the destination server passes its health check.

The process has four main stages:

  1. create a backup on the source server;
  2. restore the application, its data, and its configuration on the destination;
  3. deploy it and run the health checks on the destination;
  4. only after those checks succeed, switch the managed state and remove the source copy.

The last step is what matters. The old copy is not removed merely because the data transfer completed or the new containers started. Nitrobase waits for the application to report a healthy state.

If the restore, deployment, or health check fails, the incomplete destination copy is removed and the application on the source server is started again.

This is not a new or unusual migration technique. Its value comes from applying the safer order consistently instead of relying on memory during a server move.

The backup is the bridge between two servers

Nitrobase uses its backup and restore workflow to move an application.

The source server creates a copy containing the data, configuration, and information required for recovery. The destination reads that copy to recreate the application with the same identity and environment variables.

Because both servers need access to the backup, it must live in shared storage such as:

  • Amazon S3 or another S3-compatible service;
  • Cloudflare R2;
  • Backblaze B2.

A folder that exists only on the source server cannot be used for this workflow because the destination has no way to read it.

That requirement reinforces a principle I find useful even when I am not changing VPS providers: an important backup should exist outside the server running the application.

This is not a zero-downtime migration

I want to be explicit about this limitation because the phrase “one-click migration” can easily create the wrong expectation.

During a move, Nitrobase creates a backup and stops the source application so that no new data is written after the backup point. The application remains stopped while the copy is downloaded, deployed, and checked on the destination.

That means there will be an interruption. Its duration depends on:

  • the size of the database and volumes;
  • the upload and download speed of the backup storage;
  • the time required to pull container images;
  • the application's startup time;
  • the duration of its health checks.

In return, the source data does not continue changing after the backup has been created. For many small self-hosted applications, a controlled maintenance window is easier to accept than trying to synchronize two active copies.

If a workload truly requires zero downtime, it needs a specialized architecture for replication, traffic switching, and data synchronization. Nitrobase Beta is not trying to replace those systems.

What happens to the domain?

Once the application is running on the new server, its domain also needs to point to the correct destination.

For a free sslip.io domain, the address includes the server IP, so Nitrobase can update it to follow the destination during the move.

For a custom domain, the system cannot modify DNS records in an account it does not control. After the application is ready on the new server, the job log lists the records the user needs to update.

I like this separation because Nitrobase automates what it controls without pretending it has permission to change external DNS.

What if Nitrobase restarts halfway through?

A server move can take time. During that period, the Nitrobase panel itself may restart or encounter a failure.

Before entering the part of the job that may need to be undone, Nitrobase persists the recovery state. If the process is interrupted before the application officially switches to the destination, startup recovery returns the domains and managed state to the source, removes the incomplete destination copy, and restarts the services that were stopped.

This detail is not prominent in the interface, but it matters to me. A reliable workflow must not only handle expected errors; it must also know where it was when the coordinator itself was interrupted.

Checks performed before the move begins

Not every application can be moved immediately. Nitrobase refuses to begin when it detects unsafe conditions such as:

  • the destination server is not Ready or cannot be reached;
  • another job is already using the application;
  • the application has never been deployed;
  • the destination contains an application folder with the same identity;
  • the selected backup destination is local to only one server;
  • the source and destination do not belong to the same team.

These checks do not make a move faster. They ensure that predictable failures appear before Nitrobase stops the source application.

The problem this feature aims to solve

I did not build VPS migration because copying files is too difficult. I built it because the boundary between “copying” and “successfully moved” is often unclear.

A dependable migration process should be able to answer:

  • Which copy of the data is the final one?
  • When is the source application stopped?
  • Is the destination actually healthy?
  • When is it safe to remove the source copy?
  • How does the system return to the source if something fails?

Nitrobase tries to put those answers into a job with visible logs, state, and rollback behavior.

A Beta feature that needs real-world testing

The move workflow is still part of Nitrobase Beta. Every application has different data characteristics and startup times, so the feature needs more feedback from real environments.

When testing it, I would still start with a non-critical application, verify that the backup can be restored, and choose an appropriate maintenance window. Automation makes the process more consistent, but it does not replace understanding your own data and recovery plan.

The outcome I want is simple: when a VPS no longer fits, leaving it should not feel like a gamble.

Nitrobase source code: https://github.com/AydenGroup/nitrobase