Running Cloud Accounts as an Agency

One account for every client is chaos. One account per client is overhead. Here is where the line sits and how to organise either way.

28 August 2026 3 min read

Agencies and freelancers hit a structural question early: does every client get their own cloud account, or does everything live in one account with tags?

Both answers are defensible. The wrong one shows up eighteen months later during a handover or a billing dispute.

The case for one account per client

Clean handover. When the engagement ends, you transfer credentials and billing and walk away. No untangling.
Hard isolation. A mistake in one client’s environment cannot touch another’s. Blast radius is bounded by construction.
Unambiguous billing. The invoice is the client’s cost. No allocation spreadsheet.
The client can own it. Some clients require the account in their name for procurement or compliance.
Quota separation. One client’s heavy usage does not consume limits another needs.

The case for one account, well organised

Less administrative overhead. One set of credentials, one place to check, one support relationship.
Shared reserved capacity. Commitments and volume discounts apply across all work rather than fragmenting.
Simpler tooling. One set of API credentials for deployment and monitoring.
Cheaper at the margin. Fewer minimum charges, shared load balancers and NAT.

Where the line actually sits

Situation	Recommendation	Why
Client will take ownership eventually	Separate account	Handover is trivial
Client has compliance requirements	Separate account	Evidence and isolation are cleaner
Small brochure sites you host indefinitely	One account, separated by project	Overhead is not justified
Client handles sensitive personal data	Separate account	Blast radius and audit clarity
Short engagement, you keep hosting	One account, project separation	Simplicity wins
Client pays the cloud bill directly	Separate account	They need the invoice in their name

A workable default: separate accounts for anything the client will own or that carries compliance weight; one well-organised account for ongoing small hosting.

Organising a shared account properly

If you take the single-account route, structure it from day one:

Use the platform’s grouping primitive — DigitalOcean Projects, GCP projects, AWS resource groups or separate VPCs, Azure resource groups.
Adopt a naming convention and apply it without exception: client-environment-role, for example acme-prod-web-01.
Tag every resource with the client. Untagged resources become unattributable within weeks.
Separate networks per client. Shared VPCs mean one client’s server can reach another’s database.
Use per-client credentials for anything automated, so revoking access at the end of an engagement is one action.
Export cost reports by tag monthly, so the allocation conversation is never retrospective.

Access control that survives staff changes

Named accounts for each person, never shared logins. When someone leaves, you disable one identity rather than rotating a password everyone knew.

Where the platform supports roles, give contractors the narrowest role that lets them work, and review access quarterly. It takes twenty minutes and it is the control auditors ask about first.

Plan the exit at the start

Every engagement ends. Decide at kickoff what happens to the infrastructure when it does, write it into the agreement, and keep a current inventory so the handover is a document rather than an archaeology project.

The handover checklist is the list to work through when that day comes.

Common questions

How do I bill clients for shared infrastructure?

Tag everything, export cost by tag, and allocate shared costs — load balancers, NAT, monitoring — by an agreed rule such as proportional to compute. Agree the rule before the first invoice, not after a query.

Should clients have console access?

Give read-only access where they want visibility, and full access only where they have the skills to use it safely. Read-only access resolves most “what are we paying for” conversations.

What if a client stops paying?

Have it in the contract: notice period, then suspension, then data retention window, then deletion. Separate accounts make this cleaner because you are not suspending shared infrastructure.

Is one provider best for agency work?

DigitalOcean’s Projects and Linode’s account structure both suit multi-client work. Kamatera is useful where clients need servers in specific cities. The structure discipline matters more than the provider.

Where to go next

See the handover checklist and cutting a cloud bill for the cost conversation clients always eventually have.

DigitalOcean Kamatera Linode