u/Bitter_Anteater_7882

Its a OSS GitHub-style collaboration workspace that runs stateless and stores its durable data in Google Drive (Yeah I'm looking out for better alternatives to support). The idea came during the GitHub outage in 2026. The question was: how usable can repository collaboration feel when the app has no database, no long-running backend, and no private infrastructure beyond a serverless deployment and an owner Drive account.

The result is a small project workspace for publishing code snapshots, reading README pages, discussing issues, reviewing pull requests, and managing access from one web UI. It is not meant to replace GitHub or native Git hosting. Instead, it reduces some Git workflow friction for small teams and personal projects by treating repositories as portable ZIP snapshots and routing code changes through pull requests. PR review is current-state based: maintainers inspect the change against the repository as it exists now, test the downloadable merged ZIP if needed, and merge it without a separate Git-style conflict model.

CodeBase is hosted on Harbur itself: https://harbur.vercel.app/repo/rb/harbur

Projects can start from a local folder upload or a public GitHub mirror. Visitors can read README pages and download repository ZIPs without signing in; PR detail pages can build a downloadable merged ZIP for testing before merge. When a PR is merged, Harbur keeps a full pre-merge repository ZIP by copying the previous repository ZIP inside Google Drive, so maintainers can download the exact version from before that merge later. Authenticated contributors can open issues and pull requests, review compact PR diff hunks with line numbers, comment with mentions, watch activity, and merge changes.

The Drive-backed design avoids putting large mutable state in one shared file. High-activity collaboration events such as comments, reviews, issue updates, and PR changes are written as append-style records and later folded into compact indexes and thread documents. This avoids large blocking writes even without request serialization or a database. README sidecars, repository indexes, compact PR change metadata, and optional backup Drive mirrors keep the app usable while still accepting Google Drive's speed and API limits.

Teams that need their own repository publishing space without managing their own infra can host Harbur on free or low-cost serverless platforms and configure their own owner Drive. This can also be used to avoid a single point of failure with drive backups and GitHub mirrors.

Optional Google Drive support is available for todo sync and saving processed files, but the app remains fully usable offline without connecting a cloud account.

on mobile click the add to home screen from browser menu

Live: https://kitsy.rituraj.is-a.dev

GitHub: https://github.com/imxade/kitsy

Recent GitHub outages got me thinking: why not build a lightweight GitHub-like thing that can run entirely on free stateless hosting?

So I ended up building Harbur with TanStack Start and Its not unusable. The goal was not to compete with GitHub, Gitea, or Forgejo. I wanted to see how far I could push a fully stateless repo platform that anyone could host on free services without their own infra, database, object storage, Git server, long-running worker, or billing setup. Also it can maintain a mirror from github which syncs opportunistically

Right now Harbur depends only on Google Drive and Vercel hobby. It is also not tied to any VCS.

I picked Google Drive mostly because it makes self-hosting simple. There is no database or bucket to provision. The app stays stateless while Drive stores repository ZIPs and small metadata files.

The obvious approach of storing everything in shared JSON files falls apart quickly. Two people commenting, reviewing, closing issues, or updating PRs at the same time creates blocking writes and race conditions everywhere. A database would make this easier, but I wanted the whole stack to stay deployable on free stateless hosting.

So Harbur uses append-style records for high-activity thread actions. Comments, reviews, issue updates, PR events, and closes are written separately, then folded into compact repo indexes and thread documents later. It is not glamorous, but it avoids large shared rewrites and handles parallel mutations better than a single JSON file.

Reads needed similar work. Repo pages should not scan Drive folders or unzip archives just to show a README, so Harbur keeps compact repo indexes, README/assets sidecars, thread docs, and PR diff summaries beside the ZIP artifacts. It is still Google Drive underneath, not a database, but it became far more usable than I expected.

Uploads were another annoying constraint. Serverless functions are a bad fit for large ZIP uploads because of request limits and timeouts, so the browser uploads repository, PR, and merge ZIPs directly to Drive resumable upload URLs created by the backend.

There is also backup Drive support and GitHub mirroring support which syncs opportunistically. You can connect another Drive account and keep a restorable mirror of metadata, manifests, repository ZIPs, and PR ZIPs. Large artifacts are copied Drive-to-Drive where possible instead of being rebuilt through the server.

Repo hosted on Harbur itself:

https://harbur.vercel.app/repo/harbur/harbur

GitHub stars are appreciated:

https://github.com/imxade/harbur

Recent GitHub outages got me thinking, why not just build my own lightweight GitHub-like thing that can run entirely on free hosting like Vercel without even needing a billing account?

Better quality image

Google Drive’s 15GB felt more than enough for most team requirements.

So I ended up building Harbur with TanstackStart. Right now it only depends on Drive and Vercel. No database, object storage, or extra infra.

Harbur is basically a lightweight repo workspace built around snapshots. It renders READMEs on repo pages, supports issues, comments, pull requests, reviews, private repos, downloads, and Drive backups. Any authenticated user can create issues and PRs.

One thing I also wanted to address was the friction around Git itself. If you want to check an old PR or revert something, you can just download the pre-merge repo snapshot directly from the web UI.

Git is obviously powerful, but the DX can still feel inconvenient, and it’s not just me who thinks that. A lot of that comes from how it evolved over time instead of being designed around all requirements from the start. There are already better VCS ideas out there, but I wanted something even simpler that casual users could use entirely from a browser.

I picked Google Drive mostly because it’s convenient. Most people already have a Google account, storage, and ownership there. It also makes self-hosting much easier because there’s no database or bucket setup. The app itself stays stateless while Drive stores the repo ZIPs and metadata.

The hardest part was making Drive not feel terrible while still avoiding a heavy backend.

The obvious approach of storing everything in shared JSON files falls apart quickly. Two people commenting, reviewing, closing issues, or updating PRs at the same time creates blocking writes and race conditions everywhere. A database would solve this instantly, but setting one up can still be annoying for people who just want to self-host something simple without billing details.

So Harbur uses append-style records for high activity actions. Comments, reviews, issue updates, and PR events are written separately and later folded into compact indexes and thread documents. It’s not glamorous, but it avoids large blocking writes and handles concurrent actions surprisingly well.

Reads needed similar work too. Repo pages shouldn’t have to scan Drive folders or unzip archives just to show a README.

So Harbur keeps compact repo indexes, README sidecars, thread docs, and PR diff summaries to keep navigation reasonably fast. It’s still Google Drive underneath, so obviously it’s not database-speed, but it became far more usable than I expected.

Uploads were another annoying constraint. Serverless functions are terrible for large ZIP uploads because of request limits and timeouts.

So the browser uploads repo ZIPs directly to a Drive resumable upload URL generated by the backend.

The backend still handles the sensitive parts. Google tokens stay server-side while upload tickets, permissions, hashes, repo state, quotas, and PR base ZIPs are verified before anything is accepted as app state.

There’s also optional backup Drive support. You can connect another Drive account and keep a restorable mirror of metadata, manifests, repo ZIPs, and PR ZIPs. Large files are copied Drive-to-Drive where possible instead of rebuilding them through the server.

Repo hosted on Harbur itself: https://harbur.vercel.app/repo/harbur/harbur

GitHub stars are appreciated: https://github.com/imxade/harbur

This ended up being one of the harder things I’ve built even though it was AI-assisted. The architecture, security, design decisions, and tradeoffs were all on manual steering. Parallel mutations, cleanup, Drive limitations, serverless limits, security checks, and keeping writes non-blocking turned out to be much harder than expected.

This project was exhausting though. Probably not doing something like this again anytime soon.

But it also felt like solving a real problem again. The last time I remember enjoying something this much was back in 2021 when I made a Linux installer that could install multiple distros on the same partition without needing those distros’ live ISOs.