Kitsune, a self-hosted anime frontend with a local Go proxy in the box

A Next.js front end over AniList data and PocketBase accounts

Kitsune is described as a modern, open source anime streaming web application built with Next.js, Tailwind CSS and shadcn/ui, and the promise in the README is watch your favourite anime anywhere, anytime, with no ads and no popups.

The feature list is short and specific. There is an ad-free experience with no popups, redirects or third-party ads. The app is PWA ready, so it can be installed on mobile and desktop. Discovery covers trending, popular and seasonal anime, with search suggestions and filters, and the README attributes that to AniList.

The player is the other half. It is built on ArtPlayer with custom HLS playback, an audio and subtitle selector, and auto-skip for the intro and outro. The dependency list backs the claim: artplayer with the hls-control plugin, artplayer-plugin-ambilight, and hls.js for the stream handling.

What is not the front end's job is the user data. That is PocketBase, which the README names as the source of user profiles, bookmarks and watch progress tracking, and the pocketbase client is a runtime dependency. The pocketbase package at version 0.28.1 is in the manifest, and the pocketbase.io site is linked from the feature list.

So the architecture in one line: a Next.js and React front end that talks to AniList for catalogue data, to PocketBase for anything user specific, and to video sources for the actual streams.

The Go companion exists to route streams from your own machine

The Kitsune Companion is described as a lightweight optional desktop utility that runs locally on your computer at http://127.0.0.1:43210. The README is explicit about what it does: it routes video streams directly from your personal IP address, bypassing ISP blocks, Cloudflare challenges and browser CORS limitations.

That is the entire reason the companion exists, and it is worth being clear about it, because the alternative is that the browser fetches the video itself and the request comes from your IP anyway, unless a delivery network in between decides you are not allowed. The companion moves the fetch to a process on your machine, and the web app detects automatically when it is running.

It is a Go program, and the README gives both routes. From source, with Go 1.22 or newer:

cd companion
go run .

Or as a standalone binary:

cd companion
go build -o kitsune-companion .
./kitsune-companion

Or you can take a precompiled binary for Windows, macOS or Linux from the GitHub releases page, which runs in the system tray and includes a local web UI at http://127.0.0.1:43210/ui. The two releases that are listed for the repository are companion-v2026.10.17-b8b7d8e and companion-v2026.10.17-4054f44, both from 2026-10-17, so the release tags track the companion rather than the web application.

The front end reaches the companion through the NEXT_PUBLIC_LOCAL_PROXY_URL variable, which defaults to http://127.0.0.1:43210, so the two halves find each other without configuration in the common case.

Four environment variables, one of them mandatory

The setup starts by copying the example environment file:

cp .env.example .env

The variable table in the README is short, and only one entry is required. NEXT_PUBLIC_POCKETBASE_URL is required and defaults to http://localhost:8090, which is the PocketBase instance URL. REDIS_URL is optional, with no default, and is the Redis connection string such as redis://localhost:6379. NEXT_PUBLIC_LOCAL_PROXY_URL is optional and defaults to http://127.0.0.1:43210, the URL of the local Kitsune Companion. DOMAIN_URL is optional and defaults to localhost:3000, the host domain used for OpenGraph cards.

The REDIS_URL entry is worth a second look because of what it is for. Redis is described as being for faster caching of AniList metadata and video manifests, and the .env.example file adds that if it is omitted Kitsune falls back to in-memory caching automatically. So Redis is a performance choice rather than a dependency, and the compose file treats it as an optional companion service with its own limits: the redis-server command in the compose file sets a 256mb maxmemory, an allkeys-lru eviction policy, and disables both save and appendonly, which is a cache configuration, not a durable store configuration.

The NEXT_PUBLIC_ prefix on two of the variables is worth noting, because in Next.js it means the value is inlined into the client bundle at build time. Changing NEXT_PUBLIC_POCKETBASE_URL therefore means rebuilding, not just restarting.

PocketBase is not optional, and it owns your accounts

The PocketBase setup section is four steps, and the first one is running the server:

   ./pocketbase serve --http="0.0.0.0:8090"

Then you open the Admin UI at http://localhost:8090/_/ and create your superadmin account, go in the dashboard to Settings and Import Collections, and import the schema file located at docs/pb.json. The last step is optional: under Settings and Auth Providers you can configure OAuth2 providers such as Discord if you want them.

That schema import step is what makes the app work, and it is also the part that ties the deployment together. The collections in docs/pb.json define the users, bookmarks and watch history that the Next.js app reads and writes through the PocketBase client. There is no migration path in the README for a PocketBase instance that already exists, so deploying this over an existing one means reconciling the collections by hand.

The listening address in the example command is 0.0.0.0 rather than localhost, which is what you need if the browser is on a different machine from the server, and is something to reconsider before running it on a network you do not control.

Running it with npm, Docker Compose, or a hand-built image

The local development path is four commands: clone, npm install, copy the environment file, then npm run dev, and you open http://localhost:3000.

   git clone https://github.com/dovakiin0/Kitsune.git
   cd Kitsune

   npm install

cp .env.example .env

   npm run dev

For a server deployment the README offers Docker Compose as the recommended route, which starts the app together with a Redis instance:

docker compose up -d --build

The compose file builds the kitsune image from the repository Dockerfile, names the container kitsune, sets restart to unless-stopped, publishes port 3000, points NEXT_PUBLIC_POCKETBASE_URL at http://localhost:8090 and REDIS_URL at redis://redis:6379, and declares a dependency on the redis service. Redis uses the redis:8-alpine image with a named volume for its data.

If you would rather build the image yourself, the two commands are a docker build tagged kitsune and a docker run that publishes port 3000 and passes NEXT_PUBLIC_POCKETBASE_URL pointing at host.docker.internal:8090, which is the address that lets a container reach a PocketBase running on the host.

The Dockerfile itself is a three-stage build on node:20-alpine. The deps stage installs dependencies only when needed, the builder stage copies the source and runs npm run build with NODE_ENV set to production, and the runner stage copies the .next/standalone output and the static assets, creates a non-root nextjs user, exposes port 3000 and runs node server.js. The presence of libc6-compat and git in the deps stage is a hint about the native modules in the dependency tree.

MIT licensed, no releases, and a stack that is still moving

The licence is MIT, and the manifest confirms it with a license field of MIT and a private flag of true, which is normal for an application rather than a published package.

The stack is worth reading as a snapshot of a modern Next.js application. Next is at 16.4.2 with React at 19.3.1, the UI is shadcn/ui on top of a long list of Radix primitives with Tailwind CSS 4, data fetching is TanStack Query, and client state is zustand. There is framer-motion for animation, next-themes for theming, sonner for toasts, lucide-react for icons, and embla-carousel-react for carousels. The package version is 0.1.0.

That stack tells you the project is being kept current, which is consistent with the activity record: the last push to master was on 2026-10-19, and the release tags are dated 2026-10-17. What it does not have is a release of its own, since the repository publishes no GitHub releases for the web application, only the companion binaries.

The contribution process is the conventional one, fork, feature branch, commit, push, pull request, and the community channel is a Discord server. There is a SECURITY.md in the repository root, which is the file to read if you find a vulnerability, and given that the app proxies third-party video streams, that is a document worth reading before you expose it.

Editorial conclusion

Adopt Kitsune if you want to run your own anime front end and already have a PocketBase instance, or are willing to run one, since the accounts, bookmarks and watch progress all live there and nothing works without it. Do not adopt it expecting a finished single-binary deployment, because the frontend needs Node and a PocketBase server, and the companion is Go 1.22 or newer if you build it from source. Before you deploy, read the environment variable table, since NEXT_PUBLIC_POCKETBASE_URL is the one required setting and it is compiled into the client, decide whether the optional Redis cache is worth running, and note that the repository publishes no GitHub releases, with the two listed tags belonging to the companion rather than the web app.

Frequently asked questions

Official sources

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