Why We Forked Gitea and Built Tinqs Studio

The Problem with GitHub for Game Dev

We used GitHub for two years. It was fine for docs — small files, text diffs, pull requests. But the game repo was a different story.

A single character model with textures and animations is 50–200MB. A terrain heightmap is 16MB. An island's vegetation data is another 10MB. Our game repo was 12GB in LFS alone, growing every week. GitHub's LFS bandwidth limits, slow clone times, and $5/50GB pricing made it untenable.

More importantly, nobody on the team could see what changed. A PR that modifies a GLB file shows a binary diff. You can't preview it. You can't compare before and after. The artist pushes a model, the developer approves it blindly, and three days later someone notices the normals are inverted.

Why Self-Host, and Why Gitea

We evaluated GitLab, Forgejo, Gogs, and Gitea. The decision came down to:

• Single binary. Gitea compiles to one Go binary with SQLite support. No PostgreSQL, no Redis, no Docker compose with 7 services. Just copy the binary, write an app.ini, and run it.
• Resource usage. Our instance runs on a single EC2 instance alongside other services. It uses about 200MB RAM. GitLab needs 4GB minimum.
• LFS built-in. Gitea includes a full LFS server. No external LFS store, no S3 configuration for basic use. Files are stored locally. We added S3 backend later, but it works out of the box.
• Forkable. Gitea is MIT-licensed, written in Go, with a clean codebase. We can modify it without worrying about license restrictions or CLA headaches.

We ran vanilla Gitea for six months. It solved the cost and bandwidth problems immediately. But the UX gaps for game development were still there.

What We Built: Tinqs Studio

Tinqs Studio is our fork. It tracks upstream Gitea on the main branch and keeps all customisations on a separate branch. We rebase onto upstream releases periodically, fix conflicts, and deploy.

3D Asset Preview

The headline feature. When you open a PR that contains a .glb, .gltf, or .fbx file, you see a 3D viewer directly in the browser. Rotate, zoom, check materials. No downloads, no external tools. We integrated Online 3D Viewer (O3DV), which supports 22 file formats including STL, OBJ, 3DS, and PLY.

This changes the review process fundamentally. The artist pushes a model, the lead rotates it in the browser, leaves a comment about the UV seam on the shoulder, and the artist fixes it — all without leaving the git platform.

LFS-First Workflows

Vanilla Gitea treats LFS as an afterthought. You configure .gitattributes manually. There's no dashboard showing LFS usage, no way to see which files are tracked, no warnings when someone commits a large file without LFS.

Tinqs Studio adds auto-LFS tracking on repository creation. Game file extensions (.fbx, .glb, .png, .wav, .ogg, .tscn, .tres) are tracked by default. An API endpoint exposes LFS storage stats per repo. The goal: LFS should be invisible. It should just work.

Platform Integration

Tinqs Studio integrates project management — issues, sprints, time tracking — and OAuth2 SSO. One login for git, the game tools, and the team dashboard.

The Branching Strategy

Staying close to upstream is critical. We don't want to maintain a fork that diverges forever:

• main tracks upstream go-gitea/gitea. We never commit to it directly.
• Our production branch holds all customisations.
• Feature branches merge into production.
• When upstream releases a new version, we merge, resolve conflicts, test, deploy.

We deliberately limit what we touch. We modify templates, locale strings, CSS variables, and a handful of Go packages. We never touch the database models — schema is owned by upstream, and we ride their migrations. This keeps rebasing manageable.

What We Learned

Self-hosting git is surprisingly easy. The hard part isn't running Gitea — it's convincing yourself that you're allowed to. After years of GitHub being the default, it feels transgressive to host your own git. But a single Go binary on a $10/month server handles a small team with room to spare.

LFS changes everything for game repos. Our clone times went from 45 minutes to 3 minutes. Developers only download the LFS objects they need. CI only pulls what changed. The bandwidth savings alone paid for the server.

Forking is maintenance, not rebellion. The romantic version is "we forked Gitea and built our own platform." The reality is we changed 200 lines of Go, 50 template strings, and a CSS file. 99.5% of the code is upstream's. We're just customising the last half-percent for our use case.

3D preview is a game changer. We expected it to be a nice-to-have. It turned out to be the feature that made the rest of the team actually use git. When the artist can see their work rendered in the browser, they stop asking the developer to "check if it looks right."

Tinqs Studio is built for game teams that are tired of paying GitHub for LFS bandwidth and reviewing binary diffs blind. We're building it for ourselves first — dogfooding it on our own game — but the plan is to make it available as a platform for other studios. If you're a game team that self-hosts or wants to, we'd love to hear what features you need.