Sites, platforms and clients

When you log in to your hosting control panel (the Aegir Hostmaster web UI), almost everything you see is one of three things: a platform, a site, or a client. Once these three click into place, the rest of the panel makes sense. This page is the friendly mental model — no server jargon, just what each one is and how they fit together in your account.

The three things, in one breath

  • A platform is a codebase — a ready-to-use Drupal (or Backdrop) build that sites can be installed onto.
  • A site is one live website. It runs on a platform, and it has its own database and its own files.
  • A client is the owner. A client owns one or more sites.

Think of it like this: the platform is the kitchen (the tools and appliances), a site is a meal cooked in that kitchen (yours, and yours alone), and the client is you — the person the meal belongs to.

Platforms — the codebase your site runs on

A platform is a build of Drupal or Backdrop sitting ready on the server. It includes the core code plus a set of profiles you can install. Several different sites can share the same platform, and that's completely normal — they don't see each other, and each keeps its own database and files.

You generally don't build platforms yourself — the platforms available to you are prepared and maintained for you. What you do is choose one when you create a site (more on that below), and later, when it's time to move to a newer build, you migrate your site onto a fresh platform. You don't upgrade a platform's code underneath a running site; you move the site to a newer platform instead. If you ever need a platform that isn't in your list — a different Drupal version, or a specific distribution — that's something your host sets up for you, so open a support request and ask.

Sites — your actual websites

A site is one website you run. Each site has:

  • a domain name (the address people visit),
  • its own database (all your content and settings live here),
  • its own files directory (uploads, images, generated files),
  • a platform it runs on, and
  • a client that owns it.

Everything about a site is kept separate from every other site — your database is yours, your files are yours. Two sites on the same platform never share content.

Clients — who owns what

A client is simply the owner of one or more sites. In your account, the client is you (or your organisation). Ownership is what decides which sites show up in your panel and which ones you're allowed to manage. You don't usually have to think about clients day to day — they quietly keep everything filed under the right owner behind the scenes.

How they relate when you create a site

Creating a site is where the three come together, and the Add site form in the panel walks you through it. In order, you fill in:

  1. Domain name — the address for the new site.
  2. Install profile — the type of site to install (for example, a standard Drupal profile or a distribution). This is the recipe the new site starts from.
  3. Platform — the codebase the site will run on. This is the pick that matters most here: the list shows the platforms that support the profile you chose above, so if you change the profile the platform list may change too. That's the panel making sure your chosen recipe and chosen kitchen actually match.
  4. Language — the language the site installs in.
  5. Database server — where the site's database will live (usually there's a sensible default already selected).

So the reason you pick a platform is straightforward: a site can't run without a codebase to run on, and the platform is that codebase. The form only offers you platforms that fit the profile you picked, so you can't accidentally pair a recipe with a kitchen that can't cook it.

When you submit the form, the panel doesn't build the site on the spot — it queues the work and gets to it shortly. You'll watch it happen on the site's task list, which brings us to the lifecycle.

The lifecycle you'll see

Once a site exists, it moves through a handful of clearly named states, and every change is driven by a task you can see running in the panel. The task names below are exactly what you'll see in the UI.

  • Queued → installed. A brand-new site starts out queued. The Install work runs automatically after you submit the Add site form, and when it finishes your site is installed and live.
  • Verify Site. Any time you want to be sure a site is set up correctly, you can run Verify Site. It confirms the site is in good shape and regenerates its configuration to match what the panel expects. It's a safe, routine action — reach for it whenever something looks off.
  • Backup and Restore. Backup makes a snapshot of the site you can return to later; Restore rolls the site back to one of those snapshots (and takes a fresh backup first, just in case).
  • Disable / Enable. Disable takes a site offline without deleting anything — the site and its data stay put, visitors just can't reach it. Enable brings it back online. Handy for pausing a site you're not ready to remove.
  • Delete Site. Delete Site removes the site. Take a backup first if there's anything you might want back — deletion is meant to be final.

Each of these is a task, and each task shows its progress and a log in the panel, so you're never guessing whether something worked. You kick off the action, watch it run, and see the result.

Where to go next

That's the whole model: platforms hold the code, sites are your websites running on them, and a client owns the sites. If a word here was new to you, the glossary has short, plain definitions. And once you're ready to poke around your own files directly, see the shell and SFTP guide.