A Child Site is a fully separate Files.com Site nested under a Parent Site. Each Child Site has its own subdomain, custom domain, IP addresses, SSO providers, security and protocol settings, branding, users, groups, folders, automations, and integrations. Every site-level configuration that exists on the Parent Site exists independently on each Child Site.

Child Sites are the right fit when separation has to be at the site level: data residency in a specific region, compliance boundaries that require different security policies, brand or domain separation, or environment isolation between production, staging, and development. Workspaces handle operational delegation within a single site. Child Sites handle hard separation between sites.

Site Administrators on the Parent Site create Child Sites and retain full access to every Child Site they create. A Parent Site Administrator can switch into any Child Site and act as its Site Administrator, and can reach Child Site content directly through the Parent Site's underscore folder. Each Child Site can also have its own Child Site Administrators who manage the Child Site without access to the Parent Site or any sibling Child Site.

Each Child Site offers the same level of features as the Parent Site's plan. Storage, bandwidth, billable users, and API call usage roll up across the Parent Site and every Child Site for billing purposes. See Child Sites Usage. Child Sites require a qualifying plan.

Parent Site Administrators can constrain what Child Site Administrators are allowed to change by setting Child Site Management Policies. When a setting is included in a policy, the value set by the Parent Site applies to every Child Site in scope, and Child Site Administrators cannot override it.

Child Sites is one of several Files.com features for organizing access, administration, and separation. If you're not sure Child Sites is the right fit, see Comparing Child Sites to Related Features below.

Customers use Child Sites to operate subsidiaries and brands under separate domains, meet regional data-residency or regulatory requirements, separate production from staging and development, and run archival or warm-storage sites alongside production. See Child Site Use Cases for examples of each.

For organizations that need site-level separation, Child Sites are the right tool. For organizations that need administrative delegation without separating site-wide configuration, the alternatives below are usually a better fit. For detailed guidance on choosing between these features, see Child Sites, Workspaces, Partners, and Admin Permissions: When To Choose Each.

Child Sites vs. Workspaces

Workspaces provide operational isolation within a single Files.com Site. Each Workspace has its own users, groups, partners, folders, automations, and integrations, but all Workspaces on a site share the same custom domain, IP addresses, SSO providers, security policy, and branding. Choose Workspaces when teams need independent administration but share the same site-wide configuration.

Child Sites provide full site-level isolation. Each Child Site has its own custom domain, IP addresses, SSO, security policy, and branding. Choose Child Sites when separation must extend below site-wide settings, for data residency, regulatory compliance, environment separation, or distinct brands.

The two features compose. A common pattern is to use Child Sites for hard separation between regions, environments, or brands, and use Workspaces within each Site to delegate administration to internal teams.

Child Sites vs. Partners

Partners represent external organizations such as customers, vendors, suppliers, and trading partners that exchange files with your business. Partners live inside a Parent Site or Workspace and are designed for self-service onboarding and scoped access for an outside counterparty.

Child Sites organize your own infrastructure into separate sites. They are not the right tool for managing external relationships. When you need to onboard an external counterparty, use Partners.

Child Sites vs. Folder and Group Admins

Folder Admins and Group Admins are tactical delegation tools, not organizational layers. A Folder Admin manages one folder's settings and permissions. A Group Admin manages users inside a single group, with the specific capabilities (create, edit, enable/disable, delete, set and reset passwords, exempt from User Lifecycle Rules) decided site-wide by Site Administrators. Neither role can manage folders outside their assignment, remote servers, automations, or partners.

Use Folder Admins or Group Admins within a Site or Workspace to delegate narrow tasks. Use Child Sites when the separation needs to extend to site-wide configuration that no admin role inside the Site can change.