How to move domain from one server (IP) to another?

1. Caddy version (caddy version):

v2.3.0 h1:fnrqJLa3G5vfxcxmOH/+kJOcunPLhSBnjgIvjXV/QTA=

I see that people have asked about this multiple times in the past, but many of those forum posts pre-date Caddy2, so I figured I’d ask again.

I have an old server (VPS running outdated Ubuntu that I’d rather delete than update) running Caddy and serving the live version of a website. I have a new up-to-date server running the latest Caddy 2.3, which I want to serve the website from instead. I tested the site on the new server using local_certs, so I’m confident that everything will work except for fetching the real certs.

What are the best practices for changing the domain to point to the new server instead of the old server?

Do I need to copy over the certs manually? My understanding is that DNS caching might interfere with the new server fetching certs immediately, so if I want a smooth transition, I need to copy over the certs first.

My understanding of the steps is:

  • Copy certs from old server to new server
  • Point domain at new server
  • Update Caddyfile on new server so it knows it is serving the live site

Is that correct?

Yep, that’s what I would do.

What version of Caddy are you running on the old server? If it’s Caddy 2, you can just copy Caddy’s data directory (assuming you’re using the default file system storage), which by default is in $HOME/.local/share/caddy – copy that dir to your new server (make sure permissions/ownership are correct!) and run Caddy with your same config brought over from the old site; as long as the certs aren’t expiring soon it should start without trying to do any ACME transactions. Once you’ve verified it’s running properly, you can update your DNS records.

At least, that’s how I would do it.

2 Likes

The old server is running Caddy v2.0.0-beta.20, but I could probably update it if it mattered. (Easier than updating the whole OS! But I’d rather just nuke the server from orbit, the whole thing is one big security hole.) I don’t anticipate problems copying the data directory.

I’ll give it a shot and report back.

Just a note here:

If you really don’t care about nuking the “old” VPS, I’d do the following:

  1. Download everything to local:
    • Hosted sites code/content/etc.
    • Caddyfile and other configurations.
    • ~/.local/share/caddy contents.
  2. Use the rebuild feature of your VPS provider (DigitalOcean, Linode, Vultr, etc).
  3. Upload and reconfigure everything on the “new” VPS:
    • Upload hosted sites code/content/etc.
    • Install Caddy on the “new” server (stop it right away).
    • Replace default Caddyfile and ~/.local/share/caddy.
    • Start Caddy server (should pick up new configuration).

The advantage of “rebuilding” a VPS is that you won’t lose the “old” IP.
So it means you won’t have to touch DNS at all, also avoiding DNS caching issues.
The “stop Caddy” thing would help your users think the site is down instead of gone (which would also give them problems if you use HSTS and the like).

Here are some guides for VPS rebuilding:

DigitalOcean:

Linode:
https://www.linode.com/docs/guides/rescue-and-rebuild/#use-the-rebuild-feature
Or
https://www.linode.com/docs/guides/disk-images-and-configuration-profiles/#creating-a-disk-with-a-linux-distribution-installed
The latter would be more helpful if backing up to your local machine is not an option.

Vultr:
https://www.vultr.com/docs/vultr-vps-snapshots

Hi folks, I tried it and it seems to have worked as expected. The site seems to be live on my new server now with no downtime.

I included on demand TLS in my Caddyfile on the new server, but I honestly don’t understand on demand TLS and I’m not sure whether it was relevant or helpful in any way. Here’s the relevant sections of my Caddyfile:

# global options block: https://caddyserver.com/docs/caddyfile/options
{
	servers {
		protocol {
			experimental_http3
		}
	}
	email 	{{ admin_email }}
}

# reusable snippets: https://caddyserver.com/docs/caddyfile/concepts#snippets
(boilerplate) {
	encode gzip zstd
	file_server
}

# redirect no-www to www
(redir-to-www) {
	{args.0} {
		redir https://www.{args.0}{uri}
	}
}

# start site blocks

# handcoded Rhode Island site
www.sunrisepvd.com {
	root * /srv/sunrisepvd.com/www/public
	import boilerplate
	php_fastcgi unix/{{ php_fpm_unix_socket }}
	tls {
		on_demand
	}
}
import redir-to-www sunrisepvd.com

Is on demand TLS desirable here? My thought was that it would help since “domain names might not be properly configured right away”, since the DNS cache may take some time to update after I point the domain to the new server. But perhaps if I immediately visit the site to test, this triggers a TLS handshake and all benefit is lost?

If you don’t understand it, or are not sure if you need it, then definitely remove it. On-Demand TLS can be abused unless you set up protections, and yours doesn’t have any protections. On-Demand TLS has one very niche (but very useful!) application, and that is when you are not in control of the domains you are serving, and you are serving lots of them, and they aren’t subdomains.

This is mostly irrelevant since you copied over the certs from the old Caddy instance; unless the certs are expiring already, Caddy won’t need to do any ACME challenges for a while.

1 Like

Thank you for clarifying! I’ve removed on demand TLS and (of course) the site works fine without it.

1 Like

This topic was automatically closed after 30 days. New replies are no longer allowed.