Selfhosted
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.
-
Posts here are to be centered around self-hosting. Please ensure it is clear in your post how it relates to self-hosting.
-
Don't duplicate the full text of your blog or git here. Just post the link for folks to click.
-
Submission headline should match the article title.
-
No trolling.
-
Promotion posts require your active participation in selfhosting or related communities, or the post will be removed. No more than 10% of your posts or comments may be self-promotional, or your post will be removed. F/LOSS Exception: If your post is about a project that is completely open source & can be self-hosted in full without payment, and your account is at least 30 days old, your post is exempt from this rule as long as you continue to engage in comments.
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!
view the rest of the comments
Can I have the video pushed to a self hosted server (eg NAS or proxmox VM) and just have my android be a client of that server?
In theory, that should be possible. We haven't tested it.
Isn't that the premise of the "$4 ubuntu over droplet deployment" option?
Instead of having Secluso-Deploy ssh into some cloud box and prep it up with the server-side software, why not have a container deployment option as well? I get that you want to ensure that the server is publicly reachable for the mobile clients to work on the go, but ultimately (and in all honesty) at this point, that should be a user concern/choice (those more advanced users may be peculiar about running behind tailscale, a home-VPN, a port-routing config, …).
Needless to say, most people here might find it easier to work with containers and build trust in the project by having it run in an isolated environment with limited permissions than blindly trusting that the code is what it says it is and not quietly running a botnet at digitalocean with their PII attached.
I understand your concern. The way we designed the deployment tool was under the assumption people would be using a freshly-deployed cloud single-use server for it (as we assume they have no technical knowledge).
I'm not sure if a container is foolproof. There have been multiple CVEs in the past allowing processes to escape containers through kernel vulnerabilities. Although, I'm happy to put containers on our to-do list if this will help.
As for what the proper solution should be for advanced users, I personally am not sure. I'd need to research that further. We do try to provide things such as reproducible builds, which means if you build the code yourself using our reproducible build script, they'll match byte-for-byte against our released artifacts. This at least guarantees that it was built from our repository's code, although it does not guarantee the code itself is safe.
I think something that will help here is our planned third-party security audit, which hopefully will be sometime this summer.