apowerb/apowerb-ui repository overview

⁠apowerb-ui

The official web interface for apowerb — build an agent, give it tools and knowledge, run it, and watch what it did.

Documentation⁠ • Quickstart⁠ • API Reference⁠ • Deployment⁠ • thaink2⁠

The web interface for apowerb⁠ — build an agent, give it tools and knowledge, run it, and watch what it did.

apowerb is an agentic framework: a REST API that stores agents, builds them on Google ADK and runs them. This repository is the front end that makes it usable by someone who is not going to write curl calls — the Studio. It talks to an apowerb instance over HTTP and holds no business logic of its own.

Built with Next.js 16 (App Router), React 19 and Tailwind. Documentation: docs.apowerb.com⁠.

⁠How it fits together

flowchart LR
    U["Browser"] --> UI["apowerb-ui<br/>Next.js"]
    UI -->|"REST · NEXT_PUBLIC_API_URL"| API["apowerb<br/>FastAPI + Google ADK"]
    UI -->|"traces · PULSE_API_URL"| P["th2pulse<br/>observability"]
    API --> DB[("PostgreSQL")]
    API --> LLM["LLM providers<br/>via LiteLLM"]
    API --> RAG["th2rag<br/>retrieval"]
    API --> ORC["th2etl<br/>scheduled runs"]

The interface never reaches the database or an LLM directly. Everything goes through the apowerb API, which is what keeps this repository replaceable: a different front end against the same API is a supported thing to build.

⁠What you can do in it

Dedicated chatbot routes ship for two common cases: retrieval over your documents (/chatbot/rag) and natural-language querying of a database (/chatbot/text-to-sql).

The interface is available in English and French (next-intl, messages/), and follows the system light or dark theme.

⁠Getting started

You need Node.js 22 — the version the Docker build uses.

npm install
cp .env.example .env.local   # then edit it, see Configuration below
npm run dev

Open http://localhost:3000⁠.

⁠Just want to look around?

Set NEXT_PUBLIC_USE_MOCK_AUTH=true in .env.local and the SDK answers with a mock instead of calling a server. You get the interface with no backend at all — enough to see the screens and click through them.

For anything real, you need a running apowerb instance: this front end holds no business logic, it only calls the API. Bring one up with Installation⁠ or the Docker Compose path in the Quickstart⁠, then point NEXT_PUBLIC_API_URL at it.

⁠Configuration

The two AUTH_DISABLE_* switches only change what the interface offers. What is actually allowed is decided by the API (AUTH_BASIC_ENABLED, AUTH_REGISTER_ENABLED); set them on both sides or the interface will offer a door the server refuses.

⁠Docker

docker build -t apowerb-ui .
docker run -p 3000:3000 -e NEXT_PUBLIC_API_URL=http://host.docker.internal:8000 apowerb-ui

⁠The SDK

packages/apowerb-sdk is the typed client this interface uses to call the API — auth, agents, runs, streaming, RAG, artifacts. It is published as @apowerb/apowerb-sdk and is worth reaching for if you are writing your own front end or a Node script against an apowerb instance, rather than re-deriving the endpoints by hand.

⁠Editions, and the extension slots

apowerb is an open core. The API ships as a complete, generic server, and some capabilities — billing, usage metering, prospection, identity-provider sign-in, multi-factor authentication, agent evaluation, supervision, organisation management — are separate commercial bricks. They are absent from the open-source build, not disabled: their routes answer 404. See Editions and extensions⁠.

The administration panel itself is here: users, groups, permissions, MFA enforcement. Only the management of organisations is sold separately — deciding which tenant a person belongs to governs other people's reach, rather than serving whoever runs the install. A user's organisation is still displayed where the server reports one.

A screen that would call a brick this build does not carry is not shipped hidden, it is not shipped at all. src/__tests__/noCommercialScreens.test.js enforces that on both links and calls, deriving the forbidden symbols from the client rather than from a hand-kept list.

This interface mirrors that on the front end. src/extensions/ holds a small registry: a brick is an object with a register(registry) function, Slot.jsx marks the places in the UI where one can insert something, and installed.js lists what is installed — empty in this repository. So a screen whose capability is not in your edition simply has nothing to show, and adding a brick does not mean forking the interface.

Where the API answers 404 because a capability is not in this edition, treat it as "not in this edition", never as "broken" — the same rule as on the server side.

⁠Development

npm run dev          # dev server (Turbopack)
npm run build        # production build
npm run lint         # ESLint
npm test             # unit tests (Vitest)
npm run test:e2e     # end-to-end (Playwright)

Routes live in src/app, grouped by concern: (dashboard) for the signed-in application, (marketing) for the public pages, plus the OAuth callback routes. Shared UI is in src/components, API access in src/lib, React context in src/contexts.

⁠Screenshots

Not in the repository yet. Playwright is already configured here, which is the honest way to produce them: drive a real instance and capture the screens, so the images cannot drift from the product the way hand-picked screenshots do.

⁠License

apowerb-ui is distributed under the Apache License 2.0⁠. Copyright 2025-2026 thaink².

"apowerb" and "thaink²" are trademarks of thaink². The licence covers the code, not the marks — see TRADEMARK.md⁠.