Key part is this wrapper:

Build reactive web applications in Go while giving zero fucks ™

JavaScript? Unnecessary.

Frontend-grade interactivity on a full-stack scale without npm. Entirely in Go.

API? Chill out.

Automated, private ephemeral endpoinds under the hood. No API needed.

Client-server hustle? Forget.

Single control flow in Go with automatic real-time client sync. Just works.

Stack? Solved.

Bundle scripts, host assets, serve private files, automate CSP. One binary.

Get Started

Your Go server is a UI runtime

Web application runs on a stateful server, while the browser acts as a remote renderer and input layer.

Engineered from syntax to socket

From the way you write templates to the way bytes reach the browser — each layer was designed to push server-driven UI further than it's ever gone

The right environment for AI-assisted coding

A single Go execution flow removes frontend/backend drift, while server-side execution limits exposure of data, logic, and privileged operations.

Built on better definitions

Composable primitives you can use independently or combine into abstractions you own. Modern frontend framework capabilities without sacrificing clarity.

...and explicit by design

Constantin ZboncakEldora BorerFurman BeierGolden CormierLuisa BogisichMax WindlerNaomie GrantNola LebsackOren StreichPalma BotsfordRahul MullerZakary Rau

type Search struct {
  input doors.Source[string] // reactive state
}

elem (s Search) Main() {
  <input
    (doors.AInput{
      On: func(ctx context.Context, r doors.RequestInput) bool {
        s.input.Update(ctx, r.Event().Value) // mutate state
        return false
      },
    })
    type="text"
    placeholder="search">

  ~// subscribe results to state changes
  ~(doors.Sub(s.input, s.results))
}

elem (s Search) results(input string) {
  ~(for _, user := range Users.Search(input) {
    <card>
      ~(user.Name)
    </card>
  })
}

“It feels like programming again”— 10+ years in web dev

You probably have questions

How is it different from HTMX?

HTMX coordinates behavior through HTML attributes and endpoints. Doors lets you write interactive flow directly in Go. HTMX is HTML enhancement; Doors is a UI runtime.

How is it different from React, Next.js, and similar stacks?

With JS stacks, user flow and much of the business logic live in the browser, while the server is mostly a read/write backend. Doors runs that flow on the server in Go, with the browser as a display and input layer.

Where does it fit best?

SaaS, business systems, customer portals, admin panels, internal tools, and realtime apps — especially those with heavy user flows and complex business logic.

Where is it not the right fit?

Static non-iteractive pages, client-first apps with simple routing, and offline PWAs.

Can I use JavaScript?

Yes. Doors keeps JavaScript optional, but gives you the tools to integrate it cleanly for small UI enhancements or embedded micro-apps.

Can it scale behind a load balancer?

Yes. Doors is stateful, so scaling and rollouts require different strategies than stateless apps. The server includes mechanics that make load balancing and interruption-free updates much simpler.

Does it cost more to run?

Typically not. Doors is designed to run efficiently. Actual usage depends on app complexity and state design, but active-page overhead is often under 50 KB.

Is it production-ready?

Doors is in beta. It is ready for development and can be used in production with caution, but you should expect fixes and updates as the ecosystem matures.

start building now