SideStep Dashboard

Your Xano workspace, on your machine. A fast, local-first dashboard for browsing what's in your workspace, working with your database data, and seeing what your backend is doing — without leaving your laptop or handing your tokens to anyone.

Built with SideStep. Runs entirely on localhost: a small Node backend-for-frontend (BFF) paired with a React + Vite + Tailwind UI. You sign in through Xano's own OAuth 2.1 + PKCE flow; the BFF holds your tokens on local disk and proxies authenticated calls to your instance.

Why SideStep

• Local-first. No cloud middleman, no third-party server. It's your data, your machine, your Xano instance — end to end over loopback.
• Secure by default. Tokens stay in the BFF, never in the browser. Loopback binding, DNS-rebind guard, CSRF protection, and one-click token revocation on sign-out (details in Security).
• Zero config to start. npm install, sign in with Xano, and you're in.
• Fast. A Vite SPA over a thin local proxy — no round-trips to a hosted console.

Features

Live today

• Sign in with Xano — hosted OAuth 2.1 + PKCE, pick your instance and workspace at consent.
• Workspace overview — the connected instance/workspace and identity, plus at-a-glance counts of API groups, APIs (authenticated vs public), and tables.
• API browser — explore API groups and their endpoints, each showing its HTTP verb and authentication state (public, or which auth table guards it); drill into an endpoint for its inputs and cache settings.
• Table browser — browse database tables (auth tables flagged), inspect a table's schema and indexes, and page through its row content — read-only.

All object browsing is read-only by design: your SideStep code is the source of truth for structure, so the dashboard inspects the workspace but never edits its APIs, tables, or schema.

On the roadmap

• Table cell editing — edit row data in place (the one write path planned; structure stays code-owned).
• Request history — see recent requests to your backend and what happened.

The proxy seam (/api/instance/* → your instance's api:meta/*) is already in place, so these panels plug straight into live workspace data as they land.

Quickstart

npm install
cp .env.example .env      # then edit XANO_MASTER_URL if needed
npm run dev               # Vite on http://127.0.0.1:5173, BFF on http://127.0.0.1:4000

Open http://127.0.0.1:5173 and click Sign in with Xano. You'll be redirected to Xano to sign in and pick an instance; on return you land on the dashboard.

Production single-process mode:

npm run build             # builds the SPA to dist/client
npm start                 # BFF serves the built app + API on http://127.0.0.1:4000

Configuration

Set via environment (see .env.example):

Variable	Default	Purpose
XANO_MASTER_URL	https://app.xano.com	Base origin of the Xano OAuth server. Its /.well-known/oauth-authorization-server document is fetched for the real endpoints. Point at production or a local dev instance.
APP_PORT	4000	Fixed BFF port. The OAuth redirect_uri is registered as http://127.0.0.1:${APP_PORT}/oauth/callback, so changing this forces a re-registration on next launch.
SIDESTEP_STORE_MODE	file	Credential storage backend.
SIDESTEP_SESSION_SECRET	random per-process	Secret used to sign the local session cookie. Set it to keep sessions across BFF restarts.
XANO_OAUTH_SCOPE	offline_access workspace:read workspace:api:read workspace:database:read workspace:content:read	Scopes requested (and registered) for the connection. The read scopes back the object browser (APIs, tables, content). Widening scopes on an existing install needs a fresh client registration — sign out and back in.

How auth works

1. On first sign-in the BFF self-registers as a public OAuth client (RFC 7591 Dynamic Client Registration) and stores the minted client_id.
2. GET /oauth/login builds a PKCE (S256) authorize URL and redirects your browser to Xano's hosted login + consent, where you pick an instance.
3. Xano redirects back to http://127.0.0.1:${APP_PORT}/oauth/callback; the BFF exchanges the code for tokens (audience = the selected instance), stores them, and issues an opaque session cookie.
4. The SPA calls the BFF; the BFF attaches the access token and proxies to the instance's meta API (<instance-origin>/api:meta/…), refreshing with rotation as needed. On unrecoverable refresh failure you're prompted to sign in again.

The connected instance/workspace comes from the token's own claims (aud, xano:instance_id, xano:workspace_id, xano:role); your name/email comes from the instance's api:meta/auth/me.

Security

• Tokens live on disk, by default at ~/.sidestep/credentials.json (dir 0700, file 0600, atomic writes, cross-process locking). The refresh token is long-lived — treat this file as a sensitive credential (it can be read by any process running as you and ends up in home-dir backups). An OS-keychain backend is planned; the store already has a pluggable seam for it.
• The browser never receives Xano tokens — only the opaque session cookie (HttpOnly, Secure, SameSite=Strict).
• The BFF binds to loopback only, rejects non-loopback Host headers (DNS-rebind guard), and requires a custom header on state-changing routes (CSRF defense).
• Sign out revokes the refresh token at Xano (RFC 7009) and deletes the local token material.

Development

npm test         # vitest (server + client)
npm run typecheck
npm run build

Status

Early and moving fast. Signup stays hosted by Xano (never reimplemented here), and the dashboard is single-user for now. Read-only browsing of APIs, tables, and row content is live over the /api/instance/* → api:meta/* proxy; table cell editing and request history are next up.