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.
No low-effort posts. This is subjective and will largely be determined by the community member reports.
Resources:
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
Lots of good advice here. Something I did was make a base Debian VM that has common tasks already done- my network configs, docker installed (but not enabled), the guest agent installed, ssh root password login (until I'm done setting it up). When I want to try something, I clone the base vm, change the IP, enable docker if it needs it. Set up my new services, copy ssh id, disable ssh password.
Try to stick to the same disto and you give KSM a better chance of reducing memory usage.
b) Should it be headless?
As most people have said, typically a server is headless as it has less overhead. But it's going to depend on your use-case and needs. If you have the spare ram/cpu/disk and want to put a GUI on every VM you can. In my case, most of my VMs are headless with a couple that have a GUI out of necessity.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:
| Fewer Letters | More Letters |
|---|---|
| DNS | Domain Name Service/System |
| IP | Internet Protocol |
| LXC | Linux Containers |
| SSH | Secure Shell for remote terminal access |
4 acronyms in this thread; the most compressed thread commented on today has 15 acronyms.
[Thread #168 for this sub, first seen 27th Sep 2023, 10:35] [FAQ] [Full list] [Contact] [Source code]
Do you actually need a VM for your use case? You might use docker containers or LXC instead.
Normally I use VMs for situations where a container isn't available (Windows, openwrt) or the VM is better supported (arguably home assistant).
This indeed. To OP: if you use LXC containers using templates that Proxmox provides, they are headless by default. A Gui is a waste of resources.
I realize I’m being pedantic, but aren’t docker containers essentially just wrapped VMs?
Docker containers are more like LXCs—in fact, early versions of Docker used LXC under the hood, but the project diverged over time and support for LXC was eventually dropped as they switched to their own container runtime.
Nope. Docker containers are kind of "virtual filesystems" and programs are running on top of the host's kernel. They're just isolated processes running on their own volume - to which you can also attach external "volumes".
Usually it’s handy to have a display during initial setup and cfg. Also, with x windows port forwarding … you access your server gui over a network like god intended :)
In proxmox, especially if you are running a bunch of services (and not virtual desktops) it much better to set up an automated way of creating a cloud-init template.
You can run the script every now and then to download an updated image, load up some sensible defaults, then create a template of the VM.
After that, you just clone the template, resize drives, tweak hardware settings, adjust any cloud-init settings, then boot the VM.
It takes a while to sort out the script, after which you get consistent up-to-date cloud-init enabled templates.
Then it's like 2 minutes to clone and configure a VM from proxmox's web-gui.
And you always get consistent ready-to-go VMs.
You can even do it via CLI, so you could ansible/terraform the whole process
For sure.
My point was more … first time, ever, you boot a raw device, a display can be handy unless you know what you are doing. Once it survives a reboot…
After that, if you need a GUI — just run an x windows server on your main rig; interact with your remote server as the client without the need of a display.
I run Debian on all my vms, they have no GUI installed at all. I manage all of them over SSH
Yes, that is what i am used to.
I guess headless is better for performance and i do not see an advantage at all.
Another question: Why do you have several debians-vm's? You also could take one, right?
I use multiple VMs, and group things either by security layer or by purpose.
When organising by purpose, I have a VM for reverse proxies. Then I have a VM for middleware/services. Another VM (or multiple) for database(s). Another VM for backend/daemon type things.
Most of them end up running docker, but still.
Lets me tightly control access between layers of the application (if the reverse proxy gets pwnd, the damage is hopefully contained there. If they get through that, the only get to the middleware. Ideally the database is well protected. Of course, none of that really matters when there's a bug in my middleware code!)
Another way to do it is by purpose.
Say you have a media server things, network management things, CCTV things, productivity apps etc.
Grouping all the media server things in a VM means your DNS or whatever doesn't die when you wiff an update to the media server. Or you don't lose your CCTV when you somehow link it's storage directory into the media server then accidentally delete it.
If that makes sense.
Another way might be by backup strategy.
A database hopefully has point in time backup/recovery systems in place. Whereas a reverse proxy is just some config (hopefully stored on GitHub) and can easily be rebuilt from scratch.
So you could also separate things by how "live" the data is, or how often something is backed up, or how often something gets reconfigured/tweaked/updated.
I use VMs to section things out accordingly.
Takes a few extra GB of storage/memory, has a minor performance impact. But it limits the amount of damage my dumb ass can do.
I run a vm for each service, a php vm, a mysql vm, etc. But yes you could just have a big vm run everything
At that point why even run proxmox.