Documentation

Instances

An instance is a containerized GPU sandbox running on an RTX Pro 6000 host. Each instance has a name, one attached SSH key, and a selected GPU profile.

GPU Types

• RTX Pro 6000 - single GPU, 96 GB GDDR7. $1.95 / hour If this profile has no capacity, launch falls back to queueing.

Lifecycle

Once launched, an instance remains available until you delete it. Dashboard status badges reflect live container state (`running`, `exited`, `unknown`).

• Restart cycles the container without ending the billing session.
• Delete removes the container and ends billing for that session.

SSH Access

Running instances expose an SSH snippet in the format ssh user@<hostname>.ssh.enverge.dev. First connect after create/restart can take up to a minute while relay state settles.

Docker

Docker is pre-installed and already running inside your instance — run your own containers with no setup. Plain builds and runs work normally.

To give a container the GPU, use the nvidia runtime plus the NVIDIA_VISIBLE_DEVICES environment variable:

docker run --rm --runtime nvidia -e NVIDIA_VISIBLE_DEVICES=all \
  nvcr.io/nvidia/cuda:13.0.0-base-ubuntu24.04 nvidia-smi

Queue

When capacity is unavailable, launch requests can enter a queue instead of failing. Queue order is first-in, first-out per GPU type.

• You can have one active queue entry per GPU type.
• Queue entries can be cancelled at any time.
• When capacity opens, the oldest matching entry launches automatically.

SSH Keys

SSH keys are managed during instance creation through a named key picker.

• Names are unique per account.
• Only paste public keys, never private keys.
• Keys attached to active instances cannot be deleted.
• Removing an account key does not retroactively remove it from existing instances.

Billing

Billing is metered by usage and settled through Stripe. Session billing spans from create to delete.

Until a card is on file, launch and restart are gated. Set one up from the dashboard banner or the billing section in your user menu.

On a team, only the owner adds or manages the card. Members see read-only “billing managed by {team}” copy instead.

Queueing itself is free. Payment method checks occur when an instance is launched.

Teams

A team lets several people share one payment method. Everyone launches their own instances; usage is tracked per person and billed to the team. Open team from the user menu in the app.

Roles

• Owner - creates the team, manages billing, sends invites, sees each member's usage, and can remove members or revoke pending invites.
• Member - launches instances billed to the team. Cannot add a personal payment method. Sees their own usage in view usage; the owner sees everyone's totals on the team page.

Create a Team

Any signed-in user without an active team can create one from team in the user menu. You become the owner. If you already had solo billing, it moves to the team - you are not billed twice.

Invite a Member

• Owner enters an email on the team page and clicks send invite.
• Invitee receives an email with an accept link.
• New users sign up first (the invite authorizes that email), then accept. Existing users sign in, then accept.
• Once active, the member can launch instances as soon as the team has a payment method on file.

Limits

• One active team per user.
• One payment method per team.
• Removing a member (or revoking a pending invite) takes effect immediately. Removed members fall back to solo billing if they set up their own card.

Usage History

Usage pages show both runtime sessions and queue history. Team members see only their own sessions and queue history; the team owner sees per-member totals on the team page.

• Sessions table: one row per create-to-delete run.
• Queue history: wait duration and final outcome (launched/cancelled).
• Both views are paginated and refreshable from the UI.

Account

• Sign in with email/password or magic link.
• Password reset flow is available from sign-in.
• Sign out is available from the user menu in the app.