# Workspaces and Access

> Keep project ownership, access, and support information organized within a NexHost workspace.

Source: https://nexthomelabs.com/docs/teams
Markdown: https://nexthomelabs.com/docs-md/teams
Slug: teams
Section: Teams and Billing
Last updated: 2026-08-30
Reading time: 3 min read

---

# Workspaces and Access

Projects, services, repositories, domains, and billing are organized in a **NexHost workspace**. The workspace is the security and billing boundary: choosing the wrong active workspace before creating a project or changing a domain means the new resource is not visible to the intended team, and its cost rolls up to a different account. Confirm the active workspace before creating a project or changing a domain so the new resource is visible to the intended team.

## How workspaces organize the platform

A workspace scopes everything a team ships together:

- **Projects and services** — a project groups one or more services; services are the deployable units within it.
- **Repositories** — NexHost Git repositories are owned by a workspace.
- **Domains** — a custom domain attachment belongs to a workspace and is bound to a public service inside it.
- **Billing** — charges, invoices, and payment contact are tracked per workspace.

That scoping has operational value beyond ownership: the deployment history for a workspace answers "what shipped across our services today?" and a per-project history answers "what shipped for this specific service?" Because logs, hostnames, and environment variable snapshots are all per-release artifacts inside that boundary, the workspace is the natural place to start any audit.

## Practical access hygiene

These four habits prevent the majority of access-related surprises:

- **Keep project ownership and billing contact information current** in workspace settings. An owner that has left the organization should not remain the sole contact on a billing-impacting workspace.
- **Use a dedicated project or service for each independently deployable application.** Sharing a single service definition across two unrelated applications makes configuration and rollback unpredictable — a change to one drifts the other without a clear history.
- **Review deployment history before restoring a release.** The history lists source, configuration, and timestamp per release; it is faster to confirm the exact release you mean to reactivate than to fix the wrong restore.
- **Remove credentials from source and deployment logs before sharing them** with collaborators or support. The deployment detail already contains enough for diagnosis — the project name, service name, and timestamp — without an API key being pasted alongside it.

> [!TIP]
> When two teams share a workspace, give each service a stable, descriptive name (`storefront-web`, `storefront-worker`, `billing-cron`) so the deployment dashboard is legible during incidents without requiring extra labeling conventions.

## Day-to-day collaboration flow

- **Before you create:** confirm the active workspace name in the header.
- **Before you change a domain:** open the domain row for the target workspace — domains in another workspace are not available to attach to this project.
- **Before you share a log:** redact `DATABASE_URL`, passwords, tokens, and private host references. Keep only the key names where a reviewer needs to reason about configuration.

## Getting help

Use **Documentation** from the dashboard navigation for product guidance and **Support** for an account or deployment issue. The fastest path to a useful response is a tight report:

- The **project name**, **service name**, and **deployment time** (or the deployment detail URL) when the issue is about a deployment failure.
- A short excerpt around the **first error** — not a long dump of the whole tail — with secrets already removed.
- The workspace name when the issue is about ownership or visibility.

Do not include **passwords, access tokens, or database credentials** — not in a support message, not in a shared log — even when they feel necessary to "show the full context." A support engineer can map from key name + stage to the fix without seeing the value.

### Related documentation

- [Billing](/docs/billing) — the per-workspace billing screen and the help path inside it.
- [Deployments](/docs/deployments) — reading workspace-wide vs per-project history.
- [Logs](/docs/operations/logs) — sharing stage output safely.
- [NexHost Git](/docs/git) — how repository visibility and ownership interact with a workspace.