NexHost Git

NexHost Git#

NexHost Git provides hosted repositories that can be selected as a service source. Rather than coupling the platform to an external code host, workspaces can own repositories directly on NexHost, manage visibility there, and choose that repository as the source when they create or reconfigure a service. Repository access is managed through the dashboard and the Next CLI — the CLI handles authentication and the Git operations; the dashboard handles wiring that repository to a deployment.

The mental model is three hops: create the repository, push source into it, connect it to a service. A push does not by itself change a live release — deployments are created or triggered from the service in the dashboard.

When to use NexHost Git vs another source#

Choose NexHost Git when:

• You want repository ownership and deployability to live inside the workspace — useful for small teams, platform-internal services, or cases where the source does not belong on a public Git host.
• You want to provision repositories from the CLI (next repo create …) and keep credentials out of remote URLs.

Stay with another source when:

• The source already lives in GitHub/GitLab/your organization’s preferred Git host and the team would be fragmented by duplicating it.
• A public Git URL is the intended source and read-only fetch is sufficient.

Create a repository#

Open Dashboard → Repositories and create a repository in the intended workspace. Choose its visibility and copy the clone information presented by the dashboard. The dashboard is authoritative for the workspace-qualified name (YOUR_WORKSPACE/your-repository) — copy it rather than reconstructing it.

You can also create a repository from the CLI — this is often faster when you are provisioning several services:

next login --team YOUR_WORKSPACE
next repo create my-service --private

What that gives you:

• A hosted repository named YOUR_WORKSPACE/my-service with the visibility flag you set (--private keeps it private to the workspace).
• A credential-safe remote URL materializing only via the CLI checkout flow — next clone and the credential helper cooperate so the remote URL itself never has to contain a token.
• The workspace as the ownership boundary — only principals in YOUR_WORKSPACE can see or push to that repository.

Push source#

After creation, push the initial source via the CLI:

next clone YOUR_WORKSPACE/my-service
cd my-service
next add .
next commit -m "Initial service"
next push

Each step in more detail:

• `next clone YOUR_WORKSPACE/my-service` — clones via the platform credential helper rather than a token-bearing URL.
• `next add .` / `next commit` — the usual Git staging/commit cycle, operating on whatever branch you are on.
• `next push` — pushes to the hosted remote on the current branch. Private visibility stays enforced workspace-side.
• `next doctor` — if authentication or the local Git configuration is not ready, doctor is the one-line health check for credential helper and Git wiring.

The CLI keeps credentials out of repository remote URLs, so a git remote -v does not leak a session token even if you paste it in a shared doc. If you do need to share the remote instruction, share the qualified label (YOUR_WORKSPACE/my-service) rather than a computed URL.

Branches, visibility, and ongoing development#

NexHost Git repositories use standard Git branches. Selecting a branch for a service happens on the service itself — during New Project and later when you reconfigure the service to track a different branch.

Typical lifecycle:

1. Create the repository with the desired visibility.
2. Push main (or your team’s default branch) and verify the branch appears on the repository screen.
3. Wire the service to that repository + branch in New Project.
4. For everyday development, push feature branches normally and let the service review a staged branch before promoting.

Connect it to a service#

During New Project, choose NexHost Git as the source when it is offered, select the repository and branch, then review the service’s build, start, or publish settings before deploying. Pay particular attention to the *Root directory* when the repository is a monorepo — the path should point at the package that contains the build manifest (package.json, requirements.txt, go.mod), not at the repository root.

What happens after the wiring:

• A source push does not by itself change a live release. After you push fresh commits, go to the service and start or configure the deployment from the dashboard so the platform records a new release with that updated source.
• The deployment detail records which repository + branch + commit produced each release, along with the captured build and launch settings. Future comparisons between a working and a broken release read that provenance.
• Framework detection, output directory, build log, and timestamps are captured per release as well, so you can diff two releases even when Git history alone is unclear.

Troubleshooting#

Related documentation#

• Next CLI — full install, auth modes, and the doctor health check.
• Deployments and Logs — reading the per-release record of which source actually ran.
• Your First Deployment — the numbered dashboard path from source to verified hostname.