Starlight

Mainsail Industries · Starlight

Stargate architecture

Operators reach the on-prem site. Stargate bridges it to cloud nodes in AWS, GCP, and Azure, to the enterprise datacenter, and to edge sites over a p2p zero-trust mesh.

Stargate architectureOperators at an on-prem site reach Stargate, which bridges over a p2p zero-trust mesh to Starlight nodes in AWS, GCP, and Azure, an enterprise datacenter, and two edge compute sites.Stargateweb-based access & gatewayStarlight Desktopdesktop appLocal Starlight NodehostWeb Accessweb browserPrivate AI NodeNVIDIA Spark / DGXon-prem sitep2p zero-trustAWSaws · nodesGCPgcp · nodesAzureazure · nodescloud regionsEnterprise datacenteron-prem · dcEdge computesingle nodeEdge computeedge
  • Stargate gateway
  • Starlight node
  • p2p zero-trust link
  • Site

How it works

A session, not a stack.

The path from your browser to your servers is four hops. None of them holds your workloads.

  1. 01

    Sign in with your identity provider

    Google, GitHub, or Microsoft. The site never stores a password; it stores a session.

  2. 02

    The site opens a session to Stargate

    try.starlight.build holds a short-lived, per-user session with the gateway. Nothing else crosses that hop.

  3. 03

    Stargate bridges the p2p zero-trust mesh

    Each Starlight server is a peer. Stargate brokers a direct path where it can and a relay path where it must, such as far-edge links.

  4. 04

    You get one dashboard

    Workspaces, servers, and dashboards across on-prem, cloud, and edge. Starlight Desktop can sit beside it on the same servers.

Stargate

What Stargate is, and is not.

It is a gateway

  • A web access gateway that terminates your browser session and brokers mesh connections to Starlight servers.
  • Something you run yourself, on-prem or in your cloud account, for production.
  • Something Mainsail runs for you during a trial, so you can evaluate before you deploy one.
  • Identity-aware: every connection carries who you are and what policy applies.

It is not where workloads run

  • No VMs, containers, or models execute in Stargate. They run on your Starlight servers.
  • No data at rest. Sessions are ephemeral and scoped to a user.
  • Not a hosted control plane. If Stargate is unreachable, your sites keep running on their own.
  • Not a dependency for Starlight Desktop or the CLI, which reach servers directly.

This site

How try.starlight.build is built.

A thin web app in front of Stargate. Everything below the API layer is either your Starlight servers or Mainsail's portal.

Framework
Next.js 15, React 19, TypeScript, Tailwind v4
Auth
OAuth via Google, GitHub, and Microsoft; session cookies; role-based admin
Data
Postgres for accounts, workspaces, servers, and dashboards
API
OpenAPI 3.1 described; every handler validates with zod and returns Problem errors
Stargate
A typed client; live against your gateway, fixtures when none is configured
Portal
portal.mainsailindustries.com for licenses, user sync, and software downloads
Hosting
Vercel, Node runtime, Fluid Compute defaults, secrets in Vercel env

Browser

try.starlight.build

Next.js 15 on Vercel · dark and light themes

Identity and accounts

OAuth sign-in

Google · GitHub · Microsoft

Roles and admin

user · admin · invites

Site API

OpenAPI 3.1

/api/openapi.json · zod-validated handlers

Postgres

workspaces · servers · dashboards

Integrations

Stargate client

server status · mesh path · session

Mainsail portal

licenses · users · downloads

Your infrastructure

On-prem site
Cloud regions
Edge sites

Point it at your servers.

Sign in, add a workspace with your Stargate endpoint, and see the mesh from the browser.