Server blueprint and rebuild

A blueprint is a saved copy of a server's setup, so that a lost server can be rebuilt on a new one without rebuilding it by hand. It is kept as numbered versions, and only the newest ten are kept.

What a blueprint holds#

• Web stack: the web server (nginx or OpenLiteSpeed), the PHP versions, and the PHP extensions the server was asked to have.
• Sites: domains and aliases, type, PHP, Node, Python and runtime versions, web root, HTTPS, app and container settings (image, port, volumes, Compose file), PHP settings, page cache, WAF mode, access rules, the canonical host and the address allowlist, Octane, your own nginx or OpenLiteSpeed directives, and the deploy settings (repository, branch, commands, shared paths, release command).
• Databases: engine, version, name and owner, and which site uses each one. Not their contents.
• Users: login shell, sudo and SFTP-only flags, and the SSH keys they had (matched by fingerprint in your account).
• Cron jobs and daemons: name, user, schedule or command, timeout, enabled state, and the site they belong to.
• Firewall: the rules and the SSH sources and port.
• Backup plans: which sites a plan covers (used by the optional file restore below).

A blueprint holds no secret in clear text. The .env files and the cron and daemon command lines are stored sealed, the same way the panel stores them, and are only opened to restore. Site files, database contents, certificates, DNS records and the basic-auth password are not in it (see "What is not restored").

When a version is saved#

A blueprint is checked every 15 minutes. A new version is saved only when the setup changed, including an edited .env file. You can also press Capture now on the server's Blueprint tab. Only owners and admins see the tab's actions.

Restore onto a server#

1. Open the Blueprint tab of the new or empty server. A server that already has sites, databases, users, cron jobs or daemons is refused: a blueprint goes only onto an empty server.
2. Choose the version to restore: this server's versions, or the latest version of another server in your organization.
3. Tick Also restore the latest backup of each site's files if you want the files back (optional, see below).
4. Press Preview. Nothing is created yet. The preview lists the steps in the order they run, anything that blocks the restore, the notes about what is left out, and how many passkey approvals to expect.
5. Press Start restore, then approve the first step with your passkey. Nothing is created before that approval.

The steps run one after another, in this order: web stack, PHP extensions, firewall, users, database servers, databases, database contents, sites (each with its settings, .env file and database link), cron jobs, daemons, and the backup file restores. Each step shows its status while it runs. A step that needs a passkey (sudo users, root cron and daemons, your own directives, sensitive firewall ports, file and database restores) waits for its own approval, as it does anywhere else in the panel. A step that fails stops the restore; Retry step runs that step again, and the steps that already finished are not repeated. Cancel restore stops it; jobs already queued keep running.

Files from backups#

Site files are not in a blueprint. If the server had a backup plan, tick the option on the restore. For each site the plan covers, the newest snapshot of its folder is put back in its place on the new server, using the plan's own repository and password. Those restores overwrite what is in the folder, so each one asks for a passkey.

Each database then gets the data of its newest dump in the backup plan that covers it, loaded into the empty database the step created. A database that no restored plan covers comes back empty. A backup plan with your own key asks for its passphrase when you start the restore. The passphrase is kept sealed on the server until the restore succeeds or is cancelled, and is never shown again.

What is not restored#

• Site files and database contents not covered by a restored backup plan. Deploy the sites again, or restore the backups from the Backups page.
• Database passwords. Each database gets a new password; the sites that use it get the new credentials in their .env file.
• Certificates. They are requested again. Point the DNS records of each domain at the new server first.
• The HTTP basic-auth password of a site. The user name comes back; set the password again under Access.
• Dedicated IP addresses. Assign them to the new server and set them on the site again.
• Deploy keys. A site deployed with a deploy key gets a new one: add the key shown on its Deploy page to the repository. A site deployed through the GitHub App comes back with a deploy key; connect GitHub again to use the App.
• Deploy hook URLs. The hook gets a new address; update your provider's webhook.
• SSH keys that are not in your account. The user is created without them, and the page lists which keys are missing.
• Your own backup key. A backup plan that uses your own key needs its passphrase, so its files are restored from the Backups page.
• Provider settings (snapshots, DNS zones, cloud firewall): see the server's own pages.

DNS: domains in your Cloudflare, DigitalOcean or Hetzner zones get their address records pointed at the new server, as they do for a new site.

Permissions#

Only owners and admins can capture, preview and restore a blueprint. Members with other roles see the tab but not its actions.