Personal / Research · 2025
GSP
Gaussian Splatting rendering platform
Self hosted platform where you upload photos of a scene and it orchestrates rented GPU jobs to return a Gaussian Splatting render, with history per organization.
Technologies: Next.jsNode.jsPostgreSQLDrizzle ORMCloudflare R2Better-Auth
Overview
GSP is a multi tenant platform for 3D Gaussian Splatting: you upload a set of photos of a scene and get back a rendered splat. Gaussian Splatting reconstructs photorealistic 3D scenes from 2D images by representing them as millions of semi transparent ellipsoids instead of meshes, and it renders in real time.
I built it to understand the technology from the infrastructure side rather than from a paper.
The problem
Running a splatting render is not the hard part: it is a command over a folder of images. The hard part is everything around it. It needs a GPU, and a GPU sitting idle costs money all day. The job takes long enough that no HTTP request can wait for it. It fails often, for reasons ranging from bad input photos to a machine disappearing. And the output is heavy, so it cannot live next to the app.
Without that scaffolding, experimenting with the technique means babysitting a terminal.
Decisions
- Rent GPU compute per job instead of keeping a machine up: compute is provisioned when a job starts and released when it ends, so idle time is not paid for.
- A queue with a background worker rather than a synchronous request: uploading and rendering are separate, the user gets a job with a state (pending, running, failed, success) and can close the tab.
- Automatic retries with exponential backoff: failures here are mostly transient, so the retry is part of the pipeline instead of a manual relaunch.
- Cloudflare R2 for both inputs and outputs: uploads go straight to object storage, renders come back to it, and the app server never becomes the file server.
- Multi tenant with Better-Auth and organizations that invite members: renders belong to a team, with its own history and usage, which is also what makes usage based billing possible.
- Drizzle ORM with PostgreSQL for job and user state: the state machine of a job is the most queried thing in the system, so it stays relational and typed.
- Next.js with shadcn/ui for the admin surface: the interesting work is the pipeline, so the UI reuses components instead of inventing them.
Admin interface
Result
GSP runs the full cycle end to end: photos in, a queued job, GPU compute rented on demand, retries when something fails, and a finished render stored in R2 under the organization that asked for it.
It showed me that the interesting engineering in a GPU heavy product is rarely the algorithm: it is the queue, the retries, the storage and the tenancy around it. That is the part that turned an experiment I ran by hand into something anyone with an account can run.