Acquia Site Factory Pro cheat sheet

Acquia Site Factory is a multisite management layer on Acquia Cloud: one shared codebase serves many Drupal sites, each with its own database, files, domain, and site configuration.

The factory management console is separate from an individual site's Drupal administration interface; factory-level actions affect site records, deployments, users, and groups across sites.

A site group is a logical partition of sites used for delegated administration, bulk operations, and access scoping; group membership can determine which sites a user can manage.

Shared code means a code change deployed at factory level can affect every site using that codebase; representative site testing is required before production release.

Default domains are platform-provided hostnames assigned to sites; custom domains require DNS records pointing to the platform and TLS certificate provisioning for the hostname.

The Site Factory API is a versioned REST interface for automating site creation, cloning, deletion, user management, and task monitoring; API requests authenticate with tokens.

Environment separation provides production and non-production targets so code and updates can be validated before release; the same tested artifact should be promoted to production.

Governance decision rule: reserve factory-wide roles for users who must create, clone, delete, or deploy across sites; delegate routine site administration through site groups or per-site roles.

Site creation provisions a new site record, database, and files from a selected profile or distribution; the operation runs asynchronously and returns a task to monitor.

Cloning copies an existing site's database and files into a new site while leaving the source unchanged; the clone uses the factory's currently deployed codebase.

Deleting a site removes its site record and associated platform data after confirmation; deletion is destructive, so verify the site identity and backup state first.

A new site receives an automatically generated default domain derived from its site name; a custom domain is added separately after DNS and TLS configuration.

Site names and default domains must be unique within their factory scope; duplicate names cause creation or domain-assignment operations to fail.

Bulk site operations can create, clone, or delete multiple sites in one request; each site becomes an independent asynchronous task that can succeed or fail separately.

A clone captures the source database and files at the time the clone task runs; changes made to the source after that point are not included in the clone.

Lifecycle decision rule: use cloning for reusable site templates or migrations, use new-site creation for clean provisioning, and use deletion only after confirming backups and business approval.

Site Factory code changes move from version control through a build and deployment process to non-production, then production; the same artifact should be promoted between environments.

Because sites share a codebase, a module or theme update deployed to the factory can affect every site; test across representative sites before production release.

After code deployment, Drupal database updates must run for each affected site; Site Factory can run these updates as per-site tasks and report site-specific failures.

Non-production deployment and update testing catch site-specific update-hook failures before production; production deployment follows only after those checks pass.

Much Drupal configuration is stored per site in its database, while code and some exported configuration live in the shared codebase; deployments do not automatically synchronize all site configuration.

Drush commands in Site Factory target a specific site's database and files through site-specific aliases or the API; commands do not run across all sites by default.

A rollback restores the pre-deployment database backup and redeploys the prior code artifact; both code and database state must be returned to a consistent version.

If an update hook fails on one site, isolate that site, fix the code or data issue, and rerun only that site's update; other sites that completed successfully do not need to repeat the update.

A Site Factory user account is a global identity; access to individual sites or site groups is granted separately from the existence of the account.

Factory-level roles grant rights across the factory, such as managing sites, users, or deployments; these roles should be limited to platform operators who need cross-site control.

Drupal roles such as editor or administrator are stored per site database; granting a role on one site does not automatically grant the same role on another site.

Membership in a Site Factory site group can grant a user access to all sites in that group; removing the membership removes that group-scoped access.

API tokens act with the permissions of their associated user or service account; a leaked token exposes exactly those rights until the token is revoked or rotated.

Least-privilege decision rule: separate content editing, site administration, and factory administration so no user has more cross-site power than the current task requires.

When a user leaves, remove their Site Factory account or site-group memberships and revoke API tokens; otherwise their site and factory access may persist indefinitely.

Site Factory can integrate with an identity provider for SAML or similar single sign-on; authentication comes from the identity provider, while site and role authorization remains assigned in Site Factory.