Delete, rename or move a site

llms.txt

Sites are not forever. You rename a project, retire an old campaign or outgrow a server. This article covers the three things that can happen to an existing site: renaming it (a label change, harmless), deleting it (permanent, with a precise list of what goes), and moving it to another server, which SrvYard does not do in one click but which is a short, safe routine if you follow the order below.

Read the deletion section before you press the button: what is removed from the server cannot be brought back from SrvYard, and what is not removed (databases, for example) is just as important to know.

Before you begin

  • Permission. Renaming needs permission to update the site. Deleting needs the permission to delete sites; owners and admins have both.
  • A backup, before anything destructive. Deleting a site deletes its files. If the site has uploads or data you want to keep, run a file backup and a database backup first.
  • A Ready or Failed site. A site that is still installing, deploying a change or already deleting cannot be deleted: "Wait for the site to finish its current change before deleting it."

1. Rename a site

The name is the label SrvYard shows in lists and headings. It is not the domain, the folder or the Linux user, so renaming has no effect on how the site is served.

The site actions menu
Rename site is the last item of the site actions menu.
  1. Site actions. The three dots at the top right of the site.
  2. Rename site. Opens the dialog.
The Rename site dialog
A rename only changes the label.
  1. Site name. The new name: 2 to 100 characters, starting with a letter or digit, then letters, digits, spaces and . _ ( ) / -. The dialog reminds you that "Domains, paths and the Linux user of the site do not change."
  2. Rename. Saves. The button stays disabled until the name is different from the current one.

To change the domain of a site, use the Domains tab instead: add the new name, make it primary and remove the old one. See Add a domain, a free subdomain and DNS records. The folder on the server keeps the name it was created with.

2. Delete a site

Open the site's Settings and scroll to the end of General.

The Delete site card
Delete site sits at the bottom of the General settings.
  1. Delete site. The button is disabled unless the site is Ready or Failed. The card says "This cannot be undone."
The delete confirmation
You must type the exact site name before Delete site is enabled.
  1. Site name. Type the site's name exactly as shown. Anything else keeps the button disabled, and the server also checks it ("Type the site name to confirm.").
  2. Delete site. Starts the removal. You land on the Sites list with "Deleting the site..." and the site appears as Deleting until the server job finishes.

What is removed

On the server, in this order:

  1. The site's background processes (Supervisor programs) and their logs.
  2. The Nginx configuration of the site.
  3. The PHP-FPM pool, but only for an isolated site. A site on the server's main user shares the default pool, which stays.
  4. For a site on the main user, its scheduled jobs are taken out of that user's crontab and the others are kept.
  5. The site's files (releases, shared folder, .env, uploads) and its certificates.
  6. The Linux user, but only when the site is isolated and no other site uses that user.

In SrvYard and at your Git host:

  • The domains, certificates, processes, scheduled jobs and command history of the site are deleted from SrvYard.
  • The deploy key and push webhook SrvYard registered at GitHub, GitLab or Bitbucket are removed. If that fails, the log says so and the deletion goes on.
  • A free subdomain goes back to the pool and its DNS record is deleted, so anyone can claim the name afterwards.

What is not removed

  • Databases and database users. SrvYard does not drop them when it deletes a site. Remove them on the server's Databases tab when you are sure.
  • Backups already taken, and the backup schedules of the server's databases.
  • DNS records at your own provider. Delete the records of the domain yourself, or the name keeps pointing at the server.
  • Anything outside the site's own folder, such as files you placed elsewhere.
Warning

Deleting is permanent. SrvYard keeps no copy of the files it removes. If the job fails half-way the site is shown as Failed with the reason, and pressing Delete site again resumes safely.

Note

A site that was adopted is only forgotten when you delete it: "Nothing on the server is changed or deleted." Its files, Nginx file and processes stay as they are.

3. Move a site to another server

SrvYard has no "move" button, because a move is really "build a second copy, test it, then switch the traffic". Done in this order the site is never down.

  1. Lower the TTL. At your DNS provider set the TTL of the site's records to 300 seconds (five minutes), a day before the move, so the switch spreads quickly.
  2. Create the site on the new server. Use the same site type, PHP version, repository and branch. The domain can be a temporary one (a free subdomain works well) while you test. See Create a site on your server.
  3. Copy the environment. Open the old site's Environment, copy the variables and paste them into the new site's. Change anything that points at the old server, such as a database host.
  4. Copy the database. Export it on the old server and import it on the new one: Import and export a database. For a busy site, repeat the export just before the switch to catch recent changes.
  5. Copy uploads. Files that are not in Git (for example storage/app/public) must be copied too, with rsync between the two servers, or restored from a file backup.
  6. Deploy and test. Run a deployment on the new site and check it through the temporary domain, or by adding a line to your computer's hosts file that points the real domain at the new server's address.
  7. Add the real domain to the new site and request its certificate once DNS allows it. See Get a free Let's Encrypt certificate. A certificate cannot be issued for a name that still points at the old server, so either validate through DNS (wildcard and DNS validation) or switch DNS first and issue immediately after.
  8. Switch DNS. Point the domain's A record at the new server. Watch the new site's Logs tab until requests arrive.
  9. Keep the old site for a day, then take a last backup and delete it as in step 2. Raise the TTL back.
Tip

Queue workers and the scheduler are per site. Switch them on at the new site (see Queue workers and the Laravel scheduler) after the DNS switch and switch them off at the old site, so jobs and scheduled tasks do not run twice.

Troubleshooting

  • The Delete site button is greyed out. The site is not Ready or Failed, or you lack the permission. Wait for the current change to end.
  • "Type the site name to confirm." The text does not match the site name exactly, including case.
  • The site stays on "Deleting". The job runs on the server and takes up to 15 minutes. If it then shows Failed, read the reason, fix it (an unreachable server is typical) and press Delete site again.
  • The domain still shows a page after deleting. DNS still points at the server and Nginx answers with its default page. Remove the DNS record or point it elsewhere.
  • The database is still there. By design. Delete it from the Databases tab of the server.
  • After a move the old site sends email twice or runs jobs twice. Its queue workers or scheduler are still on. Switch them off or delete the old site.
  • The folder on the server still has the old name after a rename. Renaming only changes the label in SrvYard. It never moves folders or changes the Linux user.
Last updated 2026-10-247 min readNeed help? Contact support