Glossary (for site owners)

A short, plain-language list of the words you'll meet while running your sites. Everything here is described from your point of view — the person who logs into the control panel and looks after the sites. You don't need to know how the server works, and nothing here asks you to touch it.

If you're brand new, start with Your account and first login first, then come back here whenever a word is unfamiliar.

The things you work with

Site — one hosted Drupal site: its domain name, its database, and the code it runs on. This is the main thing you create and manage in the control panel. Most of your day-to-day work is about sites.

Platform — the pool of Drupal code your sites run on. Think of it as a Drupal codebase that one or more of your sites share. You don't edit a platform's files to upgrade a site; instead you move the site onto a newer platform (see Migrate under Tasks below).

Client — the account that owns your sites, used for access and organising who can see what. In most hosted setups you are a single Client and rarely think about it — it's just the name your sites belong to.

Instance — your whole slice of the server: your control-panel login, your sites, and your own shell account, all kept separate from every other customer on the same machine. When you see "your instance" in the docs, it means everything that's yours.

Alias — an extra web address that points at one of your sites. For example, having www.example.com also reach the site you set up as example.com. You add aliases from the site's settings in the control panel.

Where you do the work

The control panel (Aegir / Hostmaster) — the web login where you create sites, run tasks, take backups, and turn on encryption. You'll sometimes see it called "Aegir" or "Hostmaster"; they all mean the same website you sign in to. This is where most of your work happens, no shell needed.

Your shell (the oN.ftp account) — your personal command-line/SFTP login to the server, where oN is your account name (like o1, o2, and so on). It's a limited shell: you can manage your own files and run a curated set of commands, but you can't reach other customers' files or change the server itself. Always connect as the .ftp account (for example o1.ftp) when you want to run Drush or Composer — that's the login where BOA's command tools are set up to work correctly.

Tasks — things that happen to your site

Every action the control panel performs is a task. A task runs in the background and keeps a status (queued, then processing, then completed or failed) and a log you can read. The ones you'll use most:

Verify — the "make it so" button. After you change a site's settings, run Verify to have the system apply the change and re-check that everything is in order. It's safe to run again; if you're ever unsure whether a change took effect, Verify is the first thing to try.

Backup — makes a snapshot archive of the site (its files and database). From the site's Backups tab you can create a backup on demand, then export it and download it to your own computer. Keep a copy before any big change.

Restore — puts a site back to the state captured in one of its backups. You choose the backup and confirm; the running site is replaced with that snapshot.

Migrate — moves a site onto a different platform, which is how a Drupal-version upgrade is done. You pick the newer platform and the site is moved onto it.

Clone — makes a fresh copy of an existing site as a new site, using a backup as the starting point. Handy for spinning up a staging or test copy.

Backups on the command line

Backup / restore from your shell — besides the control panel, BOA gives you a mybackup command in your oN.ftp shell for working with off-site backup copies. You'll mainly meet it as mybackup restore … when pulling a file back from remote storage. For everyday snapshots, the control panel's Backup task is the simpler route.

Security

Encryption (SSL / HTTPS) — the padlock for your site: it serves traffic over https:// so visitors' connections are protected. In the control panel this setting is called Encryption on the site's edit form. Turn it on there and run Verify, and the certificate is obtained and installed for you automatically. You don't handle certificate files yourself.

The control files you can edit

You have two optional settings files you may create to fine-tune BOA's behaviour for your own sites. You don't need them to run a site — they're there for when you want to override a default. Both start life as documented templates that live alongside your platform's code; you copy the template, uncomment the one or two lines you want, and save. Changes take about a minute to take effect (BOA caches settings for performance), so don't be alarmed if a change isn't instant.

boa_site_control.ini — settings for one site. Copy the template into that site's sites/<yourdomain>/modules/ folder to change behaviour for just that site (for example, session cookie lifetime or per-site cache options).

boa_platform_control.ini — the same idea, but for every site sharing a platform. Copy the template into the platform's sites/all/modules/ folder to set a default across all of those sites.

The templates themselves are clearly marked "do not edit" — that's expected. You never edit the template; you copy it under the name above and edit your copy.

Running Drupal from the command line

Drush — the standard Drupal command-line tool, for jobs like clearing caches or running database updates on a site.

vdrush — the version you actually run in your oN.ftp shell. It runs the site-local Drush that ships inside your platform's own code, under the PHP version your shell is set to use, so a command like vdrush @yoursite.com cr (clear the cache) targets one of your sites correctly. Use vdrush whenever you work with a site from your shell, and always from the .ftp login.

When something needs the server itself

Now and then a fix genuinely lives at the server level — the machine's software, a service that won't start, anything outside your account. That's not something you can do from the control panel or your shell, and it isn't a gap in this guide: it's simply your host's job. When you hit one, open a support request and let your operator handle it.

Related term lists live in the shared Reference section, and features that used to exist but were retired are recorded under Discontinued.