How agencies can manage multiple client websites from one workspace

--- slug: manage-multiple-client-websites-one-workspace title: "How agencies can manage multiple client websites from one workspace" seoTitle: "Manage Multiple Client Websites From One Workspace" metaDescription: "A practical guide for agencies on how to manage multiple client websites from one Acrosite workspace — Projects per client repo, per-project Client Reviewers, shared Team Members, and cross-project logs." focusKeyword: "manage multiple client websites" cat: "Agency Workflows" type: "Guide" read: "8 min read" excerpt: "Stop juggling logins and repos. How agencies manage multiple client websites from one workspace using Projects, per-project Client Reviewers, shared Team Members, and a consistent content model." author: "Acrosite Team" date: "2026-06-06" updated: "2026-06-06" image: "/blog/manage-multiple-client-websites-one-workspace.webp" imageAlt: "Abstract Acrosite illustration of one workspace branching into multiple client projects, each mapped to its own repository" ---

If your agency runs more than a handful of sites, the hardest part of the day is rarely the writing. It is the switching. To manage multiple client websites today, most teams hop between separate logins, juggle a different repository for each brand, and try to remember which client uses which content path. Every context switch costs a few minutes and a little accuracy, and across a week those minutes add up to a real tax on your team.

Acrosite is built to remove that tax. A single Workspace holds every client you serve, each Project maps cleanly to one client website and its repository, and your Team Members move between them without re-authenticating or hunting for the right repo. This guide explains how that structure works, how to keep a consistent content model across very different sites, and how cross-project planning and logging give you a single view of everything in flight.

The hidden cost of the login-and-repo-switching tax

A typical multi-site setup grows by accident. You take on a client, spin up a repo, bookmark another login, and repeat. Six clients later, the operational picture looks like this:

• Each site has its own dashboard or its own folder in GitHub, so nobody has a single place to see what is publishing this week.
• Editing content means opening the right repository, finding the right path, and editing Markdown by hand — which is fine for a developer and risky for everyone else.
• Onboarding a freelancer or a junior editor means repeating that setup, with all the access mistakes that invites.

The cost is not just time. It is the small errors that creep in when a person is mentally loading a different context every few minutes: a draft published to the wrong branch, a client who sees content meant for another account, a missed deadline because the calendar lived in three different tools. Consolidating into one workspace is less about convenience and more about removing the conditions that produce those mistakes.

How to manage multiple client websites: one Workspace, many Projects

Acrosite's structure is deliberately simple, and it mirrors how an agency actually thinks.

• A Workspace is your agency's home. Billing, plan, and Team Members live here, and it is the only thing you log into.
• A Project maps to one client website. Each Project connects to that client's GitHub repository on a specific branch and content path — for example content/posts/ for a blog and content/pages/ for static pages.
• A Client groups the related Projects for a single brand, so a client with a marketing site and a separate docs site stays organized under one roof.

Because the connection lives at the workspace level through a GitHub App scoped to each connected repository, you authorize access once per client repo rather than passing personal tokens around your team. That is the recommended path over an older personal access token, and it keeps repository access tied to the agency rather than to one person's account. You can read more about the trade-offs in GitHub publishing.

The practical payoff: switching from one client to another is a click inside the same dashboard, not a new login and a fresh repository clone. Your editors stay in one tool all day.

A concrete example

Imagine an agency, "Northwind Studio," serving three clients:

1. Client A — a Next.js marketing site, content in content/posts/, deploying on every commit to main.
2. Client B — a documentation site, content in content/docs/, deploying from a release branch.
3. Client C — a small business site with a few Pages and an occasional blog post.

In Acrosite, Northwind has one Workspace, three Projects (one per repository), and three Clients. An editor writes a post for Client A, schedules a docs update for Client B, and fixes a Page for Client C — all without leaving the dashboard or touching GitHub directly. Each publish commits to the correct repository, branch, and path because that mapping is configured once per Project.

Per-project Client Reviewers keep clients in their lane

Clients want to review their own content. They do not want — and should not have — access to your other clients' work, your GitHub repositories, or your billing. Acrosite handles this with Client Reviewers invited per Project.

A Client Reviewer:

• Sees only the content assigned to them within their Project.
• Can read drafts, leave comments, and either Approve or Request Changes.
• Has no GitHub access, no billing visibility, and no workspace settings access.

Because reviewers are scoped to a single Project, a person from Client A literally cannot see Client B exists. That isolation is what makes a shared workspace safe for an agency: consolidation for your team, strict separation for your clients. When a reviewer approves a draft, it moves forward in your internal Review Queue; when they request changes, their comments come straight back to the assigned editor. The full approval flow is covered in client review.

Shared Team Members across every client

Your own people are the opposite case. You want them to move freely. Team Members are internal collaborators who belong to the Workspace, with roles such as Owner/Admin that govern what they can change.

This means:

• An editor can work across Client A, Client B, and Client C without separate accounts for each.
• Onboarding a new hire is one invitation to the Workspace, not three repository grants and a list of logins.
• When someone leaves, you remove them once and their access to every client ends — no orphaned repo permissions to chase down.

The combination is what makes the model scale: Team Members are shared and mobile, Client Reviewers are scoped and isolated, and the Workspace is the single boundary you manage.

A consistent content model across very different sites

Different clients have different content, but you do not want a different way of working for each one. Acrosite gives every Project the same content primitives so your team's habits carry across sites:

• Posts for time-based, blog-style content.
• Pages for stable, standalone content like an About or Pricing page.
• Custom Content Types for anything structured — case studies, team bios, product entries, events.
• Custom Fields define the typed fields on a content type (text, rich text, image, an SEO field, and more), so editors fill in a clean form instead of remembering frontmatter keys.

Each entry your team produces is a Content Item, and on publish it becomes a Markdown or MDX file with YAML frontmatter in the client's repository. A case study Custom Content Type might serialize like this:

---
title: "How Acme cut load time in half"
client: "Acme Co."
industry: "E-commerce"
heroImage: "/images/acme-hero.webp"
seoTitle: "Acme performance case study"
publishedAt: "2026-06-06"
---

Define that content type once, reuse the pattern across clients, and every editor produces consistent, valid frontmatter without hand-editing files. To see the model in depth, read Custom Content Types and the posts, pages, and custom content types explainer.

One calendar and one set of logs across all projects

The real advantage of consolidation shows up in visibility. When everything lives in one Workspace, planning and auditing stop being per-client chores.

• The Content Calendar gives you a single timeline of what is planned, in progress, and scheduled across every Project — so you can balance workload and avoid clustering publishes on the same day. See Content Calendar.
• Scheduled publishing holds an approved draft inside the app and commits it to the client's branch at the chosen time, with no early commit. You plan the date once and Acrosite ships it. Details are in Scheduled publishing.
• Publish Logs record each publish attempt's steps — content validated, committed to GitHub, commit SHA saved, deployment triggered — without ever exposing tokens, hook URLs, or raw provider payloads. A failed publish can be retried where it is safe to do so. See Publish Logs.
• Deployment Logs capture the results of the deployment trigger that asks the hosting provider to rebuild the live site, giving you Deployment visibility per Project.

A simple end-to-end sequence across the agency looks like this:

1. An editor drafts a Content Item in the correct Project; the draft stays private in the app.
2. The assigned Client Reviewer reads it, comments, and approves.
3. The editor schedules it on the Content Calendar.
4. At the chosen time, Scheduled publishing commits the file to the client's branch and path.
5. The deployment trigger rebuilds the site; Publish Logs and Deployment Logs record the outcome.

You can watch that flow for thirty sites from one screen, instead of logging into thirty places to check whether each one shipped. For an end-to-end overview of how the pieces fit, how it works is a good starting point, and pricing outlines the plans — Solo, Creator, Agency Starter, Agency Pro, and Enterprise — with a 14-day free trial for trying the workflow on your own sites.