flyemoji
c4c964578e
setup_required is what the SPA polls to decide whether the onboarding wall is still owed, and it disagreed with the middleware that actually enforces the wall. requireOnboarded lifts on a verified email OR an enrolled passkey; setup_required answered `u.Email == "" || !hasPasskey`. A console-tier player joins through the bind-code door with no email at all — by design, there is no SMTP at that point — so the email term never clears and the SPA keeps them on the setup screen forever, even after they enroll the passkey that already unlocked the API for them. The predicate now lives in one place (setupRequired) and both endpoints call it, so the next edit to the unlock condition cannot drift them apart again. Keying it on EmailVerified rather than email presence is the deliberate part: presence is exactly the term that trapped the no-email player, and it was also wrong on its own terms — an unverified address is not an authentication factor, so it was never what the lockdown could safely lift on. Also lands the regression test for the mechanism behind the live claim-403 report: /me/servers answers 200 for a bind-onboarded player (which is why the dashboard renders the 认领 button at all) while claim, wake and status all answer 403 with code "setup_required" — i.e. the refusal comes from requireOnboarded before the handler, not from isOwnerOrAdmin inside it, which would have said "forbidden". Enrolling a passkey and changing nothing else lifts all three, which isolates the gate as the sole cause. The backend authz is correct; the button that leads a locked-down player into a 403 is the frontend's to hide.
Felis
A Kubernetes-driven Minecraft server hosting platform — one command to deploy, automatic lifecycle, backup, and security.
一款 Kubernetes 驱动的 Minecraft 服务器托管平台，一行命令部署，自动管理生命周期与安全。
Table of Contents
Features
- Wake on Join: Servers start automatically when a player connects, and stop when idle — like hibernate for your server.
- Web Dashboard: Monitor server status, online players, and resource usage from your browser, with backup and restore management.
- Auto Backup & Restore: Scheduled world backups with one-click rollback from any backup point.
- World Reaper: Worlds idle for more than 15 days are automatically backed up and removed to free disk space.
- Multi-core Support: Compatible with Paper, Fabric, Forge, and NeoForge, federated behind a Velocity proxy.
- Modpack Submission: Players submit custom modpacks; admin approval triggers automatic build and deployment.
- Passkey Login: Passwordless authentication via fingerprint, face recognition, or hardware security keys.
- Zero Trust Security: Panel traffic protected by Cloudflare Access; the internal API is never exposed to the internet.
Getting Started
On a prepared Linux host, run:
curl -fsSL https://raw.githubusercontent.com/MliroLirrorsIngenuity/Felis/main/deploy/bootstrap.sh | sudo bash
The script installs K3s, deploys the control plane, and launches a setup wizard. Once done, open your browser at the configured domain.
Build from Source
Felis is built with Go and Node.js:
# Backend (Go 1.26+)
go build -o felis ./cmd/felis
# Frontend (Node.js 22+)
cd panel
npm ci
npm run build
# Docker image
docker build -t felis:custom .
License
The source code is released under the MIT License.
License Notes
- Attribution: Any distribution of this project or derivative works must include the original copyright notice and license statement.
- Disclaimer: This project is provided "as is", without warranty of any kind.
Acknowledgements
- Kubernetes: Container orchestration engine
- K3s: Lightweight Kubernetes distribution
- Cloudflare Zero Trust: Zero trust security infrastructure
- PostgreSQL: Data persistence
- React: User interface framework
- Vite: Frontend build tool
- TailwindCSS: CSS framework
- Bubble Tea: TUI framework
- Minecraft: What makes this all worthwhile