Child Sites let you run more than one separate Files.com environment under a single primary account. A child site is its own tenant: its own subdomain, its own users, its own permissions, its own audit log. But it shares the billing relationship and the storage pool with the parent. That mix — separate where it counts, shared where it helps — is what makes the pattern useful. Think of a primary account as the head office and each child site as a branch that runs its own front door and its own staff, while the head office still sees the books.
The word for this is multi-tenant: one system that hosts several walled-off environments at once, so each tenant feels like it has the whole thing to itself. Child sites bring that shape to a single Files.com account. This post walks through what a child site is, why teams reach for one, how to create one, and how access works for the parent admin and the child users.
A child site is a fully functional, standalone Files.com site with its own:
A child site looks and works like a completely separate Files.com site, but it shares user and storage quotas with the primary account. You get centralized control from the top and independence at each child.
Spinning up extra sites can look like overhead at first, but a child site earns its place the moment one part of the organization needs to run by different rules than the rest. The common reasons:
Separate subsidiaries or departments can run their own Files.com site and manage files independently.
Sensitive data or restricted-access projects can be isolated in their own child site, so a breach or a misconfiguration in one site can't reach the others.
A child site gives a specific project a dedicated environment, with a clean separation that's easier to manage and easier to hand off.
When two teams or regions need settings that contradict each other — different permissions, different file expiration rules — a child site lets each one keep its own configuration.
An organization with a global footprint can stand up a child site tailored to a specific region or its compliance requirements.
Developers can use a child site to test new workflows or features without touching the production site.
A child site is a clean place to park older projects or files without cluttering the primary environment.
Before you create a child site, it's worth knowing when you don't need one. If all you want is to give different teams different access inside one shared environment, that's what groups and multi-level user administration are for: one site, many groups, each with its own folder permissions. Groups are the lighter tool, and most access-control needs stop there.
Reach for a child site when the teams need real separation, not just different permissions: their own subdomain, their own audit log, their own admins, their own branding. A subsidiary that needs its own logo and login page, a regulated business unit that has to keep its records walled off, an acquired company that needs its own tenant — those are child-site jobs. A few folders that only the finance team should see is a groups job.
Creating a child site in Files.com is short and straightforward.
If you'd rather automate it — for example, to stand up a new child site every time a new subsidiary onboards — you can create child sites programmatically through the Files.com API or SDKs.
Once the child site exists, you land on its dashboard, where you manage its content, settings, and users. Each child site can also carry its own branding and white-label look, so a subsidiary or region keeps its own identity.
Getting into a child site is easy for both child users and primary admins.
This matters most when files need to move from a child site into the primary site. A child site produces documents or media files; the primary admin browses the child site, copies what's needed, and pulls it into the main environment.
Child sites are one expression of a larger idea: Files.com is the cloud-native File Orchestration Platform, one platform that replaces the stack of legacy tools IT teams run to move files — SFTP and FTP servers, MFT suites, file-sharing apps, and the scripts holding them together. It speaks every protocol, connects to 50+ cloud and on-prem systems, automates transfers, and keeps a complete audit trail. Child sites extend that to organizations that aren't one team but several.
Most teams reach for child sites when a single shared site stops being honest about how the organization is actually structured — a subsidiary that needs its own front door, a regulated unit that has to stay walled off, an acquisition that needs its own tenant. Each child site is a full Files.com tenant, and every one of them inherits the same protocol support, the same automation, and the same per-site audit log the parent has. If you're working at a smaller scale and want one shared environment with different access for different teams, Workspaces handle that inside a single site.
To see child sites in practice, explore Workspaces and Child Sites or start a free trial — no credit card, live in minutes.
Google Cloud Storage is built for scalable object storage, not for file transfer workflows. Here are five common workflows GCS can't run on its own, and how teams add automation, orchestration, and secure transfer on top of it.
Financial institutions routinely move ACH files and transaction data between customers, core banking systems, and third-party processors. Learn how modern banking file transfer workflows operate and what IT teams should look for when managing secure, automated integrations across vendors.
As medical groups grow, file sharing turns into a compliance and operational problem. Here is how healthcare IT teams set up secure SFTP access, controlled upload pages, and automated transfers without a big infrastructure project.
4,000+ organizations trust Files.com for mission-critical file operations. Start your free trial now and build your first flow in 60 seconds.
No credit card required • 7-day free trial • Setup in minutes