Skip to content

User Guide

This guide explains how to operate the ElasticBLAST Control Plane from the browser. It is organised around the main product surfaces researchers use during a BLAST workflow.

TL;DR

Researchers move through five surfaces: Dashboard (readiness), New Search (submit), Recent searches (track), Results (inspect + download), and Terminal (advanced shell). The API Reference page is for developers who want to drive the backend directly.

Workflow

  1. Open the Dashboard to confirm Azure resources are ready (AKS, Storage, ACR, terminal sidecar, BLAST databases).
  2. Create a search in New Search, starting from the BLAST program and finishing with a command preview.
  3. Track progress in Recent searches and open a job to see live status.
  4. Review and download outputs on the Results page.
  5. Use the Browser Terminal only when command-line inspection is needed — the in-browser shell runs inside the control-plane environment, no laptop tools required.
  6. Use the API Reference when you need to integrate an external client or test a single endpoint.

Pages at a Glance

Page App route Primary screenshot
Dashboard / docs/images/screenshots/dashboard-overview-desktop.png
New Search /blast/submit docs/images/screenshots/new-search-desktop.png
Recent searches /blast/jobs docs/images/screenshots/jobs-desktop.png
Results /blast/jobs/{jobId} docs/images/screenshots/results-desktop.png
Browser Terminal /terminal docs/images/screenshots/terminal-desktop.png
API Reference /docs docs/images/screenshots/api-reference.png
UI Preview /mock-app/ Static mock build — no live data

Try Without An Azure Subscription

If you do not have a deployed control plane yet, open the UI Preview. It runs the same React app with fixture data and lets you click through every page below — Dashboard, New Search, Recent searches, Results, and the API Reference — without provisioning AKS, Storage, or ACR.

Screenshot Policy

Screenshots in this guide are captured from a controlled demo environment. Capture targets, viewports, and the redaction checklist live in docs/screenshot-capture-manifest.json; the end-to-end capture process is documented in the Screenshot Workflow. Refresh an image only when the visible state of that screen changes.