Hosting for development teams comes down to one question: can each person do their job without being able to break everything else? That means individual accounts (no shared passwords), roles that match real responsibilities, and a clean way to remove access when someone leaves. This guide explains how seats and roles work, which role each person on a typical South African team should get, and the habits that keep access tidy.
Why a shared login doesn't work
Many small teams start with one hosting login that everyone uses. It feels simpler, but it causes real problems:
- No accountability. When a setting changes or a database is deleted, you can't tell who did it.
- Two-factor becomes impractical. One authenticator app on one phone can't serve five people, so 2FA gets switched off.
- Offboarding means changing the password for everyone, which people postpone, so ex-staff and ex-contractors keep access.
- Everyone has full power, including over billing and account deletion.
- POPIA. Section 19 requires reasonable technical and organisational measures to secure personal information. Knowing who can access systems that hold customer data is a basic part of that.
Individual seats fix all of these.
Seats and roles, explained
A seat is a user account attached to your organisation's hosting account. Each person signs in with their own email, password and two-factor authentication.
A role decides what that seat can do. On NewHost's Business plan (3 team seats) and Agency plan (unlimited seats), there are four roles:
| Role | Typical person | What it's for |
|---|---|---|
| Admin | Owner, technical lead | Full control: team members, settings, apps, billing |
| Developer | Developers, DevOps contractors | Working with apps, deployments, environment variables and databases |
| Billing | Bookkeeper, finance manager | Invoices, payments and plan changes, without touching apps |
| Viewer | Project manager, junior staff, auditor | Seeing status and configuration without changing anything |
The exact permissions of each role are listed in the dashboard and docs. The principle behind them is what matters when you assign roles: give each person the least access that lets them do their work.
Assigning roles on a real team
Here's how a typical ten-person web studio might set things up:
- Two admins. The owner and the technical lead. Always have at least two, so one person's leave or lost phone doesn't lock you out. More than two or three is rarely necessary.
- Developers get the developer role, including senior ones. They can ship code and manage apps, but can't add team members or change billing.
- The bookkeeper gets billing. They download VAT invoices and settle accounts without being able to change a live site.
- Project managers get viewer. They can check whether a deploy succeeded without the risk of an accidental click on production.
- Freelancers get developer access for the length of the contract, then are removed. Put a reminder in your calendar when the contract starts.
Environment variables and secrets
Role design is only half the job. The other half is where secrets live.
- Keep API keys, database passwords and payment keys in the app's encrypted environment variables, not in the repository. Anyone who can clone the repo shouldn't automatically have production secrets.
- Use different credentials for preview and production environments. On the Developer plan and up, branch pushes deploy to their own preview URL; point those at test databases and test payment keys.
- When a developer with access to production secrets leaves, rotate the secrets they could see, not just their seat.
Preview deployments explained covers how to keep preview environments separate from production.
Two-factor authentication for everyone
A role only protects you if the account behind it can't be taken over. Require every team member to turn on two-factor sign-in with an authenticator app, and store their backup codes safely. NewHost also emails an alert when a password changes, which helps someone notice if their account is being hijacked.
Read two-factor authentication with an authenticator app for a walkthrough you can send to your team.
Onboarding checklist
When someone joins:
- Invite them with their work email address, not a personal one.
- Assign the lowest role that fits their work.
- Ask them to set up two-factor sign-in on the first day.
- Give Git repository access separately, through GitHub or GitLab, with the same least-access thinking.
- Share where environment variables live and which are production.
- Note the date and role in your access register (a simple spreadsheet is fine).
Offboarding checklist
When someone leaves, do this on their last day, not "sometime next week":
- Remove their hosting seat.
- Remove them from the Git organisation and any CI/CD system.
- Revoke API keys they created, and rotate any production secrets they could read.
- Check DNS, domain and email accounts they may have had separate access to.
- Review recent changes and deploys for anything unexpected.
- Update the access register.
Access reviews
Every quarter, spend ten minutes listing every seat and role. Remove anyone who no longer needs access and downgrade roles that are broader than necessary. Access tends to grow over time and rarely shrinks by itself.
Frequently asked questions
How many admins should a team have?
Usually two: enough that you're never locked out if one person is unavailable, few enough that full control stays with people accountable for the account. Everyone else should get a narrower role.
Should a client get access to their hosting?
If the hosting account holds only that client's projects, a viewer seat is a good default: it gives visibility without the risk of accidental changes. Check what a seat can see first, and don't invite a client onto an account that also holds other clients' work. If the client has their own developer, agree what access they need and document it.
Which NewHost plans include team seats?
The Business plan includes 3 team seats and the Agency plan includes unlimited seats, both with admin, developer, billing and viewer roles. Team seats aren't part of the Starter and Developer plans.
Do roles replace the need for 2FA?
No. Roles limit what an account can do, while two-factor authentication makes it much harder for someone else to use the account. You need both.
Compare seats and plans on the pricing page, or contact us if you're moving a team's projects across and want help planning access.