I am lazy and just use .htaccess
this post was submitted on 31 Aug 2025
106 points (93.4% liked)
Selfhosted
51125 readers
1087 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 2 years ago
MODERATORS
Looks like a good project, but I genuinely don't quite get why Rust projects feel the need to advertise "written in Rust" as a feature. Do you find that a lot of users care which programming language your app is written in? Does it help with finding contributors?
I don't know which programming language most of my self-hosted apps use, and I don't mind since they all work well and do their job.
As an information security professional and someone who works on tiny, embedded systems, knowing that a project is written in Rust is a huge enticement. I wish more projects written in Rust advertised this fact!
Benefits of Rust projects—from my perspective:
- Don't have to worry about the biggest, most common security flaws. Rust projects can still have security flaws (anything can) but it's much less likely for certain categories of flaws.
- Super easy to build stuff from scratch. Rust's crates ecosystem is fantastic! Especially in the world of embedded where it's a godsend compared to dealing with C/C++ libraries.
- It's probably super low overhead and really fast (because Rust stuff just tends to be like that due to the nature of the language and that special way the borrow checker bitches at you when you make poor programming choices haha).
- It's probably cross-platform or trivially made cross-platform.
Thanks, this is a good insight.
People who are into systems languages would care and for newer languages the more people advertise their usage the more mainstream it becomes and then bigger more traditional companies would consider using it and that would help increase the size of that languages ecosystem and community so I'm okay with people adding written in Rust to their project descriptions
Imo, it's nice to see tools written in a memory safe systems language
Especially if you use a lot of them. More utility, less attack surface
This makes sense! You get the same advantage if the app uses Go or C# though, and both of those can compile to a single statically-linked executable too.
If it's written in C# that's a huge turn-off though because that means it's likely to only run on Windows.
I mean, in theory, it could run on Linux but that's a very rare situation. Almost everything ever written in C# uses Windows-specific APIs and basically no one installs the C# runtime on Linux anymore. It's both enormous and a pain in the ass to get working properly for any given C# project.
That's a very old way of thinking of things. C# has been cross platform for a long time.
Almost everything ever written in C# uses Windows-specific APIs
Not really. Most C# apps use .NET (since the framework and standard library is quite feature-rich) rather than direct Win32 calls, and .NET is cross-platform. A lot of web services are written in C# and deployed to Linux servers.
basically no one installs the C# runtime on Linux anymore
You can compile a C# app to a single executable that doesn't require the framework to be installed.
Are you running Jellyfin, the *arr suite, slskd, or Technitium DNS? They're all written in C#.
I mean, for myself personally if it were written in NodeJS or Python or something I'd be less interested.
And I don't even care about Rust. It's just that everything and their sister is written in NodeJS and Python. I say this as someone who founded a company that uses Python.
Also the more I hear about actual Rust adoption the more willing I am to consider it for the next big thing.
if it were written in NodeJS or Python or something I'd be less interested.
Does it matter if it's running in Docker and the container is lightweight (say less than 50MB), though? I like apps being written in a language I know well so I can contribute if needed, but other than that, I mostly treat a Docker image as a black box.
That'd be awesome. Unfortunately most of my experience (and I realize that is my experience) has so many packages dependencies that 50MB is impossible.
Don't get me wrong, I am proficient in JS/TS so being able to work handily in NodeJS is great, less context switching, but I feel like so many companies I contract for just jam a square peg into a round hole because - and it just makes things painful.
Yeah it's definitely not possible to reach 50MB with a Node.js Docker image, but <150MB should be doable with a distroless base image + compiling the app into one JS file (for example, using Parcel or esbuild).
It's possible to reach ~50-60MB Docker image with a C# app. Rust and Go definitely produce more compact binaries though.
It's just a way to advertise, I think. I've found myself putting more trust in projects written in Rust or Go, than say, JavaScript.
It's advertising the inherent safety that comes from Rust and Go having errors as values. They're just fundamentally better languages.
I love projects like this. Do one thing, super well, without adding a kajillion dependencies. I love the vanilla HTML / CSS approach.
Thank you for the kind words.
Won't lie, the main reason that I stuck to a vanilla frontend approach is because I didn't know what else to do. I've never been a frontend dev, and never wish to be one. So I looked at an older project, and started by trying to replicate it. In hindsight, it was probably a good decision. The backend is more intentional though, and I do try to keep things simple and clean.
The name is a dead ringer for a Bengali coder 🤝
At least it’s not JiaTan
Would you like my custom xz tool?
Certainly, pull in some weird shit in the build process too.
শুনে ভালো লাগলো যে এটা কারো চোখে পড়েছে। নয়তো সবাইকে বোঝাতে হয় কি নাম, কেন নাম। আসলে বাঙালী প্রোগ্রামার খুব বেশি চিনি না।
Amar toh ekbaare chokhe poreche 😁
Bangali "hobby" programmer khub kom i ache. Beshir bhag IT company te ache, aar shudhu kaaj er jonnoi joto ta programming dorkar pore, kore.
Fediverse e arek bangali dekhe khub i bhalo laagche 🤝🤝
I'm already aware of a few small UI oddities. There were quite a few changes in the frontend, so I kind of expect these. Please let me know if you see anything weird. You can comment here, or open a bug report. I expect to do a patch release by tomorrow.
I am digging this, thanks for keeping it updated and improving it!
I see that you say it's feature complete / no user stuff; but it'd really mesh well if it took OIDC authentication. Don't need it to make users or anything, just instead of the password popup the OIDC provider is asked for confirmation that whatever user registered with the OIDC is logged in. That'd let me leverage extra 2FA protection from the OIDC provider and juice on that one-login life.
Now I have no experience making OIDC crap work nor how it even works behind the scenes, so I can't help :( sorry; just wishful thinking.
Also saw on your github - hope our newly shit-out gestapo don't bother you!
I don't understand much about OIDC either. But I'll keep it in mind. Thanks.
This would require configuration with a whitelist of which OIDC IdPs to trust. Otherwise anybody could self-authorise a OIDC token (using their own IdP) and use that to log in.
Hmm, so that might be out of scope here. But I can try to do some kind of 2FA, shouldn't be much of an issue, really. It's just that I never thought a link shortener needed 2FA protection since the links will be publicly shared anyway.
I agree with you, a simple minimal url-shortener does not need 2FA.
Yes that tracks with how OIDC setup works with my other services (you give the container the OIDC links and shared secrets so it knows how to talk to the OIDC and trust it).
Looks nice, thank you :]
Software typically has features because people want them, so unnecessary is utterly relative
Unnecessary to me, I guess.
I've been using your application for my services for almost a month now, though I just have one redirect link at the moment. I just forgot about it after the setup, although you could consider it to be a sign of a good product?
I wish if there could be additional analytics or logs for the links like a timeline, unique + existing visitors etc, however I completely understand if they cannot be implemented for the sake of keeping the app simple. Thanks for your service regardless!
I'm happy that you like it. Any kind of analytics or logging is decidedly against my stated policy for this project, so I won't be adding it. But I understand that some might need it, and in that case, one should look at more comprehensive solutions like YOURLS.