ShotShare

Open-source image sharing, honestly reviewed. No marketing copy, just what you get when you deploy it yourself.

TL;DR

• What it is: MIT-licensed, self-hosted image sharing platform — think Imgur stripped of ads, social features, and surveillance, running on your own server [1].
• Who it’s for: Small teams, friend groups, developers, and homelabbers who need a fast way to upload screenshots and share direct links without a third-party service seeing everything [1][3].
• Cost savings: Imgur’s free tier still works for basic use, but the platform has steadily pushed users toward accounts, compression, and ad revenue. ShotShare runs on any $5–10 VPS with SQLite for zero ongoing cost [1][README].
• Key strength: Genuinely bare-bones in the right way — upload, get a link, done. Drag-and-drop, paste, or browse. Caddy handles automatic HTTPS. The whole thing deploys in a single Docker command [README][3].
• Key weakness: 178 GitHub stars. This is a small, solo-maintainer project. No user forums, no commercial backing, last meaningful activity in 2024. If the maintainer loses interest, you own the PHP [4][README].

---

What is ShotShare

ShotShare is a self-hosted image posting platform. You upload an image, you get a link. The creator’s pitch on Reddit is the most honest description of it: “ShotShare is a FOSS alternative to platforms like Imgur. Many of these platforms have moved towards a more ‘social-media’ feel and incorporated a ton of ads. The idea with this app is it should allow users to quickly share images and not much else.” [1]

That’s the entire scope. There is no feed, no follower model, no discovery, no social graph. There’s an upload screen, a profile page showing your posted shots, and direct links. The creator explicitly built it for sharing screenshots between friends — the project ships a .sxcu file (ShareX custom uploader config) so that screenshots taken with ShareX on Windows auto-upload directly to your instance [README].

Technically, ShotShare is a Laravel (PHP) application. It ships with SQLite by default, supports MySQL, PostgreSQL, and MSSQL, and uses Caddy as the built-in webserver — which means automatic SSL certificate provisioning out of the box for domains pointed at the server [README]. The frontend is built with Tailwind and Vite. It has 22 releases on GitHub, a CI badge, and a code coverage badge, which signals more engineering discipline than you’d expect from a 178-star project [README].

The project is developed by Micah Shackelford (mdshack) and is MIT-licensed with 13 forks and 188 commits as of this review [4][README].

---

Why people choose it

The Reddit announcement thread [1] is the most useful signal for what the actual use case looks like. The creator describes the target user as someone who wants to paste or drag-drop a screenshot, copy the resulting link in one click, and send it. The motivating frustration is the same one that drives most Imgur exits: the platform has become a social network, images get compressed, and the free experience is increasingly hostile.

The bentasker.co.uk deployment post [3] gives a different but complementary view. The author found ShotShare via a curated list of self-hosted apps and zeroed in on the screenshot-sharing use case specifically: “The screenshot use-case, in particular, is something that I’ve been meaning to sort out (currently I tend to put them into my file-drop, which is a bit clunky for all involved).” [3] This captures the typical ShotShare user accurately — someone with homelab infrastructure who already has Docker running somewhere and wants a dedicated, link-friendly screenshot host rather than abusing a general-purpose file drop.

The AlternativeTo listing [4] tags ShotShare as an alternative to Imgur, Flickr, and Pixeldrain. Users have also added it as an alternative to tools like Swush, Cubby.moe, and ImageFast — which suggests the community using it skews toward developers and privacy-focused homelabbers rather than photographers or marketing teams.

What ShotShare does not do — and this matters — is compete with Nextcloud Photos, Photoprism, Piwigo, or any tool in the photo management category [5]. Those tools organize, tag, and manage libraries. ShotShare is purely a sharing primitive: upload → link → done. If you want a photo library, look elsewhere. If you want a fast way to get images onto the web without ads, this is a credible option.

---

Features

Based on the README and the deployment posts:

Core upload experience:

• Drag-and-drop upload [README][1]
• Paste directly from clipboard (paste an image, get a link) [README][1]
• Browse-and-select file upload [1]
• One-click copy for direct image link and ShotShare page link [1]
• Image reactions — upvote/downvote per shot, toggleable via FEATURE_REACTIONS=true/false [README]

Sharing and routing:

• UUID-based routes (FEATURE_UUID_ROUTES=true) — generates non-sequential, non-guessable IDs for images instead of numeric IDs; becomes the default in 2.0.0 [README]
• Profile page listing all your uploaded shots [1]
• Direct image links (not just page links) for embedding in chat apps, Discord, etc.

Database and storage:

• SQLite by default (zero-config, single file, works fine for personal/small-team use)
• MySQL, PostgreSQL, MSSQL supported for higher-scale deployments [README]
• Images stored on the local filesystem (Docker volume)

Deployment:

• Built-in Caddy webserver with automatic HTTPS for HTTPS mode [README]
• HTTP mode for running behind your own reverse proxy [README]
• FORCE_HTTPS=true env var for proxy setups that terminate SSL before reaching the app [README]
• ALLOW_REGISTRATION=false to lock down who can create accounts [README][3]
• Docker volume for image storage, bind mount for SQLite file and .env [README]
• ShareX .sxcu uploader config file ships in the repo [README]

Feature flags (environment variables):

• ALLOW_REGISTRATION — open or closed instance
• FEATURE_REACTIONS — toggles upvote/downvote on images
• FEATURE_UUID_ROUTES — sequential IDs vs UUIDs
• FEATURE_FOOTER — the “Made with love / check out the source code” footer (leaving it on helps the project)
• PHP_MEMORY_LIMIT — default 128M, tune for large image uploads [README]

What it doesn’t have:

• No album or gallery grouping
• No public feed or discovery
• No tags or search
• No video support
• No expiring links (short-lived uploads)
• No S3 or object storage backend (local filesystem only)

---

Pricing: SaaS vs self-hosted math

ShotShare has no SaaS tier — it’s a pure open-source project with no commercial offering [README][4]. The cost conversation is entirely about what you’d be paying elsewhere.

Imgur comparison: Imgur’s free tier still exists but requires an account for uploads and has pushed users through multiple rounds of policy changes. Their Pro plan runs around $3.99/month. More importantly, every image you upload to Imgur sits on Imgur’s servers, associated with your account, subject to their content policies, and served wrapped in their ads [1]. For a founder sharing product screenshots, internal tool screenshots, or client-facing images, that’s a meaningful privacy leak even if the monetary cost is low.

Self-hosted ShotShare:

• Software: $0 (MIT license) [README]
• VPS: $5–10/month on Hetzner, Contabo, or DigitalOcean (a 1GB RAM instance handles it fine for personal/small-team use)
• Domain: optional, already paying for it if you’re self-hosting anything else
• Your time: under 30 minutes if you’ve done Docker deployments before

For a homelab user already running a server, the marginal cost of adding ShotShare is effectively zero — it’s another Docker container on hardware you’re already running.

The realistic comparison is not dollar savings (Imgur is cheap or free) but control and zero ads. You own the data, the links stay live as long as your server does, and there are no compression decisions made by a third party.

---

Deployment reality check

The bentasker.co.uk post [3] is the most honest account of what deployment actually looks like, and notably it’s written by someone who went further than Docker — they deployed into Kubernetes. The summary: Docker mode is clean and well-documented; Kubernetes required “a bit of trial and error (and a lot of fiddling around)” [3].

Docker deployment (the straightforward path):

# 1. Create a directory
sudo mkdir /shotshare

# 2. Create persistent files
sudo touch /shotshare/.env /shotshare/database.sqlite

# 3. Set permissions (container runs as www-data, uid/gid 82)
sudo chown 82:82 /shotshare/.env /shotshare/database.sqlite

# 4. Start with HTTPS (Caddy auto-provisions SSL)
docker run \
  -p 80:80 \
  -p 443:443 \
  -e HOST=your.domain.com \
  -e FEATURE_UUID_ROUTES=true \
  -v shotshare_data:/app/storage/app/uploads \
  --mount type=bind,source=/shotshare/database.sqlite,target=/app/database/database.sqlite \
  --mount type=bind,source=/shotshare/.env,target=/app/.env \
  --restart unless-stopped \
  -d \
  mdshack/shotshare:latest

That’s the whole thing. The README is accurate here [README][1].

What the bentasker Kubernetes deployment surfaced [3]:

• You need to set fsGroup: 82 in the pod security context — the mounts must be owned by the www-data uid or the app won’t start
• The three required mounts (database, uploads, .env) can share a single NFS volume if you want to avoid three separate persistent volumes
• Resource requests that worked: 250m CPU, 750Mi memory — described as “arbitrary and plucked out of the air” but functional for a low-traffic instance

What can go sideways:

• The .env file must be a bind mount (a specific file, not a directory), and the permissions must be correct before first launch. Getting the chown 82:82 step wrong means the container starts but can’t write to the database or upload directory.
• UUID routes are strongly recommended (FEATURE_UUID_ROUTES=true) — sequential IDs mean anyone can guess adjacent image IDs and enumerate your uploads. Enable UUID routes, especially if ALLOW_REGISTRATION=true.
• SQLite is fine for personal use. If you’re running a multi-user instance with concurrent writes, switch to PostgreSQL or MySQL early — migrating later is doable but not fun.
• The project’s last commit activity is 2024 [4]. This is a mature-but-not-actively-developed codebase. PHP Laravel under the hood means it’ll keep running, but don’t expect feature additions.

Realistic time estimates:

• Technical user familiar with Docker: 15–30 minutes to a working instance.
• Homelab person who has run Docker Compose but not bare docker run: 30–60 minutes including troubleshooting the permission step.
• Non-technical founder who has never touched a Linux server: this isn’t the right starting point. Find someone to deploy it, or use Imgur and accept the trade-offs.

---

Pros and Cons

Pros

• MIT-licensed, zero cost to run. No commercial tiers, no “open-core” restrictions, no enterprise gates. The whole thing is MIT [README][4].
• Genuinely minimal. It does what it says. Upload image, get link, done. No feature bloat, no social feed you didn’t ask for.
• Built-in Caddy = automatic HTTPS. Most self-hosted tools require you to set up a reverse proxy yourself. ShotShare handles SSL certificate provisioning internally if you point a domain at it [README].
• SQLite default. Zero database setup for personal use. Just a file. Works.
• ShareX integration out of the box. The .sxcu file means Windows users can configure ShotShare as their default screenshot upload destination with two clicks [README].
• UUID routing protects image privacy. Sequential IDs would let anyone enumerate uploads. UUID mode makes image links non-guessable [README][3].
• Registration lockdown. ALLOW_REGISTRATION=false turns it into a private instance immediately [README][3].
• Caddy or bring-your-own-proxy. HTTPS mode for standalone, HTTP mode for running behind nginx or Traefik [README].

Cons

• 178 GitHub stars, solo maintainer. This is a small project. The last significant commit was 2024 [4]. It works, but you’re betting on a one-person FOSS effort that could go dormant.
• No active community. One Reddit thread from 2 years ago, one Kubernetes blog post, one AlternativeTo listing [1][3][4]. If you hit a bug, you’re reading PHP source code.
• No expiring links. If you need images that self-destruct after N hours, ShotShare has no native support for it.
• No external storage backend. Images live on the Docker volume’s local filesystem. No S3, no Backblaze B2, no object storage. Backups are your responsibility and require direct filesystem access.
• No album/gallery organization. Everything is a flat list of uploads. No folders, no tagging, no search.
• No video. Images only. If your screenshot tool captures video clips, you need something else.
• Permission setup is a gotcha. The chown 82:82 step trips up first-time deployers. The README covers it, but it’s the most common setup failure point [3].
• Reactions feature is underwhelming. Upvote/downvote on screenshots between friends is a strange feature for a tool this minimal. Most people will disable it.

---

Who should use this / who shouldn’t

Use ShotShare if:

• You’re a developer or homelab operator who shares screenshots frequently and is tired of Imgur’s ads or account requirements.
• You already have a server or VPS running Docker and want to add a lightweight screenshot host with essentially zero overhead.
• You use ShareX on Windows and want to auto-upload to your own server instead of a third-party service.
• You’re running a small team (developers, designers, support) that shares internal screenshots and you don’t want those images sitting on Imgur or Slack’s CDN.
• You need a private instance — ALLOW_REGISTRATION=false and nobody else touches your images.

Skip it (use Imgur or Pixeldrain) if:

• You’re not comfortable with Docker and basic Linux permissions. The permission setup step alone will block non-technical users [3].
• You need images to expire after a set time. ShotShare has no TTL feature.
• You need to share video clips, not just images.
• You need album organization, tags, or search across your uploads.

Skip it (use Nextcloud, Immich, or Photoprism) if:

• You’re managing a photo library, not just sharing individual screenshots. ShotShare is not a photo manager [5].
• You need mobile apps for browsing and backing up your camera roll.

Skip it (use Zipline or Chibisafe) if:

• You need S3-compatible external storage, file expiry, multi-upload types (not just images), or a more actively maintained project with a larger community.

---

Alternatives worth considering

Based on the AlternativeTo listing [4] and the broader self-hosted image-sharing space:

• Imgur — the obvious comparison. Still works, still free for basic use, but requires an account, serves ads, and you’re handing images to a third party. If the ads don’t bother you and the privacy angle doesn’t matter, Imgur is simpler.
• Slink — a newer, more feature-rich self-hosted image sharing platform with optional compression settings, guest upload controls, user approval flows, and EXIF stripping. More configurable than ShotShare but also more complex. Described as feeling “like a commercial product” — better choice if you want more control and don’t mind a slightly heavier setup [2].
• Zipline — similar category, S3 backend support, file expiry, and more active development. Better choice if you need more than just image links.
• Chibisafe — supports multiple file types, albums, S3 storage, and has a more active community. Heavier than ShotShare but more fully featured.
• Pixeldrain — hosted service, not self-hosted. Direct file links, no account required for basic uploads. Zero setup, but you’re trusting their servers.
• ShareX image hosting — ShareX the client tool can upload to dozens of services. If you’re already using ShareX, you can connect it to any of the above, not just ShotShare.
• Nextcloud — if you need photo management with mobile sync, sharing, and library organization, Nextcloud’s Files + Photos apps cover the use case ShotShare explicitly doesn’t [5]. Heavier infrastructure requirement.

The realistic shortlist for a homelab user replacing Imgur is ShotShare vs Slink vs Zipline. ShotShare if you want the absolute minimum footprint and don’t need S3 or expiry. Slink if you want a slightly richer experience with more configuration options. Zipline if you need expiring links or external storage.

---

Bottom line

ShotShare is exactly what it says: a bare-bones, MIT-licensed, self-hosted screenshot sharing platform built by one developer who wanted Imgur without the ads. It works, it deploys in a single Docker command, and it handles automatic HTTPS via Caddy. The trade-offs are clear and upfront: no album organization, no external storage, no video, no expiring links, and a small solo-maintained codebase that saw its last major activity in 2024.

For a developer or homelab operator who shares screenshots daily and wants to stop feeding those images to Imgur, ShotShare is a 20-minute deployment that solves the problem cleanly. For anyone who needs more — libraries, mobile apps, video, or S3 storage — look at Slink, Zipline, or Immich depending on what you actually need. And for anyone who isn’t comfortable on the command line, the deployment friction is real enough that Imgur’s free tier with an account may genuinely be the better call.

If you want to deploy it and not think about it again, that’s exactly what upready.dev does for clients — one-time setup, you own it.

---

Sources

1. Reddit r/selfhosted — “ShotShare - Self-hosted image-sharing app (FOSS alternative to Imgur)” (Posted by TwoBoolean/mdshack, 2023). https://www.reddit.com/r/selfhosted/comments/18taat0/shotshare_selfhosted_imagesharing_app_foss/
2. Dhruv Bhutani, XDA Developers — “I swapped IMGUR for this self-hosted app, here’s how it went” (Jul 25, 2025). https://www.xda-developers.com/i-swapped-imgur-for-this-self-hosted-app-heres-how-it-went/
3. Ben Tasker — “Deploying ShotShare into Kubernetes”. https://www.bentasker.co.uk/posts/blog/general/deploying-shotshare-into-kubernetes.html
4. AlternativeTo — ShotsShare listing. https://alternativeto.net/software/shotsshare/about/
5. Unix & Linux Stack Exchange — “Self-Hosted Photo Sharing Tool for Debian” (2023). https://unix.stackexchange.com/questions/739625/self-hosted-photo-sharing-tool-for-debian

Primary sources:

• GitHub repository and README: https://github.com/mdshack/shotshare (178 stars, MIT license)
• Live demo: https://demo.shotshare.dev/