Workspaces and Access

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.

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 — the per-workspace billing screen and the help path inside it.
• Deployments — reading workspace-wide vs per-project history.
• Logs — sharing stage output safely.
• NexHost Git — how repository visibility and ownership interact with a workspace.