Slink: A Self-Hosted Image Sharing Service Built on Symfony and SvelteKit
Self-hosted image sharing service
At a glance
- What is it?
- Slink is an AGPL-3.0 image sharing platform you host yourself, with private-by-default share links, password and expiry controls, and local, SMB or S3 storage. It fits teams that want a link-based image workflow without a third-party host, but the documentation is the only source of operational detail here.
- Who is it for?
- Adopt Slink if you want image sharing behind your own domain, with per-share passwords, expiry, and a choice of local, SMB or S3 storage, and you are willing to run a PHP and SvelteKit application plus its database. Do not adopt it if you need a single static binary, or if you cannot accept AGPL-3.0 obligations for modified network-facing deployments.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly PHP, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Slink fills between a chat attachment and a public image host
Sending an image to a group usually means either attaching it to a message, where it gets recompressed and buried, or uploading it to a third-party host, where the link is public and the retention policy is someone else's. Slink is aimed at the middle of that range. The README describes it as "a powerful self-hosted image sharing platform designed to give users complete control over their media sharing experience," and the feature list backs that up with per-share passwords, expiry dates, and a share management page for listing, editing, publishing or revoking links.
The intended audiences named in the README are artists showing work in a community-oriented gallery, developers hosting screenshots for GitHub, portfolios and blogs, and anyone who wants to control image privacy and hosting. That last group is broad, but the concrete use case is narrow enough: you have images, you want a URL that only the holder can open, and you want that URL to stop working on a date you choose. Guest upload and ShareX integration extend this to people who never create an account, which matters for a screenshot workflow where the upload should happen from a hotkey rather than a browser tab.
Share links, storage providers and the PHP plus SvelteKit split
Slink is built with Symfony on the server and SvelteKit on the client, according to the README. That split is visible in the feature set: the server owns authentication, the public API, storage providers and moderation, while the client handles upload progress, list and grid views of upload history, dark mode and the multi-language interface. The README lists nine UI languages, including English, German, Spanish, French, Italian, Japanese, Polish, Ukrainian and Chinese.
The mechanism that matters most is the share. Every share is private by default, and access is granted only to whoever holds the link. On top of that default you can add a password, set an expiration so the share auto-revokes, or group images into a collection and share the whole set through one link. URL shortening is offered for easier sharing, though the README does not say whether short links are generated internally or through an external service, so treat that as unverified.
Storage is pluggable. The README names local, SMB and AWS S3 as supported providers, and there is a separate storage usage tracking feature plus an admin view for managing storage. Deduplication happens at upload time: the system detects duplicate images and notifies the user rather than silently storing a second copy. That check runs before or during the upload, but the README does not describe the hashing method or whether deduplication is global across users or scoped per account. If you plan to run Slink for a large group, that distinction changes your storage math considerably.
What the README actually tells you about running it
The repository ships a Docker image, referenced in the README badges as anirdev/slink, and the documentation site is split into installation, configuration, storage provider support and security pages. The installation guide lives at docs.slinkapp.io/getting-started/02-quick-start/ and the configuration reference at docs.slinkapp.io/configuration/01-environment-variables/. The README itself does not print a docker run command or a compose file, so the exact invocation has to come from those pages rather than from this article.
What you can plan around from the README alone: the application is PHP with a SvelteKit front end, it supports SSO through OIDC providers including Google, Authentik, Keycloak, Authelia and Pocket ID, and it exposes a public API with personal API keys. There is also user approval, which means you can require that an account be approved before it can upload. Configuration is environment-variable driven, which is the standard shape for a container deployment, but the variable names are not in the README. Anyone writing a deployment manifest should pull them from the configuration page and pin the image tag rather than tracking latest, because the release history shows a steady cadence of patch releases: v1.12.3, then v1.13.0, then v1.13.1 within roughly six weeks.
Where Slink is the wrong tool, and what the asterisks hide
The upload format list is the first place to slow down. The README lists PNG, JPG, WEBP, SVG, BMP, ICO, GIF, AVIF, HEIC and TIFF, but HEIC and TIFF both carry an asterisk. The README does not explain the asterisk. It could mean conditional support, an optional dependency, or a caveat about browser-side rendering. If your users upload from iPhones, HEIC is not an edge case, it is the default, so that asterisk is the difference between a working deployment and a support queue. Verify it against the documentation before you promise anything.
The second limitation is operational weight. Slink is a full web application with a database, a PHP runtime and a Node-built front end, plus optional S3 or SMB storage. That is a reasonable footprint for a team already running containers, and an unreasonable one for a single user who wants to drop a binary on a VPS and forget it. There is no mention of a static build or a serverless deployment path in the README.
The third is moderation. Slink includes image moderation, admin control over visibility, and an Explore page where publicly visible images can be browsed. The moment you enable public sharing and guest upload, you own a content surface. The README gives you the controls but not a policy. That is a decision you make, not a feature you install.
How Slink differs from a general file-sharing server
The obvious comparison is a self-hosted file sync and share suite, the kind that presents a folder tree and hands out links to files. Slink is not that. Its unit is the image, and the features are built around image-specific concerns: compression on upload, deduplication, nested tags for organization, collections, bookmarks, comments on public images, and notifications when someone interacts with your uploads.
The practical difference shows up in the share model. A file-sharing server typically exposes a path and layers permissions on top of it. Slink inverts that: shares are private by default, and the link is the credential, with an optional password and an optional expiry on top. There is no folder tree to browse in the README's description, and no mention of WebDAV or desktop sync clients. If your workflow is "mount a drive and drag files," Slink is the wrong shape. If your workflow is "produce a URL that expires," it is the right one.
The other difference is the API and integration surface. ShareX integration and personal API keys are first-class here, which is what you would expect from a project whose README names developers sharing screenshots as a target audience.
Licence, upgrade cadence and the cost of staying current
Slink is licensed under AGPL-3.0, stated in the README and in the LICENSE file. The practical consequence, stated plainly and without legal advice: if you modify Slink and let users interact with it over a network, the AGPL's source-availability condition is generally understood to apply to your modified version. Running an unmodified image for internal use is the simple case. Forking it into a product is the case where you should talk to someone qualified rather than reading a review.
The upgrade cost is visible in the release cadence. Three releases appear in the recent list over about six weeks, two of them patch versions. That pattern suggests active maintenance and also suggests that pinning a specific tag and reading the release notes before moving is the sane approach. The README does not mention database migration tooling or a documented downgrade path, so a rollback plan is on you.
There is no stated commercial support tier, no hosted option mentioned in the README, and no pricing page. The live demo at demo.slinkapp.io exists for evaluation, but the README does not describe what data it holds or how often it resets, so do not treat it as a staging environment.
Who should run Slink and what to confirm first
Slink fits a small team, a studio, or an individual who already runs containers and wants image links under their own domain. The combination of private-by-default shares, password and expiry controls, OIDC login, and a choice of local, SMB or S3 storage covers the requirements that usually push people toward a hosted image service in the first place. The public API and ShareX integration make it usable from a screenshot hotkey, which is the workflow the README explicitly targets.
It does not fit someone who wants zero moving parts, or someone who needs a general-purpose file share with sync clients, or anyone who cannot take on AGPL-3.0 obligations for a modified deployment. It also does not fit a deployment where HEIC uploads are guaranteed, until the asterisk in the README is resolved.
Before deploying, confirm three things against docs.slinkapp.io: the exact environment variable names on the configuration page, the storage provider setup for whichever backend you choose, and the meaning of the HEIC and TIFF asterisks in the format list. Then pin a tag from the release list rather than pulling latest, and read the release notes for the version you land on. The repository's last push and its most recent tagged release are close together, which is the signal that matters here: the project is being maintained, and the maintenance is the thing you are signing up to track.
Editorial conclusion
Adopt Slink if you want image sharing behind your own domain, with per-share passwords, expiry, and a choice of local, SMB or S3 storage, and you are willing to run a PHP and SvelteKit application plus its database. Do not adopt it if you need a single static binary, or if you cannot accept AGPL-3.0 obligations for modified network-facing deployments. Before committing, verify the exact image tag and environment variable names against docs.slinkapp.io, and confirm that the HEIC and TIFF support marked with asterisks in the README covers the files you actually receive.
Community notes