The following is a guest post written by Andrii Kryvoviaz, the developer and maintainer of Slink. Reach out via e-mail if you’d like to contribute content for your project.

When working on multiple projects, you need somewhere to host images. Screenshots, mockups, user photos — they all need a home. The obvious solutions are third-party services, but as someone who values control over their data and infrastructure, I wanted something I could run myself. That is how I came up with an idea of building Slink — a self-hosted image-sharing solution.

The existing options presented their own challenges. Some were complex gallery or cloud backup solutions designed for different use cases entirely. Others were simple upload-and-share services that had lost development momentum or lacked essential features. What I needed was something that could be deployed quickly but still handle real-world usage scenarios.

Architecture Decisions and Trade-offs

The core architectural decision was to package everything into a single container. This meant bundling the web server, database, and image processing into one deployable unit. While this approach has obvious trade-offs in terms of scalability and service separation, it dramatically reduces deployment complexity — something highly valued in the self-hosted community.

Unlike gallery management systems or cloud backup solutions, Slink focuses purely on the upload-and-share model (similar to Imgur.) The single container works well for both individual use and small communities, with support for different storage options (local filesystem, SMB network storage, Amazon S3) depending on infrastructure preferences.

This design choice required careful resource management and process coordination within a single container, but the architecture remains modular enough to support future requirements when needed.

What started as a basic upload-and-share system evolved significantly as real users encountered actual usage patterns. The initial version handled single image uploads with simple link sharing. However, once it began gaining traction on r/selfhosted and similar communities, new requirements rapidly emerged. The project’s direction became increasingly community-driven. I prioritize features based on how frequently they’re mentioned on Reddit and in GitHub issues — the more something appears in discussions, the higher it moves on the roadmap. This approach led to implementing some of the most impactful recent additions.

ShareX integration was one of the earliest and most frequently requested features. Power users wanted programmatic access through API keys, which also opened the door for automation and third-party tool integration. URL shortening came next, addressing a common use case for quick sharing. The nested tag system emerged from users managing hundreds of images who needed better organizational capabilities beyond simple flat tags.

The September 2025 surge in interest — partly driven by regulatory restrictions affecting major platforms - brought an influx of new users with different expectations. Communities weren’t just looking to host images; they wanted ways to discover and interact with shared content. This led to implementing bookmarks for saving favorites, threaded comments for discussions, and real-time notifications — features that added a lightweight social layer without compromising the core simplicity.

PWA support addressed mobile users who wanted app-like experiences without native applications.

Each of these features responded to concrete user requests rather than speculative roadmap planning.

Not everything highly requested gets implemented immediately. SSO/OIDC integration, for instance, remains one of the most mentioned feature requests that has yet to be added. Some features require careful consideration of how they fit within the simple deployment model, and whether they serve the core use cases effectively.

Technical Challenges and Solutions

Performance Under Load

Animated images like GIFs turned out to be surprisingly demanding. While static images are straightforward to process, animated content requires handling dozens or hundreds of frames while keeping everything synchronized. Without dedicated GPU acceleration, CPU processing shows, particularly with larger animated files. Caching helps significantly once something’s processed, but that first-time load can still be painful.

Real-Time Features in Simple Deployment

Adding live updates for comments and notifications while maintaining the single-container philosophy presented interesting challenges. The solution involved integrating Mercure for Server-Sent Events, enabling real-time communication without requiring separate message queue services or WebSocket infrastructure. This keeps deployment simple while providing responsive user experiences.

UI/UX Complexity

Getting the interface right has been trickier than I expected. You want something simple enough that anyone can just drag and drop an image, but powerful enough that admins don’t feel limited.

Lessons Learned

Building Slink taught me several lessons about self-hosted software development:

Deployment complexity is a real barrier

Even technical users appreciate simple deployment. The single-container approach, while architecturally imperfect, removes significant friction that would otherwise prevent adoption.

Features I thought were essential proved less important than ones that emerged from actual use. Listening to r/selfhosted discussions and GitHub issues provided clearer direction than any predetermined roadmap. The frequency of feature mentions became a reliable prioritization mechanism.

Performance and simplicity over feature richness

A fast, reliable system with fewer features beats a feature-rich system that’s slow or unreliable. The temptation is always there to add more — every new user will have that one missing feature that would make their workflow perfect. However, I discovered that each addition makes the system heavier and more complex, requiring careful consideration of whether it truly serves the core use cases. This taught me to focus on what matters most while keeping the codebase modular enough to support optional features when they’re genuinely needed.

Current State and Future Considerations

The platform now handles both individual and small community use cases effectively. The focus remains on responding to what users actually need rather than speculative features.

Development continues to be shaped by community feedback. The backlog includes highly-requested features like SSO/OIDC integration, along with numerous smaller improvements and refinements. Prioritization happens transparently — features that appear frequently naturally rise to the top.

The goal remains reducing friction for self-hosted image sharing while evolving based on real user requirements. The project is open source, and contributions are welcome if you want to help shape its future.

For those interested in the technical details or trying it themselves: Demo, Documentation, Source Code.