Managing sites & platforms

This is where you'll spend most of your time: the Aegir control panel, running your own sites. Everything on this page happens in the web UI you log into — no server access, no root, nothing to install. You click a button, Aegir queues a task, and a few moments later your site reflects the change.

If you're comfortable in Drupal but brand new to Aegir, the two ideas below are all you need to get going. The rest of this topic walks you through each job step by step.

Two ideas to start with

A platform is a codebase. It's one copy of Drupal (core plus contributed modules and themes) that one or more of your sites run on. When you want to move a site to a newer Drupal, you don't upgrade the site in place — you put the new code on a fresh platform and move the site there. Your host may set platforms up for you, or you may be allowed to add your own.

A site is a domain running on a platform. It has its own database, its own files, its own settings, and its own backups. Two sites on the same platform share the code but nothing else — separate databases, separate everything.

That's the whole model. Add a platform (the code), then create sites on it (the domains). Everything else — cloning, moving, HTTPS, aliases — builds on those two.

What you can do here

When you open one of your sites in the control panel, a row of tasks appears. These are the ones you'll reach for most:

  • Verify Site — re-checks the site and regenerates its config to match what the control panel says. The safe "make it match again" button; run it whenever a site looks out of sync after a change.
  • Backup and Restore — take a snapshot on demand, or roll back to an earlier one. A fresh backup is always taken before a restore, so you can't lose your current state by rolling back.
  • Clone — make a full copy of a site under a new domain, on the same platform.
  • Migrate Site — move a site to a different platform (for example, a newer Drupal) or rename it to a new domain.
  • Disable and Enable — take a site offline temporarily without deleting it, then bring it back.
  • Reset password — generate a one-time login link for the site's admin user, handy when you're locked out of your own Drupal.
  • Delete Site — remove a site completely. Its last backup is kept, but the action can't be undone otherwise.

Every one of these runs as a task: it goes into a queue, runs in the background, and shows you a live log while it works. You don't have to watch it — you'll see it turn green (or red) when it finishes.

In this topic

  • Creating a site — the create-site form field by field: Domain name, Install profile, Platform, Language, and (if you have more than one) Database server. What each choice means and what happens after you submit.
  • Everyday site tasks — Verify, Backup, Restore, Disable/Enable, Reset password, and Delete, with when to use each and what to expect from the task log.
  • Working with platforms — what a platform is, choosing which one a new site lands on, and (if your host lets you add your own) creating a platform from a Platform Path or a Deploy from makefile build.
  • Cloning & migrating — the safe way to copy a site, move it to a newer Drupal, or rename it — and the one rule that saves you the most grief: change one thing at a time.
  • Domain aliases — adding extra domains to a site under Domain Aliases, the automatic www. (or bare-domain) alias BOA generates for you by default, and using Redirect all domain aliases to so every alias points at your primary domain.

The golden rule for clone and migrate

Aegir gives you two moving jobs and it's easy to mix them up. Keep them separate:

  • Clone copies a site to a new domain on its current platform.
  • Migrate Site moves a site to a different platform, or renames it to a different domain.

The rule that keeps you out of trouble: never change two things at once. Don't clone and switch platforms in the same step, and don't migrate to a new platform and a new domain in the same step. When you want to land on a newer platform safely, the recommended path is:

  1. Clone the site on its current platform, so you have a copy to experiment with.
  2. Migrate that copy to the new platform.
  3. Check the migrated copy works exactly as expected.
  4. Only then migrate your live site.

This is the same advice the control panel itself gives you on the Clone and Migrate forms, and it exists because it's saved a lot of people from a bad afternoon.

When it's not yours to fix

Almost everything about your sites is yours to do from this control panel. A few things aren't, and that's by design — they belong to the server, which you don't (and shouldn't need to) touch:

  • Adding, removing, or reconfiguring web and database servers.
  • Installing extra system packages, changing PHP or Nginx globally, or adjusting server-wide limits.
  • Making a platform you don't have permission to create, or unlocking one your host has deliberately locked.

If you hit one of these, don't go looking for a workaround — it's something your host or operator does. Open a support request and describe what you were trying to do.

Where to go next

  • Turning on HTTPS for a site has its own topic, SSL for your sites.
  • The per-site and per-platform settings you're allowed to tune — via boa_site_control.ini (in your site's modules folder) and boa_platform_control.ini (in the platform's sites/all/modules folder) — are covered in Tuning your site.
  • Self-service backups from your own shell with mybackup are covered in Backing up & restoring.
  • Full task and control-file names are collected in the shared Reference.