Fulling v3: A Kubernetes credential boundary wrapped in a Next.js AI workspace shell

What Fulling actually is right now

The repository describes Fulling as building dedicated AI workspaces: persistent environments that combine skills, files, memory, scripts, and runtime. But the v3 foundation, which is the current default branch, does not contain that workspace yet. What exists is the identity and Kubernetes credential boundary required for that product model. That means GitHub-only sign-in through Better Auth, PostgreSQL-backed users and sessions, a protected application workspace entry, and one plaintext kubeconfig per user. The README is explicit that there is no compatibility layer for the previous product model. If you clone this expecting an agent that writes code, you will be disappointed. If you want a reference implementation for scoping Kubernetes credentials to a web user, this is a focused starting point.

The credential boundary mechanism

The core technical idea is that each authenticated user gets exactly one kubeconfig, stored as plaintext in PostgreSQL. Validation happens through Kubernetes SelfSubjectReview, which checks that the credential is real and tells you who it belongs to. The validation rejects executable credential plugins, auth-provider plugins, local file credential fields, proxy configuration, non-HTTPS API servers, redirects, and anonymous identities. That is a strong allowlist. But the README also states that authenticated users may configure an HTTPS API server on any network address. That means a user can point their kubeconfig at an internal service that speaks HTTPS, and the server will make authenticated requests to it. The README calls this an explicit deployment decision. For a security reviewer, that is the single most important line in the project.

Getting it running: two modes

There are two development paths. The public application runs with no environment variables and no database. Run npm ci and npm run dev, and you get sign-in disabled on localhost:3000. To exercise the authenticated workspace, copy .env.template to .env.local and fill in database, Better Auth, and GitHub values. Then run npm run prisma:migrate and npm run dev. The GitHub OAuth callback must be configured as ${BETTER_AUTH_URL}/api/auth/callback/github. Node.js 24 with bundled npm 11 is required. The build command runs Prisma client generation first, so npm run build should work from a clean checkout. Tests are split: npm test runs Vitest, npm run test:e2e runs Playwright.

The v2 reset trap

This release uses a new baseline schema. The README warns to run it against a new database or an explicitly reset database because it does not migrate v2 data. That is a hard break. If you have a v2 deployment, you must follow docs/v2-resource-inventory.md before replacing it, because resetting the Fulling database does not delete Kubernetes resources created by v2. That is a real operational hazard: your database can be wiped while Kubernetes workloads continue running and billing you. Anyone evaluating Fulling for production needs to read that inventory document first. The project also keeps docs/github-oauth-verification.md to verify a real OAuth application before release, which suggests the maintainers know OAuth misconfiguration is a common failure point.

Deployment choices and constraints

Fulling can deploy on Vercel without a vercel.json file, and the public application builds and starts without environment variables. However, the GitHub sign-in, database workspace, and kubeconfig flows remain disabled until the complete legacy configuration is present. The README points to docs/vercel-deployment.md for setup, verification, and rollback. Kubernetes is listed as infrastructure, but the current foundation only uses it for SelfSubjectReview validation. There is no mention of running Fulling itself on Kubernetes. The architecture doc is referenced for the target Workspace model, and the user-level kubeconfig is explicitly not the final Workspace Runtime ownership model. So the deployment story today is: Vercel for the app, Kubernetes only as the thing you validate credentials against.

Limitations and wrong-tool cases

The plaintext kubeconfig storage is the most obvious limitation. Database read access grants access to users' Kubernetes credentials. The README tries to mitigate by saying browser-facing APIs never return saved content and logs must not contain tokens or keys. That is a policy, not a technical control. If your database is compromised, the kubeconfigs are exposed. The SSRF boundary is another limitation: any authenticated user can point at an HTTPS server on any network address. That is acceptable for a single-tenant internal tool, but for a public multi-tenant service it is a liability. Fulling is also the wrong tool if you need a working AI agent now. The v2 to v3 migration path is nonexistent by design. If you have v2 data, you must start over. That is a deliberate reset, and it makes Fulling unsuitable for anyone with an existing deployment who cannot afford downtime.

Alternatives and how they differ

The closest alternative in approach is to build the same boundary yourself using Better Auth and the Kubernetes client-go libraries directly. Fulling is essentially that, but packaged. The difference is that Fulling already made the policy decisions: one kubeconfig per user, plaintext storage, SelfSubjectReview validation, and rejection of plugin-based credentials. Rolling your own would give you control over storage encryption and network policies, but you would have to write and test the validation logic yourself. Another alternative is to use a dedicated secrets manager like Vault or Kubernetes itself with short-lived credentials, which avoids plaintext storage entirely. That is a fundamentally different architecture: Fulling stores a long-lived credential, while Vault issues short-lived ones. If you need to minimize the blast radius of a database leak, the Vault model is stronger, but it requires more moving parts.

Licence and maintenance signals

Fulling is MIT licensed, which means you can fork it, modify it, and use it commercially without copyleft obligations. The repository is not archived, and the last push was 2026-08-17. There are two releases: v1.0.0 from January 2026 and v2.0.0 from May 2026. The README describes the current state as v3 foundation, but the latest release tag is v2.0.0, which suggests the repository default branch is ahead of the last tagged release. That is a signal to be careful: if you install from the default branch, you are on an untagged snapshot. The maintenance cost is moderate. The project has a clear command set for Prisma migrations and validation, but the schema reset policy means every major version may require a database reset. You should verify whether the maintainers tag releases for the v3 line before depending on this.

Editorial conclusion

Adopt Fulling v3 if you are building a multi-tenant AI workspace and want a tested identity and Kubernetes credential boundary as a starting point, and you accept plaintext kubeconfig storage plus an explicit SSRF exposure. Do not adopt it if you expect a working AI coding agent today, or if you need to migrate from v2 without a full reset. Before deploying, verify the GitHub OAuth callback URL matches your BETTER_AUTH_URL, read docs/v2-resource-inventory.md if you have a v2 deployment, and confirm your database is new or explicitly reset because the baseline schema does not migrate v2 data.

Official sources

1. FullAgent/fulling on GitHub
2. License: MIT
3. Project website
4. README
5. Releases