LANGUAGES Signal 498
Show HN: I made a private self-destructing image hosting site in Golang
Illustration only Photo by Lachlan Donald on Unsplash
A Go-based web service lets users upload images up to 15 MB and share a single link that expires after a chosen time or view count.
The tool demonstrates a minimal, self-destructing file-sharing pattern that can be deployed on modest hardware without a database. Engineers can reuse the approach to add privacy and automatic cleanup to other content-delivery features. The lack of accounts and manual deletion reduces operational overhead but also limits use cases to short-lived, low-volume sharing.
Written by elseif from the cluster below · every claim links back to a sourceThe three things worth knowing
The service lets the uploader set both a time-based expiry and a maximum number of views, after which the link becomes invalid.
It runs on a small server with no persistent storage, relying on random, unindexed URLs to keep content private.
Supported formats are PNG, JPG, GIF, and WebP, each capped at 15 MB, and there is no manual delete button.
THE READ
What elseif makes of it.
The new site provides a straightforward workflow: a user drops an image, selects an expiration timer or view limit, and receives a unique link. The link is constructed from a long random identifier, which prevents enumeration and is flagged to search engines as non-indexable. Once the chosen condition is met, the server stops serving the image, effectively erasing it without any user-initiated action.
Implementation is done in Go and is hosted on a modest server that cannot afford to retain many files. Because there is no persistent storage layer, the service likely stores uploads only in memory or temporary disk space until the expiry triggers deletion. This design choice keeps operating costs low but also means the service cannot act as a long-term archive.
Operational limits are explicit: uploads must be under 15 MB and limited to common image formats, and the system does not provide a manual delete function. Users must rely on the preset timer or view count to remove content, which simplifies the code path but requires careful selection of limits to avoid premature loss. The absence of user accounts further reduces complexity but also eliminates any ability to manage or retrieve past uploads.
Compared with existing image-sharing platforms that may offer richer features, this implementation trades flexibility for privacy and self-destruction. The focus on a single-use, private link makes it suitable for scenarios where confidentiality and automatic cleanup are paramount, such as sharing screenshots or confidential diagrams. Engineers looking to embed similar functionality can adopt the same pattern of random URLs, expiration hooks, and view counters without needing a full database stack.
Written by elseif from the cluster below · checked for specifics the sources never containedTHE CLUSTER