Vango

Full-stack Go Apps.

The server-driven Go framework designed for AI Agents.

bashinstall
go install github.com/vango-go/vango/cmd/vango@v0.3.0
vango create myapp && cd myapp && vango dev

Server-owned state

Reactive UI without hydration drift or client/server synchronization.

Thin client runtime

A compact JS runtime that captures events and applies binary patches.

Deploy-safe persistence

Generated state artifacts and warm/cold deploy visibility before release.

dashboard.go
func Dashboard(p DashProps) vango.Component {
    return vango.Setup(p, func(s vango.SetupCtx[DashProps]) vango.RenderFn {
        stats := setup.Resource(&s, loadDashboard)
        return func() *vango.VNode {

One Language

Build the UI, server logic, and product workflows in Go without maintaining a separate frontend stack.

  • Server-rendered HTML
  • Reactive state on the session loop
  • No client/server state synchronization layer

Launch shape

vango create my-app
cd my-app
vango dev

One Blessed Model

Stateful components use `vango.Setup`, render stays pure, and async work is isolated in Resources, Actions, or page Actions.

  • Setup allocates state once
  • RangeKeyed preserves list identity
  • RouteForm pairs with a page Action

Launch shape

func Counter(p CounterProps) vango.Component {
    return vango.Setup(p, func(s vango.SetupCtx[CounterProps]) vango.RenderFn {
        count := setup.Signal(&s, 0)
        return func() *vango.VNode { ... }
    })
}

Deploy-Safe State

Persistence is deliberate, schema-aware, and visible before you ship. Vango computes warm versus cold deploy impact instead of guessing.

  • Generated routes, state artifacts, and bindings are committed
  • Warm/cold deploys are explicit
  • Sessions survive safe refactors

Launch shape

$ vango state plan
Added persisted IDs: 1
Classification: WARM DEPLOY

Programming Model

One blessed way to build stateful UI.

Vango pushes you toward a narrow set of patterns on purpose: state is allocated in Setup, render stays pure, and blocking work moves into Resources, Actions, or page Actions.

  • Use `vango.Setup` for every new stateful component.
  • Keep all reactive writes on the session loop.
  • Prefer `setup.Resource`, `setup.Action`, and `setup.RouteForm` over improvised flow control.

go

Canonical Vango patterns

1func Counter(p CounterProps) vango.Component {
2    return vango.Setup(p, func(s vango.SetupCtx[CounterProps]) vango.RenderFn {
3        count := setup.Signal(&s, p.Initial)
4
5        return func() *vango.VNode {
6            return Div(
7                Button(OnClick(count.Dec), Text("-")),
8                Span(Textf("%d", count.Get())),
9                Button(OnClick(count.Inc), Text("+")),
10            )
11        }
12    })
13}

go

Persistence and release workflow

1var ThemeKey = vango.NewSessionKey[ThemePrefs](
2    "theme",
3    vango.Default(ThemePrefs{Mode: "system"}),
4)
5
6cartItems := setup.SharedSignal(&s, []CartItem{})
7announcement := setup.GlobalSignal(&s, "")
8
9return Div(
10    Button(OnClick(func() { cartItems.Set(append(cartItems.Get(), item)) })),
11    Button(OnClick(func() { announcement.Set("Maintenance tonight") })),
12)

Deploy Safety

Persist deliberately. Ship with visibility.

Vango treats persistence as a contract. The framework generates state artifacts, computes deployment impact, and makes warm versus cold changes visible before they surprise users in production.

  • Use `SessionKey`, `SharedSignal`, or `GlobalSignal` only for state that should truly persist.
  • Commit generated routes, state artifacts, and bindings alongside code changes.
  • Run `vango state plan` before shipping schema-affecting changes.

Client Boundaries

Use the smallest boundary that fits.

Most of the app should remain server-owned. When browser-local behavior or native shells matter, Vango gives you explicit escape hatches instead of encouraging silent ownership drift.

Hooks

Attach behavior to server-owned DOM when you need drag-and-drop, focus management, or small browser-local interaction.

Islands

Hand a subtree to a client runtime only when a rich editor or external widget truly owns structure.

WASM

Use a client-local execution boundary when Go itself should run in the browser for offline or latency-sensitive work.

Multi-Surface

One codebase across web, desktop, and iPhone.

Shared app code stays under `app/` and `internal/`, while native hosts live at the edge. Vango’s launch posture is web-first, with real desktop and iOS scaffolding when product needs justify it.

Web

SSR, thin client patches, and progressive enhancement over WebSocket remain the default Vango runtime.

macOS

Shared app code with a native shell and the same server-driven runtime model for desktop products.

iPhone

A scaffoldable iOS host with native bridge capabilities, StoreKit scaffolding, and the same shared Vango app codebase.

Proof

This site is a Vango app.

The launch website uses Vango’s own file-based routing, stateful components, and a `vango-docs` section mounted through normal routes. The framework is not a brochure feature here; it is the runtime behind the site.

Route-driven docs

The docs live at `/docs` and `/docs/*path`, rendered through shared site chrome instead of a separate frontend.

Interactive marketing UI

Navigation and code tabs are normal Vango components using Setup and session-loop state.

Curated source material

The docs are reshaped from the README, Developer Guide, architecture docs, and release notes.

Start with the docs. Ship with the framework.

Use the quickstart to scaffold a real app, then move into the programming model, client boundaries, and deploy-safe persistence guides.

Read the docsOpen quickstartGitHub