Apps - Nightshift

Nightshift Apps are real-time, stateful applications built and deployed through Nightshift’s remote build system. Claude uses our MCP server as a development environment: it writes the application code, submits it, and Nightshift compiles, checks, and hosts it — no local toolchain involved. A published app lives at apps.nightshift.sh/<app-id>/ where anyone you’ve shared it with can open it.

How an app gets built

Ask Claude for an app (“build me a revenue dashboard with a region filter”) and this is what happens under the hood:

Claude inspects your warehouse — listing objects and describing schemas so it writes queries against your real tables, not guesses.
It writes a small React app using the Fiber SDK (more below) and submits the source to Nightshift’s build service.
Nightshift compiles it against your live warehouse. Every query in the app is type-checked against the actual schema — a misspelled column or invalid SQL fails the build with the warehouse’s own error, before anything ships. Claude reads the errors, fixes the source, and resubmits.
On success, the app is live — hosted, versioned, and ready to open.

This loop is why apps built by an agent are trustworthy: nothing reaches production unless it compiles cleanly against your real data.

The Fiber SDK

Application code is written with Fiber, our React SDK for governed data apps. Fiber lets code define SQL queries with bound parameters, get precisely typed rows back, and render them with a built-in set of charts, tables, and KPI components — which is exactly the feedback loop that helps Claude drive toward working software quickly. A flavor of what that code looks like:

const revenueByMonth = defineQuery(`
  SELECT strftime(sale_date, '%Y-%m') AS month, sum(amount) AS revenue
  FROM sales WHERE ($region = 'all' OR region = $region)
  GROUP BY 1 ORDER BY 1
`)

function App() {
  const [region, setRegion] = useAppState("region", "all")  // filter state, synced to the URL
  const q = useQuery(revenueByMonth, { region })
  return <LineChart query={q} x="month" y="revenue" title="Revenue" />
}

Queries are static and parameterized (never string-built), filter state lives in the URL so any view of the app is shareable by link, and apps can even define managed read/write tables for their own state.

Developers can also build Fiber apps by hand with a local toolchain — npx @nightshift-sdk/create-fiber-app scaffolds a Vite project, and fiber publish ships it to the same hosting. If you’re interested in how Fiber works under the hood, read more here.

Identity: development vs. published

Like everything in Nightshift, apps are tied to our policy system. While Claude is building, its queries run under your identity (or the scoped token you’ve given it) — it can only see what you can see. Publishing changes that. A published app no longer makes queries as you — it runs under its own identity, and what it’s allowed to do is frozen at publish time into what we call the manifest. The manifest is a frozen-in-time set of queries (and, for read/write apps, table operations) extracted from the app’s source and vetted under the publisher’s access. At runtime, the hosted app can execute only manifest entries — arbitrary SQL from a browser is simply not runnable. This is a security feature, and it’s what makes sharing apps with many users safe. You can think of an app as a composed view: people you share it with see the data the app presents, without needing (or receiving) access to the underlying tables. If that sounds like a lot — don’t worry. There’s nothing you need to do to get this behavior; it all happens automatically on every publish.

Versions

Every publish creates an immutable version carrying the exact source, the built bundle, and the manifest. The live URL always serves the current version; older versions remain pinned and inspectable. In the console, an app’s detail page shows a live preview, its published source and manifest, and the full version history — so you can always answer “what exactly is this app allowed to run?”

Creating an app requires the app:create capability. If Claude authenticates as you through the standard flow, it acts with your access — which is usually the convenient and reasonable choice. Mint a scoped token instead when you want tighter control.

Next steps

Sharing — give teammates access to run or manage an app
Policies — the grant model apps are built on
Organizing site analytics data — an end-to-end example that finishes with a published app

​How an app gets built

​The Fiber SDK

​Identity: development vs. published

​Versions

​Next steps

How an app gets built

The Fiber SDK

Identity: development vs. published

Versions

Next steps