# Fulling: a Next.js and Kubernetes foundation for per-user AI workspaces

> Fulling v3 is not a finished agent but an identity and Kubernetes credential boundary: GitHub sign-in through Better Auth, users and sessions in PostgreSQL, and one plaintext kubeconfig per user. The README is explicit that the earlier product model was dropped without a compatibility layer.

**FullAgent/fulling** — Fulling is an AI-powered Full-stack Engineer Agent. Built with Next.js, Claude, shadcn/ui, and PostgreSQL. Use kubernetes as infra.

- Repository: https://github.com/FullAgent/fulling
- Website: https://fulling.ai
- Stars: 2,445 · Forks: 235
- Language: TypeScript
- License: MIT
- Published: 2026-09-09 · Updated: 2026-09-09 · Language: en
- Canonical page: https://hysenlabs.com/projects/fullagent-fulling

## What Fulling v3 actually ships, and who it is for

The README opens by describing a product that does not exist yet. Fulling is "building dedicated AI workspaces: persistent environments that combine skills, files, memory, scripts, and runtime." The v3 foundation is the part that exists: identity plus a Kubernetes credential boundary. That gap is the single most important thing to understand before evaluating the repository.

The foundation consists of GitHub-only sign-in through Better Auth, PostgreSQL-backed users, provider accounts and sessions, a protected application workspace entry, one plaintext kubeconfig per user, authenticated kubeconfig validation through Kubernetes SelfSubjectReview, and a user-scoped Kubernetes client boundary. If you are building a platform where each signed-in person needs their own cluster identity, that list is a coherent starting point. If you want an agent that writes code, the README points you to docs/architecture.md for the target Workspace model and says the current user-level kubeconfig is not the final ownership model.

The audience is narrow on purpose. This is for teams that already run Kubernetes and want the identity plumbing between a web app and a cluster settled before building agent behaviour on top. The repository states it intentionally contains no compatibility layer for the previous product model or authentication system, which tells you the maintainers chose a clean break over a migration path.

## The credential boundary: plaintext kubeconfigs, validation rules and the SSRF trade-off

Kubeconfigs are stored as plaintext in PostgreSQL. The README states the consequence without softening it: database read access grants access to users' Kubernetes credentials. Browser-facing APIs never return saved content, and logs must not contain tokens, keys, certificates, or kubeconfig content. Those are policy statements, not enforcement mechanisms you can see in the README, so treat them as things your deployment has to uphold rather than properties the code guarantees.

Validation is the more interesting mechanism. The application rejects executable credential plugins, auth-provider plugins, local file credential fields, proxy configuration, non-HTTPS API servers, redirects, and anonymous identities. That is a sensible list, and it removes the most obvious ways a submitted kubeconfig could make the server execute something or follow a redirect somewhere unexpected. Then the README names the hole itself: authenticated users may still configure an HTTPS API server on any network address, and it calls this an explicit deployment decision. In other words, the validation stops code execution and redirect tricks but does not stop an authenticated user from pointing the server at an internal HTTPS endpoint. If your threat model includes signed-in users probing your network, that is a real gap and the project says so rather than pretending otherwise.

Validation runs through Kubernetes SelfSubjectReview, which means the check is performed against the cluster the kubeconfig points at. The README does not document what happens when that cluster is unreachable at validation time, so plan for that failure mode yourself.

## Installing Fulling locally and reaching the first protected page

The only stated requirement is Node.js 24, including its bundled npm 11. The README says the public application does not require PostgreSQL or an OAuth provider, so the fastest path is the unauthenticated one:

```bash
npm ci
npm run dev
```

That starts the development server with sign-in disabled. Open http://localhost:3000 and you should see the public application without any database behind it.

To exercise the authenticated workspace you need PostgreSQL and a GitHub OAuth App, plus a filled environment file. The README gives this sequence:

```bash
cp .env.template .env.local
# Fill in the database, Better Auth, and GitHub values.
npm run prisma:migrate
npm run dev
```

The migration step matters. The README states this release uses a new baseline schema and that you should run it against a new database or an explicitly reset database, because it does not migrate v2 data. Do not point prisma:migrate at an existing v2 database expecting an upgrade.

One configuration detail is easy to get wrong. The GitHub OAuth callback must be registered as:

```text
${BETTER_AUTH_URL}/api/auth/callback/github
```

If sign-in fails after everything else looks correct, that callback path is the first thing to check. The README also points to docs/github-oauth-verification.md for verifying a real OAuth application before release.

## Deploying on Vercel or in the container image

Fulling can use Vercel's native Next.js deployment without a vercel.json file. The README says the public application builds and starts without environment variables, and that the GitHub sign-in, database-backed workspace, and kubeconfig flows remain disabled until their complete legacy configuration is present. That is a useful property for previewing the shell, and a misleading one if you forget it: a green Vercel deploy does not mean the credential boundary is working.

The Dockerfile is a three-stage build on node:24.18.0-alpine. The deps stage runs npm ci --ignore-scripts, the builder stage runs npm run build, and the runner stage creates a nextjs user, installs curl and ca-certificates, and copies the standalone output plus the static and public directories. The ca-certificates install is not incidental: outbound TLS to a user's API server depends on it. The package.json start script binds to 0.0.0.0 on port 3000, matching the dev script.

For a v2 replacement there is a step the README calls out separately. Resetting the Fulling database does not delete Kubernetes resources created by v2, and before replacing a v2 deployment you are directed to docs/v2-resource-inventory.md. A database reset that leaves orphaned cluster resources behind is an easy mistake to make on a Friday afternoon.

## Where Fulling is the wrong tool

The clearest limitation is scope. There is no agent here. The README describes the v3 foundation as the identity and Kubernetes credential boundary required for the workspace product model, and points to docs/architecture.md for the target. Anyone shopping for an AI full-stack engineer agent, which is how the repository describes the project at the top level, will find a sign-in flow and a kubeconfig validator. That mismatch between the repository description and the v3 contents is worth knowing before you clone.

The second limitation is the credential storage design. Plaintext kubeconfigs in PostgreSQL mean that any read path into that database, a backup, a read replica, a debugging session, is a path to live cluster credentials. The README mitigates this at the API and logging layers, not at the storage layer. If your compliance posture requires encrypted credentials at rest in the application database, this foundation does not offer that.

The third is the explicit SSRF boundary. Rejecting proxies, redirects, non-HTTPS servers and anonymous identities still leaves any HTTPS address reachable from the server. The README labels this a deployment decision, which is honest, but it means the security of the boundary depends on where you run the process.

Finally, the v2 break is absolute. No compatibility layer exists for the previous product model or authentication system, and the schema does not migrate v2 data. If you have v2 users, this is a rebuild, not an upgrade.

## How Fulling differs from Backstage and from running your own auth

The nearest comparison is a developer portal such as Backstage. Backstage models software ownership through a catalog of entities, plugins and a metadata file per component, and its Kubernetes plugin reads cluster state for display. Fulling inverts that: the unit is a signed-in person, the artifact is that person's kubeconfig, and the server acts as a user-scoped Kubernetes client rather than a catalog reader. Backstage answers "what do we run and who owns it." This foundation answers "which cluster identity does this session act as." If you already have a catalog, Fulling is not a replacement for it.

The other comparison is rolling your own with Better Auth or NextAuth plus the Kubernetes client library. That is genuinely close to what this repository is, and the honest reason to take Fulling instead is the validation list: rejecting executable credential plugins, auth-provider plugins, local file credential fields, proxy configuration, non-HTTPS API servers, redirects, and anonymous identities is the kind of thing that is easy to get half-right. The README also flags what hand-rolling keeps: your own decision about the SSRF boundary, since Fulling deliberately leaves it open.

## Maintenance, licence and upgrade cost

The last push to the main branch was on 2026-08-17, and the repository is not archived. Version 3.0.0 is what package.json declares, while the published releases listed are v2.0.0 from 2026-05-11 and v1.0.0 from 2026-01-30. That means the v3 foundation described in the README is ahead of the tagged releases, so pinning to a release tag gets you the earlier product model, not this one.

The upgrade cost is unusually high in one direction and low in another. Moving from v2 to v3 is a rebuild: new baseline schema, no data migration, and a separate inventory step for Kubernetes resources that v2 created and a database reset will not remove. Moving between v3 patch states should be cheaper, since the foundation is small and the scripts are standard Next.js and Prisma commands.

The licence is MIT, declared in package.json and shipped as a LICENSE file at the repository root. MIT is permissive, but that is a statement about the source, not about your obligations. Storing other people's cluster credentials in plaintext is a decision with regulatory weight in some jurisdictions, and the README's own framing of the SSRF boundary as a deployment decision pushes that judgement to you. Nothing here is legal advice; if you handle credentials for other people's infrastructure, that question belongs with someone qualified to answer it.

## Conclusion

Adopt Fulling if you are building a multi-tenant agent platform where each signed-in user needs their own Kubernetes identity and you are willing to treat the database as a credential store. Do not adopt it if you need the previous v2 product model, if you expect the README to describe a working agent, or if you cannot reset the database, because the release uses a new baseline schema and does not migrate v2 data. Verify first that your deployment can accept one plaintext kubeconfig per user, that you have run through docs/v2-resource-inventory.md before replacing a v2 install, and that you have read docs/architecture.md, which describes the Workspace model this foundation is meant to support rather than the foundation itself.

## FAQ

### What is Fulling?

Fulling is an AI-powered full-stack engineer agent project whose current v3 foundation provides identity and a Kubernetes credential boundary: GitHub-only sign-in through Better Auth, PostgreSQL-backed users and sessions, and one plaintext kubeconfig per user. The README states the workspace product model itself is still described in docs/architecture.md rather than implemented in this foundation.

### What is the meaning of fulling?

In this repository the name refers to the software project Fulling, an AI-powered full-stack engineer agent built with Next.js, Claude, shadcn/ui and PostgreSQL. The README does not discuss the textile trade that shares the name.

### What is a fulling mill?

The repository does not describe a fulling mill. Fulling here is a TypeScript application with a Next.js front end, a Prisma and PostgreSQL data layer, and a Kubernetes client boundary, and the README covers only that software.

### Is it fulling or filling?

The project name is Fulling, spelled with a u, as used throughout the README, the repository name FullAgent/fulling and the package.json name fulling. The README does not discuss the word filling.

### What is the difference between fulling and felting?

The README does not cover felting or any textile process. It documents a Next.js and PostgreSQL application with a Kubernetes credential boundary, and the only comparison it draws is between the current v3 foundation and the previous product model it replaced.

## Sources

- [FullAgent/fulling on GitHub](https://github.com/FullAgent/fulling)
- [License: MIT](https://github.com/FullAgent/fulling/blob/main/LICENSE)
- [Project website](https://fulling.ai)
- [README](https://github.com/FullAgent/fulling/blob/main/README.md)
- [Releases](https://github.com/FullAgent/fulling/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/fullagent-fulling