I just want to seed torrents. I am not planning to run plex or anything like that. I would like a budget friendly one around $5 to $7.
I’d do as @tal@lemmy.today advised.
I’m suggesting something orthogonal: I’m suggesting specifically rTorrent hosting.
Apparently rTorrent provides the maximum GB served per unit of CPU used, & since seedbox hosting is on such pathetic virtual-machines, this can matter.
_ /\ _
Voiden is an offline-first, git-native API tool built on Markdown - and it very intentionally didn’t start as “let’s build a better Postman”.
Over time, API tooling became heavyweight: cloud dependencies for local work, forced accounts, proprietary formats, and workflows that break the moment you’re offline. Testing a localhost API shouldn’t need an internet connection.
So we asked a simple question: What if an API tool respected how developers already work?
That led to a few core ideas:
Offline-first, no accounts, no telemetry
Git as the source of truth
Specs, tests, and docs living together in Markdown
We opensourced Voiden because extensibility without openness just shifts the bottleneck.
If workflows should be transparent, the tool should be too.
Github : https://github.com/VoidenHQ/voiden
Download here : https://voiden.md/download
Wow, an org mode rest client; this might be worth switching to! What I like about these is that you end up with documentation in a standard file that can live along with your APIs. Org mode can of course be saved either as org files, or exported as any number of things - whatever your team uses. Ok, time to go bully some vim users.
curl is great. I use curl. Most developers use curl. But “you can call an API with curl” and “curl is enough as an API working environment” are two very different claims.
The problem is that real API work is almost never just one request typed into a terminal like some kind of beautifully minimalist Unix haiku. It usually turns into auth, environments, copied headers, reused payload fragments, request chains, documentation, testing, debugging, sharing examples with teammates, reviewing changes in Git, and trying not to break prod because you forgot to swap one token or one base URL.
At that point, people are not really using “just curl” anymore. They are using curl plus shell scripts, plus notes, plus env files, plus copied commands from Slack, plus random JSON files, plus tribal knowledge. Which is fine, until it becomes annoying, fragile, and weirdly hard to collaborate around.
That is the gap Voiden is trying to solve.
So for me it is not “curl vs Voiden.” curl is a low-level execution tool. Voiden is a workspace for actual API work: writing requests, organizing them, reusing pieces, documenting them, testing them, versioning them in Git, and not duplicating the same headers/body/auth setup 45 times like a person slowly losing control of their life.
maintenant looks interesting 🤔
Zero-config auto-discovery for Docker and Kubernetes. Every container is tracked the moment it starts — state changes, health checks, restart loops, log streaming with stdout/stderr demux. Compose projects are auto-grouped. Kubernetes workloads (Deployments, DaemonSets, StatefulSets) are first-class citizens.
config based on labels. sounds good for a moving selfhosting world…
It even includes the update from cosmos-server now (although there’ve been some bugfixes since 0.21.0) 😀
Last year, I was tearing apart some of these fancier pacifiers for adults when I noticed something
When you know you’re going to enjoy the article.
Loaded very quickly for me, just a few seconds. I’m guessing it was overloaded for a bit.
Internet Protocol is the protocol underlying all Internet communications, what lets a packet of information get from one computer on the Internet to another.
Since the beginning of the Internet, Internet Protocol has permitted Computer A to send a packet of information to Computer B, regardless of whether Computer B wants that packet or not. Once Computer B receives the packet, it can decide to discard it or not.
The problem is that Computer B also only has so much bandwidth available to it, and if someone can acquire control over sufficient computers that can act as Computer A, then they can overwhelm Computer B’s bandwidth by having all of these computers send packets of data to Computer B; this is a distributed denial-of-service (DDoS) attack.
Any software running on a computer — a game, pretty much any sort of malware, whatever — normally has enough permission to send information to Computer B. In general, it hasn’t been terribly hard for people to acquire enough computers to perform such a DDoS attack.
There have been, in the past, various routes to try to mitigate this. If Computer B was on a home network or on a business’s local network, then they could ask their Internet service provider to stop sending traffic from a given address to them. This wasn’t ideal in that even some small Internet service providers could be overwhelmed, and trying to filter out good traffic from bad wasn’t necessarily a trivial task, especially for an ISP that didn’t really specialize in this sort of thing.
As far as I can tell, the current norm in 2026 for dealing with DDoSes is basically “use CloudFlare”.
CloudFlare is a large American Content Delivery Network (CDN) company — that is, it has servers in locations around the world that keep identical copies of data, and when a user of a website requests, say, an image for some website using the CDN, instead of the image being returned from a given single fixed server somewhere in the world, they use several tricks to arrange for that content to be provided from a server they control near the user. This sort of thing has generally helped to keep load on international datalinks low (e.g. a user in Australia doesn’t need to touch the submarine cables out of Australia if an Australian CloudFlare server already has the image on a website that they want to see) and to keep them more-responsive for users.
However, CDNs also have a certain level of privacy implications. Large ones can monitor a lot of Internet traffic, see traffic from a user spanning many websites, as so much traffic is routed through them. The original idea behind the Internet was that it would work by having many small organizations that talked to each other in a distributed fashion, rather than having one large company basically monitor and address traffic issues Internet-wide.
A CDN is also a position to cut off traffic from an abusive user relatively-close to the source. A request is routed to its server (relatively near the flooding machine), and so a CDN can choose to simply not forward it. CloudFlare has decided to specialize in this DDoS resistance service, and has become very popular. My understanding — I have not used CloudFlare myself — is that they also have a very low barrier to start using them, see it as a way to start small websites out and then later be a path-of-least-resistance to later provide commercial services to them.
Now, I have no technical issue with CloudFlare, and as far as I know, they’ve conducted themselves appropriately. They solve a real problem, which is not a trivial problem to solve, not as the Internet is structured in 2026.
But.
If DDoSes are a problem that pretty much everyone has to be concerned about and the answer simply becomes “use CloudFlare”, that’s routing an awful lot of Internet traffic through CloudFlare. That’s handing CloudFlare an awful lot of information about what’s happening on the Internet, and giving it a lot of leverage. Certainly the Internet’s creators did not envision the idea of there basically being an “Internet, Incorporated” that was responsible for dealing with these sort of administrative issues.
We could, theoretically, have an Internet that solves the DDoS problem without use of such centralized companies. It could be that a host on the Internet could have control over who sends it traffic to a much greater degree than it does today, have some mechanism to let Computer B say “I don’t want to get traffic from this Computer A for some period of time”, and have routers block this traffic as far back as possible.
This is not a trivial problem. For one, determining that a DDoS is underway and identifying which machines are problematic is something of a specialized task. Software would have to do that, be capable of doing that.
For another, currently there is little security at the Internet Protocol layer, where this sort of thing would need to happen. A host would need to have a way to identify itself as authoritative, responsible for the IP address in question. One doesn’t want some Computer C to blacklist traffic from Computer A to Computer B.
For another, many routers are relatively limited as computers. They are not equipped to maintain a terribly-large table of Computer A, Computer B pairs to blacklist.
However, if something like this does not happen, then my expectation is that we will continue to gradually drift down the path to having a large company controlling much of the traffic on the Internet, simply because we don’t have another great way to deal with a technical limitation inherent to Internet Protocol.
This has become somewhat-more important recently, because various parties who would like to train AIs have been running badly-written Web spiders to aggressively scrape website content for their training corpus, often trying to hide that they are a single party to avoid being blocked. This has acted in many cases as a de facto distributed denial of service attack on many websites, so we’ve had software like Anubis, whose mascot you may have seen on an increasing number of websites, be deployed, in an attempt to try to identify and block these:
We’ve had some instances on the Threadiverse get overwhelmed and become almost unusable under load in recent months from such aggressive Web spiders trying to scrape content. A number of Threadiverse instances disabled their previously-public access and require users to get accounts to view content as a way of mitigating this. In many cases, blocking traffic at the instance is sufficient, because even though the my butt web spiders are aggressive, they aren’t sufficiently so to flood a website’s Internet connection if it simply doesn’t respond to them; something like CloudFlare or Internet Protocol-level support for mitigating DDoS attacks isn’t necessarily required. But it does bring the DDoS issue, something that has always been an issue for the Internet, back to prominent light again in a new way.
It would also solve some other problems. CloudFlare is appropriate for websites, but not all Internet activity is over HTTPS. DoS attacks have happened for a long time — IRC users with disputes (IRC traditionally exposing user IP addresses) would flood each other, for example, and it’d be nice to have a general solution to the problem that isn’t limited to HTTPS.
It could also potentially mitigate DoS attacks more-effectively than do CDNs, since it’d permit pushing a blacklist request further up the network than a CDN datacenter, up to an ISP level.
Thoughts?
Now on that last point, there will indeed come a time when simply using the engineering technique of “making things bigger” won’t work if the attacks become sophisticated enough, but at that point networking will have fully become geopolitical tools (more than they are now).
A Layer-3 (network-layer) blacklist risks cutting off innocent CGNAT and cloud users. What you’re proposing is similar to mechanisms that already exist (e.g., access control lists at the ISP level work by asking computer B which requests it wants to reject and rejecting those that originate from computer A). However, implementing any large-scale blocking effort beyond the endpoint (i.e. telling an unrelated computer C to blackhole all requests from computer A to computer B) would be too computationally expensive for a use case as wide and as precise as “every computer on the Internet”.
Also, in your post you mentioned, “A host would need to have a way to identify itself as authoritative, responsible for the IP address in question.” This already happens in the form of BGP though it doesn’t provide cryptographic proof of ownership unless additional mechanisms are in use (RPKI/ROA).
Hi, it’s me again. I like to think that my endless questions help fuel community engagement to feel less bad :sweat_smile:
So like the title says, I’m interested in running an OPNsense router for my home network so I can do better firewall filtering for both security and privacy (ad-blocking, phoning home, etc.) purposes. I found this video by Dave’s Garage that talks about running OPNsense in Transparent Filtering Bridge mode. I also researched that it’s better to use a switch and APs for any wireless traffic rather than having the router/firewall combo do it, so any hardware suggestions there? Here’s info about my network:
So what Mini PC should I stick with (just 2 ports for WAN & LAN is fine right)? Do I need to avoid any specific brand NICs (do Mediatek cards suck)? What 4-port switch would be good? What wireless AP is recommended? Furthermore, how do you go about running cables in your home? The coax plate that my modem is connected to is literally in the corner of my house. The Wifi is bad in some spots because of this, so we’ve thought about extenders. But if I do my homelab and have a wireless AP, I can just run an Ethernet cable from the switch to a properly placed AP (I guess I’d need PoE then…) right? My mom is afraid of tripping on wires and while I say to just run them along the baseboard, she’s doubting me.
Second Protectli. They are solid little x86 boxes with no moving parts.
Furthermore, how do you go about running cables in your home?
You watch some Youtube videos about how to do it and then you follow the instructions.
It’s going to depend a lot on the construction details of your house: * Do you have wooden framing (common in the US), masonry (common in Europe, as I understand it), or something else? * Do you have access to an attic or basement/crawlspace? * Do you need to run wires on exterior walls (which means dealing with insulation), or just interior ones?
For me (wooden frame construction, accessible attic and basement), I didn’t find it to be too difficult. Is it work? Yeah, of course. But it’s not that bad, and I recommend spending the effort because having proper wall plates wtih in-wall wires is way nicer than having stuff snaking along surfaces.
Hey everyone 👋. I just wanted to share a little personal project that grew a bit more than I initially planned.
The original idea was simply to build a game so I could play Parchis (Ludo) with my family, as it’s a classic in our household. I ended up building the whole thing entirely through “vibecoding” (AI-assisted coding) because I wanted to see how far I could push current my butt tools.
The result is a full web multiplayer game (React/Vite frontend + Node/Express/Socket.io backend with SQLite to store game data).
If anyone is curious or wants to spin it up on their local network to play with friends/family: 🔗 Repo: https://codeberg.org/baner/parchis (it has a docker-compose.yml ready to go in seconds).
⚠️ A big warning about security: As I mentioned, I completely built this relying on AI, and it was initially meant as a home project. *I am not a cybersecurity expert by any means.* While I have briefly exposed it to the internet a couple of times to play with remote relatives, my absolute recommendation is to host it ONLY on your local network (LAN) or behind a VPN (like Tailscale/Wireguard). The nature of AI-generated code means it’s probably full of vulnerabilities that I haven’t caught. Play at your own risk if you decide to open ports to the wild web! 😅
This is also my first project using a monorepo structure and publishing a Docker image for others to deploy. If you take a look and see something horrible (or something that works surprisingly well haha), all feedback is super welcome. I hope someone finds it fun for a local game night!
https://lemmy.zip/pictrs/image/f6530eaa-d644-44fa-b16a-43cc9da22f42.avifhttps://lemmy.zip/pictrs/image/c1565209-1015-4877-8c82-c2e3fae0c616.avifhttps://lemmy.zip/pictrs/image/d6dc5657-becc-4cf0-904b-ec1e14be7566.avifhttps://lemmy.zip/pictrs/image/7b9ac290-016c-4529-b6cb-cb0a8cd2c2fe.avifhttps://lemmy.zip/pictrs/image/ccf41f63-5f49-4c6a-99e2-8d23cb8bb42d.avifhttps://lemmy.zip/pictrs/image/d1072de0-036a-4358-adb9-e2bc5cbfca02.avifhttps://lemmy.zip/pictrs/image/1b09e506-5d7e-441d-8adb-bcbac4de3d61.avifhttps://lemmy.zip/pictrs/image/f28c7aee-6253-456c-a94b-7625881923d1.avif
This project seems pretty neat! I appreciate that you are upfront that it is AI-assisted (some projects don’t do that and get grilled for it), I might check it out!
Thanks, I have tried to follow best security practices on this like using JWT for authentication, sanitize all inputs for SQL injections, password hashing, etc. Still better to be cautious, project still need some fixes but not affecting the overall gameplay. Right now I am working on documentation. It can be played as a guest but creating an account allows the game to track stats about win, lost, captures, XPs and a lot more. is mobile friendly, there is an android app but is not part of the repository at this time. make sure to share back your experience if you check it out.
I run a SearXNG instance and rate limiting has never been a issue until now. so i wanted to ask what the cheapest and most privacy respecting vpn/proxys are to use.
Are you the only user of this searxng?
no
Hello!
I’ve been playing around with self-hosting for a while now and I’ve started moving over to a VPS. At home I have a PC that’s on more or less 24⁄7 with an *arr stack, jellyfin and some other services. They can only be accessed through Netbird. The services aren’t that important, the data doesn’t really need to be backed up since it’s not very important. On the VPS, however, I would like to host some more critical services, such as:
I want them available 24⁄7, even if I decide to distrohop and wipe my PC at home. The problem is how to structure all this. My current idea is to run Gitea and Overleaf out in the open behind some reverse proxy without authentication (Nginx or Nginx Proxy Manager). I’d like Vaultwarden and Immich to be on the same VPS, but, I don’t want those services to be accessible to anyone but me, so I’d need some form of ACL or authentication system. I’m thinking of using Netbird for this, since I already use it on all of my devices.
So I would set up DNS records from within Netbird that would point immich.domain.tld and vaultwarden.domain.tld to the internal Netbird IP of the VPS. In the reverse proxy, I’d set up access control such that it only redirects the Netbird IP range to those services. On Cloudflare, I’d point git.domain.tld to the external IP of the VPS with proxy enabled.
Everything would receive HTTPS certificates, and I’d block incoming traffic on every port except for 80 and 443.
Is this a good setup? Any tips or recommendations? Any pitfalls?
Thanks!
@versionc
Nice setup, pretty close to what I run. Few thoughts:
Reverse proxy + auth: I'd look at Traefik over Nginx Proxy Manager - it plays really well with Docker (auto-discovers containers, handles Let's Encrypt certs). For the auth layer on Vaultwarden/Immich, consider Authentik instead of tying it to Netbird. Gives you SSO across everything and you're not locked into one VPN mesh for access control. I run Authentik in front of most of my services and it's been solid (minus the time I accidentally deleted its secrets and locked myself out of everything - back up your auth server config).
Netbird approach: Using Netbird IP ranges for access control on the reverse proxy can work, but it's a bit fragile. You're coupling your network topology to your auth policy. If Netbird changes IPs or you add a device, you're editing nginx configs. A proper auth proxy in front gives you more flexibility.
Gitea / Forgejo: I'd also recommend checking out Forgejo if you haven't - it's a community fork of Gitea that's been moving faster and stays fully open. I ran Gitea for years before switching. Either way, I'd push back on running it without auth entirely. Even for public repos, you want auth on the admin/write side. Forgejo (and Gitea) support public repos with anonymous read access - you don't need to skip auth, just configure repo visibility. The built-in controls are solid enough.
General structure: Your instinct to keep critical services (Vaultwarden especially) off the public internet is right. Password manager should have the smallest attack surface possible. The VPS-as-entry-point pattern is good. I do the same thing with a cheap VPS running a reverse tunnel so my home IP is never exposed.
One thing to think about: if you wipe your home PC, make sure your VPS services can stand alone. Docker volumes + a backup strategy (even just weekly to cheap cloud storage) will save you when something goes sideways.
