Glint — A Self-Hosted Photography Portfolio

Hundreds of photos dropped in → One request per photo

The admin uploader streams photos one at a time with live progress. Each request stays under Cloudflare's 100 MB body limit, a Raspberry Pi only ever processes one image at once, and a single bad file never sinks the batch.

Original camera file → Archive + 2 web variants

The original is kept byte-for-byte as the photographer's archive. sharp bakes in EXIF orientation and writes a 400px grid thumbnail and a 1600px lightbox image. Re-encoding strips every byte of metadata, including GPS.

Processed files → One portable folder

Albums, photos, likes and settings live in a single SQLite file next to the uploads. There's no database server to run, and the whole site backs up by copying one folder. Schema migrations apply automatically when the container starts.

Request for an image → Access-checked response

Every image goes through one access check: public, unlocked with the album password, or admin. Originals are admin-only, locked albums are never cached at the CDN, and changing an album's password instantly revokes old unlocks.

Mixed aspect ratios → Justified contact-sheet rows

A hand-rolled justified-layout algorithm packs photos into full-width rows at their native aspect ratios, with no crops and no third-party layout library. Opening a photo morphs it from its spot in the grid into the fullscreen lightbox.

An album link → A rich preview anywhere

Every album renders its own Open Graph card with its cover photo, so links look right in iMessage, Slack and X. A live sitemap lists only public albums, and unlisted or locked ones are kept out of search.

Secure by Default, Not by Documentation

The people who self-host a portfolio won't edit config files, so nothing ships with a default password or secret. On first start Glint generates its session secret and an admin password, saves them in the data folder, and prints the password once in the logs.

Location Privacy Built In

Camera files often carry GPS coordinates, sometimes of the photographer's home. Visitors only ever receive re-encoded copies with metadata stripped. The untouched originals stay on the server, reachable only by the admin.

One Container, One Folder

No database server, no object storage, no queue. The app, the SQLite database and the image pipeline run in one container, and all state lives in a single mounted folder. The whole setup is understandable in a single read.

Runs Safely on Any Linux Box

Docker creates a missing data folder owned by root. A tiny entrypoint fixes ownership on first start, then drops root with setpriv before the server runs, so a fresh install just works and the app never runs as root.

Multi-Arch Release Pipeline

Tagging a version triggers GitHub Actions to build the image natively on both x86 and ARM runners in parallel (no QEMU emulation), then stitch them into one multi-arch manifest on GHCR. A Raspberry Pi and a cloud VM pull the same tag and get the right binary automatically.

One Compose File, Two Ways Online

Compose profiles switch the edge without changing the app: --profile tunnel adds Cloudflare Tunnel for home hardware, and --profile caddyadds automatic HTTPS for a cloud server. Both wait for Glint's health check before taking traffic.

Safe for a Public Repo

My other homelab apps deploy through self-hosted GitHub runners. Glint deliberately doesn't: on a public repository, a pull request could run code on the home server. Instead, my Pi pulls tagged releases exactly like any other user.

Dogfooded on a Raspberry Pi

glint.dheepstack.com runs the public compose file on the Raspberry Pi in my homelab, with photos on its NVMe SSD, behind the same Cloudflare Tunnel as my other self-hosted apps. If a release breaks, I'm the first to know.

Self-host it in three commands

curl -fsSLO https://raw.githubusercontent.com/dheepak875/Glint/main/docker-compose.yml
docker compose up -d
docker compose logs glint   # your generated admin password

App

Data & media

Delivery