Portal Guide
Browser Flows For Users And Providers
The Jungle Grid portal is a role-aware browser surface for jobs, billing, provider operations, and account management. It stays aligned with the same orchestrator APIs the CLI uses.
Portal surfaces
- •Login and signup are guest-only browser entry points; signed-in users are sent straight to /portal.
- •The dashboard, jobs, templates, submit flow, and billing views adjust to the active account role.
- •The submit wizard now estimates likely cost before the user confirms the job.
- •Managed template launches have progress pages and session history under /portal/templates.
- •Advanced routing stays tucked behind optional controls so default users remain on the intent-first path.
01
Entry points and session behavior
The browser starts at /signup or /login, stores the chosen account session locally, and sends signed-in users directly to /portal on repeat visits. CLI device confirmation continues through /auth/device so a signed-in browser can approve terminal login.
- •Role-linked accounts can activate either user or provider behavior with the same underlying account.
- •The auth pages now show Jungle Grid branding on mobile and redirect away if a session already exists.
02
Dashboard and jobs
The dashboard gives users quick stats, recent jobs, and shortcuts into the submit flow. Providers see node-focused metrics instead. The jobs page provides a filterable table and job detail views with runtime information when available. Separate logs and artifacts pages expose account-level runtime output and managed files.
- •Users see recent workloads and can open the full jobs list from /portal/jobs.
- •Providers see node-oriented data in the same role-aware shell.
- •Recent jobs and the jobs page use horizontally scrollable tables on mobile instead of collapsing critical fields.
- •Job details, /portal/logs, and /portal/artifacts show runtime output and result artifacts where the execution path reports them.
03
Submit job flow
The submit page is a multi-step wizard for describing the image, workload type, and optional tuning inputs. An Advanced routing panel exposes optional price ceiling, preferred family, avoid-family list, region preference, and latency or cost priorities without forcing exact GPU selection. In the review step, the portal fetches a live estimate and requires explicit confirmation before the real submit call.
- •Estimated output includes likely placement, runtime range, queue wait range, estimated start window, hourly rate, and cost range.
- •If soft preferences are relaxed because no live capacity matches them, the estimate card shows exactly which constraints were relaxed.
- •The final submit action is blocked until the estimate has been acknowledged.
- •If estimation is unavailable, the UI still warns clearly before allowing confirmation.
04
Templates and managed app sessions
The templates page is the browser entry point for curated managed app workspaces such as LoRA Pilot, OneTrainer, and SwarmUI. Launching a template creates a workspace app session, redirects to a progress page, and later enables a proxied dashboard URL once the primary service is ready.
- •The Template catalog lists curated launch lanes plus the Custom job fallback for raw job submission.
- •The Template sessions section groups active and past managed app launches by template for the active workspace.
- •Each progress page shows launch steps, lifecycle activity, linked job state, services, resources, runtime, and cost.
- •Dashboard links are available only after the primary UI has passed readiness through the Jungle Grid proxy.
05
Billing and payout management
Billing is role-aware. Users top up a compute wallet in USD and review credits consumed, while providers track earnings history from the same section. Provider payouts are temporarily unavailable while the platform standardizes on USD.
- •User topups use a Paystack-backed checkout and verification flow in USD only.
- •Provider payout controls are shown as temporarily unavailable rather than active forms.
- •The billing view now has mobile-safe loaded states for balances, action areas, and history tables.
06
Account, keys, credentials, and webhooks
Account and settings cover identity linking, Google linking, and profile-level operational controls. API keys, private registry credentials, Hugging Face credentials, webhooks, and integrations each have shipped portal routes rather than living only in a future settings area.
- •Accounts can link both user and provider roles to the same email.
- •The account page shows the active role and linked identities.
- •API keys are managed under /portal/api-keys and should be treated as server-side secrets.
- •Private registry credentials and Hugging Face tokens are managed under /portal/credentials.
- •Webhook secrets and delivery inspection are managed under /portal/webhooks.
- •The integrations page shows current CLI, API, and MCP setup snippets without guessing third-party integration status.